丢包率不高但应用仍然卡顿一次基于 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 分钟业务流量tcpdump-ieth0host10.10.20.15 and tcp port443-s0-nn-wclient.pcap tcpdump-ieth1host10.10.20.15 and tcp port443-s0-nn-wserver.pcap几个关键点-s 0完整抓包避免截断影响分析-nn不做 DNS/端口名解析减少干扰明确过滤业务 IP 和端口控制样本纯度抓包时间覆盖用户投诉时间窗而不是随机抓一分钟自我安慰如果环境流量大建议补充环形抓包策略避免磁盘被写爆tcpdump-ieth0 tcp port443-s0-nn-C100-W10-wtrace_%Y%m%d%H%M%S.pcap四、核心分析平均 RTT 正常不代表没有性能问题把数据导入 Wireshark 后第一反应通常是看是否有大量红色重传。但这次案例并没有明显的大面积重传真正异常出现在RTT 分布与 ACK 返回节奏。1看 TCP Stream Graph重点观察Round Trip Time GraphTime-Sequence Graph (Stevens)Throughput Graph结果发现大多数包 RTT 在 8-15ms 之间但每隔几十秒会出现持续 2-5 秒的 RTT 抬升抬升时段里部分数据包 RTT 能冲到 120-300ms这期间不是大量丢包而是 ACK 返回节奏明显变慢这说明链路更像是排队拥塞而不是物理中断。2看 Dup ACK 与 Fast Retransmission 是否集中爆发进一步过滤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、看长尾、看微突发。很多时候问题就藏在这些不够显眼、但足够致命的细节里。如果你正在建设更可观测的网络排障体系AnaTrafwww.anatraf.com可以作为流量分析与网络可视化排查的辅助工具用更直观的方式帮助团队发现异常链路、性能抖动与故障趋势。