常见网络加速技术浅谈（二）

2020-07-01 00:00:00 数据 网卡 网络 字节 数据包

上一篇我们看了一些网络加速的技术，它们致力于减少处理每个网络数据包所需要的CPU时间，要么是把一些网络协议的运算卸载（offload）到网卡，要么是减少数据拷贝对CPU资源的消耗。在上一篇我们说过，网络加速要解决的核心问题是CPU可以用来处理每个网络包的时间变短了。因为带宽的增速比CPU处理速度的增速大，所以相同的CPU时间，需要处理的网络数据包更多了。如果换一个思路：减少网络数据包的数量，那相同的CPU时间，需要处理的网络数据包更少了，分给每个网络数据包的时间也更就多了。这次我们看看相关的一些技术。

Jumbo Frames

以太网提出的时候是按照1500字节MTU（Maximum Transmission Unit）设计的，也就是Ethernet Frame的payload（数据段）大是1500字节。为什么是1500字节？这是一个效率和可靠性的折中选择。因为单个包越长，效率肯定越高，但相应的丢包概率也越大。反过来，单个包越小，效率更低，因为有效数据占整个网络数据比例更低，不过相应的丢包概率也更小。 因此，IEEE802.3规定了以太网的MTU是1500。

网络传输的时候，MTU必须匹配，MTU1500向MTU9000的机器发数据没问题。但是反过来，MTU9000向MTU1500的机器发数据，因为数据太长，MTU1500的机器识别不了会丢包。因此，网络数据的收发端MTU必须匹配。另一方面，互联网从几十年前就开始构建，为了统一标准，增加兼容性，整个互联网都是根据IEEE802.3规定的MTU1500来构建。

但是，现在的网络设备可靠性有了很大的提升，可以稳定传输更大的网络包。Jumbo Frames就是MTU为9000字节的Ethernet Frames。对于Jumbo Frames来说，每个网络数据包的有效数据占比更多，因为网络协议的头部长度是固定的，网络数据包变长了只能是有效数据更多了。另一方面，以10G网络为例，MTU1500需要CPU每秒处理超过800,000个网络包，而MTU9000只需要CPU每秒处理140,000个网络包。因此，在MTU9000下，单位时间CPU需要处理的网络包更少了，留给CPU处理每个网络包的时间更多了。

支持Jumbo Frames需要相应的硬件，新的硬件基本都支持了，只需要简单的配置即可。但是Jumbo Frames在实际使用的时候有一定的局限性。因为Jumbo Frames提出时，互联网已经按照MTU1500搭建完了，而MTU又必须匹配，改造全网基本不太可能。所以Jumbo Frames一般只在数据中心内部网络使用，例如内部存储网络。连接互联网的MTU一般还是设置为1500。

GSO

GSO全称是Generic Segmentation Offload，它只在网络数据发送时有效。GSO的作者Herbert Xu说过“If we can't use a larger MTU, we can go for the next-best thing: pretend that we're using a larger MTU.”有点像，现在我不能吃烧鸡，那老板来两片素鸡，比什么也没有强点。既然互联网是基于MTU 1500构建，在互联网上传输的网络包必须遵循MTU 1500，那如果在操作系统里面尽量晚进行IP Fragmentation，在TCP/IP协议栈里就会有一段“路径”，其上传递的网络数据是一个payload超过1500字节的网络包，相当于在传递一个大MTU的网络数据。在这段“路径”上，CPU需要处理更少的网络数据包，相应的留给CPU处理每个网络包的时间就更多了。

其实上一篇介绍的TSO也有这个思想，从用户程序到网卡之间，一直都不进行TCP Segmentation和IP Fragmentation，数据包大可以到64K。但是，TSO只支持TCP协议，并且需要硬件网卡的支持，而GSO就是为其他场合提出。其实严格来说，除了TCP，其他的网络数据大包变小包都是发生在IP层，因此属于IP Fragmentation，所以这里叫GS(egmentation)O并不是恰当。

