The ISP Column 互联网视角专栏

其他格式: PDF TXT 数据包大小的考量 2024年10月 Geoff Huston

如今，分组交换网络已经运行了几十年，现在世界上的大部分数字通信服务都依赖于数据包而不是虚拟电路。然而，在这个分组交换的世界中，一些最基本的问题仍然没有答案。也许最基本的问题是：“数据包应该有多大？” 令人惊讶的是，这个问题并没有明确的答案！

目前，互联网上通用的默认答案是，一个互联网数据包的大小在20到1500字节之间。任何更大的数据包都可能遇到数据包分片的问题，从而增加数据包被丢弃的风险。任何更小的数据包，IP 数据包头部可能会被严重截断。因此，大多数主机和应用程序都遵循这个规则，发送在这个大小范围内的的数据包。

情况并非总是如此。1981年9月发布的 RFC 791，《互联网协议规范》中建议 IP 主机必须能够接收最大 576 字节的 IP 数据包（无论它们是完整到达还是分片到达）。只有当发送主机能够保证目标主机（以及数据包转发路径上的活动网络元素）能够接受更大的数据报时，才能使用大于 576 字节的数据包。该文档解释了这种选择的原因：“选择 576 这个数字是为了允许传输合理大小的数据块，以及所需的头部信息。例如，这个大小允许一个 512 字节的数据块加上 64 字节的头部信息放入一个数据报中。最大的 [IPv4] 互联网头部是 60 字节，而典型的互联网头部是 20 字节，为更高级别协议的头部留出了空间。”

以太网（Ethernet）的出现

在20世纪70年代中期，人们开始研究一种完全不同的高速网络形式，用于局域网。最初的发表描述是“以太网：用于本地计算机网络的分布式分组交换”，可以追溯到1976年。由于以太网是一种简单且具有成本效益的中等距离（几公里半径）高速网络解决方案，因此它作为局域网的首选网络技术而获得了发展动力。以太网的主要优点是其分散式设计的简单性。以最简单的形式，网络本身就是一段同轴电缆。最多可以通过简单的信号转发器连接三个这样的长度。没有主控制器，每个主机管理自己的数据时钟并执行自己的争用解决。它是一个公共通道广播网络，每个连接的主机都可以看到每个数据包。当行业从单一的中央大型计算机转向更分布式和多样化的信息处理模型时，以太网非常适合许多计算环境中新兴的个人计算机和工作站环境的网络需求。

对于 10Mbps 以太网，帧（或数据包）有效负载的大小在 46 到 1500 字节之间，以太网帧格式增加了 18 个字节（12 个字节的 MAC 地址，2 个字节的帧长度和 4 个字节的 CRC）。这些帧大小数字是数据时序和网络利用率之间权衡的结果。

最小以太网数据包大小和原始公共总线 (CSMA/CD) 以太网冲突检测算法之间存在一种巧妙的关系。以太网试图维护的一件事是，发送器始终知道是否另一个发送器同时在公共线路中处于活动状态，以便两个发送器都可以中止其传输，退避并在以后重试。因此，以太网帧必须足够大，以便数据包的前导位必须能够传播到以太网网络的另一端，并且与另一个发送器的前沿的冲突必须在帧传输停止之前传播回原始发送器。这意味着 LAN 的总端到端长度必须不超过最小帧大小的一半。

对于最大数据包大小，以太网选择朝着最大化传输效率的方向发展，而不是为了保持隐含的数据时序完整性而牺牲速度和容量。事后看来，这被证明是一个精明的决策。

您可以使最小以太网帧大小更小，但 LAN 本身的最大直径必须缩小，或者您可以支持物理上更长的 LAN，但对于小型帧存在未检测到的帧冲突的风险，这将需要来自上层传输协议的纠正。

光速

这些考虑因素与电磁波在铜导体上的传播速度有关，而这又与真空中的光速有关。

真空中的光速，或物理科学常数 c，可能是所有科学中研究最多的常数。根据电磁理论，当在真空中测量时，其值不应取决于辐射的波长。根据爱因斯坦关于广义相对论中光传播速度的预测，测量的光速不依赖于观察者的参考系；真空中的光速是一个普遍常数。

自 1638 年以来，对 c 值的估计一直在进行改进，当时伽利略在“Two New Sciences”中发表了他对“如果不是瞬时的，那也是非常迅速的”的估计。目前公认的值是每秒 299,792.458 公里。

