关于网站集约化建设公函,每平每屋设计家官网,成都html5网站设计,收钱码合并的网站怎么做问题背景
网络路径不一致#xff0c;或者说是网络路径来回不一致#xff0c;再专业点可以说是网络路径不对称#xff0c;以上种种说法#xff0c;做网络方向的工程师肯定会更清楚些#xff0c;用简单的描述就是#xff1a;
A 与 B 通讯场景#xff0c;C 和 D 代表中间…问题背景
网络路径不一致或者说是网络路径来回不一致再专业点可以说是网络路径不对称以上种种说法做网络方向的工程师肯定会更清楚些用简单的描述就是
A 与 B 通讯场景C 和 D 代表中间路径可能存在的 N 个不同设备 A - B 方向经过了这样的路径A — C — B B - A 方向经过了这样的路径B — D — A
以上网络场景实际挺常见的正常通讯没有任何问题。
开篇明义此案例就是一个上述场景下的丢包问题原因已明简单分享下分析过程。 案例取自 SharkFest 2011《Packet Trace Whispering》 问题信息
数据包跟踪文件基本信息如下
λ capinfos Session-I1-Case2-pktloss.pcap
File name: Session-I1-Case2-pktloss.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: 67 bytes
Number of packets: 71
File size: 5883 bytes
Data size: 13 kB
Capture duration: 11.639492 seconds
First packet time: 2011-02-18 04:26:07.508816
Last packet time: 2011-02-18 04:26:19.148308
Data byte rate: 1141 bytes/s
Data bit rate: 9135 bits/s
Average packet size: 187.20 bytes
Average packet rate: 6 packets/s
SHA256: 9c9e5cd8c6c2ef892efcd5d0302b17407b3943bbc02f6cc676d7457ade452e42
RIPEMD160: de6dde6f5460acb52f399cc491c8cad81c0f5ab3
SHA1: 7e9de2c390e85874cc234a40c33c1f1e2cbc94ae
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 71跟踪文件在 linux 上通过 tcpdump 所捕获数据包数量并不多只有 71 个长度截断为 67 字节文件数据大小 13K 字节捕获时长 11.64 秒平均速率 9135 bps。
统计会话信息中可见 TCP 流 1 条客户端 192.168.1.1 - 服务器端 10.10.10.10 。 专家信息如下可以看到存在一定数量的疑似重传和疑似虚假重传现象符合丢包现象。 问题分析
展开数据包跟踪文件数据包详情如下 可以看出 TCP Stream 0 并没有捕获到 TCP 三次握手阶段的数据包但通过 TTL 字段值 128 可判断出捕获点在服务器端上或者靠近服务器端的地方而 RTT 约为 0.1ms 并且数据传输的规律是一个数据分段一个 ACK 确认不断交互。
通过点选右下黑色位置可直接快速跳转到问题所在可见 TCP 重传和疑似重传等问题。 也可以通过以下显示过滤表达式快速筛选 TCP 分析中的异常问题这也是比较常用的技巧。
tcp.analysis.flags可以看到总共有 10 个匹配数据包包括来自于服务器端 10.10.10.10 的 TCP 重传以及来自于客户端 192.168.1.1 的 TCP 虚假重传为什么会有如此泾渭分明的重传现象呢 展开 TCP 详细分析主要如下 服务器端 10.10.10.10 的 TCP 重传
可以看到包括 No.47-48 以及之前的数据包均正常交互。但从 No.49 Seq 2904 开始由于一直未收到 ACK 在约 300ms 左右发生了超时重传 No.50之后同样一直未收到 ACK产生了不断超时重传现象间隔 300ms、600ms、1.2s 、1.2s、1.2s 和 2.4s。
特殊的地方在于每一次超时重传的时候有时还会带上新的数据分段TCP Len 不断变大但同样没有收到任何确认。 客户端 192.168.1.1 的 TCP 虚假重传
不同于最初一个数据分段一个 ACK 确认不断交互的传输规律经过服务器 10.10.10.10 的连续单方向数据传输无响应后客户端 192.168.1.1 在 No.58 发送了一个数据分段 Len 11 并且可以看到服务器端 10.10.10.10 正常回复了 ACK 确认收到但是在 200ms 后客户端 192.168.1.1 仍然产生了超时重传现象之后的现象依旧不断重传间隔 200ms、400ms、800ms 和 1.6s。
为什么是 TCP 虚假重传 这是因为在数据包跟踪文件中有数据分段也有 ACK 确认所以 Wireshark 基于上下文综合判断该重传属于 TCP 虚假重传现象。 实际上再想到开篇提到的网络路径不一致问题就可以明白整个过程。
由于服务器端发送的数据分段无法正常收到 ACK 确认因此产生了 TCP 超时重传注意这里丢失的是服务器端发送方向的数据分段而客户端 - 服务器端传输方向数据分段可以正常发送且能收到但服务器端返回的 ACK 数据包同样无法返回至客户端所以客户端产生了 TCP 超时重传注意这里丢失的是服务器端发送方向的 ACK因此根本原因出现在服务器端 - 客户端传输的方向在某一个时点开始传输的任何数据包均无法正常到达客户端。
经过长时间的不断跟踪最后查明问题是在单向路径上的一台交换机引擎软件 BUG 引起。 问题总结
我们可能无法确定根因但数据包分析可以为我们指明正确的方向。
