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*

注意

接收窗口自動調整有五個層級：停用、高度限制、限制、正常和實驗性。 如需自動調整如何影響輸送量的詳細資訊，請參閱 效能調整網路適配器。

低延遲和高頻寬網路的輸送量速度變慢

兩部伺服器聯機在低延遲和高頻寬的相同網路上。 當您使用 ctsTraffic 工具建立基準或測試 TCP 效能時，只有多核心 CPU 伺服器中的 CPU 0 尖峰。

發生此問題的原因是未啟用或未正確設定接收端調整 （RSS） 或虛擬機佇列 （VMQ） 功能。 當實體機器是 Hypervisor 時，請使用 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，然後選取 [新增選取的值] 以顯示篩選。

   

4. 新增 “【” 以停用先前的篩選，如下所示：

   

5. 選取套用。 具有此序號的完整 TCP 序列如下所示：

   

   此結果顯示伺服器未收到原始框架 #441 ，且由寄件者重新傳輸。 如果未收到序列的通知，就會重新傳輸框架。 若要瞭解 TCP 的運作方式，請參閱 透過 TCP/IP 的三向交握和 Windows TCP 功能的描述。 然後，從客戶端追蹤複製 TCP.SequenceNumber == <value> 順序篩選，並將它貼到伺服器追蹤上。

   在伺服器上，只收到指定序列的一個封包，如下列結果所示：

   

   此結果證明中繼網路裝置上的傳送者與接收者發生封包遺失。 封包會離開傳送者，但永遠不會到達接收者。 這是基礎網路的問題，網路管理員應該加以解決。

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 的使用，這應該啟用。