TCP 排障检查单
排 TCP 问题最怕跳步：还没确认握手是否完整就去查重传，或者拿单侧抓包给全局下定论。按固定顺序过一遍能避免这类误判——连接是否建立、谁先发数据、确认是否正常推进、有无异常标注、两侧结论是否一致、应用日志能否对上时间线。每一步无论有没有发现，都值得记录。
基本信息
| 适用平台 | 所有基于抓包的 TCP 排障场景 |
|---|---|
| 核心价值 | 用固定顺序避免跳步带来的误判 |
| 输出要求 | 每一步的结论都要写下，包括「无异常」 |
| 配套手段 | 两端抓包、ss 状态、应用日志 |
典型使用场景
- 新问题快速过一遍：用统一顺序保证不漏环节
- 交接与复核：别人能按同一套顺序复现你的结论
- 定位归属：把网络侧与应用侧的责任分开
- 判断证据充分性：明确哪一步还没做、结论还缺什么
- 沉淀到团队文档：把顺序固化成排障规范
检查单
检查单
# 1) 握手三步是否齐全？失败看 RST 还是无响应
# 2) 数据方向与首字节出现的时间点
# 3) ACK 是否正常推进，有无重复确认堆积
# 4) tcp.analysis 有哪些标注（重传、乱序、窗口）
# 5) 两端抓包的结论是否一致
# 6) 应用日志与抓包时间线能否对齐常见跳步后果
| 跳过的步骤 | 典型误判 | 正确做法 |
|---|---|---|
| 未确认握手完整性 | 把建连问题当成数据问题 | 先看 SYN、SYN-ACK、ACK |
| 忽略方向与首字节时间 | 责任被错判到网络侧 | 按时间线分段落归因 |
| 未看窗口状态 | 把窗口受限当成丢包 | 检查窗口填充与零窗口 |
| 只用单侧抓包 | 把局部现象当成全局事实 | 两端同时取数对照 |
每个「没有异常」的检查点都要写进报告，它们同样有价值：能证明某个方向已被排除，避免后续重复排查同一件事。
抓包时长必须覆盖完整现象窗口。周期性抖动、定时任务引发的故障往往要抓满一个完整周期才能复现，抓两分钟就收工通常什么都看不到。
两侧同时抓包时先确认时钟。未同步的情况下，可用一次已知往返时延做基准平移，再对比其余时间点，比直接相减可靠得多。