丢包率不高但应用仍然卡顿？一次基于 tcpdump +RTT抽样的网络性能排障实战

丢包率不高但应用仍然卡顿？一次基于 tcpdump + RTT 抽样的网络性能排障实战

在很多生产环境里，网络问题最容易被"表面指标"误导。监控看起来并不糟：带宽没打满、CPU 没爆、接口错误包不多、平均丢包率也几乎为零，但业务侧就是持续反馈"打开慢""偶发超时""接口一阵快一阵慢"。这类问题最麻烦，因为它不属于那种一眼就能看到红灯闪烁的故障，而是典型的性能退化型网络问题。

本文分享一次非常具有代表性的排障方法：当链路没有大面积中断、也没有明显高丢包时，如何用 tcpdump 抓包 + RTT 抽样分析 + TCP 时序观察，把问题从"用户感觉卡"一步步压缩到"某一段链路存在微突发拥塞与排队抖动"。

topic：网络性能分析与时延抖动排查

一、故障现象：不是完全不可用，而是"忽快忽慢"

某园区业务系统出现了典型投诉：

Web 页面首次打开有时 1 秒，有时 8-10 秒
API 平均成功率很高，但长尾延迟明显上升
视频会议并未大面积掉线，但偶发卡顿、音视频不同步
常规 ping 结果平均时延并不高，却偶尔冒出明显尖刺

初看这些现象，很容易让人把锅甩给应用、数据库或者终端性能。但如果你只看"平均值"，大概率会被带偏。因为真正影响用户体验的，往往不是平均时延，而是：

时延抖动是否变大
TCP 往返时间是否出现长尾
链路是否发生微突发排队
重传是否集中在特定流量窗口

一句话总结：这不是"网络通不通"的问题，而是"网络稳不稳"的问题。

二、排障思路：先分层，再定点，再抓关键时间线

面对这种性能型问题，建议按下面的顺序推进：

1）先确认是不是网络层问题

不要一上来就深挖应用日志。先用三类信号快速判断：

ICMP：看基础时延与抖动
TCP：看握手、窗口、重传、ACK 节奏
应用访问：看慢请求是否和网络尖刺时间对齐

如果你发现：

ping 平均值不高，但 P95/P99 很差
TCP 建连偶发变慢
应用超时与 RTT 尖刺时间段一致

那就非常值得进入抓包分析。

2）抓包位置不要只选一处

这一步很多团队常翻车：只在客户端抓一个包，然后试图解释全世界。

正确做法是尽量形成双点或三点视角：

客户端出口抓包
服务器入口抓包
必要时在中间关键网关/SPAN 口补抓

这样做的好处是：

能判断时延增加发生在哪一段
能区分发送慢、传输慢、还是接收处理慢
能定位是否存在中间设备排队或策略处理延迟

三、抓包执行：tcpdump 不求花哨，先把证据抓对

本次案例中，先在客户端出口和服务器入口分别抓取 5 分钟业务流量：

bash 复制代码

tcpdump -i eth0 host 10.10.20.15 and tcp port 443 -s 0 -nn -w client.pcap

tcpdump -i eth1 host 10.10.20.15 and tcp port 443 -s 0 -nn -w server.pcap

几个关键点：

-s 0：完整抓包，避免截断影响分析
-nn：不做 DNS/端口名解析，减少干扰
明确过滤业务 IP 和端口，控制样本纯度
抓包时间覆盖用户投诉时间窗，而不是随机抓一分钟自我安慰

如果环境流量大，建议补充环形抓包策略，避免磁盘被写爆：

bash 复制代码

tcpdump -i eth0 tcp port 443 -s 0 -nn -C 100 -W 10 -w trace_%Y%m%d%H%M%S.pcap

四、核心分析：平均 RTT 正常，不代表没有性能问题

把数据导入 Wireshark 后，第一反应通常是看是否有大量红色重传。但这次案例并没有明显的大面积重传，真正异常出现在 RTT 分布与 ACK 返回节奏。

1）看 TCP Stream Graph

重点观察：

Round Trip Time Graph
Time-Sequence Graph (Stevens)
Throughput Graph

结果发现：

大多数包 RTT 在 8-15ms 之间
但每隔几十秒，会出现持续 2-5 秒的 RTT 抬升
抬升时段里，部分数据包 RTT 能冲到 120-300ms
这期间不是大量丢包，而是 ACK 返回节奏明显变慢

这说明链路更像是排队拥塞而不是物理中断。

2）看 Dup ACK 与 Fast Retransmission 是否集中爆发

进一步过滤：

wireshark 复制代码

tcp.analysis.duplicate_ack || tcp.analysis.fast_retransmission || tcp.analysis.retransmission

