通过

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

命令提示符命令检查自动图尼格级别。

使用 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

PowerShell：Set-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 以打开 网络连接。
  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

数据流的第一个数据包正在内联处理，然后将数据包延迟到工作线程。 此模式尝试平衡延迟和吞吐量。

Loopbackworkercount

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

Loopbacklargemtu

允许配置大型 MTU 的使用，应启用此功能。