实战网络问题排查（四）

您所在的位置：网站首页 › 秒传链接失败什么原因造成的 › 实战网络问题排查（四）

实战网络问题排查（四）

2024-07-12 11:51| 来源: 网络整理| 查看: 265

1. 引言

上一篇文章中，我们较为详细的介绍了 wireshark 的用法：

实战网络问题排查（三） -- wireshark 使用详解

使用 wireshark 最为重要的当然是要利用它来诊断网络问题了。

本文我们就通过 wireshark 来看看遇到这几类网络问题时我们应该如何着手吧。

本文主要参考《Network Analysis Using Wireshark Cookbook》Chapter9 的前4节。

2. 通过 wireshark 查看 TCP 连接信息

TCP 建立连接和通信的过程想必你早已经烂熟于心了，你也可以参看我之前写的这篇文章：

传输控制协议 -- TCP

2.1 连接建立

如图所示，这三行就是 TCP 三次握手的过程：

首先，客户端 TCP 进程发送了一个 SYN 报文，初始序列号 Seq 为 0，除此之外，我们还能在 wireshark 中看到 MSS、Selective ACK 等等更为详细的信息：

这些信息里，你可能比较关心：

Maximum Segment Size (MSS) -- 最大报文长度，单个 TCP 报文的最大长度。Windows Size (WSopt) -- 窗口大小。SACK -- 也就是 Selective ACK，当需要重传时，只需要重传单个丢失的报文，只有两端均支持这一特性的时候才会启用。Timestamps options (TSopt) -- 客户端与服务端之间的延时。

第二行的消息，是服务端 ACK 客户端的 SYN 报文，同时也包含了服务端的 SYN 信息。

报文中包含了服务器端的初始序列号以及服务端窗口大小等信息。

除了客户端报文的序列号外，第三行客户端 ACK 的报文中，再次指明了客户端窗口大小。

2.2 问题排查

很简单，如果你在抓包结果中看到客户端发送 SYN 报文后，服务端没有任何回复或者回复了 RST 报文，那么显然，服务端的对应端口可能没有被监听、主动拒绝，或者被防火墙拦截。

你可以确认客户端、服务端均正常运行后，检测防火墙配置，检查你传递的用户名、密码是否正确，以及你要访问的 ip、端口是否正确。

你可能会通过 ping 命令去检测服务端是否存活，但很多情况下，服务端会通过防火墙屏蔽 ICMP 报文，所以你无法 ping 通服务端，但这不代表 server 已经挂掉了。

3. TCP 重传

TCP 通信过程中一个最常见的问题就是 TCP 重传。

TCP 重传是 TCP 用来恢复受损、丢失、重复或失序的一个重要机制，如果发送方一段时间内未收到已发送包的确认，发送方就会触发重传。

在通信过程中，如果 TCP 重传的报文达到 0.5%，就会对性能产生严重影响，如果达到了 5%，那 TCP 连接就将会中断。

在 wireshark 中，重传报文被标记为 TCP Retransmission。

通过配置显示过滤器获取当前抓包结果中所有的重传报文：

experssage == "Retransmission (suspected)"

如图所示：

3.1 Case1. 对多个目的地址发生重传

就像上面这张图，你会发现 Destination 并不集中，分布于多个目的服务器，这通常是链路问题，可能是你的网卡负载过高。

通过 wireshark 的 Statistics 菜单的 IO Graph 选项，可以打开 wireshark 的 IO 负载监控，由此你可以看到当前机器上的通信是不是已经达到了网卡的负载瓶颈。

如果像上图这样，网卡负载不高，那有可能是因为网卡或链路中存在故障或其他挤占带宽的高负载链路。

你可以登录到链路中的通信设备查看丢包率。

3.2 Case2. 重传只发生在同一个目的地址

上图这样的情况，所有的重传都集中在同一个目的地址上，这通常是应用自己的处理性能低造成的。

想要进一步确认是否是这个原因引起的，你可以按照下面的步骤来看：

如上一节中介绍的，通过 wireshark 提供的 IO Graph 查看网络负载是否过高。通过 Statistics 菜单的 Conversation 选项，打开网络会话窗口，在 IPv4 选项卡下，勾选 Limit to display filter 复选框，就可以看到所有发生重传的会话，可以进一步确认。在网络会话窗口中，点击 TCP 选项卡，同样勾选 Limit to display filter 复选框，可以查看具体的重传端口，确认是哪个应用，从而定位具体的问题。