观察到的问题不是"全时段大量重传"，而是：

在 RTT 尖刺窗口内，Dup ACK 明显增加
少量 Fast Retransmission 成簇出现
窗口恢复后，流量迅速回归正常

这类现象通常意味着：

某段设备缓存排队过深
上行/下行某一方向发生瞬时拥塞
QoS、策略路由、隧道封装或出口共享链路存在突发竞争

也就是说，真正的敌人不是"持续性高丢包"，而是短时高排队 + 少量丢包 + TCP 拥塞控制放大效应。

五、为什么用户感觉很卡？因为 TCP 对抖动非常敏感

很多非网络岗位会问：

明明平均只多了几十毫秒，为什么页面会慢这么多？

答案很简单：应用体验受长尾时延支配，而不是受平均值支配。

以 HTTPS 业务为例，一个完整请求里常常包含：

TCP 建连
TLS 握手
多个请求/响应往返
资源并发加载

当 RTT 从 10ms 抖到 150ms，即使只是部分阶段发生，也会导致：

建连变慢
TLS 协商拖长
首字节时间（TTFB）上升
小对象请求堆积
前端页面瀑布图整体后移

如果再叠加一点点重传，用户主观感受就会从"稍慢"直接变成"系统不稳定"。

所以，网络性能分析里最怕的不是稳定的 20ms，而是不稳定的 10ms~200ms 来回横跳。

六、继续缩圈：问题不在服务器，而在出口共享链路

为了验证是不是服务器处理慢，我们对比了客户端与服务器两侧抓包时间线，发现：

服务器发包节奏稳定
服务器侧并未出现明显应用处理停顿
延迟主要增加在服务器回包到客户端 ACK 返回这一段

再结合接口监控，某出口上联在特定时间段出现：

总带宽利用率并未满载
但瞬时流量尖峰很高
队列缓存长度偶尔拉长
某备份任务与在线视频流在同一出口竞争

这就是典型的平均带宽不高，但瞬时突发把队列打深。

很多网络事故都死在这里：

监控只看 1 分钟平均带宽
没看 1 秒级甚至 100ms 级突发
没看队列深度
没看业务高峰与批量传输任务是否重叠

最后只会得出一个非常废话的结论：

网络看起来也还行。

"看起来还行"这五个字，基本就是性能排障里最贵的成本。

七、修复动作：不是一味扩容，而是先治理流量形态

最终处理没有直接粗暴扩带宽，而是分三步：

1）错峰处理大流量任务

把原本在办公高峰期运行的备份同步任务移到低峰时段，先消除明显的流量竞争源。

2）为关键业务设置更合理的 QoS

对核心业务端口和关键应用流量做优先级保障，避免小流量控制报文和交互请求被大流量吞没。

3）补 1 秒级指标与队列观测

把原来只看分钟平均的监控，补成：

1 秒级接口吞吐
丢包/错包趋势
队列利用率
TCP 重传率
业务 RTT 长尾指标（P95/P99）

修复后回看数据：

平均 RTT 变化不大
但 P99 RTT 明显下降
TCP Dup ACK 显著减少
用户投诉量快速归零

这再次证明：排障不能只盯平均值，必须盯长尾和波动。

八、给运维团队的实战建议

如果你也遇到"业务偶发卡顿但网络指标不红"的情况，建议优先检查以下 5 项：

1. 看 P95/P99，不只看平均值

平均时延没意义，长尾才决定体验。

2. 抓双点包，别单点臆测

单点抓包容易误判，双点对时序最有价值。

3. 查微突发，不只查总带宽

分钟平均平静如水，不代表秒级没有惊涛骇浪。

4. 看 ACK 节奏与 RTT 曲线

这比单纯数重传包更能解释"为什么用户会卡"。

5. 把网络、应用、任务调度放到一张时间线上

很多问题本质上不是单点故障，而是多个系统在同一时间窗口互相踩踏。

九、结语

网络性能排障真正难的地方，不是不会抓包，而是容易被"看上去正常"的平均指标麻痹。很多线上卡顿问题，根因并不是链路断了，而是链路在关键时刻短暂地变差，然后由 TCP、TLS 和应用交互层层放大，最终变成用户眼中的"系统很慢"。

所以，下次再遇到"丢包率不高但用户一直喊卡"的场景，别急着让应用背锅。先抓包、看 RTT、看长尾、看微突发。很多时候，问题就藏在这些不够显眼、但足够致命的细节里。

如果你正在建设更可观测的网络排障体系，AnaTraf（www.anatraf.com）可以作为流量分析与网络可视化排查的辅助工具，用更直观的方式帮助团队发现异常链路、性能抖动与故障趋势。