Wireshark TS | 选择性or针对性丢包

问题背景

首先解释下什么是选择性or针对性丢包,这只是我对某些问题场景的描述,并非专业术语,譬如 MTU 问题场景就算其中一种,超出固定大小限制的数据包无法正常传输等等。

本篇介绍的是某一个比较特殊的丢包场景,在开通新的国际线路后,应用开发人员发现无法连接到服务器,认为可能是有网络丢包现象,遂升级问题进行排查。

案例取自 SharkFest 2011《Packet Trace Whispering》

问题信息

数据包跟踪文件基本信息如下:

bash 复制代码
λ capinfos Session-I1-Case1-HK.pcap
File name:           Session-I1-Case1-HK.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 1618 bytes
Packet size limit:   inferred: 54 bytes
Number of packets:   133
File size:           11 kB
Data size:           28 kB
Capture duration:    741.679716 seconds
First packet time:   2011-03-16 17:53:09.318379
Last packet time:    2011-03-16 18:05:30.998095
Data byte rate:      39 bytes/s
Data bit rate:       312 bits/s
Average packet size: 218.00 bytes
Average packet rate: 0 packets/s
SHA256:              12e030a7c5abbe16991abf0817091d0d758ce60384cad3666c29a209b457dba8
RIPEMD160:           17f23fb2e4776b7670f3740c2ecfa82b49c0832e
SHA1:                5f645d95ac02c16c8cf31170376bfa4a077ebb59
Strict time order:   True
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 1618
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 133

跟踪文件在 linux 上通过 tcpdump 所捕获,数据包数量并不多,只有 133 个,长度截断为 54 字节,文件数据大小 28k 字节,捕获时长相对较长 741.68 秒,平均速率仅 312 bps。

统计会话信息中,可以看 IP 地址信息,推断进行了匿名化处理,并存在 4 条 TCP 流。

专家信息如下,可以看到存在部分协议解析层面的 Error 问题、 TCP ACKed unseen segment 等 Warning 问题,以及比较普遍的(疑似)重传和 DUP ACK 现象,数量并不多,需要进一步实际分析。

问题分析

展开数据包跟踪文件数据包详情如下:

通过统计会话信息可知 TCP 流仅 4 条,快速过滤并浏览可知 TCP Steam 0-2 基本正常,无丢包重传现象。

bash 复制代码
tcp.stream in {0,1,2}

或者通过点选黑色箭头标注位置,可直接快速跳转到问题所在,比较清晰的可见 TCP 重传和 DUP ACK 等问题现象,存在于 TCP Stream 3 中。

进行 TCP Stream 3 具体分析,首先是 TCP 三次握手信息,

  1. 服务器端口 22,之后也可知两端运行 SSH 协议 2.0 版本;
  2. IRTT 0.243327 秒,约 243 ms,可见客户端通过国际线路至服务器端确实很远;
  3. 客户端和服务器端的 MSS 均为 1460;
  4. 客户端支持 SACK,但服务器不支持;
  5. 另外 TTL ,客户端 122,服务器端 52,可判断抓包点在中间路径。

转至 TCP 重传信息位置,主要分析如下:

  1. 在收到 No.112 客户端的数据分段后,服务器以 No.113 ACK 确认了该数据,但在之后 No.114 一直到最后,均只有服务器单方向的数据包;
  2. 在 No.114 - No.120,服务器所发送的连续 7 个数据分段均没有得到客户端的确认,疑似产生了丢包行为,客户端并未收到相关数据包;
  3. 之后因为未收到客户端的确认,服务器发生了超时重传,可以看到 TCP 通过指数回退方式进行了 7 次重传,No.121-No.125、No.130、No.133,约 2.5s、5s、10s、20s、40s、64s 和 64s 间隔;另外还有一个很少见的现象是, TCP 在此处进行了聚合重传,并不是之前 7 个数据分段的单独超时重传,而是一次性通过一个 TCP 数据分段 928 字节发出;

a. 可以通过 TCP Seq Num 对应验证,2401 - 3329;

b. 也可以通过 TCP Len 验证,88+212+68+308+100+100+52=928,也就是 982 - 54(14 Ethernet II 头部+ 20 IP 头部 + 20 TCP 头部) 的结果;

c. 比较特别的超时重传行为,暂未明确是某种超时重传算法,又或者是某种内核版本下的特别行为,有清楚的同学麻烦告知下,谢谢。

  1. 理所当然,数据不会被无限、反复地重传。当达到一定重传次数后,如果仍然没有任何确认返回,就会判断为网络或对端服务器发生了异常,TCP 就会强制关闭连接,并且通知上层应用通信异常强行终止;
  2. 其中也夹杂着 TCP ACKed unseen segment ,通过 ACK Num 1313 ,对比 1312 ,疑似确认了一个客户端发出的 FIN ,之后的 DUP ACK 也是同样问题,数据包跟踪文件貌似未捕获到来自客户端的一些数据包。

那么丢包的实际原因到底是什么呢? 通过数据包的字段逐个对比,发现了以下根因:

  1. 服务器端 No.111 数据分段 DSCP 值为默认 0,No.113 ACK 数据包 DSCP 值同样为 0,包括 No.111 之前所有的服务器端数据包均如此,也正常双向交互;
  1. 但从 No.114 开始,服务器端的每一个数据包 DSCP 值变为了 4 ,Unknown 未定义 。

最终解释:

回到最开始的问题描述,因为端到端这些数据包是通过了国际线路,此处不论是源服务器端(个人猜测小概率)或者是中间运营商设备(大概率)修改了部分数据包 DSCP 值的缘故,在之后的传输路径上由于 DSCP 值无法匹配正常转发而造成丢包,不断重传仍无法解决后 FIN 连接,因此从客户端的现象来说就是无法连接服务器。

问题总结

不常见的问题,诡异的现象和最终原因,但一切皆有可能,不是嘛。

相关推荐
m0_547486661 小时前
计算机网络名词解释汇总
网络·计算机网络
麻瓜也要学魔法6 小时前
链路状态路由协议-OSPF
网络
Estar.Lee7 小时前
查手机号归属地免费API接口教程
android·网络·后端·网络协议·tcp/ip·oneapi
傻啦嘿哟7 小时前
代理IP在后端开发中的应用与后端工程师的角色
网络·网络协议·tcp/ip
Red Red8 小时前
网安基础知识|IDS入侵检测系统|IPS入侵防御系统|堡垒机|VPN|EDR|CC防御|云安全-VDC/VPC|安全服务
网络·笔记·学习·安全·web安全
向阳12188 小时前
Dubbo HTTP接入之triple协议
网络协议·http·dubbo
亚远景aspice9 小时前
ISO 21434标准:汽车网络安全管理的利与弊
网络·web安全·汽车
Estar.Lee10 小时前
时间操作[计算时间差]免费API接口教程
android·网络·后端·网络协议·tcp/ip
友友马10 小时前
『 Linux 』网络层 - IP协议(一)
linux·网络·tcp/ip