2. TCP/IP协议栈详解

这一章，咱们聊聊数据包在协议栈里到底是怎么“跑”的。很多搞网络的看了多年 TCP/IP 图，但真要分析吞吐瓶颈时，却说不清每一层到底干了什么、费了多少开销。

我个人习惯把协议栈想象成一台“包快递流水线”——每经过一层，就套一个信封，信封上有不同的地址和说明。到了接收端，再一层层拆开。每次套信封和拆信封，都有代价。下面我们就掰开揉碎看看每一层的开销。

2.1 数据包的封装与解封装

先看发送方向。应用层扔出一块数据（比如 HTTP 请求报文），然后传输层给它加上 TCP 头（或 UDP 头），变成段（Segment）。接着网络层加上 IP 头，变成包（Packet）。链路层再加上 以太网头 和尾部校验，变成帧（Frame）。最后物理层把帧编码成比特流，扔到线缆上。

接收方顺序反过来，每一层剥掉对应的头部，把数据往上送。整个过程就像俄罗斯套娃。

下面我用一张图把全过程串起来——

2.2 各层开销深度分析

记住这张图后，咱们看看每一层具体“吃”掉多少带宽。我直接给出一张对比表，你一眼就能看出大小差异——

2.3 实战：千兆以太网的理论与实测吞吐

千兆以太网，线速是 1 Gbps = 1,000,000,000 比特/秒（注意不是 1024 进制）。但在协议栈眼里，这 1 Gbps 包含了所有帧间隙、前导码、帧头和校验。真正能被应用层用到多少？

先算一个标准以太网帧的时长。假设帧长 L（不含前导码和间隙，但包括以太网头、IP 头、TCP 头、有效载荷、FCS），那么线缆上实际发送的“物理帧”长度是 L + 8（前导码）+ 12（IPG最小）。所以链路利用率 = L / (L + 20)。下面这个表很实用——

看到没？只靠增大帧长，最多能从 762 Mbps 提升到 998 Mbps，差 236 Mbps 呢！我在一个数据中心项目中，就是因为 NFS 默认用巨型帧，吞吐从 820M 飙到 990M+。这也是为什么 iSCSI、NFS 这类协议强烈推荐 jumbo frames。

2.4 避坑指南：你可能忽略的开销

• TCP 选项膨胀：时间戳 12B，SACK 许可 2B，窗口缩放 3B……如果两端的 TCP 栈用了很多选项，MSS 会被压缩。我在某云厂商排查时发现，Linux 默认开了 TCP 时间戳，每个包额外多 12 字节，当时还没用巨型帧，一下子有效吞吐掉了近 1%。
• VLAN 标签：给帧额外加 4 字节，如果你在接入交换机口用 trunk，帧长变成 1522，有些老旧交换机就丢弃了，造成丢包重传。我曾经因为配置不当，导致跨 VLAN 的 iSCSI 流量吞吐只有 400M。
• IP 分片：当 IP 包超过 MTU 且未设置 DF 位时，中间网络设备会分片。分片导致额外头部开销和重组负担。嗯，这个在千兆网里很少见，但万一遇到，吞吐直接腰斩。
• 以太网最小帧限制：如果大量小包（例如 64B ACK 包），物理层利用率降到 76%，CPU 还需要每秒处理 14.88 万个小包，硬件中断暴涨。这时你看到网卡跑不满 1G，可能不是带宽不够，而是包率爆了。