前言

感觉很有一段时间没有写 TroubleShooting 方面的案例分析了，一来故障案例难得，二来近期分散了些精力研究网络协议栈，三来工作很忙 😅 总之借口多多。这期间自己也产生了很多技术问题，请教了很多老师，但也仍留有很多的疑惑，出于学习交流的目的，上周因此建立了技术群，希望能和不同技术方向的老师互相讨论，学习下经验、技术和案例。

问题背景

仍然是来自于朋友分享的一个案例，实际案例不难，原因也就是互联网线路丢包产生的重传问题。但从一开始只看到数据包截图的判断结果，和最后拿到实际数据包的分析结果，却不是一个结论，方向有点跑偏，所以记录下本篇。

问题信息

开局的数据包截图大概就如下，一堆超时重传信息，问题是什么，有的可能直接说就是丢包，像我稍微熟悉点的，一眼感觉就像是互联网常见的 MTU 问题。客户端发送的数据包 Len 2760 也就是 2 个 MSS 1380 的大小，在中间传输过程中碰到了 MTU 问题， 以至于 1380 大小的数据包被丢弃，因此产生了众多超时重传。

基于以上截图，初始结论就是互联网线路问题，根因是 MTU 。但总有意外的事发生，等我拿到了实际数据包仔细分析，虽然还是互联网线路产生的丢包问题，但根因却不是 MTU 了，初始结论错误。

数据包跟踪文件信息主要如下：

λ capinfos 1220.pcapngFile name:           1220.pcapngFile type:           Wireshark/... - pcapngFile encapsulation:  EthernetFile timestamp precision:  microseconds (6)Packet size limit:   file hdr: (not set)Packet size limit:   inferred: 54 bytesNumber of packets:   40File size:           4264 bytesData size:           37 kBCapture duration:    14.583142 secondsFirst packet time:   2023-12-18 07:35:28.365933Last packet time:    2023-12-18 07:35:42.949075Data byte rate:      2553 bytes/sData bit rate:       20 kbpsAverage packet size: 931.10 bytesAverage packet rate: 2 packets/sSHA256:              096e0919a13f8ff2c0b8b4691ff638c14345df621ecd9157daa3b3ce3447b88cSHA1:                3267274c4fce576dde3446d001372b9b34f15717Strict time order:   TrueCapture application: Editcap (Wireshark) 4.2.0 (v4.2.0-0-g54eedfc63953)Capture comment:     Sanitized by TraceWrangler v0.6.8 build 949Number of interfaces in file: 1Interface #0 info:                     Encapsulation = Ethernet (1 - ether)                     Capture length = 262144                     Time precision = microseconds (6)                     Time ticks per second = 1000000                     Time resolution = 0x06                     Number of stat entries = 0                     Number of packets = 40

客户端通过 Wireshark 捕获数据包，捕获时长 14.58s，数据包数量 40 个，文件大小 4.264 字节，平均速率约 20kbps，总体上来说速率很低。数据包经过 Editcap 编辑和 TraceWrangler 处理，一方面是改了文件格式，另一方面就是重要的匿名。

关于 TraceWrangler 匿名化软件简介，可以查看之前的文章《Wireshark 提示和技巧 | 如何匿名化数据包》

专家信息如下，数据包总数 40 的情况下，疑似重传数据包数量就有 12 个，该 TCP 连接的质量可想而知。

问题分析

首先是 TCP 三次握手，客户端和服务器各自所通告的 MSS 为 1460 和 1380 ，两者取小为 1380 ，所以最后传输遵循的最大 TCP 分段就是 1380。另 IRTT 0.027269 秒，同时也支持 SACK 和 WS 。

客户端 192.168.38.134 所发送的数据，在直到产生问题的 No.18 Len 2760 之前，数据包长度还是小分段 213、129、105、737 等，这也确实容易第一眼给人错觉，像是 No.18 之后 MSS 1380 的数据分段发生了 MTU 问题造成丢包重传。

我们将数据包分成三段，No.1-3 TCP 三次握手，No.4-16 正常数据交互，No.17 以及之后为问题点，重点分析。

分析全过程如下：

1. No.17-22 均为客户所发送的数据分段，除了 No.17 Len 683 较小分段外，其他均为 1 或 2 个 MSS 1380 分段；

2. 经过一个 RTT 时间，服务器端返回的 No.23 ACK Num 969 仅仅确认了 No.17 ，紧接着的 No.24 即判断为 TCP Dup ACK，因为它的 ACK Num 仍为 969，并携带有 SACK 标识 SLE 7869，SRE=9249。此处关键，代表说明确认收到了客户端所发送的 Seq Num 969 之前以及 Seq Num 7869-9249 之间的数据，意味着服务器端还是收到了一个 9249-7869=1380 MSS 大小的数据分段，所以并不是初始结论，超出了中间路径 MTU 大小而造成所有 MSS 1380 大小的数据包被丢弃；

3. 但问题仍是中间互联网线路中间发生了丢包，哪些数据分段丢失了？No.18-20 , Seq Num 969 - 7869 之间的数据。由于客户端收到了 No.24 SACK ，所以紧接着进行了 No.25-26、No.28-29 的快速重传。考虑到拥塞窗口减小的缘故，只重传了 Seq Num 969 - 6489 的数据，而 Seq Num 6489 - 7869 并未发送。期间又收到了一个客户端 No.27 SACK，确认又收到了一个 Seq Num 9249 - 10629 =1380 MSS 大小的数据分段；

4. 不幸的是，经过一个 RTT 时间，服务器端返回的 No.30 SACK 仍仅确认了 Seq Num 2349 之前的数据，也就是相较之前，只确认多收到了一个 MSS 1380 的数据分段，而 SLE,SRE 没有任何变化，说明之前重传的数据包又发生了丢包；

5. 此时拥塞窗口继续减小，客户端仅发送了一个 No.31 的新数据分段，以及再次重传了 No.32 Seq Num 为 2349 的数据分段，因为 No.30 代表缺失了 Seq 2349 - 7869 之间的数据；

6. 服务器返回的 No.33 SACK 继续仅多确认了一个 MSS 1380 大小的数据，ACK Num 为 3729，客户端再次重传 No.34-35；

7. 之后 No.36 - No.40 ，客户端进行了多次超时重传，超时时间明显不断翻倍，此时不管是中间互联网线路持续丢包，还是服务器端因长时间等待已释放连接，总之不再有确认返回。

问题总结

整个分析过程中因为多出了 SLE SRE 的缘故，判断出的问题根因也发生了变化，并非 MTU 问题。而最终经朋友反馈，应用传输丢包问题的原因就是运营商线路丢包，符合实际数据包现象（丢失的数据分段无规律可言），毕竟数据包从不说谎。

原文始发于微信公众号（Echo Reply）：Wireshark TS | 应用传输丢包问题