適用於 Azure VM 的 TCP/IP 效能微調

2025-05-01

本文說明常用的 TCP/IP 效能微調技術，以及對 Azure 上執行的虛擬機器使用這些技術時需要注意的事項。它提供技術的基本概觀，並探索如何調整虛擬機。

常用的 TCP/IP 微調技術

MTU、分割和大型傳送卸載

MTU

最大傳輸單位（MTU）是通過網路介面傳送的最大封包大小（封包加上網路存取標頭），其大小以位元組為單位指定。 MTU 是可設定的設定。 Azure VM 使用的預設 MTU，以及全球大多數網路裝置的預設設定為 1,500 位元組。

分割

當傳送的封包超過網路介面的 MTU 時，就會發生分割。 TCP/IP 協議棧會將封包分成符合介面的 MTU 的較小片段。分割發生在 IP 層，且與基礎通訊協定 (例如 TCP) 無關。當 2,000 位元組封包透過 MTU 為 1,500 的網路介面傳送時，封包會細分為一個 1,500 位元組封包和一個 500 位元組封包。

來源和目的地間路徑中的網路裝置可以卸除超過 MTU 的封包，或將封包分成較小的片段。

在 IP 封包中「不分割」位元

「不分割」(DF) 位元是 IP 通訊協定標頭中的旗標。 DF 位元表示傳送者與接收者間路徑中的網路裝置不得分割封包。您可以基於許多原因設定此位元。 (如需範例，請參閱本文的〈路徑 MTU 探索〉一節。)當網路裝置收到已設定「不分割」位元的封包，且該封包超過裝置介面的 MTU 時，則標準行為是讓裝置捨棄該封包。裝置會將 ICMP 需要分割訊息回傳給封包的原始來源。

分割的效能影響

分割可能會對效能造成負面影響。效能影響的主要原因之一是封包片段和重新組譯的CPU/記憶體影響。當網路裝置需要分散封包時，它必須配置 CPU/記憶體資源來執行分散。

當封包重新組合時，就會發生相同的情況。網路裝置必須儲存所有片段，直到接收端已接收這些片段，然後才能將它們重新組合成原始封包。

Azure 和分割

Azure 不會使用加速網路處理分散的封包。當 VM 收到碎片化的封包時，非加速路徑會加以處理。因此，分散的封包遺漏加速網路的優點，例如延遲較低、抖動降低，每秒封包數較高。基於這個理由，建議您盡可能避免分割。

根據預設，Azure 會卸除以不依序抵達 VM 的分散封包，這表示封包不符合來源端點的傳輸順序。當封包透過因特網或其他大型 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 封包。乙太網路卡接著會根據 MTU，將此完整的非分段帧分割成許多較小的帧，這些帧可以在 VM 上執行的封包捕獲中看到。

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“需要進行片段化”（類型 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 固定設為 1350 位元組，並將通道介面 MTU 設定為 1400。如需詳細資訊，請參閱 VPN 裝置和 IPsec/IKE 參數頁面。

延遲、來回時間和 TCP 視窗縮放

延遲和來回時間

光線速度會透過光纖網路決定網路等待時間。兩個網路裝置之間的來回時間（RTT）會控管 TCP 網路輸送量。

路由	距離	單向時間	RTT
紐約至舊金山	4,148 公里	21 毫秒	42 毫秒
紐約至倫敦	5,585 公里	28 毫秒	56 毫秒
紐約到雪梨	15,993 公里	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 連線的每秒最大輸送量 (MB)。 (為了方便閱讀，量值單位使用 MB。)

TCP 視窗大小 (位元組)	RTT 延遲 (毫秒)	每秒最大輸送量 (MB)	每秒最大輸送量 (Mb)
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 延遲 (毫秒)	每秒最大輸送量 (MB)	每秒最大輸送量 (Mb)
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 GB）。

支援 TCP 視窗縮放

Windows 可以為不同的連線類型設定不同的比例因素。 (連線類別包括資料中心、網際網路等等。)您可以使用 Get-NetTCPConnection PowerShell 命令來檢視視窗縮放連線類型：

Get-NetTCPConnection

您可以使用 Get-NetTCPSetting PowerShell 命令來檢視每個類別的值：

Get-NetTCPSetting

您可以使用 Set-NetTCPSetting PowerShell 命令，在 Windows 設定初始 TCP 視窗大小和 TCP 比例因素。如需詳細資訊，請參閱 Set-NetTCPSetting。

Set-NetTCPSetting

下列值為 AutoTuningLevel 的有效 TCP 設定：

自動調整級別	比例因素	比例乘數	計算最大視窗大小的公式
停用	無	無	視窗大小
受限制	4	2^4	視窗大小 * (2^4)
高限制性	2	2^2	視窗大小 * (2^2)
一般	8	2^8	視窗大小 * (2^8)
實驗	14	2^14	視窗大小 * (2^14)

