网络 | 网络问题分析定位方法

一、背景

  在日常工作中不可避免碰到各种网络问题，有些问题的定位和处理可能花费较多时间。快速定位和解决网络问题可以加快开发测试环境的建立。此外，合理使用一些网络诊断工具甚至可以帮助开发测试人员理解程序运行过程，为解决问题提供思路，因此有必要对其进行总结。
  本文是在交易系统及其业务系统日常的开发、测试过程中，针对网络问题排障的经验总结。旨在通过简单有效的工具，定位网络问题所在的层次，以帮助开发、测试和运维人员快速部署环境，提高工作效率。

二、网络模型简介和分析过程

  在OSI网络模型中，可按不同层次粗分为五个层次，分别是物理层、数据链路层、网络层、传输层和应用层。在各层中都有相应的协议完成对应的功能，具体可总结为下表。

image.png

  虽然网络模型相对而言比较复杂，且设备种类和配置项多，定位问题需要一定的基础知识和经验，但在实际排查问题过程中，可以通过简单的工具进行测试，大致判断出问题属于模型中的哪一层，然后使用具体的分析工具或者寻求相应岗位的支持。
  可以看到，网络层位于五层模型最中间，且该层提供了日常应用中最常见的工具，如ping命令等。因此，从网络层入手排查问题通常是一个不错的选择，可以将问题限定在下面三层或者上面两层。
  例如，如果测试人员发现A服务无法访问B服务，先从A所在的服务器pingB所在的服务器，如果可以通，说明物理层、数据链路层和网络层是没问题的，可以将问题定位于传输层和应用层。
  在数据链路层，可以先判断机器是否与其网关连通，如果不能连通，则可能是网络设备的配置或者安全策略，如交换机端口、trunk模式、路由器转发策略等问题，此类问题通常由专门的基础设施岗位人员负责，可以寻求他们的帮助。
  如果问题在传输层和应用层，可以简单的命令判断端到端口的连接情况，如使用telnet命令。考虑到服务的正常访问需要网络（包括访问策略）和服务本身两者都正常，因此可以先从本机telnet该端口，如果可以访问，则说明服务正常，问题可能在网络。如果端口不可访问，则说明服务没有正常启动，需要着重排查服务本身是否正常。如果他机可以正常访问服务端口，这时可以使用更为复杂的分析工具，如Wireshark，tcpdump等抓包分析。
  大致流程可以总结为下图：

image.png

  上图是在交易系统及其业务系统的开发和测试过程中，针对网络问题的排障所总结的诊断步骤。需要指出，在实际工作中碰到的网络问题千差万别，有的甚至需要网络方面专家的协助，因此这个诊断过程是针对一般的、大部分的网络排障经验的总结。

三、案例

  本节介绍4个在实际工作中遇到的网络排障或者分析的案例。由于简单的网络问题一般都可以通过第二节介绍的诊断树来判断，而用抓包分析工具可以获取更多、更有价值的信息，因此本节重点介绍如何使用抓包工具进行问题的定位和分析。

3.1 ssh登陆卡顿

  在某次交易系统测试过程中，交易系统部署在多台服务器上，由于需要对分布在不同服务器上的组件进行统一管理，管理脚本需通过SSH连接到其他服务器。但连接时会卡住一段时间，导致管理脚本无法有效工作。在排障过程中，首先复现问题，如图2。

image.png

  可以看到，使用SSH登陆时，会卡在请求过程，经过测试，等待时间约为10秒，之后可以正常输入密码登陆。为了弄清楚在这10秒时间里发生了什么，我们在10.10.10.83（服务器，链路中间有NAT）上使用Wireshark抓包，同时在客户端尝试登陆。过滤后的结果如图3。

image.png

  由上图可以看到，从498号数据包开始，服务器停止应答，5秒钟后客户端担心连接丢失发送了一个keepAlive的数据包，之后又停顿了5秒，加起来刚好10秒。因此可以肯定服务器在498-654号包之间和655-804号包之间做了其他事情。查看654-805号包，得到图4结果。

