怎么查网站有没有做404,关键词云图,wordpress 进管理页面,临潼微网站建设问题背景
仍然是来自于朋友分享的一个案例#xff0c;实际案例不难#xff0c;原因也就是互联网线路丢包产生的重传问题。但从一开始只看到数据包截图的判断结果#xff0c;和最后拿到实际数据包的分析结果#xff0c;却不是一个结论#xff0c;方向有点跑偏#xff0c;…问题背景
仍然是来自于朋友分享的一个案例实际案例不难原因也就是互联网线路丢包产生的重传问题。但从一开始只看到数据包截图的判断结果和最后拿到实际数据包的分析结果却不是一个结论方向有点跑偏所以记录下本篇。
问题信息
开局的数据包截图大概就如下一堆超时重传信息问题是什么不熟悉的可能直接就说是丢包了像我稍微熟悉的一眼感觉就像是互联网常见的 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 262144Time precision microseconds (6)Time ticks per second 1000000Time resolution 0x06Number of stat entries 0Number 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 7869SRE9249。此处关键代表说明确认收到了客户端所发送的 Seq Num 969 之前以及 Seq Num 7869-9249 之间的数据意味着服务器端还是收到了一个 9249-78691380 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 问题。而最终经朋友反馈应用传输丢包问题的原因就是运营商线路丢包符合实际数据包现象丢失的数据分段无规律可言毕竟数据包从不说谎。
