1. 连接超时概述
大家好，我是老张。做网络排查十几年，我遇到最多的问题就是——连接超时。说白了，就是客户端发了个请求，服务器半天没回应，最后客户端撂挑子了：「我等不了了，超时！」
你想想看，用户点个按钮，转圈转半天，最后弹个「网络连接失败」。这体验，谁受得了？
1.1 什么是连接超时
连接超时，指的是客户端发起网络连接请求后，在规定时间内没有收到预期的响应，从而主动终止连接尝试的过程。
举个例子：你打电话给朋友，拨号后等了30秒没人接，你挂了。这就是超时。
在TCP/IP网络里，超时通常发生在三个层面：
- TCP三次握手超时——SYN包发出去，没收到SYN-ACK
- 应用层响应超时——连接建立后，请求发出去，服务器没回数据
- DNS解析超时——域名查不到IP，或者查询过程卡住了
核心要点：超时不是「连接断了」，而是「在规定时间内没等到该来的东西」。这个「规定时间」由操作系统或应用程序的超时计时器决定。
1.2 超时发生的网络层级
我习惯把超时问题按OSI模型分层来看。不同层级的超时，表现和根因完全不同。
| 网络层级 | 典型超时场景 | 常见原因 |
|---|---|---|
| 应用层（HTTP/HTTPS） | 请求发出去，服务器没回200 | 后端处理慢、线程池满、数据库卡死 |
| 传输层（TCP） | 三次握手没完成 | 防火墙丢包、服务器端口未监听、网络拥堵 |
| 网络层（IP） | ICMP不可达或TTL超时 | 路由环路、路由表错误、MTU问题 |
| DNS层 | 域名解析无响应 | DNS服务器挂了、缓存污染、网络隔离 |
我记得有一次，客户说「网页打不开，一直转圈」。我抓包一看，TCP三次握手都完成了，HTTP请求也发出去了，但服务器就是没回数据。最后发现是后端Java应用Full GC卡了20秒。嗯，这是典型的应用层超时。
1.3 超时对业务的影响
超时不是小事。它带来的影响往往是连锁反应：
- 用户体验直线下降——页面白屏、按钮无响应、操作失败
- 业务中断——支付超时导致订单失败、API调用超时导致服务降级
- 雪崩效应——一个服务超时，导致上游服务线程池被占满，进而拖垮整个链路
- 数据不一致——分布式系统中，超时可能导致事务状态不确定
我曾经踩过的坑：有一次线上支付接口频繁超时，我以为是网络问题。查了半天才发现，是数据库连接池配置太小，请求排队等连接，等超时了。所以，超时问题不一定是网络问题，也可能是后端资源瓶颈。
1.4 诊断思路总览
面对超时问题，我的诊断思路可以总结为一张图：
我的诊断流程大致分四步：
- 确认现象——什么业务超时？超时时间是多少？是偶发还是持续？
- 分层定位——用抓包工具（Wireshark/tcpdump）确认超时发生在哪一层
- 根因分析——根据抓包结果，结合系统日志、监控数据，找到根本原因
- 验证闭环——修复后再次抓包，确认超时不再出现
我的小习惯：每次诊断超时问题，我都会先看一眼超时时间配置。很多「超时」其实是超时时间设得太短，业务正常处理就需要那么久。调大超时时间，问题就解决了。当然，这治标不治本，但至少能先恢复业务。
好了，这一章我们先把超时的概念和诊断思路理清楚。后面几章，我会带大家用Wireshark一步步抓包，看各种超时场景的「现场照片」。你会发现，抓包就像看监控录像，真相就在那里。