应用停顿的抓包形态
应用停顿在抓包里的形态很有辨识度：请求已经到达服务端，但迟迟没有响应数据发出，间隔明显大于基线，同时看不到重传、零窗或任何丢包标注。这说明网络没有参与制造这段延迟，责任落在应用侧，例如垃圾回收停顿、锁竞争、等待下游依赖超时。排查的正确顺序是先确认网络干净，再与服务端资源指标和日志按时段对齐。如果停顿呈周期性出现，优先怀疑定时任务或垃圾回收这类固定节奏的因素。
基本信息
| 抓包特征 | 无重传、无零窗，但响应延迟明显偏大 |
|---|---|
| 前置条件 | 请求已到达服务端 |
| 归因方向 | 应用层计算或等待 |
| 配合证据 | 服务端资源指标与应用日志 |
| 周期性停顿 | 优先怀疑定时任务与垃圾回收 |
典型使用场景
- 卡顿定位：把用户体验到的卡顿指向应用层而不是网络
- 排除网络：用抓包先证明网络侧没有异常
- 时段对齐：与服务端监控曲线按同一时间轴比对
- 周期性分析：按停顿间隔与时长判断诱因类型
- 优化验证：调整参数后确认停顿是否消失
核对顺序
核对顺序
# 1) 主列表中确认没有重传与零窗标注
# 2) 服务端侧抓包确认请求已到达
# 3) 与服务端资源曲线和日志按时间对齐
# 4) 网络排除后再把结论归到应用层停顿特征与诱因
| 特征 | 可能诱因 | 验证方式 |
|---|---|---|
| 周期性短停顿 | 垃圾回收或定时任务 | 与内存曲线和调度表对齐 |
| 偶发长停顿 | 锁竞争或下游超时 | 看下游调用日志 |
| 停顿逐渐变长 | 负载累积 | 看队列深度与线程状态 |
| 随机出现 | 资源争抢 | 看宿主与容器指标 |
周期性的停顿优先怀疑定时任务或垃圾回收：把停顿时刻与任务调度表、内存回收曲线对齐，往往能直接命中原因。
停顿的间隔与时长分布本身就是线索，报表里只记平均值会把这类突发特征完全抹平。