网络分层模型回顾：OSI七层模型与TCP/IP四层模型，超时问题可能发生在哪一层？
聊超时排查，绕不开网络分层模型。很多新手一上来就抓包，结果看得一头雾水。我个人的习惯是——先定位问题出在哪一层，再动手。方向对了，效率才能上来。
说白了，网络分层就是把复杂的通信过程拆成几个独立的模块。每一层只管自己的事，出了问题也只在那一层里找原因。超时问题，本质上就是某一层的“预期响应”没有在时间内到达。
OSI七层模型 vs TCP/IP四层模型
先看个对比，心里有个底。
| OSI七层模型 | TCP/IP四层模型 | 典型协议/设备 | 超时常见场景 |
|---|---|---|---|
| 应用层 | 应用层 | HTTP, DNS, SSH, FTP | HTTP 504, DNS查询超时 |
| 表示层 | SSL/TLS, 数据加密 | 证书验证超时 | |
| 会话层 | NetBIOS, RPC | 会话建立超时 | |
| 传输层 | 传输层 | TCP, UDP | TCP连接超时, 重传超时 |
| 网络层 | 网络层 | IP, ICMP, 路由器 | 路由不可达, TTL超时 |
| 数据链路层 | 网络接口层 | 以太网, MAC, 交换机 | ARP超时, 链路断开 |
| 物理层 | 网线, 光纤, 信号 | 物理断连, 信号衰减 |
你想想看，实际工作中我们很少直接拿OSI七层去套。TCP/IP四层模型更实用，但OSI的细分层在排查某些边界问题时特别好用——比如SSL握手超时，你光看传输层是看不出名堂的。
超时问题到底发生在哪一层？
这个问题没有标准答案。因为同一个“连接超时”现象，可能根因在不同层。我习惯按这个思路来分层定位：
核心原则：从底层往上层查。物理层没问题，再看链路层；链路层通了，再看网络层。一层一层往上推，不要跳层。
1. 物理层 & 数据链路层
这是最容易被忽略的一层。我记得有一次线上告警，所有服务器都连不上数据库。查了半天，最后发现是机柜的交换机光模块坏了。物理层断了，上层再折腾也没用。
- 典型现象：网卡灯不亮、ping完全不通、ARP请求无响应。
- 超时表现：连接建立阶段直接卡死，没有任何回包。
- 排查手段：看网卡状态、换网线、检查交换机端口。
2. 网络层
这一层出超时，最常见的就是路由问题。我曾经遇到一个案例：两台服务器在同一网段却ping不通，结果是其中一台的默认网关配置错了，导致ICMP报文被丢到了外网。
- 典型现象：ping超时、traceroute中途断掉、TTL超时。
- 超时表现：请求发出后没有ICMP回包，或者收到“Destination Unreachable”。
- 排查手段：traceroute看路径、检查路由表、确认防火墙规则。
3. 传输层
这是超时问题的“重灾区”。TCP的三次握手、四次挥手，任何一个环节卡住都会导致超时。我排查过的超时案例里，大概有60%都跟传输层有关。
- 典型现象：TCP连接超时、SYN重传、连接被RST。
- 超时表现：客户端发SYN后一直没收到SYN-ACK，或者收到后ACK丢了。
- 排查手段：抓包看TCP握手状态、检查半连接队列、确认端口是否监听。
一个小技巧：用 ss -tlnp 看端口监听状态，用 netstat -s 看TCP重传统计。如果重传率超过1%，基本可以断定传输层有问题。
4. 应用层
应用层超时往往最隐蔽。因为底层通信是通的，但应用逻辑没响应。比如HTTP的504 Gateway Timeout，就是上游服务没在规定时间内返回数据。
- 典型现象：HTTP 504/502、数据库连接池耗尽、DNS解析超时。
- 超时表现：TCP连接已建立，但应用层数据迟迟不来。
- 排查手段：看应用日志、检查线程池/连接池状态、确认DNS解析耗时。
一张图看懂分层排查逻辑
下面这张图是我自己总结的排查路径。每次遇到超时，我就按这个顺序过一遍，基本不会漏。
避坑指南：我踩过的几个坑
我曾经犯过一个低级错误：线上服务超时，我盯着应用日志看了两个小时，各种调超时参数。最后发现是网线被机柜门夹住了，物理层断了。从那以后，我排查超时的第一步永远是——先看物理层。
还有一次，客户反馈连接经常超时。我抓包发现TCP有大量重传，但网络层ping是通的。后来发现是MTU不匹配，导致大包被分片后丢失。嗯，这个问题卡在网络层和传输层的交界处，光看一层是看不出来的。
总结一下
超时问题可能发生在任何一层。但只要你掌握了分层排查的思路，就不会慌。我个人习惯用这个口诀：
- 物理链路先确认——灯亮不亮？线插没插？
- 网络层看路由——traceroute走一遍。
- 传输层抓包看——SYN、ACK、RST，一个都不能少。
- 应用层查日志——超时参数、线程池、连接池。
记住，网络分层不是理论，是工具。用好了，超时问题就是一层窗户纸。