电荷通过导体传播的速度是一个相关值；它也一直是激烈实验的主题。也许最奇怪的实验是由 Jean-Antoine Nollet 于 1746 年 4 月在巴黎进行的。Nollet 使用一条由大约 200 名僧侣组成的蜿蜒线，通过一英里长的铁丝连接，观察到当他通过铁丝施加强大电流时他们的反应。僧侣们的同步尖叫声表明，就 Nollet 所知，电压通过导体“瞬时”传输。

光在玻璃或光纤电缆中的速度明显较慢，约为每秒 194,865 公里。电压在铜中的传播速度为每秒 224,844 公里。

将此值与以太网的设计联系起来，一个在铜线上运行的 10Mbps 系统将以真空中的光速的 0.75 倍或每秒 224,844 公里的速度传输比特。这意味着 10Mbps 的 64 字节将包含在 11.51 公里的铜缆中，或 5.75 公里的“来回”信号传播中。最初的以太网设计规范允许总共三个 500 米长的同轴铜缆运行，以及 2 个中继器的余量，以及容忍各种物理错误配置的充足开销！

10Mbps 以太网上的最大数据包速率约为每秒 15,000 个小数据包，或每 65 微秒一个数据包。由于硅处理在 20 世纪 80 年代后期的低 MHz 频率下运行，因此传输性能和硅交换能力之间存在大致的匹配。

那么 1518 字节的最大以太网帧大小呢？这里的权衡是，更长的最大帧大小允许更高的传输效率，因为 18 字节的帧开销分摊到更大的数据有效负载上，而更短的最大数据包会减少多个发送器之间存在争用时的平均等待时间。一个二元参数会提出 1,024 或 2,048 字节作为最大有效负载大小，而 1,500 感觉像是这两个值之间某种形式的折衷方案。

这不会是这种折衷方案首次出现在网络技术中。48 字节 ATM 有效负载的设计显然是委员会在 32 字节有效负载（旨在减少 ATM 网络中的潜在抖动）和 64 字节有效负载（旨在提高数据传输效率）的倡导者之间达成的妥协的结果。

FDDI

在 20 世纪 90 年代初期的一小段时间里，看起来下一代本地网络将使用一种名为 FDDI（光纤分布式数据接口）的 100Mbps 令牌环架构。网络本身提供从零（仅 FDDI 标头）到最大尺寸的帧有效负载（高达 4,478 字节）的有效负载范围。

事后看来，很明显 FDDI 从未真正获得部署的关键动力。它用于需要超过 10Mbps 的聚合网络容量的场景中。在许多情况下，它没有取代 10Mbps 以太网，而是充当支持多个 10Mbps 边缘以太网的公共核心。当时，主机使用的 10Mbps 以太网适配器比 FDDI 便宜得多，因此各个主机继续使用 10Mbps LAN 连接，而公共服务器可能使用了 FDDI 连接。然而，在以太网和 FDDI 之间进行映射不仅仅是重新组帧并将数据包传递到下一个。FDDI 上的字节顺序是“big-endian”，而以太网使用“little-endian”字节顺序。更重要的是，FDDI 网络上的最大 IP 数据包大小大于以太网，简单的 FDDI 到以太网桥接单元将被迫丢弃大型 FDDI 数据包。这种混合 FDDI/以太网部署通常使用路由器来执行映射，在 IPv4 大型数据包的情况下，当将数据包从 FDDI 传递到以太网接口时，它们将被分片。这种将“馈送”以太网互连到 FDDI 核心的路由解决方案绝不是最佳的，并且路由器分片和主机重组的开销会降低底层 100Mbps FDDI 系统的底层性能增益。

更快的以太网（Ethernet）

1995 年，发布了 IEEE 802.3u 规范，用于 100Mbps 以太网（快速以太网）。该系统取消了被动公共总线，并将其替换为连接主机的有源交换集线器。维护了以太网帧协议，并保留了 10Mbps 以太网数据包大小范围。潜在的峰值数据包速率提高了 10 倍，达到每秒 150,000 个小（64 字节）数据包到每秒 8,234 个大（1,518 字节）数据包。

三年后的 1999 年，发布了 IEEE 802.3ab，指定了 1Gps 以太网。10Gbps 以太网在 2002 年左右指定。下一个 10 倍速度的提高花费了更长的时间，在 2015 年左右，100Gbps 以太网进入市场。当前的工作重点是完成 Terrabit 以太网 (TbE)。

