SYN 重传在说什么
客户端发出 SYN 后如果没有收到 SYN-ACK，会按超时机制重发 SYN：间隔大致按一秒、两秒、四秒、八秒递增，序列号与首次相同。抓包上表现为同源地址、同源端口、同序列号的多个 SYN，且时间间隔成倍增长。这是判断「请求发出去了但没有被应答」的直接证据。重试次数由内核参数决定，最终放弃的时间点由这些间隔累加而成，因此这类故障在客户端侧通常表现为几秒到几十秒的等待。
基本信息
| 抓取写法 | dst port 443 and tcp[tcpflags] = tcp-syn |
|---|---|
| 识别特征 | 同源同端口同序列号的重复 SYN，间隔递增 |
| 重试次数 | 由内核参数控制（常见系统参数为六次左右） |
| 放弃时间 | 各次间隔累加，通常跨度为数十秒 |
| Wireshark 视角 | 相对时间列能直接看出间隔是否成倍增长 |
典型使用场景
- 确认连接超时的原因：是本地没有发出还是发出后没有回应
- 评估故障影响范围：统计多少客户端出现同一目标的重传
- 判断问题出在哪一段：配合服务端抓包确定 SYN 是否到达
- 核对内核参数调整效果：对比调整前后的重试次数与放弃时间
- 识别负载均衡健康检查：健康检查也会产生重传，需先剥离
常用示例
常用示例
tcpdump -i eth0 -nn 'dst port 443 and tcp[tcpflags] = tcp-syn' -c 20 # 只看建连请求
tcpdump -i eth0 -nn -ttt 'dst port 443 and tcp[tcpflags] = tcp-syn' -c 10 # 加间隔看重传节奏
tcpdump -i eth0 -nn 'host 10.0.0.9 and tcp[tcpflags] = tcp-syn' # 某客户端的重试
tcpdump -nn -r a.pcap 'tcp[tcpflags] = tcp-syn and dst port 8443' | wc -l # 统计请求总数
sysctl net.ipv4.tcp_syn_retries # 查看当前重试次数重传过程的观察点
| 观察项 | 正常表现 | 异常表现 |
|---|---|---|
| 重传次数 | 一到两次偶发属于链路波动 | 稳定出现多次说明持续性丢包或服务不可达 |
| 重传间隔 | 成倍增长（约一秒起） | 间隔不规则可能是抓包点丢包导致采样不全 |
| 序列号 | 每次重传保持一致 | 序列号变化说明这是新连接而非重传 |
| 是否有应答 | 重传后收到服务端应答 | 始终无应答说明请求未到达或服务端未处理 |
| 源端口 | 同一源端口持续重试 | 源端口变化说明客户端在新建连接而不是重试 |
重传只在发送侧可见，服务端是否收到必须靠对端抓包确认。单向抓包只能说「这里没有看到应答」，不能断言服务端没有收到请求。
负载均衡与监控的健康检查会周期性地产生 SYN，如果目标不可用，它们同样会重传。统计业务影响前先按来源地址或端口把探测流量分离出来。
与内核参数配合
与内核参数配合
sysctl net.ipv4.tcp_syn_retries net.ipv4.tcp_synack_retries # 两侧的重试次数
ss -tan state syn-sent | head -20 # 本机处于等待应答状态的连接
journalctl -k | grep -i 'syn' | tail -20 # 内核日志里是否有相关提示判读要点
- 客户端重传而服务端完全没有抓到 SYN，说明请求在路径上被丢弃
- 服务端抓到了 SYN 但没有回 SYN-ACK，重点查监听状态与队列参数
- 服务端回了 SYN-ACK 而客户端仍在重传，说明回程方向丢失，属于典型的不对称故障
- 只有个别客户端重传时优先查这些客户端的出口链路与本地策略配置