摘要

  • 尾部封装在同一个链路报文里把可变长度的高层协议头移到数据后面，给接收方创造按内存页处理数据的机会；接收后仍要还原正常的高层报文。
  • 普通 ARP 解析成功，只说明找到了链路硬件地址，并不说明邻居理解特殊封装。使用前必须获得相应能力信息。
  • 从 1984 年文档描述的整接口选择，到 1989 年逐目的地协商和默认关闭要求，兼容责任被收窄到实际参与通信的链路双方。

先到，不等于先交给应用

设想一帧数据已经进入接收机器，但解释它的 IP、TCP 头还在后面。这里的“后面”不是下一帧，也不是晚些时候才会发来的控制消息。它们就在同一个链路报文的尾部，等待接收方按特殊格式找到，再放回高层协议应当看到的位置。

这是尾部封装最容易被名称带偏的地方。它不是给文件追加说明，也不是改变 TCP 流的字节次序。线上排列与交给协议栈的逻辑排列，可以由链路接收代码隔开。只要接收方理解格式并正确复原，应用不必知道这次搬家发生过。

1984 年 4 月的 RFC 893 记录了 4.2BSD UNIX 等系统当时使用的办法。文档明确是信息性说明，不是 ARPA Internet 的正式协议。它讨论的不是让全世界统一换一种 IP，而是一个具有特定内存结构的接收方，如何请求邻居帮它减少内部工作。

理解这点，才能看懂后来的限制：一种机器上的高效布局，并不会自然成为另一种机器的义务。

一段可变的头，挡住了一整页

网络数据到达应用，未必只移动一次。设备、内核和用户地址空间之间，都可能出现内存到内存的复制。对采用页式虚拟内存的机器而言，有时可以改页表映射，让同一批数据换一种可访问关系，而不必把每个字节再抄到新位置。

机会是有条件的。RFC 893 讨论的典型前提，是数据从页边界开始，长度为页的整数倍，或补齐到适当边界；它同时说明，具体条件取决于硬件架构与页级保护安排。这不是所有机器都适用的“零复制”承诺。

麻烦来自数据前面的头。链路层前缀可以固定，但 IP、TCP 等封装头的长度可能变化。即使接收缓存的起点选得很好，头部长度一变，真正想交给用户的数据仍可能落在页中间。为了重新对齐而复制，恰好会吃掉希望获得的收益。

尾部封装把这些可变部分挪到数据后面，让数据区在链路固定前缀之后获得更可预测的位置。发送方调整排列，接收方才有机会利用本机的页机制。这里优化的对象是接收路径，不是线路本身突然传得更快。

文档以 VAX 和 512 字节数据块解释过当时的布局。这是一个时代与架构相关的例子，不能当成今天计算机的统一页大小，也不能据此给每个 IP 或 TCP 头规定不变长度。没有独立测量，历史作者对其实现收益的报告也不应变成今日性能数字。

把头找回来，才算收到原报文

特殊排列必须可辨认。链路类型信息指出这是尾部格式，并帮助接收代码确定数据区之后的位置。尾部还带有原协议类型、头部长度信息以及原来的高层协议头。接收方去掉封装所需的部分，再把高层头与数据恢复成正常关系。

因此，发送端并没有把“如何解释数据”的责任交给猜测。它用另一套链路级识别规则暂时代替正常的前置头。失去这套规则，接收方看到的就不是一个可直接交给普通 IP 处理的布局。

同月发布的 RFC 894 提供了标准的 IP over Ethernet 对照：以太类型标识 IP，IP 头后面直接跟 IP 数据。链路为了达到最小数据长度而添加的填充，不属于 IP 总长度所计算的内容。尾部封装是经同意使用的另一种链路排列，不会因为仍然运送 IP，就与普通布局自动兼容。

它也不会扩大链路容量。阅读旧文还需要核对勘误：勘误 570 的状态为 Verified，纠正 RFC 894 中把 1500 字节称为“最小值”的用词，应为“最大值”。重新排列、编码可表达的范围与链路允许的实际长度，是三个不同问题。

省下复制，也可能失去早看一眼的机会

