有专门做房孑特卖的网站吗,中国铁建集团门户网官网,网站ui案例,凡科登录入口下载问题背景
沿用之前文章的开头说明#xff0c;应用传输慢是一种比较常见的问题#xff0c;慢在哪#xff0c;为什么慢#xff0c;有时候光从网络数据包分析方面很难回答的一清二楚#xff0c;毕竟不同的技术方向专业性太强#xff0c;全栈大佬只能仰望#xff0c;而我们…问题背景
沿用之前文章的开头说明应用传输慢是一种比较常见的问题慢在哪为什么慢有时候光从网络数据包分析方面很难回答的一清二楚毕竟不同的技术方向专业性太强全栈大佬只能仰望而我们能做到的是在专注于自身的专业方向之外尽量扩展知识面学会找出问题的规律并提出可能的解决建议。
本篇案例是一个应用开发团队提出的“缓慢”问题分别在发送和接收端抓取了相关数据包“SendSideFinal.pcap” 以及 “RcvSideFinal.pcap”实际上部分场景下的数据包分析确实需要在多点捕获包括发送端或者接收端甚至于中间路径的多个节点这样更有助于网络问题分析。 案例取自 SharkFest 2010《Wireshark in the Large Enterprise》 问题信息
跟踪文件基本信息如下
λ capinfos SendSideFinal.pcap RcvSideFinal.pcap
File name: SendSideFinal.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Packet size limit: inferred: 70 bytes
Number of packets: 220
File size: 18 kB
Data size: 46 kB
Capture duration: 95.639823 seconds
First packet time: 2009-09-11 05:24:51.255133
Last packet time: 2009-09-11 05:26:26.894956
Data byte rate: 485 bytes/s
Data bit rate: 3885 bits/s
Average packet size: 211.14 bytes
Average packet rate: 2 packets/s
SHA256: 104aeea149181060e3d3c744bb9ea4aea13c0be832e92e0852abf173df253f77
RIPEMD160: 3d5d768f175a949e818c9f1160688c8854234b59
SHA1: 1e117af53e4bbdd9b0cb3636117374a191c4ebf3
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:Encapsulation Ethernet (1 - ether)Capture length 65535Time precision microseconds (6)Time ticks per second 1000000Number of stat entries 0Number of packets 220File name: RcvSideFinal.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Packet size limit: inferred: 70 bytes
Number of packets: 213
File size: 18 kB
Data size: 45 kB
Capture duration: 91.744055 seconds
First packet time: 2009-09-11 05:24:55.248731
Last packet time: 2009-09-11 05:26:26.992786
Data byte rate: 492 bytes/s
Data bit rate: 3936 bits/s
Average packet size: 211.94 bytes
Average packet rate: 2 packets/s
SHA256: 15731bbc644d0e2c1a304ef955ec62052d7fae377d3d8a420fc566e5be819404
RIPEMD160: d28207f0689fb74106d4d206c94cd305dd30cb2a
SHA1: bf129e7e359676a3d2cb496a8fa7169344356c7d
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:Encapsulation Ethernet (1 - ether)Capture length 65535Time precision microseconds (6)Time ticks per second 1000000Number of stat entries 0Number of packets 213数据包跟踪文件在 linux 上通过 tcpdump 所捕获两端数据包数量分别为 220 和 213 个长度截断为 70 字节。发送端文件数据大小 46k 字节捕获时长 95.64 秒平均速率 3885 bps而接收端文件数据大小 45k 字节捕获时长 91.74 秒平均速率 3936 bps总体来说两端信息基本匹配确实速率很低。
专家信息如下可以看到异常的简洁没有 Warning 相关信息可见传输缓慢的问题并不是常见的丢包导致重传所引起。 问题分析
首先从发送端 “SendSideFinal.pcap” 跟踪文件开始展开数据包信息如下可以看到数据包文件缺失 TCP 三次握手阶段的数据包仅有数据传输 PSH/ACK 相关最后以 RST 数据包结束。 其中 TCP 会话完整性分析中 tcp.completeness 44 也说明了相关情况44 4 8 32其中 4 为 ACK8 为 DATA32 为 RST。 TCP 会话完整性分析说明详见《 Wieshark 提示和技巧 | TCP 会话完整性分析》 另从上面数据包交互来看两端实际都有数据分段在传输如果不是数据包文件的名字 “SendSideFinal.pcap” 以及 “RcvSideFinal.pcap”也确实不好辨别哪个是发送端哪个是接收端。从我个人的角度来说定义出哪个是客户端哪个是服务器端以及两个文件的捕获点可能会更加简单些。
首先因为是 TCP 传输所以 TCP 端口 60301 和 7609 一般就可以分辨出客户端 10.10.10.10服务器 192.168.1.1。
其次如何判断这两个数据包跟踪文件分别是在哪里捕获的呢 可以通过两个字段值分析一个 TTL一个 ACK 间隔时间。
“SendSideFinal.pcap” 中 192.168.1.1 TTL 为 6464 一般为 linux 系统的默认值逐跳减 1 既然为 64说明捕获点是在本地或是靠近本地侧譬如上连接入交换机上也就是在 192.168.1.1 “SendSideFinal.pcap” 中 ACK 间隔时间ACK 对于数据分段的确认譬如 No.5 确认 No.4 以及 No.2 确认 No.1No.11 确认 No.10间隔时间都极短0.1-0.2ms相对于中间网络传输的时间很小而如果反过来判断很多数据包交互时间都无法说通所以也可判断捕获点是在本地或是靠近本地侧也就是 192.168.1.1。 也有同学也会注意 No.7 以及 No.9 的间隔时间为什么同样是 192.168.1.1 也是 ACK而不考虑在内首先简单来说就是上面提到的如果反过来判断现象不匹配其次细想下No.7 只是发送端发送数据间隔的时间譬如像浏览网页停顿几秒再去点击一次的间隔综合判断下来的结论就是 “SendSideFinal.pcap” 是在服务器端 192.168.1.1 所捕获而 “RcvSideFinal.pcap” 是在客户端 10.10.10.10 所捕获。而剩下来的一个 No.9 不同于绝大部分的正常传输规律那么它就真的是属于有问题的那一个了。
“SendSideFinal.pcap” 中数据交互规律如下图总结一番
服务器端 192.168.1.1连续发送三次 Length 为 179 的数据帧后再发送一个 Length 为162 的数据帧后最后一个 ACK第一组未抓全客户端 10.10.10.10发送一次 Length 为 152 的数据帧后发送一个 ACK连续三次后 再发送一个 Length 为 189 的数据帧汇总以上以客户端 10.10.10.10 发起Length 为 152、179、66 的一组数据帧连续交互三次后 再以服务器端 192.168.1.1 所发起的 Length 162、189、66 的一组数据帧做为结束。当然由于未捕获到最起初的数据包此一组数据帧也可能为起始 找到 “SendSideFinal.pcap” 数据包传输的规律后同时再结合“RcvSideFinal.pcap”对比分析就比较容易识别出缓慢的问题所在慢在哪。
通过数据包的 ip.id 字段可以找到两个数据包跟踪文件中的数据包对应关系如下左图 No.7 请求和 No.8 响应间隔 200ms一部分来自于 RTT一部分来自于响应具体是多少通过右图对比可以得知响应时长极短不到 1ms而 RTT 近乎 200ms此后服务器端 192.168.1.1 No.9 带来第一个慢的地方ACK 的时长为 106ms初步判断可能是延迟确认的时间略长。 以下仍以之前总结的数据交互规律说明如下
以客户端 10.10.10.10 发起Length 为 152、179、66 的一组数据帧连续交互三次后 再以服务器端 192.168.1.1 所发起的 Length 162、189、66 的一组数据帧做为结束右图客户端 No.4 发起第一组 Length 为 152 的数据帧经 RTT 后得到了服务器端 No.5 的 ACK 确认但同样 No.6 约有 100ms 的 ACK 确认间隔初步判断可能是延迟确认的时间同样略长之后第二组 Length 为 152 的 No.7 数据帧就带来一次很大的间隔发送延迟约 1.91s之后同样有一个约 109ms 的 ACK 确认间隔之后第三组 Length 为 152 的 No.10 数据帧就又带来一次很大的间隔发送延迟约 1.90s之后同样有一个约 105ms 的 ACK 确认间隔左图服务器端 No.19 最后发起 Length 为 162 的数据帧经 RTT 后客户端收到后立马响应带有数据分段的数据帧最后服务器端 No.21 约有 92ms 的 ACK 确认间隔。
问题总结
总结两个数据包跟踪文件的数据包交互规律以及时间分析应用缓慢的问题主要出现在客户端 10.10.10.10 的数据请求阶段每一次间隔基本都在 1.9s 左右相对于如此大的延迟时间两端基本都存在的延迟确认 100ms 左右的时间几乎都可以忽略不计了。
