问题背景
仍然是来自于朋友分享的一个案例，实际案例不难，原因也就是互联网线路丢包产生的重传问题。但从一开始只看到数据包截图的判断结果，和最后拿到实际数据包的分析结果，却不是一个结论，方向有点跑偏，所以记录下本篇。
问题信息
开局的数据包截图大概就如下，一堆超时重传信息，问题是什么，不熟悉的可能直接就说是丢包了，像我稍微熟悉的，一眼感觉就像是互联网常见的 MTU 问题，客户端发送的数据包 Len 2760 也就是 2 个 MSS 1380 的大小，在中间传输过程中碰到了 MTU 问题， 以至于 1380 大小的数据包被丢弃，因此产生了众多超时重传。
基于以上截图，初始结论就是互联网线路问题，根因是 MTU 。但总有意外的事发生，等我拿到了实际数据包仔细分析，虽然还是互联网线路产生的丢包问题，但根因却不是 MTU 了，初始结论错误。
数据包跟踪文件信息主要如下：
λ capinfos 1220.pcapng File name: 1220.pcapng File type: Wireshark/... - pcapng File encapsulation: Ethernet File timestamp precision: microseconds (6) Packet size limit: file hdr: (not set) Packet size limit: inferred: 54 bytes Number of packets: 40 File size: 4264 bytes Data size: 37 kB Capture duration: 14.583142 seconds First packet time: 2023-12-18 07:35:28.365933 Last packet time: 2023-12-18 07:35:42.949075 Data byte rate: 2553 bytes/s Data bit rate: 20 kbps Average packet size: 931.10 bytes Average packet rate: 2 packets/s SHA256: 096e0919a13f8ff2c0b8b4691ff638c14345df621ecd9157daa3b3ce3447b88c SHA1: 3267274c4fce576dde3446d001372b9b34f15717 Strict time order: True Capture application: Editcap (Wireshark) 4.2.0 (v4.2.0-0-g54eedfc63953) Capture comment: Sanitized by TraceWrangler v0.6.8 build 949 Number of interfaces in file: 1 Interface #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 处理，一方面是改了文件格式，另一方面就是重要的匿名。
专家信息如下，数据包总数 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 以及之后为问题点，重点分析。
分析全过程如下：
No.17-22 均为客户所发送的数据分段，除了 No.17 Len 683 较小分段外，其他均为 1 或 2 个 MSS 1380 分段；
经过一个 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 大小的数据包被丢弃；
但问题仍是中间互联网线路中间发生了丢包，哪些数据分段丢失了？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 大小的数据分段；
不幸的是，经过一个 RTT 时间，服务器端返回的 No.30 SACK 仅确认了 Seq Num 2349 之间的数据，也就是相较之前，只多确认收到了一个 MSS 1380 的数据分段，而 SLE,SRE 没有任何变化，说明之前重传的数据包又发生了丢包；
此时拥塞窗口继续减小，客户端仅发送了一个 No.31 的新数据分段，以及再次重传了 No.32 Seq Num 为 2349 的数据分段，因为 No.30 代表缺失了 Seq Num 2349 - 7869 之间的数据；
服务器返回的 No.33 SACK 继续仅多确认了一个 MSS 1380 大小的数据，ACK Num 为 3729，客户端再次重传 No.34-35；
之后 No.34 - No.40 ，客户端进行了多次超时重传，超时时间明显不断翻倍，此时不管是中间互联网线路持续丢包，还是服务器端因长时间等待已释放连接，总之不再有确认返回。
问题总结
整个分析过程中因为多出了 SLE SRE 的缘故，判断出的问题根因也发生了变化，并非 MTU 问题。而最终经朋友反馈，应用传输丢包问题的原因就是运营商线路丢包，符合实际数据包现象（丢失的数据分段无规律可言），毕竟数据包从不说谎。
