丢包率不高但应用仍然卡顿？一次基于 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）可以作为流量分析与网络可视化排查的辅助工具，用更直观的方式帮助团队发现异常链路、性能抖动与故障趋势。