RFC 893 并未把这项设计写成没有代价的进步。接收者首先要愿意并能够使用；实现对齐的代价不能超过节约；挪到尾部的头应相对较小；避免复制的收益还要值得增加软件复杂度。

另一个代价来自时间。头在尾部，接收方就要等整包到齐，才能进行依赖这些信息的协议处理。习惯边收边看头的实现，可能失去提前判断、提前拒绝或选择接收资源的机会。

文档承认，推迟类型识别是一项有效批评。它的回应有明确边界：所讨论的 DMA 接收情形，本来就在整包传完后才开始相应处理。这个条件能解释为什么那种实现愿意接受交换，却不能证明今天所有 DMA 硬件都没有早期处理能力。

同样的线序变化，在一台机器上可能减少昂贵复制，在另一台上却只增加缓冲和分支。兼容性要求之所以不是附加礼节，正因为优化的收益与成本并不均匀分布。

一张网卡的开关，装不下所有邻居

RFC 894 允许同一 Ethernet 上同意使用的系统互相采用尾部封装，但没有要求任何主机必须实现。发送者需要明确知道对方能够解释，不能把“我发得出来”当成“你应当收得懂”。

1984 年两份文档描述的 4.2BSD 选择仍比较粗：启动时按接口决定使用或从不发送尾部格式。共享介质上的接收者需要形成相应的一致配合。通过 ARP 扩展获得逐主机信息，当时被描述为考虑中或预期会有的改进。

这不是对所有 BSD 版本的永久判断，也不能用来推断每家实现的首次上线日期。它说明的是，文档当时面对的操作单位是接口，而真正的能力差异却存在于邻居之间。

到 1989 年 10 月，RFC 1122 第 2.3.1 节把边界写得更细：链路双方，无论主机还是网关，都确认支持后才可使用；若没有动态的逐目的地协商，默认配置必须禁用。它没有禁止自愿优化，而是拒绝让一个未验证的全局假设成为默认行为。

ARP 找到了谁，还没说明谁会读

普通 ARP 成功，不是对所有封装格式的验收。RFC 826 中，路由先选定链路与下一跳，ARP 再把相应协议地址关联到链路硬件地址。外层 Ethernet 的 ARP 类型、ARP 内容里的协议地址空间，以及区分请求和应答的操作码，各自承担不同功能。

RFC 1122 描述的协商保留普通 IP ARP 交换。愿意接收尾部格式的一方另外发一条 Trailer ARP 应答，在 ARP 内使用相应的协议类型。它不是把所有普通 IP 应答替换掉，也不是要求先发一种新的尾部 ARP 请求。

收到普通请求的一方，可以在正常 IP 应答旁附加能力应答；发起请求的一方，则可在收到匹配的正常应答时反向通告自己的接收能力。两种角色都能表达“我可以收”，但通告并不是对应用数据的确认，也不保证速度，更不带来密码学身份验证。

已经配置为使用该格式的主机，可以把邻居能力记入本地状态，例如 ARP 缓存中的标记。所谓“目的地”，在这里要保持链路语境。1987 年 6 月的 RFC 1009 讨论网关与 proxy ARP：网关可能以自己的接口地址回应一个可以转发到的离链目标。学到的链路对端，不一定就是应用最终联系的远端主机；它的能力也不能替整条路径作证。

回复必须有一个结束条件

额外应答还有一个小而重要的约束。有行为不当的主机，可能对 Trailer ARP 应答再发普通 IP ARP 应答。若另一方对每条普通应答都发能力应答，两边就可能不断互相触发。

RFC 1122 因而限制了“收到应答后再通告”这一分支：普通应答必须是在解决一个尚未完成的请求，也就是处理它之前硬件地址仍未知。给收到的请求发送正常答复时，附加能力应答则是另一种情况。

结束条件不在某个凭空添加的重试次数里，而在本地有没有待完成的工作。只看当前包的类型还不够；实现要知道它为何到来。

这与尾部封装的另一种故障相呼应。RFC 1122 提醒，只有具备某些大小属性的包才会被选为特殊格式，因此不兼容时可以有些包成功，有些包消失。小规模通信成功，无法证明所有路径都兼容。但这也不是“所有大包必坏”，更不是看到大小相关丢包就可以断定尾部封装。需要把实际格式、选择条件与邻居状态对在一起。