4、TCP握手超时：SYN_SENT状态分析、SYN重传机制、tcp_syn_retries参数调优
说到TCP连接超时，SYN_SENT状态是我排查时最先盯住的地方。说白了，这就是客户端发出了SYN包，正眼巴巴等着服务端回SYN+ACK。如果这一步卡住了，整个连接就悬在半空。
我记得有一次线上告警，用户反馈App登录转圈十几秒才弹"网络异常"。我登上去一看，大量连接停留在SYN_SENT状态。嗯，这背后就是SYN握手超时的问题。
4.1 SYN_SENT状态到底意味着什么？
你执行ss -tna或者netstat -tna，看到某个连接状态是SYN_SENT。这表示：
- 客户端已经发出了SYN包
- 还没收到服务端的SYN+ACK
- 连接正在等待中
正常情况下，这个状态一闪而过。如果它持续存在，说明网络链路或者服务端有问题。
核心判断标准：
- SYN_SENT持续几秒：可能是网络延迟或丢包
- SYN_SENT持续十几秒以上：大概率是服务端端口未监听或防火墙拦截
- 大量SYN_SENT堆积：可能是目标服务挂了，或者遭遇了SYN洪水攻击
4.2 SYN重传机制——内核是怎么"自救"的？
客户端发出SYN后，如果迟迟没收到SYN+ACK，内核不会傻等。它会启动重传。这个机制我简单拆解一下：
- 第一次发送SYN，启动定时器
- 超时未收到ACK，重传SYN
- 重传间隔逐渐增大（指数退避）
- 达到最大重传次数后，放弃连接，返回ETIMEDOUT
重传间隔的规律是这样的：
| 重传次数 | 间隔时间 | 累计耗时 |
|---|---|---|
| 第1次 | 1秒 | 1秒 |
| 第2次 | 2秒 | 3秒 |
| 第3次 | 4秒 | 7秒 |
| 第4次 | 8秒 | 15秒 |
| 第5次 | 16秒 | 31秒 |
你看，如果默认重试5次，客户端要等31秒才会放弃。这就是为什么用户觉得"卡了很久"才报错。
我的排查习惯：遇到SYN_SENT超时，我会先抓包确认SYN是否真的发出去了。有时候是客户端自己没发出来（比如路由表问题），有时候是发了但服务端没收到。抓包一看便知。
4.3 tcp_syn_retries参数调优
这个参数控制的就是SYN重传次数。路径在/proc/sys/net/ipv4/tcp_syn_retries，默认值是5或6（不同内核版本有差异）。
我个人习惯根据业务场景来调：
- 内部服务调用：网络环境可控，丢包率低，可以设小一点，比如3次。这样7秒就能快速失败，让上游尽快切换。
- 公网客户端：网络质量参差不齐，建议保持默认5次，或者适当增加到6次。我见过有些弱网环境，4秒的间隔都不够。
- 高并发场景：如果大量连接同时超时，重传风暴会加剧负载。这时候调小重传次数，快速释放连接资源。
我曾经踩过的坑：有一次为了追求"快速失败"，把tcp_syn_retries改成1。结果用户反馈在电梯里经常连不上。因为电梯场景下信号切换时丢包率很高，一次重传根本不够。后来改回3次，问题解决。调优不能只看实验室数据，得考虑真实环境。
4.4 实战：如何定位SYN_SENT超时根因？
我总结了一套排查步骤，你遇到类似问题可以直接套用：
- 确认状态：
ss -tna | grep SYN_SENT，看目标IP和端口 - 抓包验证：
tcpdump -i eth0 host 目标IP and port 目标端口，看SYN是否发出 - 检查重传：抓包中看到多个SYN包，说明对端没回ACK
- 测试对端：
telnet 目标IP 目标端口，看端口是否可达 - 检查防火墙：确认中间设备没有拦截SYN包或SYN+ACK包
这里有个小技巧：用ss -tna | awk '{print $1, $2, $5}' | grep SYN_SENT可以快速统计每个目标IP的SYN_SENT连接数。如果某个IP堆积特别多，那问题大概率出在那边。
4.5 调优参数速查表
| 参数 | 默认值 | 推荐范围 | 适用场景 |
|---|---|---|---|
| tcp_syn_retries | 5 | 2-6 | 控制SYN重传次数 |
| tcp_synack_retries | 5 | 2-6 | 控制SYN+ACK重传次数（服务端） |
| tcp_retries1 | 3 | 2-5 | 数据包重传阈值（低于此值不报错） |
| tcp_retries2 | 15 | 8-15 | 数据包重传阈值（超过后断开连接） |
调参时记得用sysctl -w net.ipv4.tcp_syn_retries=3临时生效，确认没问题再写进/etc/sysctl.conf。
避坑指南：别在业务高峰期直接改全局参数。我习惯先挑一台非核心机器做验证，观察一两天。另外，容器环境要注意，有些容器镜像会覆盖内核参数，得在Dockerfile或K8s的sysctl配置里单独设置。
4.6 知识体系总览
下面这张图把SYN超时的核心逻辑串起来了，你可以对照着理解：
这张图从左到右展示了完整的握手流程。客户端发出SYN后进入SYN_SENT状态，如果收不到SYN+ACK，就会触发指数退避的重传机制。最终，tcp_syn_retries参数决定了重传几次后放弃。调优的核心就是在"快速失败"和"容忍丢包"之间找到平衡点。
嗯，关于SYN握手超时，核心就是这些。你下次再看到SYN_SENT堆积，应该知道从哪里下手了。