通过以太网的这种速度提高计划，对支持的帧大小没有基本更改。一旦以太网取消了公共总线模型以及相关的争用检测和管理，并转向实际上是使用公共数据包交换集线器的一系列点对点串行连接，就不需要将以太网数据包大小与特定的一组网络约束绑定在一起，并且支持向后兼容性的愿望（这支持即插即用的混合以太网网络）远远超过了通过更改基本以太网数据包大小规范来实现传输效率的任何微小优势。

Tb 速度的以太网意味着每秒约 1.5B 个小数据包和每秒 82M 个大数据包的峰值数据包速率。

巨型帧大小

在 30 年的时间里，我们设法将本地网络的传输速度惊人地提高了 100,000 倍。与此同时，处理器时钟速度从大约 100Mhz 提高到大约 5Ghz，增幅较小（但仍然令人印象深刻），为 50 倍。今天的硅交换系统只有在大多数数据包都很大时才能跟上传输系统的速度。

似乎传输速度和硅处理时钟速度之间日益增长的差异问题并没有完全被忽视，尤其是在高密度数据中心的背景下。二十多年来，一些以太网交换机和网络接口的供应商一直支持大于 IEEE 802.3 标准 1,518 字节最大帧大小的以太网帧大小。这种变化的规模并不大，所谓的以太网巨型帧中常见的 9,000 字节最大帧大小只是帧大小的 6 倍增加。

但是，这些巨型帧存在许多问题，包括 IEEE 无法为 802.3 网络上的巨型帧提供单一的明确标准。一些网络设备支持更大的巨型帧，一些支持更小的巨型帧。使用各种传输技术构建端到端路径也无济于事。这些链路中的许多链路可能使用通用的以太网帧格式，但这并不意味着在 1,518 字节的 802.3 标准之外存在一致的端到端最大帧大小。如果主机愿意，可以执行一种路径 MTU 发现形式，但是此发现过程会消耗时间。在许多情况下，最快的方法是避免此 MTU 发现步骤，而仅使用 1,500 字节的数据包。

还值得注意的是，随着执行 TCP 分段卸载的网络接口卡的引入，主机施加的引入更大帧的许多压力已消除。主机可以向网络接口发送和接收大帧，从而从主机处理器卸载高数据包处理负载，因为使用较小数据包连接到网络的增量负载在网络接口处理器中处理。例如，对于大型发送卸载，可以将 65,535 字节的数据包从主机传递到网络接口，然后将其分段为 45 个 1,460 字节的段，这些段被传递到网络中。

在处理大型数据包时，互联网协议没有明确的故事。IP（V4 和 V6）都支持最大 65,535 字节的数据包大小（由于两种协议的 IP 标头中都有 16 位数据包长度字段），但在实践中，非常大的 IP 数据包并不是公共互联网的可靠选择。问题在于 IP 分片。正如我们已经注意到的，在不求助于产生路径 MTU 发现成本的情况下，最大的保证路径是假设 MTU 大小约为 1,460 字节。更大的数据包更可能需要分片才能通过网络传递，并且问题在于尾随片段不包含传输标头，并且会给网络中发现的各种形式的安全相关中间件带来问题。这里的权衡是在发送主机中产生数据分段的增量成本，并发送具有较高概率不需要任何形式的数据包分片的数据包，并避免此成本，并在从静默数据包丢弃中恢复时运行会话性能降低的风险。

传输 vs 硅

似乎有点奇怪的是，互联网的故事与以太网的故事相似，其中数据时钟速度的大规模增加（从 10Mbps 到 1Tbps）是在相同的数据包大小范围内实现的。这意味着网络速度的每次增加都以更大的处理强度为代价，其中处理器时钟速度的改进和内存周期时间的总体情况并没有以接近相同的速度增长。

处理响应一直是弥补处理器并行性水平的差异，并通过卸载进行负载分配。到目前为止，似乎处理能力能够大致跟上网络的速度，但尚不清楚这种情况会持续多久。

