tcpdump可捕获含sack选项的tcp报文，需用-s 128保全tcp头及options，并通过bpf过滤ack报文与tcp头长≥80字节的包，再结合wireshark筛选tcp.options.sack分析异常模式，最后验证内核参数net.ipv4.tcp_sack及接收缓冲区状态。
Linux 下用 tcpdump 捕获并分析 SACK-Range（Selective Acknowledgment）报文，是排查 TCP 传输中“部分数据丢失但连接未断、重传不及时或异常”的关键手段。SACK 允许接收方精确告知发送方哪些数据段已收到、哪些丢失，从而避免盲目重传。当出现“应用层感知丢数但无明显超时/重连”时，SACK 异常往往是症结所在。
以下分三步说明：精准捕获 → 快速识别 → 定位丢包环节
一、用 tcpdump 捕获含 SACK 选项的 TCP 报文
SACK 信息位于 TCP Option 字段中（类型为 5），需确保抓包时保留完整 TCP 头（默认即满足），且过滤条件聚焦在有 SACK 的报文上：
tcpdump -i eth0 -nn -s 128 'tcp[tcpflags] & (tcp-ack) != 0 and (tcp[12:1] & 0xf0) >= 0x50' -w sack_debug.pcap
说明：
-
-s 128：截取至少 128 字节，确保能覆盖 TCP 头 + Options（SACK 通常需额外 10~30 字节） -
tcp[tcpflags] & (tcp-ack) != 0：只抓带 ACK 标志的报文（SACK 只出现在 ACK 报文中） -
(tcp[12:1] & 0xf0) >= 0x50：检查 TCP 头长度字段（偏移 12 字节的高 4 位），≥ 0x50 表示头长 ≥ 80 字节（即含 Options，SACK 通常在此范围） -
-w：保存为 pcap 文件，便于后续用 Wireshark 深度分析
✅ 小技巧：若只想看 SACK 块内容（如
SACK: 1000-2000, 3000-4000），可加-A查看 ASCII 解码，但更推荐保存后用 Wireshark 分析——它会自动解析并高亮 SACK Range。
二、识别典型 SACK 异常模式（Wireshark 或 tshark 辅助）
打开 sack_debug.pcap 后，在 Wireshark 过滤栏输入：
tcp.options.sack
即可只显示含 SACK 的报文。重点关注以下三类现象：
重复 SACK 同一段（Stuck SACK）
接收方连续多个 ACK 都报告同一段丢失（如始终SACK: 5000-6000），但发送方未重传该段 → 可能发送端未响应 SACK（内核 bug / TCP 栈异常）或该段已被跳过重传逻辑。SACK 范围不连续且空洞扩大
例如：ACK 1000, SACK 2000-3000, 5000-6000ACK 1000, SACK 2000-3000, 5000-6000, 8000-9000
→ 新增空洞，说明中间又有数据未达，但发送端未及时补发 → 可能拥塞控制过于保守，或接收窗口长期为 0 导致发送停滞。SACK 与 Dup ACK 共存但无重传
出现 3+ 次 Dup ACK（相同 ACK number）且附带 SACK，但后续无对应重传包（retransmission）→ 内核可能禁用了 F-RTO 或 SACK 恢复被绕过（如net.ipv4.tcp_sack=0被误关）。
三、结合系统状态确认是否为协议栈限制导致
SACK 生效依赖内核配置和资源。即使抓到 SACK 报文，若系统层面抑制了响应，仍会丢数据：
-
检查 SACK 是否启用：
sysctl net.ipv4.tcp_sack # 应返回 1；若为 0，执行 sudo sysctl -w net.ipv4.tcp_sack=1
-
检查接收缓冲区是否持续满（导致新包进不来，旧 SACK 无法更新）：
ss -i | grep ":端口号" # 查看 rmem_rtt、rcv_space、rcv_ssthresh cat /proc/net/snmp | grep -A1 Tcp | grep -E "(InSegs|OutSegs|RetransSegs|SACKMisses)"
若
SACKMisses持续增长（netstat -s | grep SACK），说明内核尝试用 SACK 但失败，常见于net.core.rmem_max过小或net.ipv4.tcp_rmem自动缩容。 -
检查是否有丢包发生在 SACK 之前环节（如网卡 Ring Buffer 溢出）：
ethtool -S eth0 | grep -i "drop\|overrun\|error" netstat -s | grep -A5 "Tcp:" | grep -E "(packet.*drop|SACK)"
不复杂但容易忽略：SACK 本身不丢包，但它暴露的是“已发生的丢包”和“恢复机制是否工作”。真正要解决的，是找到 SACK 所指向的那段数据为何没被重传、或为何根本没发出去——这往往指向发送端拥塞控制、接收端缓冲区管理、或中间设备（如防火墙/负载均衡）剥离了 TCP Options。
