两套分层模型怎么对上
排障时经常听到「二层通三层不通」「四层负载」「七层问题」，这些术语来自 OSI 七层模型；而实现层面 TCP/IP 只分四层。两者不是一一对应关系：OSI 的会话层与表示层在实际实现里被并入应用层，物理层与数据链路层在网络接口层中实现。把两张表对上，跨团队沟通和工具选择都不会再鸡同鸭讲。
基本信息
| 对应关系 | OSI 七层 → TCP/IP 四层（网络接口层、网际层、传输层、应用层） |
|---|---|
| 层数与实现 | 实现对应用层、表示层、会话层不加区分，统归应用层 |
| 术语来源 | ISO/IEC 7498-1 定义 OSI；RFC 1122/1123 描述 TCP/IP 实现要求 |
| 排查顺序 | 自下而上验证：先看物理与链路，再看 IP 可达，最后看端口与应用 |
| 工具对应 | 每层都有对应的专用工具，混用工具会导致层级判断错误 |
分层与工具对照
| OSI 层 | TCP/IP 层 | 典型协议/设备 | 排障工具 |
|---|---|---|---|
| 物理层 | 网络接口层 | 光电信号、网卡、介质 | ethtool、ip -s link、光功率计 |
| 数据链路层 | 网络接口层 | 以太网、VLAN、STP、交换机 | arping、ip neigh、交换机 show 命令 |
| 网络层 | 网际层 | IP、ICMP、路由、路由器 | ping、traceroute、ip route get |
| 传输层 | 传输层 | TCP、UDP、四层防火墙 | ss、nc、conntrack |
| 会话/表示/应用层 | 应用层 | HTTP、DNS、TLS | curl、dig、tcpdump、openssl |
典型使用场景
- 跨团队沟通对齐术语：把业务侧的描述翻译成具体层级与验证手段
- 选对排查工具：二层问题用 arping，三层用 ping，四层用 nc，七层用 curl
- 界定责任边界：明确「四层监听正常」不等于「HTTP 服务可用」
- 看云产品文档：负载均衡的「四层/七层」指的是 TCP/UDP 与 HTTP 两档能力
- 复盘会上统一口径：用统一层级描述现象，避免各说各话
术语翻译
术语翻译
# 把口头描述翻译成可验证的层级
「二层不通」 → ARP、MAC 地址表、VLAN 层面的问题
「三层不通」 → IP 可达性与路由问题（ping、ip route get）
「四层不通」 → TCP/UDP 端口层面（监听、防火墙、安全组）
「七层问题」 → 应用协议或业务逻辑（HTTP 状态码、TLS、DNS）
# 云平台语境
四层负载 = 转发 TCP/UDP，不解析应用内容
七层负载 = 可解析 HTTP 并做路由、改写、健康检查厂商说「二层转发正常」通常指 MAC 地址表学习正常；云平台说「四层监听」指 TCP/UDP 级别，不包含 HTTP 内容解析。