转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese

HTTP的问题可能是由于慢速服务器或客户端，TCP性能问题，本文讨论上述问题以及其他可能因素。

诊断过程:

浏览网页性能变差的原因有很多，需要逐步分析。步骤如下：

1. 首先，不仅要确认网络负载状况，还要注意通信链路上的出错率，以及导致性能变差的最明显的表现；
2. 诊断TCP问题，检查以下细节：

• 在Expert info窗口，确保没有太多重传以及重复ACK（百分之0.5至0.8尚可忍受）。
• 确保HTTP连接上没有reset，可能由于防火墙或站点限制引发。

   3.  确保没有以下DNS问题：

• 慢速响应时间
• 域名未找到

如果以上均不适用，就需要对HTTP深入研究。

注意：将网络和IT环境看作一个整体。对于慢速网络浏览应用，TCP问题亦不能分离于HTTP，DNS问题。可能是由于慢速HTTP服务器，因服务器的慢速响应而产生了TCP重传。或者，由于DNS慢速服务器，打开网页可能需要好几秒钟。一步步定位问题就好了。

当你第一次打开一个网页，可能需要几秒钟。在这种情况下，应当查看以下情况：

1. 检查线路是否过载
2. 检查线路延时（通过ping工具）
3. 查看错误代码，通常能看到浏览器报错原因，但并不总是能看到。
4. 配置过滤器http.response >= 400并查看有多少错误。以下章节，你会看到需要注意的示例。

Informational codes：

Success codes：

Redirect codes：

Network Analysis Using Wireshark Cookbook

转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese

通常来说，数据库，应用和网络在IT架构中处于不同的分支。数据库的故障排查由DBA来完成，但是网络工程师仍可以从抓包中定位出问题并不出自网络。当IT抱怨“网速慢”，实际并不一定是这样。下文帮助我们验证所谓“网速慢”的问题。

工作过程:

对于数据库问题，按照以下步骤：

1. 当怀疑是“慢速网络响应”时，问以下问题：

• 问题发生于本地还是全局？是只发生在远端办公室，还是center也有发生？如果整个网络都出现问题，就不会是WAN带宽问题。
• 对于所有客户端是否都发生了这样的问题？如果只是某些特定用户碰到问题，则可能是这些用户运行了某些应用导致。
• 客户端和服务器之间通讯链路是否过载？导致过载的应用是什么？
• 是所有应用都运行缓慢，还是使用特定数据库的应用运行缓慢？是PC比较老旧，还是服务器资源耗尽?

   2.  搞清楚上述问题之后，开始故障排查：

     1.  打开Wireshark开始抓包。可以将对端端口连到PC，服务器，VLAN，或连接远端客户端的路由器。

     2.  在expert info中查看TCP事件。这些事件发生在整个通信链路，或是特定的IP地址，还是特定的TCP端口？此操作能够帮助定位问题并验证是否发生于特定链路，服务器，或是应用。测试连接到Internet的数据流时，可能会得到发往站点或mail server（诸如此类）的很多重传以及重复ACK。在组织内部，重传范围应当在百分之0.1至0.5。连接到Internet时，可能会高得多。

   3.  当你看到网络上有问题时，按照前几张的故障排查步骤给予解决。但是，也有些网络问题会影响数据库操作。下例中，可看到客户端与服务器通信链路往返延时达到35至40ms。

     1.  我们查看TCP stream 8（1），连接开始于TCP SYN/SYN-ACK/ACK。如下图（2）所示。可以看到整个连接花费了371个报文（3）。

     2.  连接继续，可见到DB请求与响应之间时间间隔大约35ms。

     3.  由于往返已经有371个报文，371X35 ms大约是13秒。加上可能发生一些重传导致延时，用户查询一次数据库可能要等待10至15秒。

     4.  这种情况下，应当与DBA讨论怎样大幅减少网络上传输的报文数量，或是改变终端服务器或网络接入的方式。

   4.  另一个可能发生的问题是抓包文件反映出有软件问题。以下截图中可看到5个重传（1），并且客户端打开了一个新的连接（3）。看起来像一个TCP问题但只发生在软件中一个特定窗口。这只是由于一个软件进程停止运行，因此TCP无法对客户端作出响应（2）。