這些設定最有可能會影響 TCP 效能，但請記住，網際網路上的許多其他因素 (除了 Azure 的控制項外) 也會影響 TCP 效能。

加速網路和接收端調整

加速網路

虛擬機器網路功能歷來都是客體 VM 和 Hypervisor/主機上的 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，而不是只有一個 CPU。如需有關 RSS 更多技術說明，請參閱接收端調整簡介。

若要在 VM 上啟用加速網路時取得最佳效能，您必須啟用 RSS。沒有使用加速網路的 VM 也可以因使用 RSS 而獲益。若要了解如何判斷 RSS 是否已啟用，以及如何啟用，請參閱最佳化 Azure 虛擬機器的網路輸送量。

TCP TIME_WAIT 和 TIME_WAIT Assassination

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 Assassination 來解決這項調整限制。 TIME_WAIT Assassination 可讓通訊端在某些情況下重複使用，例如在新連線的 IP 封包中，序號超過上一個連線中最後一個封包的序號。在此情況下，作系統允許建立新的連線（它接受新的SYN/ACK），並強制關閉先前處於TIME_WAIT狀態的連線。 Azure 中的 Windows VM 支援這項功能。若要深入了解其他 VM 的支援，請洽詢作業系統廠商。

若要了解如何設定 TCP TIME_WAIT 設定和來源連接埠範圍，請參閱可以修改以改善網路效能的設定。

會影響效能的虛擬網路因素

VM 輸出輸送量上限

Azure 提供各種 VM 大小和類型，每個 VM 都有不同的效能功能組合。其中一項功能就是網路輸送量 (或頻寬)，量值單位是 Mb/秒 (Mbps)。因為虛擬機器裝載於共用硬體，因此使用相同硬體的虛擬機器必須公平共用網路容量。相較於較小的虛擬機器，大型虛擬機器會配置較多的頻寬。

每台虛擬機所分配的網路頻寬是根據該虛擬機的出站（外發）流量來測量的。所有離開虛擬機器的網路流量都會計算到配置的限制，不會因為目的地不同而有差異。如果虛擬機有 1,000 Mbps 的限制，該限制會套用到輸出流量是針對相同虛擬網路中的另一部虛擬機，還是 Azure 外部的虛擬機。

進入不會直接加以測量或限制。但是還有其他因素，例如 CPU 和儲存體限制可能會影響虛擬機器處理內送資料的能力。

加速網路旨在改善網路效能，包括延遲、輸送量和 CPU 使用率。加速網路可提升虛擬機器的輸送量，但不能超過虛擬機器的配置頻寬。

Azure 虛擬機器必須至少有一個連接的網路介面。可能會有數個連接的網路介面。配置給虛擬機器的頻寬，是連接該機器的所有網路介面上所有輸出流量的總和。換句話說，配置的頻寬是以每個虛擬機器為基礎，跟連接該機器的網路介面有多少個無關。

預期的輸出輸送量和每個 VM 大小支援的網路介面數目，皆詳細列在 Azure 中 Windows 虛擬機器的大小。若要查看最大輸送量，請選取類型，例如一般用途，然後在產生的頁面上尋找有關大小系列的區段 (例如「Dv2 系列」)。每個系統都會有一張表格說明，並在最後一個資料行中提供網路規格，其標題為「最大 NIC/預期的網路頻寬 (Mbps)」。

輸送量限制適用於虛擬機器。輸送量不受這些因素影響：

網路介面數目：頻寬限制會套用到虛擬機器的所有輸出流量總計。
加速網路：雖然此功能有助於達到已發佈的限制，但不會變更限制。
流量目的地：所有目的地都會計入輸出限制。
通訊協定：通過所有通訊協定的所有輸出流量都會計入限制。

如需詳細資訊，請參閱虛擬機器網路頻寬。

Linux 虛擬機（VM）優化

現代的 Linux 核心提供了可以協助提升一致性和效能的功能，而某些工作負載有時可能需要這些功能。

如需詳細資訊，請參閱優化 Azure VM 上的網路頻寬

網際網路效能考量

如本文所述，網際網路上的因素和 Azure 控制之外的因素都會影響網路效能。以下是其中一些因素：

延遲：兩個端點之間的來回時間會受到中繼網路上的問題、不採用「最短」距離路徑的流量，以及次佳對等互連路徑的影響。
封包遺失：封包遺失是由網路壅塞、實體路徑問題，以及效能不佳的網路裝置所造成。
MTU 大小/分割：沿著路徑分割會造成資料抵達延遲或封包不照順序抵達，這都會影響封包傳遞。

路徑追蹤是一個不錯的工具，可沿著來源裝置和目的地裝置間的每一條網路路徑，測量網路效能特性 (例如，封包遺失和延遲)。

