1. 连接超时概述：什么是连接超时、超时分类、超时对业务的影响

大家好，我是老张。做网络运维十几年了，处理过的超时问题少说也有上千个。今天咱们聊聊连接超时——这个让运维人又爱又恨的话题。

说白了，连接超时就是一个请求在规定时间内没得到响应。你想想看，你给朋友发了条，等了半天没回，这就是超时。只不过在计算机世界里，这个“朋友”可能是数据库、API接口或者某个微服务。

连接超时的本质，是通信双方在预期时间内未能完成握手或数据交换。我习惯把它分成两个维度来看：

核心要点：超时不是故障本身，而是故障的表现形式。就像发烧不是病，是症状一样。我们要找的是引起超时的根因，而不是单纯把超时时间调大。

我记得刚入行那会儿，遇到超时第一反应就是改大超时阈值。结果呢？系统越来越慢，用户投诉越来越多。后来才明白——超时是系统在告诉你：出问题了，快查查。

实际工作中，我遇到的超时主要分三类。咱们一个一个说。

TCP连接超时，是最底层、最常见的超时类型。它发生在三次握手阶段。

你想想看，客户端发了个SYN包，服务器没回SYN-ACK。客户端等啊等，等到超时阈值到了，就放弃了。这就是TCP连接超时。

我的经验：TCP连接超时通常不是代码问题，而是网络问题。防火墙拦截、路由不可达、服务器负载过高，都可能导致SYN包石沉大海。

我曾经处理过一个案例：某业务凌晨突然大面积超时，查了半天发现是防火墙策略变更，把某个端口给封了。嗯，这种问题最坑人——白天还好好的，半夜就炸了。

HTTP请求超时比TCP超时更“上层”一些。TCP连接已经建好了，但HTTP层面的请求/响应没完成。

我习惯把HTTP超时再细分成几种：

说白了，HTTP超时就是请求发出去了，但响应没在规定时间内回来。我见过最离谱的情况是：一个接口正常响应50ms，但偶尔会卡到30秒。查到最后发现是某个定时任务在整点抢锁，导致接口排队。

数据库连接超时，是后端开发最头疼的问题之一。它通常表现为：

数据库连接超时的根因，我总结下来无非这么几种：

避坑指南：我曾经遇到过一个问题——数据库连接池配置了100个连接，但应用一启动就报超时。查了半天发现是连接池的maxWait设置成了-1（无限等待），结果所有线程都卡在获取连接上。嗯，有时候配置项太多，反而容易踩坑。

超时不是小事。我见过太多因为超时处理不当导致的线上事故了。咱们用一张图来看看超时的影响链路：

从这张图能看出来，超时的影响是逐级放大的。我见过最典型的场景是这样的：

真实案例：某电商平台大促期间，一个商品详情接口因为数据库慢查询导致响应时间从50ms飙升到5s。前端设置的超时是3s，结果所有请求都超时重试。重试次数一多，数据库连接池直接被打满。最终导致整个商品模块不可用，持续了20分钟。嗯，这就是典型的超时引发雪崩。

超时对业务的具体影响，我总结成几个维度：

我的建议：处理超时问题，不要只盯着超时时间本身。我习惯先问三个问题：

这三个问题问完，基本能锁定一半的根因。

好了，这一章咱们把连接超时的概念、分类和影响理清楚了。说白了，超时就是系统在喊救命。你听懂它喊的是什么，才能对症下药。