1. 连接超时概述：什么是连接超时、超时产生的根本原因、TCP三次握手与超时的关系
1.1 什么是连接超时？
连接超时，说白了就是客户端发起连接请求后，等了半天没等到回应，最后系统告诉你「不等了，放弃吧」。你想想看，我们平时用浏览器打开一个网页，如果那个网站挂了，浏览器转几圈之后就会弹出一个「连接超时」的错误提示——这就是最典型的场景。
从技术角度定义，连接超时是指：发起方发送了 SYN 报文后，在规定时间内没有收到对方的 SYN-ACK 回应，系统主动终止连接尝试的过程。这个「规定时间」就是超时阈值，由操作系统内核参数控制。
核心要点：连接超时 ≠ 连接被拒绝。被拒绝你会收到 RST 报文，那是明确的「不行」。超时是「没消息」，这才是最让人头疼的。
我记得有一次线上告警，用户反馈某个支付接口偶尔连不上。我上去一看，既不是拒绝也不是超时，而是间歇性丢包导致的超时重传——这种问题最难复现，也最考验抓包功底。
1.2 超时产生的根本原因
为什么会超时？原因其实就三类，我习惯把它们归纳为「网络不通、服务不答、中间乱搞」：
- 网络路径不通：路由不可达、防火墙拦截、物理链路故障。这类问题通常表现为「一直超时，从不成功」。
- 服务端没响应：服务进程挂了、端口没监听、内核 backlog 队列满了。服务端根本没机会发出 SYN-ACK。
- 中间设备干扰：防火墙丢 SYN、负载均衡器超时、NAT 设备老化。这类最隐蔽，我在项目中遇到过好几次。
| 原因分类 | 典型表现 | 抓包特征 |
|---|---|---|
| 网络不通 | 每次连接都超时 | 只看到 SYN 发出，无任何回应 |
| 服务没响应 | 端口可达但无应答 | SYN 发出后，SYN-ACK 始终不出现 |
| 中间设备干扰 | 间歇性超时 | SYN 重传多次后放弃，无 RST |
避坑指南：我曾经排查过一个案例，客户端 telnet 某端口总是超时，但服务端 netstat 显示端口在监听。抓包后发现防火墙把 SYN 报文标记为「可疑流量」直接丢弃了，连 ICMP 都不回。所以别只看服务端状态，中间路径才是真正的黑盒。
1.3 TCP 三次握手与超时的关系
要理解连接超时，必须先吃透三次握手。握手过程本身就是一个「超时敏感」的交互流程。我画了一张图，把三次握手和超时点标了出来：
三次握手的流程大家都熟，但超时发生在哪里？我直接说重点：
- 客户端发 SYN：启动一个定时器，等待 SYN-ACK。如果超时没收到，客户端会重传 SYN。
- 服务端回 SYN-ACK：服务端也在等客户端的 ACK，如果超时没收到，服务端重传 SYN-ACK。
- 客户端发 ACK：握手完成，连接建立。
连接超时主要发生在第一步——客户端发了 SYN 之后，一直没等到 SYN-ACK。系统会尝试重传，重传次数耗尽后，返回 ETIMEDOUT 错误。
个人经验：Linux 默认的 SYN 重传次数是 6 次（net.ipv4.tcp_syn_retries），每次超时时间翻倍：1s、2s、4s、8s、16s、32s。算下来总共约 63 秒才会放弃。很多应用层超时设得比这个短，所以实际报错可能是「应用层超时」而不是「系统层超时」——抓包时要注意区分。
1.4 超时参数速查
我整理了一份常用系统的超时参数表，方便你排查时对照：
| 操作系统 | 参数名 | 默认值 | 说明 |
|---|---|---|---|
| Linux | tcp_syn_retries | 6 | SYN 重传次数，约 63s 后放弃 |
| Linux | tcp_synack_retries | 5 | 服务端 SYN-ACK 重传次数 |
| Windows | TcpMaxConnectRetransmissions | 3 | SYN 重传次数，约 21s 后放弃 |
| macOS | net.inet.tcp.syn_retries | 3 | 与 Windows 类似 |
注意：别以为改大重传次数就能解决问题。我曾经遇到一个项目，把 tcp_syn_retries 改成 10，结果客户端卡了 2 分钟才报错——用户体验极差。正确的做法是：先抓包定位根因，再决定是调参数还是修网络。
1.5 抓包怎么看连接超时？
用 Wireshark 抓包时，连接超时的特征非常明显：
- 你会看到连续多个
[SYN]报文，间隔逐渐增大 - 没有对应的
[SYN, ACK]回应 - 最后客户端发出
[RST]或直接静默放弃 - Wireshark 会标记为
[TCP Retransmission]
# 典型的连接超时抓包片段（过滤后）
1 0.000000 192.168.1.2 → 10.0.0.1 TCP 74 [SYN] Seq=0
2 1.000123 192.168.1.2 → 10.0.0.1 TCP 74 [SYN] Seq=0 [TCP Retransmission]
3 3.001456 192.168.1.2 → 10.0.0.1 TCP 74 [SYN] Seq=0 [TCP Retransmission]
4 7.003789 192.168.1.2 → 10.0.0.1 TCP 74 [SYN] Seq=0 [TCP Retransmission]
5 15.008123 192.168.1.2 → 10.0.0.1 TCP 74 [SYN] Seq=0 [TCP Retransmission]
看到这种模式，基本可以断定是连接超时。接下来要做的就是顺着路径排查——是防火墙丢了？路由不可达？还是服务端根本没收到？这些我会在后面的章节逐一展开。
一句话总结：连接超时的本质是 SYN 报文石沉大海。抓包看到 SYN 重传，就是超时；看到 SYN 发出去有回应（哪怕是 RST），就不是超时。记住这个判断标准，排错时能省一半时间。