在生产力虚拟环境中，要达到高性能的网络是极为重要的目标。 针对这个目标，微软使用在非虚拟环境下相同等级的技术来在 Linux 虚拟环境中达成这个目标。 举例来说，让虚拟机不透过 hypervisor 即可直接使用硬件网卡，例如如果有一张实体的 10G 网卡，我们必须要确保虚拟机能够尽可能达到 10G 的网络传输性能。 在 Azure 公有云上，我们早已投入大量的技术与开发能量在优化 Linux 于虚拟环境的性能，以及虚拟机使用多个虚拟 CPU 的性能优化。 并且也针对多个程序或者执行续使用相当多的网络联机做了优化设计。 而每个网络包的延迟也是相当重要的部分，所以除了吞吐量要大之外，也必须顾及延迟的问题。 也在 Linux 上实作这些功能并且作了实际的评估与测量。 在稍后的章节会更仔细深入地提及这些测量的设置与结果。
Linux网络性能特性
在 Linux 系统整合服务驱动程序（LIS）中，已经包含数个提升网络性能及吞吐量的功能。 这些功能包括 Virtual Receive Side Scaling (vRSS) 以及数种 TCP/IP 的处理优化。 vRSS 功能通过多个 vCPU 来处理流入的网络包以增强网络性能。 在没有 vRSS 的情况下，流入的包会导致第一颗 vCPU 经常中断处理网络包。 而在繁重的网络使用时，第一颗 vCPU 的使用率常常飙高至 100% 的使用率，而造成使用率的瓶颈，但其他的 vCPU 却仅有少量的负载。 因此 vRSS 可以更有效利用多核来平均中断不同的核心，减少第一颗 vCPU 因网络造成的大量使用率。 经由测试，在八颗 vCPU 的情况下，网络的吞吐量可以有显著的提升。 如果您运行的虚拟机有多至八颗 vCPU 以上，则 vRSS 仅会使用其中的八颗 vCPU 来处理网络包。 相反的若您使用小型虚拟机，仅搭载一颗 vCPU 时，则 vRSS 将不会带来任何好处。 与 vRSS 类似，当在传送包时，也会将这些包交由多颗 vCPU 来处理，来避免单颗 vCPU 高使用率所带来的瓶颈。
现今 TCP 体积变得越来越大，甚至已经超越当初 Ethernet 的标准 MTU 规范。 Linux 客户端内的虚拟网卡驱动程序会采用较大的包来转入 Hyper-V 主端后传送。 Hyper-V 主端使用实体网卡转送这种大型的数据到实体的网络上。 如果物理网卡不支持这么大的包，则 Hyper-V 会透过软件分割切段。 不过从 Linux 客户端传递至 Hyper-V 主端采用较大包的传输效率明显高于使用较小的包。
而在检查码 (Checksum) 的作法也是类似的，在 Linux 客户端到 Hyper-V 的包传输上，其包是没有检查码片段的，而 Hyper-V 再转送包去外部网络时，将会使用物理网卡来做检查码的计算与附加。 如果物理网卡不支持检查码计算功能，则 Hyper-V 将会透过软件计算。 而在后述的情况，无论在客户端或者主端做软件计算所消耗的效能是几乎没有差异的。
上述功能不需要您去做特别的调整或管理。 Hyper-V 将会自动地依照情境启用这些功能来提升网络吞吐量以及减少 CPU 在处理网络上的额外消耗。
Linux网络可用性特性
其中一个新的网络功能为虚拟网卡可用性功能。 这个功能将会在 Windows Server 2016 Hyper-V（可于目前处于技术预览阶段使用到），以及最新版本的 LIS 驱动程序（4.0 或者之后的版本）。 通过虚拟网卡可用性功能，你可以在虚拟机运行当中随时添加或者移除虚拟网卡，这项功能也能减少虚拟机下线时间。 这在您排除网络问题时相当有用，因为您可直接加入新的网络联机到已知有网络问题的虚拟机中。
以下例子简单示范，当您有一台运行于 Hyper-V 上的 Linux 虚拟机，并配有一张虚拟网卡。 则在 Linux 客户端内使用 ifconfig 命令将会看到下图呈现的样子：
如预期的，您将会看到网络经由 eth0 联机，还有一个本地回路 (loopback)。
但如果您到 Hyper-V 加入另外一张虚拟网卡至此虚拟机中，大部分的 Linux 虚拟机会立刻检测到此虚拟网卡，并指派为 eth1 且自动使用 DHCP 获取 IP 。 这张虚拟网卡可以马上被使用，则 ifconfig 后的结果为下图：
当您在 Hyper-V移除虚拟网卡时，Linux 虚拟机将会实时的移除这张网卡。
Linux网络性能
我们建立一个测试环境，架设两台 Linux 虚拟机分别在两台分开的 Hyper-V 。 而这两个 Hyper-V 通过过实体的 10G 网络骨干链接，当然也支持更快的 40G 版本。 而这两台 Linux 虚拟机各自配备 8 颗虚拟 CPU 以发挥 vRSS 最大性能。 我们通过 iperf3 这个工具来测量 Linux 客户端的最大网络吞吐量。 iperf3 是个开源工具可以点这里到 Github 查看更多细节。 我们设定 iperf3 使用 16 条测试，并且有不同程度的吞吐量，来仿真典型生产力服务器的工作情况。
因此上述的测量配置看起来将会如下图：
总结