一个数据包究竟有多大?

科技   2024-10-28 17:12   江苏  

我们已经运行了几十年的分组交换网络,但一些极为基础的问题仍未得到明确解答。其中,最基本的问题莫过于:“一个数据包应该有多大?”令人惊讶的是,这个问题至今没有明确的答案。

当前,互联网在实际操作中默认的数据包大小范围在20到1,500个八位字节之间。若数据包过大,可能会遭遇碎片化问题,进而增加数据包丢失的风险;若数据包过小,则IP数据包的报头信息可能会被严重压缩,影响数据的完整性。因此,大多数主机和应用程序都倾向于在这个范围内发送数据包。

然而,情况并非一成不变。1981年9月,互联网协议规范RFC 791指出,IP主机必须能够接收最大为576个八位字节的IP数据包(无论这些数据包是完整到达还是分段到达)。只有当发送主机确信目的地(以及数据包转发路径上的所有网络元素)能够处理更大的数据包时,才允许发送大于576个八位字节的数据包。RFC 791文档对此选择的理由进行了说明:“选择576这个数值是为了在确保报头信息完整的同时,还能传输合理大小的数据块。例如,这个大小可以容纳一个512个八位字节的数据块以及64个八位字节的报头信息(用于构成一个完整的数据报)。最大的IPv4报头是60个八位字节,而典型的互联网报头为20个八位字节,这为更高级别协议的报头信息预留了足够的空间。”

进入以太网

20世纪70年代中期,人们着手研究一种全新的局域网高速网络技术,其中最早于1976年发表的描述为“以太网:局域网分布式分组交换”。以太网凭借其简单且经济高效的特点,迅速成为中距离(半径几公里)高速网络解决方案的首选,特别是在局域网环境中。其显著优势在于分散式设计的简洁性:最基本的以太网形式仅由一段同轴电缆构成,最多可通过简单的信号中继器扩展至三段同轴电缆的连接。没有主控制器,每个主机都能自主管理数据时钟并执行争用解决策略。这是一个公共信道广播网络,每个连接的主机都能接收到网络上的每个数据包。随着信息处理模式从单一中央大型计算机向更分散、多样化的方向转变,以太网完美契合了新兴个人计算机和工作站环境的网络需求。

在10Mbps以太网中,帧(或数据包)的有效载荷大小介于46到1500个八位字节之间,加上以太网帧格式所增加的18个八位字节(包括12个八位字节的MAC地址、2个八位字节的帧长度和4个八位字节的CRC校验),这些帧大小是经过精心权衡数据定时和网络利用率后确定的结果。

最小以太网数据包大小与原始的公共总线(CSMA/CD)以太网冲突检测算法之间存在着紧密关联。以太网的设计确保了当另一个发送器同时在公共线路上活动时,发送器能够立即感知到,从而双方都能中止传输,退出并稍后重试。因此,以太网帧必须足够大,以确保数据包的前导位能够传播到网络的另一端,并且与另一个发送器的前导位发生冲突的信号能在帧传输停止前传回原始发送器。这意味着局域网的总端到端长度不得超过最小帧大小的一半。

对于最大数据包大小,以太网选择了最大化传输效率的路径,而非为了保持隐式数据时序完整性而牺牲速度和容量,这一设计决策后来被证明是极为明智的。

若要使最小以太网帧尺寸更小,则必须缩短局域网的最大直径;若要保持物理上更长的局域网,则可能面临小帧未检测到的帧冲突风险,这需要依赖上层传输协议进行纠正。

10Mbps以太网的最大数据包传输能力约为每秒15,000个小数据包,即每65微秒就能发送一个数据包。鉴于20世纪80年代末硅片处理时钟频率相对较低,当时的传输性能与硅片交换能力基本匹配。

