SYN+ACK 重试是什么
net.ipv4.tcp_synack_retries 控制服务端方向的握手重试：收到客户端的 SYN 并回复 SYN+ACK 后，如果迟迟等不到最终的 ACK，内核会按指数退避重传 SYN+ACK，次数用尽后回收这条半连接。默认 5 次。它决定了服务端上 SYN_RECV 状态能维持多久，也影响半连接队列在异常流量下的占用时间。客户端方向的对应参数是 net.ipv4.tcp_syn_retries，两者方向不同、含义不同。
基本信息
| 参数 | net.ipv4.tcp_synack_retries |
|---|---|
| 默认值 | 5，按指数退避重传 SYN+ACK |
| 作用方向 | 服务端，针对未收到最终 ACK 的半连接 |
| 关联状态 | SYN_RECV 半连接的持续时间 |
| 对应参数 | net.ipv4.tcp_syn_retries 控制客户端 SYN 重传 |
| 观测方式 | ss -nt state syn-recv 查看半连接数量 |
典型使用场景
- 排查 SYN_RECV 堆积：判断是对端异常、路径丢包还是扫描流量造成
- 缩短异常连接占用：希望半连接更快回收，减轻队列压力
- 客户端超时分析：客户端侧看到的握手失败时间与服务端重传策略相关
- 网络质量评估：移动网络与高丢包链路上，ACK 丢失会造成大量半连接
- 安全事件复盘：扫描类流量留下的半连接特征
查看与观察
查看与观察
sysctl net.ipv4.tcp_synack_retries # 读当前重试次数
ss -nt state syn-recv | wc -l # 半连接数量
ss -nt state syn-recv | head # 看来源地址分布
nstat -az TcpExtTCPReqQFullDrop # 半连接队列溢出的丢弃计数
tcpdump -n -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)' | head # 观察 SYN+ACK现象与判断
| 现象 | 可能原因 | 判断方式 |
|---|---|---|
| SYN_RECV 短时增多 | 正常建连中的过渡态 | 看持续时间与数量级，通常自行回落 |
| SYN_RECV 持续高位 | 对端不回 ACK 或路径丢包 | 按来源地址分布判断是集中还是分散 |
| 来源分散且高频 | 端口扫描或伪造源地址流量 | 结合防火墙日志与流量特征分析 |
| 来源集中在少数网段 | 特定链路质量差或客户端异常 | 对相关链路做抓包与质量测试 |
SYN_RECV 状态本身是正常过渡态，短暂出现几条到几十条并不代表异常。需要关注的是数量级、增长趋势以及来源分布：分散且高频通常指向扫描或伪造源地址流量，集中在少数网段则更像链路质量问题。
减小重试次数会让客户端更早放弃：在移动网络或跨运营商链路上，抖动引起的 ACK 丢失会因此更早变成建连失败，用户体验反而下降。调整前先确认问题确实发生在服务端半连接环节。