如果转向支持网络中最大数据包大小的某种增加，则将在一定程度上缓解处理速度的压力，但尚不清楚是否有足够多的支持来支持此类更改。路径 MTU 发现并未受到热烈欢迎（我注意到在 1989 年 11 月 IETF 会议的会议记录中，MTU 发现工作组的任务是解决此问题，并预计到 1990 年 4 月完成某种形式的任务！）对于许多最终主机网络实施来说，更快的方法似乎是选择一个 MTU，该 MTU 可以高度保证在大多数网络中工作，并将路径 MTU 发现作为一种选择，供那些可以利用更大数据包大小的应用程序使用，即使是以执行发现的增量成本为代价。（从这个意义上说，有趣的是注意到 IEEE 802.11 Wifi 规范定义了 2,304 字节的 MTU，但似乎大多数主机实现都使用 1,500 的 MTU 值，以减少从 WiFi 接入网络移动到完整路径中的下一个跃点时潜在的数据包丢失陷阱。）

同样有趣的是，QUIC 传输协议更进一步，默认使用 1,200 字节的路径 MTU。是的，QUIC 可以选择使用路径 MTU 发现，但默认行为似乎只是使用此选项。它只是更快更简单！

虽然平台在速度方面不断扩展，但网络堆栈似乎不愿意承担有效和高效的路径 MTU 发现的任务。实际上，目前的观点是缩小数据包的大小，以避免任何需要 IP 级别的数据包分片。在传输速度不断提高的环境中，这似乎很奇怪，但当涉及数据包大小时，我们似乎在说 1,500 字节是数据包大小的实用上限，并且对于更大的互联网来说，这种立场没有迫在眉睫的迹象。我不确定最初的以太网设计师是否猜到他们最初选择的 1,500 字节在接下来的五十年甚至更长时间里会保持不变！

在公共互联网上的工程共识似乎是，基于最初的 10Mbps 以太网，数据包的大小介于 20 到 1500 字节之间。但一开始的问题是：“数据包应该有多大？”

数据包有效负载越大，传输效率越高。使用 IPv4，1,500 字节的效率为 97%（有效负载与 IP 数据包总大小之比），而在 IPv6 中，效率为 96%。使用 802.3 巨型数据包时，在 9,000 字节的效率为 99.6% (V4) 和 99.3% (V6)。因此，越大越好——对吗？

另一方面，数据包越大，噪声会向有效负载添加位错误的概率就越大，并且如果使用恒定大小的循环冗余校验和，则数据包越大，未检测到的位错误的可能性就越大。在单通道介质中，更大的数据包在数据包被使用时会阻止所有其他人访问该介质，这会增加网络路径的抖动。在 ACK 步进滑动窗口协议（例如 TCP）中，发送方从 ACK 流中的隐式信令推断网络路径的状态。减少这些 ACK 信号的密度（就像更大的数据包一样）会降低发送方调整其发送行为以尝试匹配可用网络条件的能力。

如果我们接受原始 10Mbps 以太网的设计折衷方案，那么 1Tbs 以太网的可比数据包大小范围将为 6.4M 字节到 151M 字节。对于在 6.4M 字节的帧中放置一个 40 字节的 ACK 数据包，这似乎是一个疯狂的填充量！另一种方法是保持原始的最小数据包大小 64 字节，这意味着接收器需要处理每秒 823（大）到 1.5B（小）个数据包的传入数据包速率。

如果我们不愿意更改最小帧大小，那么最大帧大小应该为多少？

如果主机（和应用程序）不愿意执行路径 MTU 发现（由于时间开销），并且该应用程序对 1,518 帧大小提供的效率级别感到满意，那么为什么不只将此值用作主机的接口 MTU？此方法的优点是，可以高度保证此帧大小将在整个以太网组帧网络中工作。如果主机（和接口卡）使用此大小作为默认网络 MTU 大小，那么它们将不会遇到任何可靠性问题，也无需处理当本地连接的网络 MTU 与其他路径组件的 MTU 不匹配时的大小调整问题（在这里，我专门指 IPv6 分片实现以及在网络和连接的主机之间发出分片需求信号的稳健性问题。如果主机只是使用 1,500 字节的 MTU，则所有这些问题都可以避免。

数据包应该有多大？今天的答案与大约 50 年前给出的 10Mbps 以太网的答案相同。对于在公共互联网中使用，46 到 1,500 字节之间的任何大小都是合理的答案。

免责声明

以上观点不一定代表亚太网络信息中心的观点。

关于作者

GEOFF HUSTON AM B.Sc., M.Sc., 是 APNIC 的首席科学家，APNIC 是服务于亚太地区的区域互联网注册机构。 www.potaroo.net