那么,对于最大以太网帧大小——1518个八位字节(或1.518KB)而言,这里存在一个权衡问题。较长的最大帧大小能提升传输效率,因为18个八位字节的帧开销在更大的数据有效负载上会得到更好的分摊。相反,较短的数据包则能减少在多个发射器之间发生争用时的平均等待时间。二进制参数建议将最大有效负载大小设为1,024个八位字节或2,048个八位字节,而1,500个八位字节似乎是对这两个值的某种折衷选择。

FDDI

在20世纪90年代初期,人们曾认为下一代本地网络将采用称为FDDI(光纤分布式数据接口)的100Mbps令牌环架构。FDDI网络支持的有效载荷范围广泛,从零(仅FDDI报头)到最大4,478个八位字节的帧有效载荷。

然而,事实证明,FDDI并未获得关键的部署动力。它主要应用于需要超过10Mbps聚合网络容量的场景,并未完全取代10Mbps以太网,而是常常作为支持多个10Mbps边缘以太网的通用核心网络。当时,由于10Mbps以太网适配器相较于FDDI更为经济实惠,单个主机继续采用10Mbps LAN连接,而普通服务器则可能使用FDDI连接。

但需要注意的是,FDDI与以太网之间的数据包映射并非简单重构和直接传递。FDDI采用“大端”字节顺序,而以太网则使用“小端”字节顺序。此外,FDDI网络上的最大IP数据包大小大于以太网,因此简单的FDDI到以太网桥接单元无法处理大型FDDI数据包,而会将其丢弃。

为了应对这种混合FDDI/以太网部署的挑战,通常使用路由器来执行数据包映射。对于IPv4大数据包,在将数据包从FDDI传递到以太网接口时,路由器会对其进行分割。然而,这种将“馈线”以太网与FDDI核心互连的路由解决方案并非最优选择,因为路由器分割和主机重组的开销会削弱底层100Mbps FDDI系统的性能优势。

更快的以太网

1995年,IEEE 802.3u规范推出了100Mbps以太网(也称为快速以太网)。这一系统摒弃了被动公共总线,转而采用主动交换集线器,主机通过该集线器进行连接。同时,以太网帧协议以及10Mbps以太网的数据包大小范围均得以保留。其潜在峰值数据包速率提升了10倍,从每秒 150,000 个小数据包(64 八位字节)到每秒 8,234 个大数据包(1,518 八位字节)。