更多建议：

右键数据库客户端与服务器会话报文，会打开一个窗口，有助于DBA查看网络问题。当碰到延时问题时，例如，通过移动电话接入Internet，数据库客户端到服务器的通讯可能效率低下。可能需要切换接入方式。

很重要的一点是搞清楚数据库的工作模式。如果客户端正在接入数据库服务器，数据库服务器正在使用从另一台服务器共享的文件，可能客户端——服务器工作良好，但问题可能出在数据库服务器与文件服务器之间共享文件上。确保在开始测试之前确知所有依赖条件。

最重要的是，与DBA保持良好关系。

Network Analysis Using Wireshark Cookbook

转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese

因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。

DNS基础:

DNS命名空间是一个分层结构，类似于Unix文件系统。如下图的分层空间所示。

每个节点都有一个标签，最多可以有63个字符。树结构的根部是一个特殊的标签为null的节点。树结构中节点的域名就是一串标签列表，从该节点开始，一直到根节点，通过dot来将标签分开。（这是与Unix文件系统不同的地方，将路径名放在最前沿着树结构下来）。树结构中的每一个节点必须有一个唯一的域名，但是树结构中不同的point可以有相同的标签。

域名分为绝对域名与相对域名。绝对域名也称为完全合格的域名FQDN(Full Qualified Domain Name)，它是以“.”结尾的域名，例如sun.tuc.noao.edu.。如果不以“.”结尾，则假设该域名需要被补充完整。域名如何补充则取决于使用的DNS软件。

顶级域名分为三个区域：

1. arpa是用来做反向域名解析的特殊域。
2. 七个3字母域名称为普通域名，也有称为组织域。
3. 所有两个字母域名是基于ISO 3166国家代码，称为国家域名或地理域名。

上图中没有显示的很重要的一点是DNS中责任的分派。没有一个单一的实体来管理树中的每一个标签。相反，一个实体（网卡）维持树中的一部分（顶级域名）并将其他责任分配给zone中其他实体。

zone指DNS树中分开管理的子树。例如，二级域名就是一个常见的zone，noao.edu。很多二级域名又分为更小的zone。例如，一所大学按照系别，公司按照部门分为分为更小的zone。

熟悉Unix文件系统的会注意到DNS树按zone分区很像逻辑Unix文件系统分为物理磁盘分区。如同我们从上图中无法看出zone的委托授权管理位于何处，从Unix文件系统的类似图中也难以看出哪个目录在哪个磁盘分区上。

一旦zone的委托授权分派好，zone的负责人需要为其提供多个域名服务器。当zone中安装了新的机器，zone的DNS管理员为其分配域名与IP地址，并将信息输入域名服务器的数据库中。域名服务器委托授权管理一个或多个zone。zone管理人员必须为其提供一台主域名服务器以及一个或多个二级域名服务器。主服务器和二级服务器必须相互独立并冗余，以使zone不会受到单点故障的影响。主服务器和二级服务器的区别在于，主服务器从磁盘文件加载zone的所有信息，而二级服务器从主服务器获取所有信息。这一过程称为zone transfer。

当新的机器添加到zone中，管理员将合适的信息（至少需要名称和IP地址）添加到主服务器系统的磁盘文件中。之后告知主域名服务器重新读取自己的配置文件。二级服务器定期查询（通常3小时一次），如果主服务器有新的数据，二级服务器通过zone transfer来获取。

当域名服务器没有所需信息时怎么办呢？它必须联系另外一台域名服务器。这是DNS的分布式特性。并不是每一台服务器都知道如何联系其他域名服务器，但每一台服务器都知道如何联系根域名服务器。根服务器的IP地址存放于主服务器的配置文件中。主服务器必须知道根服务器的IP地址，而非DNS名。之后，主服务器获知所有二级域名服务器的名称和位置（即IP地址）。整个交互过程是：发起请求的域名服务器必须联系根服务器，根服务器告知请求服务器联系另外一台服务器，这样逐级进行。

