OSI 与 TCP/IP 分层模型、封装与平面
内容摘要：分层是理解网络的第一工具。本章讲清 OSI 七层与 TCP/IP 四层的对应与差异、数据如何在发送端被逐层封装、在接收端被逐层解封装、每层的**协议数据单元（PDU）**叫什么、以及「控制平面 / 数据平面 / 管理平面」这组正交视角。重点澄清一个高频误区：OSI 不是互联网必须严格遵守的调用栈。
难度：入门 | 前置知识：01 网络基础与互联网结构 | 所属层次：贯穿全层
一、为什么要分层
分层（layering）是一种关注点分离（separation of concerns）：每层只解决一类问题，并向上层提供稳定接口，向下层隐藏实现细节。
- 可替换：把电缆换成 Wi-Fi，上层 TCP/HTTP 不用改（只换链路层实现）。
- 可组合：同一个 IP 层之上可以跑 TCP、UDP、QUIC；同一个 TCP 之上可以跑 HTTP、SMTP、SSH。
- 可独立演进：HTTP/1.1 升到 HTTP/2、TLS 1.2 升到 1.3，不需要改路由器。
代价：分层带来头部开销与跨层信息缺失。例如 TCP 看不到下层链路的真实丢包原因（是拥塞还是无线误码），这正是无线网络里拥塞控制常「误判」的根源（见 14）。分层是取舍，不是免费的。
二、OSI 七层与 TCP/IP 四层
OSI（Open Systems Interconnection，开放系统互连） 模型由 ISO 定义（ISO/IEC 7498-1），共七层，主要用于教学与讨论。TCP/IP 模型（RFC 1122 定义主机要求）是互联网的实际实现，只有四层。
| OSI 层 | TCP/IP 层 | 典型协议 | PDU 名称 | 关键设备/机制 |
|---|---|---|---|---|
| 7 应用 / 6 表示 / 5 会话 | 应用层 | HTTP、DNS、TLS、SMTP | 消息 / 数据（message/data） | 应用、代理、负载均衡 |
| 4 传输 | 传输层 | TCP、UDP、QUIC* | 段（segment，TCP）/ 数据报（datagram，UDP） | 端口、套接字 |
| 3 网络 | 网络层（Internet） | IPv4、IPv6、ICMP | 包 / 分组（packet） | 路由器 |
| 2 数据链路 | 链路层 | 以太网、802.11、ARP | 帧（frame） | 交换机、网卡 |
| 1 物理 | 链路层 | 电/光/电磁信号 | 比特（bit） | 网线、光纤、集线器 |
关于 TLS 与 QUIC 的层次归属：TLS 通常被描述为「介于传输层与应用层之间」的安全层；QUIC 在 UDP 之上实现了传输+安全+多路复用，模糊了传统分层。这类协议正是「OSI 不是严格调用栈」的最好例证——不要强行把它们塞进某一层，理解其职责比贴标签更重要（见 16、17）。
关键澄清：OSI ≠ 互联网的实现
这是本库的硬性纠偏：
- 互联网按 RFC 1122 的 TCP/IP 四层实现，没有严格的会话层与表示层实体。
- OSI 是参考模型，方便交流「工作在第几层」（如「四层负载均衡」「七层网关」），但报文在真实协议栈里并不会经过七个独立模块。
- 用「层」定位问题很有用（如「这是三层可达但四层不通」），但不要把 OSI 当成代码调用链。
三、封装与解封装：数据在栈里的旅程
封装（encapsulation）：发送端自上而下，每层给上层数据加上本层头部（有时含尾部），形成本层 PDU。解封装（decapsulation）：接收端自下而上，每层剥离本层头部、按其中的「上层协议」字段交给正确的上层。
每层如何知道「上层是谁」——靠头部里的「解复用键（demultiplexing key）」：
| 边界 | 解复用字段 | 示例值 | 抓包显示 |
|---|---|---|---|
| 以太网 → 网络层 | 以太网头 EtherType | 0x0800=IPv4、0x86DD=IPv6、0x0806=ARP | Wireshark「Type」 |
| IP → 传输层 | IPv4 Protocol / IPv6 Next Header | 6=TCP、17=UDP、1=ICMP | 「Protocol」 |
| TCP/UDP → 应用 | 目的端口（Destination Port） | 80/443/53 | 「Dst Port」 |
设计动机：这套「层层解复用」让同一台主机能同时跑多种协议与多个连接——网卡收到一个帧，靠 EtherType 判断交给 IPv4 还是 ARP；IP 靠 Protocol 判断交给 TCP 还是 UDP；TCP 靠端口交给正确的套接字。四元组（源 IP、源端口、目的 IP、目的端口）+ 协议唯一确定一条连接（见 13）。
头部开销与 MTU 的联系
每层头部都占字节。以经典以太网为例（数值为常见值，具体见 03、05、09）：
- 以太网头 14 字节 + FCS 4 字节；标准 MTU（Maximum Transmission Unit，最大传输单元）= 1500 字节（指 IP 载荷上限）。
- 典型 IPv4 头 20 字节 + TCP 头 20 字节 → 一个「满帧」里应用数据约 1460 字节（即 TCP 的 MSS）。
为什么重要：封装开销直接决定「一个包能装多少有效数据」，进而影响吞吐；而当路径上某段 MTU 更小又禁掉 ICMP 时，会出现「小包通、大包卡」的 PMTUD 黑洞（详见 09）。分层的头部开销不是抽象概念，它会变成真实故障。
四、跨层交互：分层不是「老死不相往来」
严格分层是理想，工程实现中存在大量跨层信息传递：
- PMTUD：三层 ICMP「需分片」错误会反馈影响 TCP 的分段大小（09）。
- QoS：应用/传输层的标记（DSCP）写在 IP 头，供链路层排队调度（QoS 与高可用）。
- 硬件卸载（offload）：网卡把本属传输层的校验和、分段（TSO/GRO）下沉到硬件做，这会改变你在本机抓包看到的包大小（见 04、20 抓包与实验）。
排障启示：正因为存在跨层交互与卸载，「在发送主机抓到的包」未必等于「真正上线的包」。这是本库反复强调「多点抓包、双向验证」的底层原因（20 抓包与实验、分层故障排查）。
五、另一组正交视角：控制/数据/管理平面
「分层」是纵向切分；「平面（plane）」是横向按职责切分，二者正交，都要掌握。
| 平面 | 职责 | 典型协议/机制 | 故障表现 |
|---|---|---|---|
| 控制平面 | 决定「怎么转」 | OSPF/BGP、ARP/NDP、STP、DHCP | 路由收敛慢、黑洞、环路 |
| 数据平面（转发平面） | 实际「搬数据」 | FIB 查表、ASIC/eBPF 转发 | 丢包、时延、限速 |
| 管理平面 | 配置与观测 | SSH、SNMP、NETCONF、日志 | 失联、无法运维 |
工程价值：区分平面能精准描述故障。例如「控制平面正常（路由表对）但数据平面丢包」指向硬件/队列问题；「数据平面通但管理平面失联」是运维事故（这也是本库强调带外访问与防失联的原因，见 防火墙与访问控制）。SDN（软件定义网络）的核心思想正是把控制平面与数据平面解耦。
六、最小可复现实验：亲眼看到「层层封装」
用只读命令观察同一次通信在不同层的表现。仅访问文档域名 example.com。
1、实验目标
- 在一次 HTTPS 请求里，分别观察链路层（MAC）、网络层（IP）、传输层（端口）与应用层（HTTP/TLS）的证据。
2、平台与工具
- 本机验证环境：macOS 26.6.2，
curl 8.7.1。Linux 上ip/ss命令见注释；抓包用tcpdump（需要权限，见 20 抓包与实验）。
3、执行命令
传输层 + 应用层证据（一条命令看穿多层，本机可跑）：
curl -sS -o /dev/null -w \
'link: 本机 MAC 由网卡决定(见下条命令)\nnet(IP) = remote_ip=%{remote_ip} local_ip=%{local_ip}\ntransport= remote_port=%{remote_port} local_port=%{local_port}\napp = http_version=%{http_version} code=%{response_code} scheme=%{scheme}\n' \
https://example.com/本机实测（2026-09-07）：
net(IP) = remote_ip=104.20.23.154 local_ip=192.168.x.x
transport= remote_port=443 local_port=54xxx
app = http_version=2 code=200 scheme=HTTPS解读：一条
curl里同时暴露了网络层（IP）、传输层（端口，443=对端 HTTPS 服务，本地是临时端口/ephemeral port）、应用层（HTTP/2、状态码）。本地 IP 被我脱敏为192.168.x.x（RFC 1918 私有段），遵循本库脱敏规范。
链路层证据（查看本机接口 MAC 与链路，只读）：
# macOS（本机可跑）
ifconfig en0 | grep -E 'ether|inet '
# Linux 等价（iproute2）
ip -br link show
ip -br address show抓包看封装层次（需权限，限定包数，见 20 抓包与实验 的授权与脱敏要求）：
sudo tcpdump -i any -nn -c 5 'tcp port 443 and host example.com'4、预期现象
curl输出中，remote_port=443是对端知名端口，local_port是临时端口（每次不同）。tcpdump每行会显示IP src.sport > dst.dport: Flags [...]，即网络层地址 + 传输层端口 + TCP 标志位同屏呈现，直观体现「一层套一层」。- 由于 TLS 加密，应用层内容不可见，只能看到 TCP/TLS 记录层——这正是加密对抓包的影响（见 17、20 抓包与实验）。
5、结论边界与清理
- 上述为单主机、单次观测，
local_ip/端口/对端 IP 均随环境变化，不可推广。 - 只读命令无需清理；
tcpdump若写入 PCAP，须按脱敏规范删除敏感字段后再引用。
七、错误示例与常见误区
| 误区 | 纠正 |
|---|---|
| 「数据在协议栈里真的经过 OSI 七个模块」 | OSI 是参考模型；互联网实现是 TCP/IP 四层，无独立会话/表示层实体。 |
| 「TLS 就是第 5 层（会话层）」 | TLS 职责跨传输与应用之间，不必强行归层；理解其加密/认证职责更重要。 |
| 「本机抓到的包 = 上线的包」 | 网卡卸载（TSO/GRO/校验和）会改变本机可见的包大小与校验，需在链路上或多点验证。 |
| 「分层保证每层独立无关」 | 存在大量跨层交互（PMTUD、QoS、卸载），排障必须考虑。 |
| 「控制平面通 = 业务通」 | 控制平面（路由对）与数据平面（真转发）可能分离；要分别验证。 |
八、性能影响
- 头部开销：每层头部降低有效载荷比例（payload efficiency）。小包场景（如高频 RPC）开销占比更高，是「包速率（pps）瓶颈」的常见来源（见 性能观测）。
- 封装/解封装成本：每层处理都消耗 CPU；高吞吐场景依赖网卡卸载与零拷贝降低开销（04）。
- 跨层误判：无线链路误码被 TCP 误当拥塞而降速，是分层「信息缺失」导致的性能问题（14）。
九、安全风险与加固
- 分层 = 分层防御点：可在链路层（端口安全）、网络层（ACL/防火墙，防火墙与访问控制）、传输层（TLS，17）、应用层（WAF，网络安全）分别设防，构成纵深防御。
- 封装也被攻击利用：VLAN 跳跃、隧道封装绕过检测等（VPN 与隧道、网络安全）。
- 管理平面隔离：管理平面应与数据平面隔离，避免业务流量影响运维通道，或运维接口被攻击面暴露。
十、版本与平台差异
- RFC 1122/1123 定义 TCP/IP 主机要求，是四层模型的权威依据；OSI 见 ISO/IEC 7498-1。
- Linux vs macOS/Windows：分层模型一致，但工具不同——Linux 用
ip/ss/tc，macOS 用ifconfig/netstat，Windows 用ipconfig/netsh。本库实验主体为 Linux，差异处单独标注。
十一、常见问题与排查方向
- 「三层能 ping 通但四层连不上」：网络层可达，传输层可能被防火墙拦、端口未监听或队列满（13、防火墙与访问控制）。
- 「抓包看到的包比预期大很多」：网卡 GRO/TSO 卸载所致，非异常（20 抓包与实验）。
- 「能配置但业务不通」：区分管理/控制/数据平面，逐平面验证。
十二、关联章节
检索关键词
OSI 七层 TCP/IP 四层 封装 解封装 PDU 帧包段 EtherType Protocol 端口 解复用 四元组 控制平面 数据平面 管理平面 OSI 不是调用栈 跨层交互 卸载
权威来源
- RFC 1122 / RFC 1123《Requirements for Internet Hosts》（TCP/IP 分层与主机要求）
- ISO/IEC 7498-1（OSI 参考模型）
- IANA EtherType、Protocol Numbers、Port 注册表
- Wireshark 官方文档（分层解析与显示）
分层与封装以 RFC 1122/1123 与 ISO/IEC 7498-1 为准，
verified_at: 2026-09-07；实测命令输出来自 macOS 26.6.2 本机，本地地址已按规范脱敏。