1999年,IEEE 802.3ab规范发布,标志着1Gbps以太网的诞生。随后,在2002年左右,10Gbps以太网问世。在2015年,100Gbps以太网进入市场。目前,业界正致力于完成Terabit以太网(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(最大传输单元)发现来应对这一问题,但这一过程耗时较长。因此,在多数情况下,使用1,500八位字节的数据包成为最快捷的方法。

值得注意的是,随着执行 TCP 分段卸载的网卡的引入,主机在处理大帧方面的压力得到了一定程度的缓解。主机可以向网络接口发送和接收大帧,从而将高数据包处理负载从主机处理器卸载到网络接口处理器上。例如,在使用大型发送卸载功能时,65,535八位字节的数据包可以从主机传递至网络接口,然后由其分段为45个1,460八位字节的段并发送至网络。

IPV4和IPV6虽然支持最大65,535八位字节的数据包(因两种协议的IP标头中均包含16位数据包长度字段),但实际上,在公共互联网上,超大IP数据包并非可靠选择。原因在于IP碎片问题。为确保数据传输的可靠性,最稳妥的做法是假设MTU大小约为1,460八位字节,以避免产生路径MTU发现成本。而较大的数据包更可能需要通过碎片才能通过网络,但尾随的碎片不包含传输标头,可能给网络中的安全相关中间件带来问题。因此,这里存在一个问题:需要在发送主机中承担数据分段的增量成本,发送可能无需任何形式数据包碎片的数据包,并且面临因静默数据包丢弃而导致的会话性能下降风险。

传输与硅

互联网与以太网的发展历程相似,在相同的数据包大小范围内,数据时钟速度从10Mbps显著跃升至1Tbps,这一变化带来了网络速度的巨大提升,但同时也增加了处理强度的要求。相比之下,处理器时钟速度和内存周期时间的增长却未能与网络速度的提升保持同步。

处理响应是通过卸载来弥补处理器并行度的提高和负载分配的差异。尽管到目前为止,处理性能似乎还能与网络速度保持相对一致,但这种状态能否持续下去仍是一个未知数。

增加网络中最大数据包大小或许能在一定程度上减轻处理速度的压力,但这一变化是否能够得到足够的支持尚不确定。路径MTU(最大传输单元)发现机制并未受到广泛欢迎,许多终端主机网络实现更倾向于选择一个在大多数网络中都能高度保证工作的MTU,而将路径MTU发现作为可选功能,供那些能够利用更大数据包大小的应用程序使用,尽管这样做可能会增加发现成本。值得注意的是,IEEE 802.11 Wifi规范定义了2,304八位字节的MTU,但大多数主机实现仍使用1,500八位字节的MTU值,以减少在WiFi接入网络移动到完整路径中的下一跳时可能出现的数据包丢失风险。

QUIC传输协议则更进一步,默认使用1,200八位字节的路径MTU,尽管它也可以选择使用路径MTU发现机制。

平台速度在不断提升,但网络堆栈似乎并不愿意承担有效且高效的路径MTU发现任务。当前的观点更倾向于缩小数据包大小,以避免IP级数据包碎片的需求。在传输速度持续提高的环境下,这似乎有些奇怪,但在数据包大小方面,1,500八位字节似乎已成为实用上限,且对于更大的互联网来说,这一立场并未显示出即将发生变化的迹象。

公共互联网的工程共识是数据包大小应介于20到1,500八位字节之间,这一范围基于最初的10Mbps以太网设计。但我们开头的问题是:数据包应该有多大?

从传输效率的角度来看,数据包有效载荷越大,效率越高。例如,对于IPv4,1,500八位字节的效率为97%,而对于IPv6则为96%;对于802.3巨型数据包,9,000八位字节的效率为 99.6%(V4),99.3%(V6)。然而,另一方面,数据包越大,噪声将比特错误添加到有效载荷中的可能性就越大,且如果使用恒定大小的循环冗余校验和,未检测到比特错误的可能性也会增加。此外,较大的数据包还会在使用时阻止所有其他数据包访问媒体,从而增加网络路径的抖动。在 ACK 滑动窗口协议(如 TCP)中,发送方根据 ACK 流中的隐式信号推断网络路径的状态。降低这些 ACK 信号的密度(如较大的数据包的情况)会降低发送方调整其发送行为以尝试匹配可用网络条件的能力。

如果我们接受原始10Mbps以太网的设计权衡,那么1Tbps以太网的可比数据包大小范围将是6.4M到151M八位字节。当然,这并不实际。另一种方法是保持原始最小数据包大小为64八位字节,但这意味着接收器需要处理每秒高达1.5B的数据包传入速率(对于小数据包)或每秒823个数据包(对于大数据包)。

如果我们不愿意改变最小帧尺寸,那么最大帧尺寸的选择就成为一个关键问题。

如果主机和应用程序由于时间开销而不愿意执行路径MTU发现,并且对1,518帧大小提供的效率水平感到满意,那么直接使用此值作为主机的接口MTU可能是一个合理的选择。这种方法可以高度保证此帧大小将在整个以太网框架网络中工作,从而避免可靠性问题和大小适配问题。

数据包应该有多大?今天的答案与50年前10Mbps以太网的答案相同:46到1,500八位字节之间的任何大小都是在公共互联网中使用的合理选择。

原文链接:
https://www.potaroo.net/ispcol/2024-10/packet-sizes.html




【活动专栏】

【投稿】:SDNLAB原创文章奖励计划

SDNLAB
SDNLAB是专注网络创新技术的先锋媒体社区和实践应用平台,涵盖AI 网络、DPU/智能网卡、SD-WAN/SASE、Web3.0、零信任、云网融合等相关领域,提供新闻资讯、技术交流、在线实验、行业分析、求职招聘、教育培训等多元服务。
 最新文章