因为不依赖硬件，又要尽可能晚的分段或者分片，所以GSO选择在发给网卡驱动的前一刻将大包分成多个小包。这样，虽然网卡收到的还是多个小的网络数据包，但是在TCP/IP协议栈里面，如下图所示，还是有一段路径，CPU需要处理少量的大包。

因为在发给网卡驱动的前一刻完成，所以GSO可以作为TSO的备份。在发给网卡驱动时检查网卡是否支持TSO，如果支持，将大包直接传给网卡驱动。如果不支持，再做GSO。

根据LinuxFoundation的文档，在MTU1500时，使用GSO可以使得网络吞吐量（throughput）提升17.5%。

LRO

LRO全称是Large Receive Offload，或者又称为RSC（Receive Side Coalescing），从名字可以看出它只在网络数据接收时有效。LRO是TSO的逆方向实现，是指网卡将同一个TCP连接的TCP Segments 合并成一个大的TCP包，再传给操作系统。这样避免了操作系统处理并合并多个小包，减少了CPU的运算时间，并且在TCP/IP协议栈，CPU需要处理更少的网络数据包。与TSO一样，LRO也需要网卡的支持。

但是与TSO不一样的是，LRO并没那么好用。因为TSO发生在数据的发送方，发送方掌握了网络数据的全部信息，发送方可以按照自己的判断控制发送的流程。而LRO发生在数据的接收方，而且是相对于数据发送方的异步接收，所以LRO只能基于当前获取到的有限数据和信息做出合并，存在一定的困难。这就像我们拆一个东西很容易，但是要重新组装回去很难一样。

LRO可能会丢失重要的数据，例如数据发送方在Header加了一些字段来区分不同的网络包。合并可能导致这些字段的丢失，因为合并之后只有一个Header了。而且当操作系统需要转发数据时，合并之后的网络包可能需要重新被分段/片。再重新分成小包，原来Header里面的差异字段就彻底丢失了。因为LRO的局限性，在一些新的网卡上，LRO已经被删除了。

GRO

GRO全称是Generic Receive Offload，这是GSO在接收端的对应。GRO的作者与GSO是同一个人，都是Herbert Xu。不像GSO作为TSO的替补，GRO逐渐取代了LRO。因为GRO运行在系统内核，掌握的信息更多，GRO可以用更加严格的规则来合并网络数据包。因为合并的时候更严格，所以可以避免关键的信息丢失。另一方面，在一些需要转发的场合，GRO可以利用GSO的代码来重新分段。

其他的优点还有，GRO也更加通用，不仅不依赖硬件设备，还支持TCP协议以外的协议。

UFO

UFO全称是UDP fragmentation offload。从名字可以看出，这是针对UDP的优化。但是不像TCP，UDP没有Segmentation的过程，用户程序发给UDP多长的数据（当然要控制在64K以内），UDP都会转给IP层。IP层会根据MTU进行Fragmentation。UFO使得网络设备，例如网卡，可以将一个超长的UDP数据段（超过MTU），分成多个IPv4分片（fragment）。因为在网卡做了，所以，CPU的运算量被节省下来了。

不过，在新的linux内核中，UFO已经被弃用了。因为除了TSO，其他的offload基本上都是在IP层做Fragmentation，那UFO也没有必要单独存在，因此它与GSO合并表示了。

tx-udp_tnl-segmentation

Overlay网络，例如VxLAN，现在应用的越来越多。Overlay网络可以使得用户不受物理网络的限制，进而创建，配置并管理所需要的虚拟网络连接。同时Overlay可以让多个租户共用一个物理网络，提高网络的利用率。Overlay网络有很多种，但是具有代表性的是VxLAN。VxLAN是一个MAC in UDP的设计，具体格式如下所示。

从VxLAN的格式可以看出，以VxLAN为代表的Overlay网络在性能上存在两个问题。一个是Overhead的增加，VxLAN在原始的Ethernet Frame上再包了一层Ethernet+IP+UDP+VXLAN，这样每个Ethernet Frame比原来要多传输50个字节。所以可以预见的是，Overlay网络的效率必然要低于Underlay网络。另一个问题比传50个字节更为严重，那就是需要处理这额外的50个字节。这50个字节包括了4个Header，每个Header都涉及到拷贝，计算，都需要消耗CPU。而我们现在迫切的问题在于CPU可以用来处理每个网络数据包的时间更少了。

