OSI 七层模型：从背诵到排障

很多人第一次接触 OSI 七层模型的感受是：能背出来，但不知道有什么用。

我自己的用法只有一个：把它当作排障时的“共同语言”。

当你和别人讨论网络问题时，能说清楚“我怀疑问题在第几层”，往往比贴一堆截图更高效。

七层到底各管什么#

下面这张表不追求严谨的学术定义，只追求“实用”。

层	名称	你真正会遇到的东西	常见例子
7	应用层	业务语义、协议字段、请求/响应	HTTP(S), DNS, SSH, MQTT
6	表示层	编码/加密/压缩（最典型：TLS）	TLS/SSL, JSON, gzip
5	会话层	连接的建立/维持/恢复（很多时候被库“吞掉”）	连接复用、会话恢复
4	传输层	端口、可靠性、拥塞控制	TCP, UDP, QUIC(基于UDP)
3	网络层	IP、路由、跨网段可达性	IPv4/IPv6, ICMP, 路由表
2	数据链路层	同一二层域内的转发、MAC、ARP	Ethernet, Wi‑Fi, ARP, VLAN
1	物理层	线材/信号/射频/光口	网线、光模块、信号强度

你不需要把“会话层/表示层”分得特别死。工程里最常用的分法是：

L1-L2：链路是否真的通
L3：IP 是否可达、路由是否正确
L4：端口/传输是否可用
L7：协议/应用是否正常

OSI 与 TCP/IP 的对应关系（够用版）#

现实世界大多数文档会用 TCP/IP 四层/五层模型。你可以粗略这样映射：

TCP/IP 应用层 ≈ OSI 的 L5-L7
TCP/IP 传输层 = OSI L4
TCP/IP 网际层 = OSI L3
TCP/IP 链路层 ≈ OSI L1-L2

别被“模型不一致”吓到：模型是为了帮助你定位问题，不是为了把世界划分得绝对正确。

用七层模型做排障：一套可复用的检查顺序#

下面给一个我最常用的“由下到上”流程（也适合写在 issue 模板里）：

1）L1/L2：链路#

网线/光口/无线是否连接正常？
同网段内是否能看到对方（交换机、AP、网卡状态）？
arp -a 是否出现目标 MAC（同二层域）？

2）L3：IP 与路由#

本机 IP/网关/DNS 是否正确？
ping <网关>、ping <同网段主机>、ping <跨网段主机> 分别怎样？
ip route/route -n 是否存在正确的默认路由？

3）L4：端口与传输#

TCP：nc -vz host port / curl -v 能否建立连接？
UDP：能否抓包看到双向流量（UDP 不一定“有连接”可判定）？
防火墙/安全组是否拦了端口？

4）L7：协议与业务#

HTTP：状态码是什么？是否 301/403/502？
DNS：是否解析到了预期 IP？是否被污染/劫持？
TLS：证书域名、SNI、时间是否正确？

两个最常见的“概念误会”#

误会 1：HTTPS 都是“应用层”的事#

HTTP 的语义（URL、Header、Status Code）是应用层（L7）。但加密本身（TLS）更像表示层（L6）。

工程里遇到的典型现象：

curl http://... 正常
curl https://... 失败

这经常意味着：链路/路由/端口没问题，问题集中在 TLS（证书、SNI、握手版本、时间）。

误会 2：NAT 是“路由”（所以算三层）#

NAT 经常发生在三层设备上，但它做的是“地址转换”，不是“可达性本身”。

工程里更实用的说法是：

路由：决定“包往哪走”（L3 核心）
NAT：决定“包长什么样”（常见于网关/防火墙）

一句话总结#

当网络出问题时，不要上来就说“网络坏了”。试着把问题表述成：

“我怀疑是二层不通（ARP 没回来）”
“三层可达，但四层端口连不上（疑似防火墙）”
“TCP 能握手，但 TLS 握手失败（证书/SNI/时间）”

这就是 OSI 七层在工程里的价值。

Cum historia mutat valde