握手重试与建连延迟
建连阶段的握手报文若没有得到响应，客户端会按重传超时逐次重试，抓包表现为同一序号的首包以倍增的间隔重复出现。这类故障与“连接被拒绝”的表现完全不同：被拒绝会立即收到重置报文，而无人应答只能等到重试次数耗尽，再由应用层报告连接超时，用户感知的失败时间往往是秒级甚至更长。重试次数与超时参数由系统控制，两端都要核对；排查时还要把首次握手与重试握手区分开，避免误当成多条并发连接。
基本信息
| 抓包判据 | 同序号的建连首包以倍增间隔重复出现 |
|---|---|
| 参数来源 | 重试次数与超时由内核参数控制 |
| 应用表现 | 连接超时，而非连接被拒绝 |
| 相关依据 | RFC 6298（重传超时计算） |
| 对照现象 | 被拒绝时会立即收到重置报文 |
典型使用场景
- 建连超时排查：确认失败是无人应答还是被明确拒绝
- 参数核查：核对两端系统的重试次数与超时设置
- 路径丢包定位：结合重试间隔判断丢包可能发生的位置
- 与解析问题区分：先确认地址解析是否已经成功
- 故障时间评估：重试耗尽的总时长决定用户实际等待时间
过滤与对照
过滤与对照
tcp.flags.syn == 1 && tcp.flags.ack == 0 # 只看建连首包
# 观察同序号首包的间隔是否成倍增加
# 对照：被拒绝的场景会立即收到重置报文
# 重试耗尽后应用侧才会报连接超时建连失败形态对照
| 形态 | 抓包表现 | 用户感知 |
|---|---|---|
| 无人应答 | 首包按倍增间隔重试 | 等待数秒后超时 |
| 连接被拒绝 | 立即收到重置报文 | 近乎即时失败 |
| 解析失败 | 看不到对应连接报文 | 报错信息指向域名 |
首次握手与重试握手之间的间隔属于超时重传行为，不要把它们当成两条并发连接；统计并发数时要把重试部分剔除。
建连慢与解析慢同时出现时两者都表现为等待，必须按时间线的先后顺序切分，否则无法判断究竟是哪一段先出问题。