網路設計考量

除了本文稍早所說明的考量之外，虛擬網路的拓撲也會影響網路效能。例如，將全域流量回傳到單一中樞虛擬網路的中樞和支點設計，會產生網路延遲，進而影響整體網路效能。

網路流量通過的網路裝置數目也會影響整體延遲。在中樞和支點設計中，如果流量先通過支點網路虛擬設備和中樞虛擬設備，然後再傳輸到網際網路，則網路虛擬設備就會產生一些延遲。

Azure 區域、虛擬網路和延遲

Azure 區域是由存在於一般地理區域內的多個資料中心組成。這些資料中心實際上可能並不相鄰。在某些情況下，它們以高達10公里的距離分隔。虛擬網路是 Azure 實體資料中心網路頂端的邏輯重疊。虛擬網路不表示資料中心內的任何特定網路拓撲。

例如，位於相同虛擬網路和子網路中的兩部 VM，可能位於不同的機架、資料列甚或資料中心。它們之間可能隔著一英呎的光纖纜線，也可能隔著數公里的光纖纜線。這種變化可能在不同的 VM 之間產生不同的延遲 (幾毫秒的差異)。

VM 的地理位置，以及兩個 VM 之間的潛在延遲，會受到可用性設定組、鄰近放置群組和可用性區域的設定所影響。但是，某一區域中不同資料中心之間的距離是該區域特有的，而且主要是受到區域中的資料中心拓撲所影響。

來源 NAT 連接埠耗盡

Azure 中的部署可與 Azure 外部為於公用網際網路和/或公用 IP 空間中的端點進行通訊。當執行個體起始輸出連線時，Azure 會以動態方式將私人 IP 位址對應至公用 IP 位址。 Azure 建立此對應之後，此輸出產生流程的傳回流量便也可以送達產生該流程的私人 IP 位址。

對於每一個輸出連線，Azure Load Balancer 必須將這個對應維持一段時間。由於 Azure 的多租用戶性質，為每個 VM 的每個輸出流程維持此對應，會耗用大量資源。因此，依據 Azure 虛擬網路的設定，設定了一些限制。或者，更精確地說，Azure VM 只能在指定的時間進行一些輸出連線。達到這些限制時，VM 將不會進行更多輸出連線。

但您可以設定這個行為。如需 SNAT 和 SNAT 連接埠耗盡的詳細資訊，請參閱這篇文章。

測量 Azure 上的網路效能

本文中的許多效能上限都與兩部 VM 之間的網路等待時間/來回時間（RTT）相關。本節提供一些如何測試延遲/RTT 的建議，以及如何測試 TCP 效能和 VM 網路效能的建議。您可以使用本節所述的技術，對之前所述的 TCP/IP 和網路值進行微調和效能測試。在稍早提供的計算中輸入延遲、MTU、MSS 和視窗大小值，並將理論最大值與測試期間觀察到的實際值進行比較。

測量來回時間和封包遺失

TCP 效能與 RTT 和封包遺失密切關聯。 Windows 和 Linux 中提供的 PING 公用程式，可讓您用最簡單的方法來測量 RTT 和封包遺失。 PING 的輸出會顯示來源與目的地之間的最小/最大/平均延遲。它會顯示封包遺失。 PING 預設為使用 ICMP 通訊協定。您可以使用 PsPing 來測試 TCP RTT。如需詳細資訊，請參閱 PsPing。

ICMP 和 TCP Ping 不會測量加速的網路數據路徑。若要測量數據路徑，請閱讀本文中的 Latte 和 SockPerf。

測量虛擬機器的實際頻寬

若要正確測量 Azure VM 的頻寬，請遵循本指南。

如需測試其他案例的詳細資訊，請參閱下列文章：

偵測效率不佳的 TCP 行為

在封包擷取中，Azure 客戶可能會看到具有 TCP 旗標的 TCP 封包 (SACK、DUP ACK、RETRANSMIT 和 FAST RETRANSMIT)，表示可能發生網路效能問題。這些封包會特別指出因封包遺失而造成的網路效率不佳。但是，封包遺失不一定是由 Azure 效能問題所造成。效能問題可能是應用程式、作系統或其他可能與 Azure 平臺不直接相關的問題的結果。

此外，請記住，在網路上發生重新傳輸和重複 ACK 是正常現象。您可以信任建置的 TCP 通訊協定。封包擷取中這些 TCP 封包的辨識項不一定表示發生系統網路問題，除非這些辨識項數量過多。

然而，這些封包類型就表明了 TCP 輸送量不會達到其最大效能，原因如本文的其他章節所述。

下一步

既然您已瞭解 Azure VM 的 TCP/IP 效能微調，請考慮探索規劃虛擬網路的其他因素。您也可以深入瞭解如何連線和設定虛擬網路。