本文介绍常用的 TCP/IP 性能优化技术，以及将其用于 Azure 上运行的虚拟机时要注意的一些事项。 它提供技术的基本概述，并探讨了如何优化虚拟机。
常用的 TCP/IP 优化技术
MTU、分段和大规模发送卸载
MTU
最大传输单元（MTU）是最大大小帧（数据包和网络访问标头），以字节为单位指定，可通过网络接口发送。 MTU 是可配置的设置。 在 Azure VM 上使用的默认 MTU（也是大多数网络设备上全局使用的默认设置）为 1,500 字节。
碎片化
当发送的数据包超过网络接口的 MTU 时，就会发生分段。 TCP/IP 堆栈将数据包分解为符合接口 MTU 的较小片段（片段）。 分段发生在 IP 层，与底层协议（例如 TCP）无关。 当通过 MTU 为 1,500 的网络接口发送 2,000 字节数据包时，数据包将分解为一个 1,500 字节数据包和一个 500 字节数据包。
源与目标之间的路径中的网络设备可能会丢弃超过 MTU 的数据包，或者将数据包分段成较小的片段。
IP 数据包中的 Don't Fragment（不要分段）位
Don't Fragment (DF) 位是 IP 协议标头中的一个标志。 DF 位指示发送方与接收方之间的路径中的网络设备不得将数据包分段。 设置此位的原因有很多。 （请参阅本文的“路径 MTU 发现”部分中的一个示例。）当网络设备收到一个设置了 Don't Fragment 位的数据包时，如果该数据包超过了设备的接口 MTU，则标准行为是该设备丢弃该数据包。 设备会将一条 ICMP Fragmentation Needed（需要 ICMP 分段）消息发回给数据包的原始源。
分段对性能的影响
分段可能会对性能造成负面影响。 影响性能的主要原因之一是数据包碎片化和重新组装对CPU和内存造成的影响。 当网络设备需要对数据包进行分片时，它必须分配 CPU 和内存资源来进行分片。
重组数据包时也是如此。 网络设备必须存储所有片段，直到这些片段被接收并可重组成原始数据包为止。
Azure 和碎片化
Azure 不会使用加速网络处理碎片数据包。 当 VM 收到碎片数据包时，非加速路径将处理它。 因此，分段数据包会错过加速网络的优势，例如延迟较低、抖动减少和每秒数据包数较高。 出于此原因，我们建议尽可能避免碎片化。
默认情况下，Azure 会删除按顺序到达 VM 的碎片数据包，这意味着数据包与源终结点的传输序列不匹配。 当数据包通过 Internet 或其他大型 WAN 传输时，可能会出现此问题。
优化 MTU
可以通过增加 VM 流量的 MTU 来提高内部虚拟网络吞吐量。 但是，如果 VM 与虚拟网络外部具有不同 MTU 的目标通信，则可能会发生分段并降低性能。
有关在 Azure VM 上设置 MTU 的详细信息，请参阅 为 Azure 中的虚拟机配置最大传输单元（MTU）。
大规模发送卸载
大规模发送卸载 (LSO) 可以通过将数据包分段任务卸载到以太网适配器来提高网络性能。 启用 LSO 后，TCP/IP 堆栈会创建一个大型 TCP 数据包，并将其发送到以太网适配器进行分段，然后再转发它。 LSO 的优势使 CPU 能够将数据包分段为符合 MTU 的大小，并将该处理卸载到以太网接口硬件。 若要详细了解 LSO 的好处，请参阅支持大规模发送卸载。
启用 LSO 后，Azure 客户可能会在数据包捕获期间注意到大型帧大小。 这些较大的帧大小可能导致某些客户认为发生了分段或者使用了较大的 MTU，但实际上并非如此。 使用 LSO，以太网适配器可以将更大的最大段大小（MSS）播发到 TCP/IP 堆栈，以创建更大的 TCP 数据包。 然后，以太网适配器根据它在 VM 上执行的数据包捕获中可见的 MTU 将此整个非分段帧分解为多个较小的帧。
TCP MSS 窗口缩放和 PMTUD
TCP 最大片段大小
TCP 最大片段大小 (MSS) 是一项限制 TCP 片段大小的设置，可避免将 TCP 数据包分段。 操作系统通常使用此公式设置MSS：
MSS = MTU - (IP header size + TCP header size)
IP 标头和 TCP 标头各为 20 字节，总共为 40 字节。 MTU 为 1,500 的接口的 MSS 为 1,460。 该 MSS 可配置。
此项设置符合在源与目标之间建立 TCP 会话时的 TCP 三向握手。 双方都会发送 MSS 值，两个值的较小者用于 TCP 连接。
请记住，源和目标的 MTU 不是 MSS 值的唯一决定因素。 中间网络设备（例如 VPN 网关，包括 Azure VPN 网关）可以独立于源和目标调整 MTU，以确保提供最佳网络性能。
路径 MTU 发现
MSS 会经过协商，但不一定表明可以使用实际 MSS。 源与目标之间的路径中的其他网络设备可能比源和目标具有较低的 MTU 值。 在这种情况下，MTU 小于数据包大小的设备会丢弃该数据包。 该设备会发回包含其 MTU 的 ICMP Fragmentation Needed (Type 3, Code 4) 消息。 此 ICMP 消息可让源主机适当减小其路径 MTU。 此过程称为“路径 MTU 发现”(PMTUD)。
PMTUD 进程由于效率低下而降低了网络性能。 超过网络路径的 MTU 时，必须使用较低的 MSS 重新传输数据包。 如果网络防火墙阻止了需要分片的 ICMP 消息，发送方将不知道需要修改 MSS 为更低的值，并多次重新传输数据包。 因此，我们建议不要增加 Azure VM MTU。
VPN 和 MTU
如果使用执行封装功能的 VM（如 IPsec VPN），那么在数据包大小和 MTU 方面还有其他一些注意事项。 VPN 向数据包添加更多标头。 添加的标头会增加数据包大小，并且需要较小的 MSS。
对于 Azure，我们建议将 TCP MSS 钳位设置为 1,350 字节，将隧道接口 MTU 设置为 1,400。 有关详细信息，请参阅 VPN 设备和 IPsec/IKE 参数页。
延迟、往返时间和 TCP 窗口缩放
延迟和往返时间
光的速度决定了光纤网络上的网络延迟。 两个网络设备之间的往返时间（RTT）控制 TCP 网络吞吐量。
| 路线 | 距离 | 单向时间 | RTT |
|---|---|---|---|
| 纽约到旧金山 | 4,148 km | 21 毫秒 | 42 毫秒 |
| 纽约到伦敦 | 5,585 km | 28 毫秒 | 56 毫秒 |
| 纽约到悉尼 | 15,993 km | 80 毫秒 | 160 毫秒 |
此表显示了两个位置之间的直线距离。 网络中的距离往往大于直线距离。 下面是计算受制于光速的最小 RTT 的简单公式：
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
可以使用 200 作为传播速度。 传播速度是在1毫秒内光传播的距离，单位是公里。
我们以从纽约到旧金山的距离为例。 两者之间的直线距离为 4,148 公里。 在公式中输入该值会导致以下公式：
Minimum RTT = 2 * (4,148 / 200)
公式输出以毫秒为单位。
若要获得最佳网络性能，符合逻辑的做法是选择两者之间距离最短的目的地。 还应将虚拟网络设计为优化流量路径并减少延迟。 有关详细信息，请参阅本文的“网络设计注意事项”部分。
延迟和往返时间对 TCP 的影响
往返时间直接影响到最大 TCP 吞吐量。 在 TCP 协议中， 窗口大小 是发送方需要从接收方接收确认之前通过 TCP 连接发送的最大流量。 如果 TCP MSS 设置为 1,460，TCP 窗口大小设置为 65,535，则发送方可以在从接收方确认之前发送 45 个数据包。 如果发送方未获得确认，则会重新传输数据。 公式如下：
TCP window size / TCP MSS = packets sent
在此示例中，65,535 / 1,460 的结果已四舍五入为 45。
这种“等待确认”状态是确保数据可靠传递的机制，是导致 RTT 影响 TCP 吞吐量的原因。 发送方等待确认的时间越长，发送更多数据之前需要等待的时间越长。
下面是计算单个 TCP 连接的最大吞吐量的公式：
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
下表显示了单个 TCP 连接的最大每秒兆字节吞吐量。 （为便于阅读，此处使用了每秒兆字节作为度量单位。）
| TCP 窗口大小（字节） | RTT 延迟（毫秒） | 最大每秒兆字节吞吐量 | 最大每秒兆位吞吐量 |
|---|---|---|---|
| 65,535 | 1 | 65.54 | 524.29 |
| 65,535 | 30 | 2.18 | 17.48 |
| 65,535 | 六十 | 1.09 | 8.74 |
| 65,535 | 90 | 0.73 | 5.83 |
| 65,535 | 120 | 0.55 | 4.37 |
如果数据包丢失，则发送方重新传输发送的数据时，TCP 连接的最大吞吐量会降低。
TCP 窗口缩放
TCP 窗口缩放是一种动态增加 TCP 窗口大小的技术，允许在确认之前发送更多数据。 在前面的示例中，45 个数据包会被发送出去，然后才需要确认。 如果增加在需要确认之前可以发送的数据包数，则会减少发送方等待确认的次数。
下表演示了这些关系：
| TCP 窗口大小（字节） | RTT 延迟（毫秒） | 最大每秒兆字节吞吐量 | 最大每秒兆位吞吐量 |
|---|---|---|---|
| 65,535 | 30 | 2.18 | 17.48 |
| 131,070 | 30 | 4.37 | 34.95 |
| 262,140 | 30 | 8.74 | 69.91 |
| 524,280 | 30 | 17.48 | 139.81 |
但是，TCP 窗口大小的 TCP 标头值长度仅为 2 个字节，这意味着，接收窗口的最大值为 65,535。 为了提高最大窗口大小，我们引入了 TCP 窗口缩放因子。
该缩放因子也是可以在操作系统中配置的设置。 下面是使用缩放因子计算 TCP 窗口大小的公式：
TCP window size = TCP window size in bytes * (2^scale factor)
下面是窗口缩放因子为 3，窗口大小为 65,535 时的计算公式：
65,535 * (2^3) = 524,280 bytes
缩放因子为 14 时，TCP 窗口大小为 14（允许的最大偏移量）。 TCP 窗口大小为 1,073,725,440 字节（8.5 千兆位）。
TCP 窗口缩放支持
Windows 可为不同的连接类型设置不同的缩放因子。 （连接类包括数据中心、Internet 等。）可以使用 Get-NetTCPConnection PowerShell 命令查看窗口缩放连接类型：
Get-NetTCPConnection
可以使用 Get-NetTCPSetting PowerShell 命令查看每个类的值：
Get-NetTCPSetting
可以使用 Set-NetTCPSetting PowerShell 命令在 Windows 中设置初始 TCP 窗口大小和 TCP 缩放因子。 有关详细信息，请参阅 Set-NetTCPSetting。
Set-NetTCPSetting
以下数值是AutoTuningLevel的有效 TCP 设置：
| AutoTuningLevel | 缩放因子 | 缩放乘数 | 用于计算 计算最大窗口大小 |
|---|---|---|---|
| 已禁用 | 无 | 无 | 窗口大小 |
| 受限 | 4 | 2^4 | 窗口大小 * (2^4) |
| 严格限制 | 2 | 2^2 | 窗口大小 * (2^2) |
| 普通 | 8 | 2^8 | 窗口大小 * (2^8) |
| 实验 | 14 | 2^14 | 窗口大小 * (2^14) |
这些设置很有可能会影响 TCP 性能，但请记住，Internet 中不受 Azure 控制的许多其他因素也可能会影响 TCP 性能。
加速网络和接收端缩放
加速网络
虚拟机网络功能模块一直以来对客户机和虚拟机监控程序/主机的 CPU 资源要求很高。 主机 CPU 在软件中处理通过主机传输的所有数据包，包括所有虚拟网络封装和解封。 通过主机的流量越多，CPU 负载就越高。 如果主机 CPU 因处理其他操作而繁忙，这些操作会影响网络的吞吐量和延迟。 Azure 使用加速网络解决了此问题。
加速网络通过 Azure 的内部可编程硬件以及 SR-IOV 之类的技术，提供一贯的超低网络延迟。 加速网络将大量的 Azure 软件定义网络堆栈从 CPU 转移到基于 FPGA 的 SmartNIC。 此更改使最终用户应用程序能够回收计算周期，从而在 VM 上减少负载，降低抖动并提高延迟的一致性。 换而言之，性能可能更具确定性。
加速网络允许来宾 VM 绕过主机来与主机的 SmartNIC 直接建立数据路径，从而提高了性能。 加速网络的部分优势如下：
较低的延迟/每秒更高的数据包数（pps）：从数据路径中删除虚拟交换机可以消除主机中数据包用于策略处理的时间，并增加可以在 VM 中处理的数据包数。
减少抖动：虚拟交换机处理取决于需要应用的策略量以及正在执行处理的 CPU 的工作负荷。 将策略实施卸载到硬件消除了这种可变性，因为可以将数据包直接传送到 VM，消除了主机与 VM 之间的通信，以及所有的软件中断和上下文切换。
降低了 CPU 利用率：绕过主机中的虚拟交换机可以减少用于处理网络流量的 CPU 资源。
若要使用加速网络，需要在每个适用的 VM 上显式启用它。 有关说明，请参阅 创建具有加速网络的 Linux 虚拟机 。
接收端缩放
接收端缩放 (RSS) 是一种网络驱动程序技术，它通过在多处理器系统中的多个 CPU 之间分配接收处理，更有效地分配网络流量的接收负载。 简单来说，RSS 可让系统处理更多的接收流量，因为它使用所有可用的 CPU，而不是只使用一个。 有关 RSS 的更多技术讨论，请参阅 接收端缩放简介。
在 VM 上启用加速网络后，若要获得最佳性能，需要启用 RSS。 RSS 也能够为不使用加速网络的 VM 带来优势。 有关如何确定 RSS 是否已启用以及如何启用 RSS 的概述，请参阅 “优化 Azure 虚拟机的网络吞吐量”。
TCP TIME_WAIT 和 TIME_WAIT 抹消
TCP TIME_WAIT是影响网络和应用程序性能的另一个常见设置。 繁忙的 VM 经常以客户端或服务器的形式打开和关闭多个套接字。 在正常 TCP 操作期间，套接字通常会进入 TIME_WAIT 状态，并在该状态下停留较长时间。 此状态确保在套接字关闭之前在套接字上传递任何剩余数据。 因此，TCP/IP 堆栈通常通过静默删除客户端的 TCP SYN 数据包来防止套接字重用。
可以配置套接字保持为 TIME_WAIT 状态的时长。 持续时间范围为 30 秒到 240 秒。 套接字是一种有限的资源，其可用性是可配置的。 通常，在任意给定时间，大约 30,000 个套接字可供使用。 如果系统使用所有可用的套接字，或者客户端和服务器使用不匹配TIME_WAIT设置，则 VM 可能会尝试重复使用仍处于TIME_WAIT状态的套接字。 在这种情况下，新连接会失败，因为 TCP SYN 数据包以无提示方式删除。
出站套接字的端口范围值可以在操作系统的 TCP/IP 堆栈中进行配置。 这同样适用于 TCP TIME_WAIT 设置和重复使用套接字的情况。 更改这些数字可能会提高可伸缩性。 但是，根据具体的情况，这些更改可能会导致互操作性问题。 如果更改这些值，应小心。
可以使用 TIME_WAIT 抹消来解决此缩放限制。 使用 TIME_WAIT 抹消可以在某些情况下重用某个套接字，例如，当新连接的 IP 数据包中的序列号超过前一连接的最后一个数据包的序列号时。 在这种情况下，作系统允许建立新连接（它接受新的 SYN/ACK），并强制关闭处于TIME_WAIT状态的上一个连接。 Azure 中的 Windows VM 支持此功能。 若要了解其他 VM 是否支持此功能，请咨询 OS 供应商。
若要了解如何配置 TCP TIME_WAIT设置和源端口范围，请参阅 可修改的设置以提高网络性能。
可能会影响性能的虚拟网络因素
VM 最大出站吞吐量
Azure 提供各种 VM 大小和类型，每个 VM 具有不同的性能功能组合。 其中一项功能是以兆位/秒 (Mbps) 计量的网络吞吐量（或带宽）。 由于虚拟机托管在共享硬件上，因此网络容量需在使用同一硬件的虚拟机中公平地共享。 与更小的虚拟机相比，为更大的虚拟机分配的带宽更多。
分配给每个虚拟机的网络带宽是根据来自虚拟机的出口流量（出站）流量来测量的。 从虚拟机流出的所有网络流量均计入分配限制，不管流向哪个目标。 如果虚拟机有 1,000 Mbps 的限制，则此限制适用于出站流量是发往同一虚拟网络中的另一个虚拟机还是 Azure 外部的虚拟机。
入口流量并未被直接测量或限制。 但是，其他因素（例如 CPU 和存储限制）可能会影响虚拟机处理传入数据的能力。
加速网络旨在改进网络性能（包括延迟、吞吐量和 CPU 使用率）。 虚拟机的吞吐量可以通过加速网络来改进，但仍受分配给该虚拟机的带宽的限制。
Azure 虚拟机上至少附加了一个网络接口。 它们可能包含多个网络接口。 分配给某个虚拟机的带宽是流经所有网络接口（已连接到该虚拟机）的所有出站流量的总和。 换言之，带宽是按虚拟机分配的，而不管该虚拟机上附加了多少个网络接口。
Azure 中 Windows 虚拟机的大小中详细介绍了每个 VM 大小支持的预期出站吞吐量和网络接口数。 若要查看最大吞吐量，请选择一种类型（例如“常规用途”），然后在结果页上找到有关大小系列的部分（例如“Dv2 系列”）。 对于每个系列，有一个表格的最后一列中提供了网络规范，其标题为“最大 NIC 数/预期网络带宽 (MBps)”。
吞吐量限制适用于虚拟机。 吞吐量不受以下因素影响：
网络接口数：带宽限制适用于来自虚拟机的所有出站流量的总和。
加速网络：虽然此功能有助于实现已发布的限制，但它不会更改限制。
流量目标：所有目标都计入出站限制。
协议：所有协议的所有出站流量都计入限制。
有关详细信息，请参阅 虚拟机网络带宽。
Internet 性能注意事项
如本文所述，Internet 因素以及不受 Azure 控制的因素可能会影响网络性能。 以下是其中的部分因素：
延迟：两个终结点之间的往返时间受中间网络上的问题、不采用“最短”距离路径的流量以及次优对等路径的影响。
数据包丢失：数据包丢失是由网络拥塞、物理路径问题以及性能不佳的网络设备引起的。
MTU 大小/碎片：沿路径的碎片可能导致数据到达延迟或数据包到达顺序不足，这可能会影响数据包的传递。
Traceroute 是一个不错的工具，它可以测量源设备与目标设备之间的每条网络路径上的网络性能特征（例如数据包丢失和延迟）。
网络设计注意事项
除了本文前面所述的考虑因素以外，虚拟网络的拓扑也可能会影响网络性能。 例如，将全球流量回传到单中心虚拟网络的中心辐射设计引入了网络延迟，这会影响整体网络性能。
网络流量通过的网络设备数也会影响总体延迟。 在中心辐射型设计中，如果流量在传输到 Internet 之前会通过辐射网络虚拟设备和中心虚拟设备，则网络虚拟设备会造成一些延迟。
Azure 区域、虚拟网络和延迟
Azure 区域由一个笼统的地理区域中的多个数据中心构成。 这些数据中心的实体位置可能并不相互靠近。 在某些情况下，它们被分隔开了多达10公里。 虚拟网络是位于 Azure 物理数据中心网络顶部的逻辑叠加层。 虚拟网络并不意味着数据中心内部采用任何特定的网络拓扑。
例如，同一个虚拟网络和子网中的两个 VM 可能位于不同的机架、设备排中，甚至位于不同的数据中心内。 它们可以被相隔几英尺或几公里的光纤电缆分隔开来。 这种变数可能会在不同的 VM 之间造成可变的延迟（相差几毫秒）。
VM 的地理位置以及两个 VM 之间的潜在延迟受可用性集、邻近放置组和可用性区域的配置的影响。 但是，某个区域中数据中心之间的距离与该区域直接相关，主要受该区域中数据中心拓扑的影响。
源 NAT 端口耗尽
Azure 中的部署可以与 Azure 外部公共互联网和/或公共 IP 空间中的终结点进行通信。 当实例发起出站连接时，Azure 会动态将专用 IP 地址映射到公共 IP 地址。 在 Azure 创建此映射后，发起的出站流的返回流量还可以抵达发起该流的专用 IP 地址。
对于每个出站连接，Azure 负载均衡器需要保持此映射一段时间。 根据 Azure 的多租户性质，对每个 VM 的每个出站流保持此映射可能会消耗大量的资源。 因此，需要根据 Azure 虚拟网络的配置设置一些限制。 或者，更确切地说，Azure VM 只能在给定时间进行一些出站连接。 达到这些限制后，VM 不会进行更多的出站连接。
但是，此行为是可配置的。 有关 SNAT 和 SNAT 端口耗尽的详细信息，请参阅 本文。
测试 Azure 上的网络性能
本文中的许多性能最大值都与两个 VM 之间的网络延迟/往返时间（RTT）相关。 本部分提供有关如何测试延迟/RTT 以及如何测试 TCP 性能和 VM 网络性能的一些建议。 可以使用本部分所述的方法，来优化前面所述的 TCP/IP 和网络值并执行性能测试。 在前面提供的计算中输入延迟、MTU、MSS 和窗口大小值，并将理论最大值与测试期间观察到的实际值进行比较。
测量往返时间和丢包率
TCP 性能严重依赖于 RTT 和丢包率。 测量 RTT 和丢包率的最简单方法是使用 Windows 和 Linux 中提供的 PING 实用工具。 PING 的输出显示源和目标之间的最小/最大/平均延迟。 它显示数据包丢失。 PING 默认使用 ICMP 协议。 可以使用 PsPing 来测试 TCP RTT。 有关详细信息，请参阅 PsPing。
ICMP 和 TCP ping 不会测量加速的网络数据路径。 若要测量数据路径，请阅读 本文中的 Latte 和 SockPerf。
测量虚拟机的实际带宽
若要准确测量 Azure VM 的带宽，请遵循 本指南。
有关测试其他方案的详细信息，请参阅以下文章：
检测低效的 TCP 行为
在数据包捕获中，Azure 客户可能会看到带有 TCP 标志（SACK、DUP ACK、RETRANSMIT 和 FAST RETRANSMIT）的 TCP 数据包，这可能表示存在网络性能问题。 具体而言，这些数据包表示由于数据包丢失而导致网络效率低下。 但数据包丢失不一定是 Azure 性能问题造成的。 性能问题可能是应用程序问题、操作系统问题或者不直接与 Azure 平台相关的问题造成的。
另请注意，在网络中，某些重新传输和重复 ACK 是正常的。 TCP 协议原本就很可靠。 数据包捕获中出现这些 TCP 数据包并不一定证明存在系统性的网络问题，除非这些数据包大量出现。
尽管如此，出现此类数据包表明 TCP 吞吐量并未实现其最大性能，本文的其他部分已讨论了原因。
后续步骤
了解 Azure VM 的 TCP/IP 性能优化后，请考虑探索 规划虚拟网络的其他因素。 还可以 详细了解如何连接和配置虚拟网络。