DNS的一个基本属性是缓存。即，当一个域名服务器收到一条映射信息（如一个主机名的IP地址），它会将该信息放入缓存，以使之后的查询可以使用缓存后的结果，而无需额外发起对其他服务器的查询。

转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese

动态主机设置协议（Dynamic Host Configuration Protocol, DHCP）是一个局域网的网络协议，使用UDP协议工作，主要有两个用途：

·         给内部网络或网络服务供应商自动分配IP地址给用户

·         给内部网络管理员作为对所有电脑作中央管理的手段

本文介绍DHCP的工作原理。

DHCP工作原理:

DHCP从一个IP地址池中提供IP地址，该池有DHCP服务器数据库定义，称为scope。如果客户端接受这一地址，则它可在一个预定义的期限内使用该地址，称为租约。如果客户端无法从DHCP服务器获取IP地址，它就无法正常初始化TCP/IP。

在DHCP为客户端配置TCP/IP参数时，DHCP服务器和客户端都需要经历四步过程。注意到很多通讯是通过广播的方式来完成的。如果路由器无法转发这些DHCP消息时，广播通信可能会造成问题。

当客户端处于以下四种状态之一时，必须使用IP租约进程：

• 配置使用DHCP的客户端第一次初始化TCP/IP；
• 客户端请求特定的IP地址但服务器拒绝了该地址，在DHCP丢弃租约时即会发生。
• 客户端之前租约了一个IP地址，但之后释放了该IP地址，现申请一个新的租约。这种情况发生于用户输入ipconfig /release和ipconfig /renew命令时。

客户机请求IP地址（DHCPDISCOVER）:

当一个IPv4客户机启动时监测到需要IP地址，它会初始化一个TCP/IP的限制版本，之后广播一个报文请求寻找DHCP服务器的地址。该广播报文告知监听服务器客户端需要IP地址信息。DHCP客户端发送的报文这一阶段包括租约请求，客户端源地址，0.0.0.0，目的地址，即广播地址255.255.255.255。报文也包括客户端硬件MAC地址和机器名，该信息也指明了向DHCP服务器发起请求的设备。

客户端向DHCP服务器发送请求IP地址的真实报文称为DHCPDISCOVER报文。网络上每一台安装了TCP/IP协议的主机都会接收到这种广播信息，但只有DHCP服务器才会做出响应。

服务器提供IP地址（DHCPOFFER）:

所有拥有有效IP地址的DHCP服务器都会向DHCP客户端提供IP地址信息。它响应以地址池中一个未分配的IP地址供请求主机使用。要能够响应DHCPDISCOVER报文，DHCP服务器必须拥有客户端的有效IP配置信息。DHCP服务器回复的DHCPOFFER报文包含以下信息：

• 客户端的硬件地址
• 提供的IP地址
• 合适的子网掩码
• 租约有效期
• 服务器ID，即DHCP服务器的IP地址

客户机选择IP地址（DHCPREQUEST）：

DHCP客户端选择它所接收到的第一个DHCPOFFER报文提供的IP地址。之后，它把这一信息广播至网络。该报文中，客户端请求服务器提供给它的IP地址。这是因为客户端可能收到不止一个DHCP服务器发送的offer。通过广播这一请求，客户端告知其他DHCP服务器不会再接受其他offer。为了进一步确保客户端接受的服务器offer没有疑义，DHCPREQUEST报文中还包含以下信息：

• 提供所接受offer的服务器IP地址
• 客户端硬件地址
• 客户端接受的IP地址

服务器确认IP租约（DHCPACK）：

DHCP服务器对客户端作出响应，将IP地址分配给客户端。之后，它发送DHCPACK确认信息给客户端。该信息包含IP地址的有效租约以及其他配置信息。

有时，在客户端接收服务器提供的租约后，DHCP租约请求仍可能不成功。可能有以下几种情况：

• 由于客户端移动至其他子网，IP地址无效
• 客户端尝试租约它之前的IP地址但该IP地址不再可用

在上述情况下，服务器会发送一条不成功信息DHCPNACK。收到DHCPNACK的客户端必须重新开始整个DHCP初始化进程。也就是说，它必须发送另一个DHCPDISCOVER报文查找新的IP地址。