Wireshark TS | 应用传输丢包题目

题目背景

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

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

基于以上截图，初始结论就是互联网线路题目，根因是 MTU 。但总有不测的事发生，等我拿到了实际数据包仔细分析，固然还是互联网线路产生的丢包题目，但根因却不是 MTU 了，初始结论错误。
数据包跟踪文件信息重要如下：

1. λ capinfos 1220.pcapng
2. File name:           1220.pcapng
3. File type:           Wireshark/... - pcapng
4. File encapsulation:  Ethernet
5. File timestamp precision:  microseconds (6)
6. Packet size limit:   file hdr: (not set)
7. Packet size limit:   inferred: 54 bytes
8. Number of packets:   40
9. File size:           4264 bytes
10. Data size:           37 kB
11. Capture duration:    14.583142 seconds
12. First packet time:   2023-12-18 07:35:28.365933
13. Last packet time:    2023-12-18 07:35:42.949075
14. Data byte rate:      2553 bytes/s
15. Data bit rate:       20 kbps
16. Average packet size: 931.10 bytes
17. Average packet rate: 2 packets/s
18. SHA256:              096e0919a13f8ff2c0b8b4691ff638c14345df621ecd9157daa3b3ce3447b88c
19. SHA1:                3267274c4fce576dde3446d001372b9b34f15717
20. Strict time order:   True
21. Capture application: Editcap (Wireshark) 4.2.0 (v4.2.0-0-g54eedfc63953)
22. Capture comment:     Sanitized by TraceWrangler v0.6.8 build 949
23. Number of interfaces in file: 1
24. Interface #0 info:
25.                      Encapsulation = Ethernet (1 - ether)
26.                      Capture length = 262144
27.                      Time precision = microseconds (6)
28.                      Time ticks per second = 1000000
29.                      Time resolution = 0x06
30.                      Number of stat entries = 0
31.                      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 以及之后为题目点，重点分析。

分析全过程如下：

• 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 题目。而最终经朋侪反馈，应用传输丢包题目的原因就是运营商线路丢包，符合实际数据包征象（丢失的数据分段无规律可言），毕竟数据包从不说谎。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。