Wireshark TS | 应用传输丢包题目
题目背景仍然是来自于朋侪分享的一个案例，实际案例不难，原因也就是互联网线路丢包产生的重传题目。但从一开始只看到数据包截图的判断结果，和最后拿到实际数据包的分析结果，却不是一个结论，方向有点跑偏，以是记载下本篇。
题目信息
开局的数据包截图大概就如下，一堆超时重传信息，题目是什么，不熟悉的可能直接就说是丢包了，像我稍微熟悉的，一眼感觉就像是互联网常见的 MTU 题目，客户端发送的数据包 Len 2760 也就是 2 个 MSS 1380 的大小，在中间传输过程中碰到了 MTU 题目， 以至于 1380 大小的数据包被抛弃，因此产生了浩繁超时重传。
https://img-blog.csdnimg.cn/img_convert/4ce3fef74e4d61a8d1a6b9980f57b564.png
基于以上截图，初始结论就是互联网线路题目，根因是 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 处理惩罚，一方面是改了文件格式，另一方面就是重要的匿名。
关于 TraceWrangler 匿名化软件简介，可以检察之前的文章《Wireshark 提示和技巧 | 如何匿名化数据包》
专家书息如下，数据包总数 40 的情况下，疑似重传数据包数目就有 12 个，该 TCP 连接的质量可想而知。
https://img-blog.csdnimg.cn/img_convert/ac32feffd61270da3a9b34aa16721022.png
题目分析
首先是 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 题目造成丢包重传。
https://img-blog.csdnimg.cn/img_convert/358c4ccefa3de16bd055ce99c6a210d5.png
我们将数据包分成三段，No.1-3 TCP 三次握手，No.4-16 正常数据交互，No.17 以及之后为题目点，重点分析。
https://img-blog.csdnimg.cn/img_convert/c54b405c9cf7985d3d4b073232467ce0.png
分析全过程如下：
[*]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企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]