1. 超时现象全景：什么是连接超时？

大家好，我是老赵。做网络运维十几年了，要说哪个问题最让人头疼，连接超时绝对排前三。你想想看，用户在那点了一下，转圈圈，然后弹个「请求超时」——这背后到底发生了什么？

说白了，连接超时就是客户端发出去的数据包，在规定时间内没等到预期的回应。系统觉得「算了不等了」，直接放弃这次通信。嗯，这里要注意：超时不是网络断了，而是「等太久了」。

1.1 超时的三种常见分类

我在项目中遇到过各种各样的超时，归纳起来就三类。咱们一个一个说。

超时类型	发生层面	典型表现	我见过的最坑案例
TCP 连接超时	传输层	三次握手没完成，卡在 SYN_SENT	防火墙把 SYN 包丢了，客户端干等 21 秒
HTTP 请求超时	应用层	请求发出去，响应迟迟不来	后端线程池满了，前端 30 秒超时断开
DNS 解析超时	应用层（依赖 UDP）	域名转 IP 这一步卡住了	内网 DNS 服务器挂了，所有服务都连不上

1.2 TCP 连接超时：最底层的等待

TCP 连接超时，说白了就是三次握手没走完。客户端发了个 SYN，服务器没回 SYN+ACK。为什么会这样？

• 网络不通：路由丢了，防火墙拦了，物理链路断了
• 服务器没监听：端口没开，或者服务根本没启动
• 服务器负载太高：全连接队列满了，内核直接把 SYN 丢了

我记得有一次线上告警，所有业务都连不上数据库。查了半天，发现是数据库服务器的 net.core.somaxconn 设得太小，连接队列溢出了。客户端那边就是典型的 TCP 连接超时——卡在 SYN_SENT 状态，直到 21 秒后超时退出。

1.3 HTTP 请求超时：应用层的煎熬

HTTP 请求超时比 TCP 超时更「高级」一点。TCP 连接已经建好了，请求也发出去了，但响应就是不来。这通常意味着：

• 后端处理慢：业务逻辑复杂，数据库查询慢，或者调了外部接口卡住了
• 线程/连接池耗尽：所有工作线程都在忙，新请求排队等
• 客户端设置不合理：超时时间设得太短，正常处理时间都超过了

我个人习惯把 HTTP 超时拆成三段来看：连接超时（connectTimeout）、读取超时（readTimeout）、写入超时（writeTimeout）。每一段的意义完全不同。

// 以 Java HttpClient 为例
RequestConfig config = RequestConfig.custom()
    .setConnectTimeout(5000)      // 建立 TCP 连接的超时
    .setConnectionRequestTimeout(3000) // 从连接池获取连接的超时
    .setSocketTimeout(10000)      // 等待数据的超时（readTimeout）
    .build();

你想想看，如果只设一个总超时，出了问题你根本不知道卡在哪一步。是连不上？还是连上了但数据没回来？还是连接池里等太久？

1.4 DNS 解析超时：最容易被忽略的坑

DNS 解析超时，嗯，这个坑我踩过不止一次。客户端要访问 api.example.com，先得问 DNS 服务器这个域名对应什么 IP。如果 DNS 服务器没响应，或者响应太慢，整个请求还没开始就结束了。

DNS 超时的特点：

• 影响面极大：一个 DNS 挂了，所有依赖这个域名的服务都受影响
• 表现迷惑：用户看到的是「连接超时」，但根因在 DNS
• 缓存双刃剑：本地缓存能救命，但缓存过期时恰好 DNS 挂了，那就炸了

1.5 超时对业务的影响

超时不是小事。它不只是用户体验变差，而是实实在在的损失。我列几个真实场景：

业务场景	超时类型	影响	我见过的损失
电商下单	HTTP 请求超时	用户重复提交，产生多笔订单	一晚多出 2000 笔重复订单
支付回调	TCP 连接超时	支付成功但没通知业务系统	用户付款了但订单还是「未支付」
视频播放	DNS 解析超时	CDN 域名解析失败，视频加载不出来	高峰期 30% 用户看不了视频
微服务调用	连接池超时	线程阻塞，雪崩效应	一个服务超时拖垮整个调用链

说白了，超时就像多米诺骨牌——第一块倒了，后面的全跟着倒。一个上游服务的超时，可能导致下游所有服务都跟着超时，最终就是整个系统不可用。

1.6 本章知识体系总览

下面这张图，是我自己梳理的超时知识体系。你看一遍，心里就有谱了。

这张图把超时的分类、根因、影响串起来了。你记住一个原则：超时不是故障本身，而是故障的「症状」。后面的章节，我会带你一层一层剥开这个症状，找到真正的病根。