LWN订户已向您提供以下仅限订阅的内容。成千上万的订阅者依靠LWN从Linux和自由软件社区获得最好的消息。如果您喜欢这篇文章，请考虑订阅LWN。感谢您访问LWN。网
与计算领域的大多数组件一样，网络硬件随着时间的推移稳步增长。事实上，今天'；s的高端网络接口通常比其所连接的系统处理数据的速度更快。网络开发人员多年来一直致力于提高其子系统的可扩展性；当前的项目之一是Eric Dumazet和Coco Li开发的大型TCP补丁集。大TCP不是'；但在某些情况下，它有可能显著提高网络性能。想象一下，你正在努力跟上100Gb/s网络适配器的步伐。正如网络开发者Jesper Brouer在2015年所描述的那样，如果一个人使用的是1538字节的长期最大数据包大小，全速运行接口意味着每秒要处理800多万个数据包。在这个速率下，CPUH需要大约120N的时间来处理每个数据包，这并不需要很多时间；一次缓存未命中可能会破坏整个处理时间预算。不过，如果数据包的数量减少，情况会变得更好，而这可以通过使数据包变大来实现。因此，毫不奇怪，高性能网络安装，尤其是局域网，在局域网中，所有东西都作为一个单元进行管理，使用更大的数据包大小。通过适当的配置，可以使用最大为64KB的数据包，从而大大改善了这种情况。但是，在以兆字节或千兆字节为单位移动数据的环境中（或者更多——cat视频一直在变大），系统仍然需要处理大量数据包。数据包计数在很多方面都是有害的。在系统中传输的每个数据包都有一个重要的固定溢出。每个包必须在网络堆栈中找到自己的路径，从上层协议层到接口的设备驱动程序（或背面）。更多的数据包意味着来自网络适配器的中断更多。sk#buffstructure（"；SKB"；）用于在内核中表示数据包的是一个大型Beast，因为它必须能够支持可能正在使用的任何网络功能；这会导致每个包的内存使用和内存管理成本显著增加。因此，至少对于某些类型的应用程序，我们有充分的理由希望能够以更少、更大的数据包移动数据。IP分组的长度存储在IP报头中；对于IPv4和PV6，该长度都存在于16位字段中，将最大数据包大小限制为64KB。在设计这些协议时，一个64kb的数据包可能需要几秒钟才能在可用的主干网线上传输，因此它看起来一定是一个非常大的数字；当然，64KB比任何人理性地想要放入一个数据包的容量都要多。但时代变了，64KB现在似乎是一个非常低的限制。对这个问题的认识并不是最近才开始的：1999年采用的RFC 2675中有一个解决方案（至少是IPv6）。IPv6规范允许放置"；一步一步地"；带有附加信息的标题；顾名思义，逐跳标头用于在两个直接连接的系统之间传递选项。RFC 2675通过对协议进行几处调整来实现更大的数据包。发送"；jumbo和#34；数据包时，系统必须将（16位）IPpayload length字段设置为零，并添加包含实际有效负载长度的逐跳标头。该报头中的长度字段是32位，这意味着巨型数据包最多可以包含4GB的数据；这对每个人来说都应该足够了。当连接的最大传输单元（MTU）设置得非常高时，大型TCP补丁集增加了生成和接受巨型数据包所需的逻辑。不出所料，要想让它真正发挥作用，有很多细节需要管理。更重要的问题之一是，任何大小的数据包都很少存储在物理上连续的内存中，这通常很难获得。对于零拷贝操作，缓冲区位于用户空间，数据包保证通过物理内存分散。因此，数据包被表示为一组"；碎片"；，每个页面可以短至一（4KB）；网络接口处理从传输中收集数据包的任务（或在收到数据包时将其分割）。当前内核将存储在SKB中的片段数量限制为17，这足以将64KB的数据包存储在单页块中。这一限制显然会干扰更大数据包的创建，因此patch set将最大片段数提高到45个。但是，asAlexander Duyck指出，许多接口驱动程序对一个数据包可能被拆分成的最大片段数的假设进行编码。他说，在不修复驱动程序的情况下提高这一限制可能会导致性能下降，甚至导致硬件锁定。经过一些讨论，Dumazet建议通过添加一个配置选项来解决这个问题，该选项控制任何给定数据包允许的最大片段数。对于构建自己内核的站点来说，这是很好的，而这一功能的潜在用户相对来说很可能会这样做。不过，它对分销商几乎并没有帮助，他们必须为所有用户的这个选项选择一个值。在任何情况下，许多驱动程序都需要更新以处理巨型数据包。现代网络接口执行分段卸载，这意味着创建单个数据包的大部分工作是在接口本身内完成的。使用大型打包机进行分段卸载，只需进行少量调整；一些驱动程序在批处理集中更新。另一个小问题与RFC 2675逐跳标头的放置有关。根据IPv6标准，这些报头位于IP报头的中间位置；这可能会让那些"；知道"；可以在apacket中的IP头之后立即找到TCP头。tcpdump实用程序在这方面存在一些问题；似乎还有相当多的BPF项目包含了这种假设。因此，即使底层硬件和链路可以处理这些数据包，在默认情况下也会禁用巨型数据包处理。Dumazet在发布补丁时提供了一些简短的基准测试结果。实现185000字节的数据包大小可以将网络吞吐量提高近50%，同时还可以显著减少往返延迟。因此，BIGTCP似乎是一个值得拥有的选项，至少在使用高速链路并能可靠传输大数据包的环境（例如数据中心）中是这样。如果明天'；美国的猫视频来得更快一些，大TCP可能是原因之一。见杜马泽'；s2021 Netdev将就此主题进行讨论，了解更多详细信息。（登录发表评论）
这与现代文件系统在使用现代存储的全部带宽时遇到的问题没有太大区别。不是'；根本问题不一样吗？CPU的速度并没有加快，但其他硬件的速度却在加快，因此抽象层必须尽可能少地工作，算法必须非常高效。操作系统开发非常有趣的时刻。
硬盘的I/O速度也没有明显提高。它'；它实际上开始成为一个问题，因为随着HDD变得更大而不是更快，存储空间与I/O带宽的比率变得非常偏向前者，因此大量HDD不会'；我们没有足够的总带宽来大规模使用。你可以通过购买大量小型硬盘来解决这个问题，但那'；它是如此昂贵（每GB）以至于你'；我们最好还是买SSD吧。因此，我们'；重新开始看到SSD的使用增加，即使在硬盘寻找时间本来可以接受的领域，硬盘有时会降级到"；酷"；存储和批处理。（以上描述了我在超大规模服务方面的经验。对于"；普通规模的"；服务，你'；可能可以使用一个或十个硬盘，但如果你突然决定建立自己的私人YouTube，你至少应该运行这些数字，以防万一。）
我相信"；现代化的存储"；2022年，每台NVMe驱动器的IOPS均达到500万次。
对于许多用例来说，这仍然是非常昂贵的（目前）；HDD（甚至磁带）仍有大量发展。例如，一些供应商开始部署多驱动器硬盘（我们最近在Linux中得到了支持），因此您可以同时进行多个读/写操作——显然是'；它仍然比flash慢。
100Gb/s的NIC和交换机也是如此，所以目前它们都不是消费者级的。
嗯，无可否认，我的家庭系统不是'；我不像很多人。。。但我重新组织了（就像去年存档的那样）大量邮件列表，值得注意的是，即使在雷鸟回来说"；完成"；，磁盘子系统——raid-5阵列——正在拼命追赶。有32GB的ram，只要它能缓存所有优秀的I'；我不担心，但它'；知道这一点还是有点吓人'；尽可能快地刷新磁盘队列中的大量内容。。。
即使在我2007年开始在谷歌工作时，这也是一个问题；磁盘变得如此之大，以至于像恢复之类的东西都成了问题。所以问题一直存在，它'；随着问题越来越严重，它只是慢慢地进入更“正常”的问题领域。
2022年2月15日17:45 UTC（星期二）由rgmoore发布（✭ 支持者✭, #[链接]
我假设，对于YouTube这样的东西，最终的解决方案涉及多个级别的缓存，在延迟和成本之间进行不同的权衡。对于一个主要通过浏览来访问的网站，你可以根据'；关于用户'；屏幕，并可以相应地预填充缓存。我'；我确信有工程师的全部工作就是优化这种行为。这也让我想知道，一些可怕的YouTube算法是不是'；t试图引导观众进入'；现在很流行，因为它'；它肯定在缓存中可用。
与我的谷歌帽对话：说最终解决方案涉及"；多级缓存"；就像说一场魔法游戏：聚会涉及多个规则。[1] 除此之外，我'；I’我真的没有评论的自由，但我可以在[2]向您介绍公司关于推荐系统工作原理的官方热线。[3] [1]见https://media.wizards.com/2022/downloads/MagicCompRules%2...对于MTG规则。但是唐'；我不会真的去读它们，因为它们'；re用于解决特定问题，而不是作为"；这里'；这就是如何玩这个游戏"；起点。[2]: https://blog.youtube/inside-youtube/on-youtubes-recommend...[3]：链接的博客帖子是Google/YouTube'；他在这件事上的官方立场，可能并不反映我个人的观点（我对讨论这个问题没有兴趣）。它'；S也从2021年9月开始，所以事情从那时开始可能已经改变了。
>；实现185000字节的数据包大小可以将网络吞吐量提高近50%"；吞吐量#34；涉及通过DMA从NIC上获取大的TCP数据包，对于如此多的数据，可能是分散-聚集类型。它'；值得注意的是，这些传输的速度足以使速度提高50%。
>；当前内核将存储在SKB中的片段数量限制为17个，即>；足以在单页块中存储64KB的数据包。该限制将>；显然会干扰更大数据包的创建，因此补丁集会引发>；碎片的最大数量（到45）。但是，正如亚历山大·杜伊克指出的那样，>；许多接口驱动程序对最大片段数的假设进行编码>；一个数据包可以被分成几个部分。在不修正>；他说，驱动程序可能会导致性能下降，甚至导致硬件锁定；她说>>；经过一些讨论后，Dumazet建议通过添加一个>；配置选项，用于控制>；任何给定的包。对于构建自己内核的网站来说，这很好，因为>；这项功能的潜在用户相对来说更可能这样做。它提供的服务很少>；不过，对于分销商，他们必须为所有>；他们的用户。嗯，听起来很像块层中的"；阻塞队列限制"；；其中，每个实现块层接口的低级驱动程序也为该特定队列提供了一组限制，除其他外，还包括该队列的分散-聚集列表的外观，以便底层设备能够实际处理它。例如，一些设备可以'；t处理多页分散元素，而其他元素可以；有些在单个列表中有分散元素的上限，以此类推。这样就没有'；不必是单个配置开关和/或整个内核的旋钮。
>；软件"；知道"；TCP报头可以在数据包的IP报头之后立即找到。
我在此确认，在20世纪80年代，64KB的数据包对我来说似乎太大了
RFC2675在IPv6中为4GB数据包添加了32位字段，那么IPv4呢，IPv4怎么能处理超过16位长度的数据包呢？我仍然不知道'；我不明白这是怎么回事。
传统技术可以'；不能做超过16位的数据包长度；如果你需要网络上的巨型数据包，你必须升级到IPv6。
实现这样的更改的一个问题是使用全局设置，这对一个设置来说控制太多。例如，增加MTU的问题。它'；很难改变MTU，因为它'；s用于控制接收数据包大小和发送数据包大小。局域网上的每个人都必须同意MTU，因为交换机不'；t在ICMP或（对于IPv4）碎片域中运行。那么，如果一个'；s公司的主干网已发展到显著更高的带宽，但仍会丢弃一小部分数据包，TCP流量控制算法基于延迟限制传输。更大的MTU会有所帮助，但实现这一点需要在参与对话的每个子网中设立一个卖旗日。如果一个人可以改变系统，接受更大的MTU，但不发送更大的MTU，那么卖旗日就不是'；t必需，因为每个系统都可以配置为接受较大的MTU，但不能传输它们。一旦每个系统都被更改，那么路由器端口和端点系统就可以更改为更大的MTU。我希望BIG TCP也能做类似的事情，首先可以将系统配置为在发送之前接受BIG TCP，这样可以避免在卖旗日要求实现它。除了点对点通信，每个系统都需要数年才能使用大型TCP。理想情况下，它可以基于连接对而不是交换机控制的以太网帧大小限制来实现。