首先，VxLAN的这50个字节是没法避免的。其次，那就只能降低它的影响。这里仍然可以采用Jumbo Frames的思想，因为50个字节是固定的，那网络数据包越大，50字节带来的影响就相对越小。

先来看一下虚拟机的网络连接图。虚拟机通过QEMU连接到位于宿主机的TAP设备，之后再通过虚机交换机转到VTEP（VxLAN Tunnel EndPoint），封装VxLAN格式，发给宿主机网卡。

理想情况就是，一大段VxLAN数据直接传给网卡，由网卡去完成剩下的分片，分段，并对分成的小的网络包分别封装VxLAN，计算校验和等工作。这样VxLAN对虚机网络带来影响就可以降到低。实际中，这是可能的，但是需要一系列的前提条件。

首先，虚拟机要把大的网络包发到宿主机。因为虚拟机里面也运行了一个操作系统，也有自己的TCP/IP协议栈，所以虚拟机完全有能力自己就把大的网络包分成多个小的网络包。从前面介绍的内容看，只有TSO才能真正将一个大的网络包发到网卡。GSO在发到网卡的时候，已经在进入驱动的前一刻将大的网络包分成了若干个小的网络数据包。所以这里要求：虚机的网卡支持TSO（Virtio默认支持），并且打开TSO（默认打开），同时虚机发出的是TCP数据。

之后，经过QEMU，虚拟交换机的转发，VTEP的封装，这个大的TCP数据被封装成了VxLAN格式。50个字节的VxLAN数据被加到了这个大的TCP数据上。接下来问题来了，这本来是个TCP数据，但是因为做了VxLAN的封装，现在看起来像是个UDP的数据。如果操作系统不做任何处理，按照前面的介绍，那就应该走GSO做IP Fragmentation，并在发送给网卡的前一刻分成多个小包。这样，如果网卡本来支持TSO现在就用不上了。并且更加严重的是，现在还没做TCP Segmentation。我们在上一篇花了很大的篇幅介绍其必要性的TCP Segmentation在这里也丢失了。

对于现代的网卡，除了TSO，GSO等offload选项外，还多了一个选项tx-udp_tnl-segmentation。如果这个选项打开，操作系统自己会识别封装成VxLAN的UDP数据是一个tunnel数据，并且操作系统会直接把这一大段VxLAN数据丢给网卡去处理。在网卡里面，网卡会针对内层的TCP数据，完成TCP Segmentation。之后再为每个TCP Segment加上VxLAN封装（50字节），如下图右所示。这样，VxLAN封装对于虚拟机网络来说，影响降到了低。

从前面描述看，要达成上述的效果，需要宿主机网卡同时支持TSO和tx-udp_tnl-segmentation。如果这两者任意一个不支持或者都不支持。那么系统内核会调用GSO，将封装成VxLAN格式的大段TCP数据，在发给网卡驱动前完成TCP Segmentation，并且为每个TCP Segment加上VxLAN封装。如下图左所示。

如果关闭虚拟机内的TSO，或者虚拟机内发送的是UDP数据。那么在虚拟机的TCP/IP协议栈会调用GSO，发给虚拟机网卡驱动的前一刻，完成了分段、分片。虚拟机终发到QEMU的网络数据包就是多个小的网络数据包。这个时候，无论宿主机怎么配置，都需要处理多个小的网络包，并对他们做VxLAN封装。

总结

零零碎碎说了这么多，这些网络加速技术一般不需要使用者去配置。因为如果支持的话，默认都是打开的。使用的时候大家只需要确认自己的系统是否带有这些功能。又或者，在调试一些问题的时候，看看是否是因为这些功能引起的，如果是的话，手动关闭它们。

参考链接：

ibm.com/developerworks/

slideshare.net/eurobsdc

kernel.org/doc/Document

kernel.org/doc/Document

wiki.linuxfoundation.org

lwn.net/Articles/358910

hustcat.github.io/udp-a

相关文章