image.png

  至此我们已经获得真相，服务器在接到客户端的SSH请求之后，从688号包开始查询DNS，企图获得客户端的域名，而域名服务器没有响应，服务器在等待超时后允许客户端继续操作。因此，在等待的10秒里服务器是在查询DNS。通过修改服务器的sshd配置文件，将use_DNS设置为no之后，问题解决。

3.2为什么ping不通

  在网络排障过程中，安全策略是需要重点考虑的。在某次交易系统测试中，测试人员发现一台服务器的某个IP地址无法从外网访问，但是同一网段的机器可以访问该IP。根据第二节介绍的分析流程，首先要弄清楚服务器是否收到了外网发送的请求。因此，使用tcpdump对该无法访问的网卡进行监听，同时使用外网机器（172.25.167.34）ping该IP地址（172.31.196.13），得到图5结果。

image.png

  显然，从监听的数据包来看，服务器收到了外网请求，只是“不愿意”回复。因此，可以推断可能是服务端内部的策略限制，导致服务器不回复。通过搜索可知，在Linux中为了防止攻击者伪装源IP，当发现请求来源与非同一网段时，会尝试进行反向路径解析以确认该外部IP是否是伪装的，控制该功能的配置开关是rp_filter,如图6。

image.png

  通过将该选项由严苛的（1）调整为非严苛的（2），该问题得到解决。

3.3网页为什么有时打不开

  有时，开发测试人员也会碰到网络一会儿正常一会儿不能正常使用，或者连通速度很慢等问题。这类问题的产生通常由某些阈值导致，在阈值允许的范围内正常工作，超过阈值则会出现异常。在某次业务测试中，测试人员发现某服务的登陆页面需要尝试多次才能打开，或者浏览器没有响应，通过测试排除链路通讯和服务端端口监听问题。为了弄明白为什么登陆页面有时无法打开，需要先知道服务端有没有收到浏览器的请求。我们在服务端使用Wireshark抓包，同时在浏览器进行访问请求,结果如图7。

image.png

  从过滤结果可以看出，28058号包是服务端接收到了浏览器的请求，并在之后进行了一次成功的回应（28059号）。但从28126号包开始，服务端不断尝试重传（29620号、32617号等），说明浏览器没有接收到服务端的后续数据。考虑到成功传输的28059号数据包len=0,而重传的数据包len=1460，因此可以推测可能与数据包len有关。考虑到该Web服务运行在虚拟机上，因此可能是虚拟机的MTU值设置超过了网络限定值，导致数据包被截断。通过修改操作系统的MTU值，该问题被解决。

3.4. 谁占用了我的文件

  合理的使用网络分析工具不仅可以快速定位网路问题，也可以帮助开发测试人员理解程序运行的逻辑和步骤。在某次业务测试中，测试人员发现系统在保存word文档时偶尔会发生错误，提示“文件被占用”。为了弄清楚是谁占用了哪个文件，我们先需要理清楚word如何保存文件。使用Wireshark监控网卡数据包，同时更新某word文档并保存在网络映射的磁盘中,获得如图8的结果。

image.png

  从网络数据包的通讯过程片段可以看出，当需要保存名为temp.docx的文件时，word会先尝试删除名为8CA809E6.tmp的文件（842号数据包），当对方告知这个文件不存在时（843号），word程序先将旧文件保存为8CA809E6.tmp（844号），然后确认这个操作成功（848-849号），成功后，再将之前已经保存好的新文件DF165639.tmp重命名为temp.docx（850号）。
  由此可知，word程序的保存过程设计的较为复杂，需要生成两个临时文件。因此考虑该问题是临时文件被占用所导致，如杀毒软件等。事实上，通过检查杀毒程序的配置，证明了该推测。

  通过以上案例可以看出，多方面的配置和策略都可能引起网络通讯问题，在无法直接判断问题时，可以使用抓包工具等帮助判断。同时，合理的使用这些工具，也可以帮助理解问题发生的本质原因，有利于提高开发测试质量。

出处：大商所行业测试中心 作/译者：谢恒