TCP/IP 性能的已知问题

注意

本文包含在由 3 个部分组成的系列中。 可查看 第 1 部分:TCP/IP 性能概述 和第 2 部分:TCP/IP 性能基础网络问题

本文介绍以下 TCP/IP 性能问题:

  • 高延迟和高带宽网络时吞吐量缓慢
  • 低延迟和高带宽网络时吞吐量缓慢
  • 基础网络问题

高延迟和带宽网络上的吞吐量速度缓慢

位于不同站点中的两个服务器通过高延迟网络连接。 使用 ctsTraffic 工具测量的吞吐量低于基线。

这是因为任一服务器上都没有启用 TCP 窗口缩放选项。 使用 Windows 命令提示符或Windows PowerShell通过设置 TCP 接收窗口自动优化级别来启用 选项。

使用命令提示符启用自动调整级别

运行以下命令:

netsh int tcp set global autotuninglevel=normal 

若要检查是否启用了自动调整级别,请使用以下命令:

netsh int tcp show global

用于检查 autotunig 级别的命令提示符命令。

使用 PowerShell 启用自动调整级别

运行以下 cmdlet:

Get-NetTCPSetting | Set-NetTCPSetting -AutoTuningLevelLocal Normal

若要检查是否启用了自动调整级别,请使用以下 cmdlet:

Get-NetTCPSetting | Format-List SettingName,Autotuninglevel*

用于检查是否已启用自动调整级别的 PowerShell cmdlet。

注意

接收窗口自动调整有五个级别:禁用、高度受限、受限、正常和实验。 有关自动调整如何影响吞吐量的详细信息,请参阅 性能优化网络适配器

低延迟和高带宽网络上的低吞吐量速度

两台服务器在具有低延迟和高带宽的同一网络上连接。 使用 ctsTraffic 工具创建基线或测试 TCP 性能时,多核 CPU 服务器中仅出现 CPU 0 峰值。

出现此问题的原因是,未启用或未正确配置接收端缩放 (RSS) 或虚拟机队列 (VMQ) 功能。 当物理计算机是虚拟机监控程序时,请使用 VMQ。 如果不是,请在操作系统 (OS) 和网卡上启用 RSS。

注意

无线网卡不支持 RSS 或 VMQ 功能。

为 OS 启用 RSS

使用命令提示符或 PowerShell 启用 RSS,如下所示:

命令提示符netsh int tcp set global rss=enabled

PowerShellSet-NetAdapterRss -Name <interface name> -Enabled $True

为网卡启用 RSS

首先,检查是否启用了 RSS 功能。 使用以下 cmdlet 检查相关配置的网络卡高级属性:

Get-NetAdapterAdvancedProperty | Where-Object -property RegistryKeyword -Like *rss* | format-table -AutoSize

注意

更改高级属性可能会导致网络连接中断或丢失。 在进行更改之前,请参阅 NIC 供应商文档。

按照以下步骤为网卡启用 RSS:

  1. 运行 ncpa.cpl 以打开网络Connections
  2. 右键单击目标连接,然后选择 “属性>配置”。
  3. 在“高级”选项卡下,在“属性”列表中找到“接收端缩放”,然后将“值”设置为“启用”。
  4. 选择“确定”。

也可以使用 PowerShell cmdlet 启用 RSS:

Set-NetAdapterAdvancedProperty -Name <Interface name> -RegistryKeyword *RSS -RegistryValue 1

基础网络问题

本部分介绍如何在测量吞吐量基线或排查吞吐量问题时检查基础网络问题。

若要获取数据包级日志分析,请使用网络数据包捕获工具 ((如 Microsoft 网络监视器、Wireshark 或 ctsTraffic) )检查基础网络问题。

使用网络数据包捕获工具获取日志的步骤

  1. 使用 Microsoft 网络监视器Wireshark 开始日志记录,以捕获两个终结点上的流量。 还可以使用 Windows 内置捕获工具,如下所示:

    1. 以管理员身份打开“命令提示符”。

    2. 运行以下命令:

      NETSH TRACE START CAPTURE=YES REPORT=DISABLED TRACEFILE=<FILEPATH>.ETL MAXSIZE=512
      

      注意

      使用 netsh trace 命令时,可能需要多个捕获。

  2. 运行 CTStraffic.exe 工具以生成 .csv 文件

  3. 停止日志记录。 对于 Windows 内置捕获工具,请以管理员身份键入 NETSH TRACE STOP 命令提示符。

分析捕获文件

下面的示例演示如何分析筛选的结果。 在此方案中,ctsTraffic 工具使用推送模式 (默认模式) ,这意味着数据包将从客户端发送到服务器。

  1. 在 Microsoft 网络监视器中打开捕获文件。

  2. 使用 Property.TCPRetransmit==1 && tcp.Port==4444 筛选器筛选网络跟踪,该筛选器定位重新传输数据包。 数据包重新传输意味着永远不会收到来自发送方的给定 TCP 序列的 TCP 确认。

    注意

    若要分析 ETL 文件,请转到 “工具>选项>”“分析程序配置文件>”“Windows>设置为活动>”确定”。

    重新传输帧的网络跟踪捕获。

    如屏幕截图所示,帧 #441 重新传输两次,这意味着发送方将传输三次帧。 使用相同的 TCP 序列号 (2278877548) 来标识此帧。

  3. 右键单击“帧详细信息”中的“SequenceNumber”,然后选择“添加所选值以显示筛选器”。

    在右键单击 SequenceNumber 后,在“帧详细信息”中选择“将所选值添加到显示筛选器”选项。

  4. 通过添加“//”来禁用上一个筛选器,如下所示:

    禁用显示筛选器中的上一个筛选器。

  5. 选择“应用”。 显示具有此序列号的完整 TCP 序列,如下所示:

    选择“应用”按钮以显示完整的 TCP 序列。

    此结果显示服务器未接收原始帧 #441 ,并且由发送方重新传输。 如果未收到序列的确认,则会重新传输帧。 若要了解 TCP 的工作原理,请参阅 通过 TCP/IP 进行三向握手Windows TCP 功能说明。 然后,从客户端跟踪复制 TCP.SequenceNumber == <value> 序列筛选器,并将其粘贴到服务器跟踪上。

    在服务器上,仅接收给定序列的一个数据包,如以下结果所示:

    从服务器端显示的 TCP 序列。

    此结果证明,中间网络设备上的发送方与接收方存在数据包丢失。 数据包离开发送方,但永远不会到达接收方。 这是基础网络的问题,应由网络管理员解决。

TCP 环回性能

随着 Windows Server 2019 的发布,TCP/IP 环回处理模型已更改,以解决以前 Windows 版本中存在的某些性能瓶颈。 本部分介绍可用于更改 TCP/IP 环回处理行为的配置选项。

配置参数可通过 netsh 配置工具获得。 可以单独为 IPv4 和 IPv6 设置每个设置。 默认值可能因不同的 Windows 版本而异。

注意

在常规用途 Windows 计算机上,不应更改默认值。

如果应用程序开发人员确定环回数据路径是应用程序性能不足的根本原因,则可以使用以下命令根据应用程序的个别需求定制配置。

netsh int ipv6|ipv4 set gl loopbackexecutionmode=adaptive|inline|worker
netsh int ipv6|ipv4 set gl loopbackworkercount=<value>
netsh int ipv6|ipv4 set gl loopbacklargemtu=enable|disable

解释

Loopbackexecutionmode
Worker

在此模式下,数据包在发送端排队,并由接收端的工作线程进行处理。 此模式有利于吞吐量,而有利于延迟。

Inline

在此模式下,处理在发送方和接收方的应用程序线程上下文中完成。 此模式比吞吐量更有利于延迟。

Adaptive

数据流的第一个数据包内联处理,然后将数据包延迟到 workerthread。 此模式尝试平衡延迟和吞吐量。

Loopbackworkercount

允许配置已使用的工作线程数。

Loopbacklargemtu

允许配置大型 MTU 的使用,这应启用。