適用於 Azure VM 的 TCP/IP 效能微調
本文說明常用的 TCP/IP 效能微調技術，以及對 Azure 上執行的虛擬機器使用這些技術時需要注意的事項。 內容將提供這些技術的基本概觀，並探索如何進行調整。
常用的 TCP/IP 微調技術
MTU、分割和大型傳送卸載
MTU
傳輸單位上限 （MTU） 是最大大小框架 （封包加上網路存取標頭），以位元組為單位指定，可透過網路介面傳送。 MTU 是可設定的設定。 Azure VM 使用的預設 MTU，以及全球大多數網路裝置的預設設定為 1,500 位元組。
分割
當傳送的封包超過網路介面的 MTU 時，就會發生分割。 TCP/IP 堆疊會將封包分成符合介面 MTU 的較小片段。 分割發生在 IP 層，且與基礎通訊協定 (例如 TCP) 無關。 當傳送的 2000 位元組封包超過網路介面的 MTU 設定值 1500 時，封包將會拆分成一個 1500 位元組的封包和一個 500 位元組的封包。
來源和目的地間路徑中的網路裝置可以卸除超過 MTU 的封包，或將封包分成較小的片段。
在 IP 封包中「不分割」位元
「不分割」(DF) 位元是 IP 通訊協定標頭中的旗標。 DF 位元表示傳送者與接收者間路徑中的網路裝置不得分割封包。 您可以基於許多原因設定此位元。 (如需範例，請參閱本文的〈路徑 MTU 探索〉一節。)當網路裝置收到已設定「不分割」位元的封包，且該封包超過裝置介面的 MTU 時，則標準行為是讓裝置捨棄該封包。 裝置會將 ICMP 需要分割訊息回傳給封包的原始來源。
分割的效能影響
分割可能會對效能造成負面影響。 影響效能的主要原因之一是封包分割和重組對 CPU/記憶體的影響。 當網路裝置需要分割封包時，它必須分配 CPU/記憶體資源來執行分割。
當封包重新組合時，就會發生相同的情況。 網路裝置必須儲存所有片段，直到接收端已接收這些片段，然後才能將它們重新組合成原始封包。
Azure 和分割
加速網路不會處理 Azure 中的分割封包。 當 VM 收到分割的封包時，將會透過非加速路徑來處理它。 這表示分割的封包不會獲得加速網路的優點 (延遲較低、抖動降低，每秒封包數較高)。 基於這個理由，建議您盡可能避免分割。
根據預設，Azure 會卸除亂序片段，也就是未依照從來源端點傳輸的順序抵達 VM 的分割封包。 當封包透過網際網路或其他大型 WAN 傳輸時，可能會發生這種情況。 在某些情況下，可以啟用亂序片段重新排序。 如果應用程式需要此情況，請開啟支援案例。
調整 MTU
我們不建議客戶增加 VM NIC 上的 MTU。 如果 VM 需要與未在虛擬網路中設定類似 MTU 的目的地通訊，可能會發生分割，因而降低效能。
大型傳送卸載
大型傳送卸載 (LSO) 可將分割的封包卸載到乙太網路卡，藉此提升網路效能。 啟用 LSO 時，TCP/IP 堆疊會建立大型 TCP 封包並傳送至到乙太網路卡進行分割，然後轉送分割的封包。 LSO 的好處是，它可以使 CPU 無需將封包分割為符合 MTU 的大小，並將處理工作卸載到乙太網路介面，並在硬體中執行。 若要深入了解 LSO 的優點，請參閱支援大型傳送卸載。
啟用 LSO 時，Azure 客戶可能會在執行封包擷取時看到大型框架大小。 這些大型框架大小可能會導致某些客戶認為發生分割或使用大型 MTU (但其實沒有)。 若使用 LSO，乙太網路卡可向 TCP/IP 堆疊公告使用較大的區段大小 (MSS)，以建立較大的 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 的介面會有 1,460 的 MSS。 但您可以設定 MSS。
在來源與目的地之間設定 TCP 工作階段時，TCP 三向交握會接受此設定。 兩端都會傳送 MSS 值，但會使用兩者中較低的值進行 TCP 連線。
請記住，來源和目的地的 MTU 不是決定 MSS 值的唯一因素。 中繼網路裝置 (例如 VPN 閘道，包括 Azure VPN 閘道) 可以單獨調整 MTU，與來源和目的地無關，以確保最佳網路效能。
路徑 MTU 探索
裝置可以交涉 MSS 值，但可能不會指出可以使用的實際 MSS。 這是因為來源和目的地間路徑中的其他網路裝置，可能會有比來源和目的地還低的 MTU 值。 在此情況下，MTU 小於封包的裝置將會捨棄封包。 裝置會傳回 ICMP 需要分割 (類型 3，代碼 4) 訊息，其中包含其 MTU。 這個 ICMP 訊息可讓來源主機適當地減少其路徑 MTU。 這個程序稱為「路徑 MTU 探索」(PMTUD)。
PMTUD 程序的效率不佳，且會影響網路效能。 傳送的封包超過網路路徑的 MTU 時，必須以較低的 MSS 重新傳送封包。 如果傳送者未收到 ICMP 需要分割訊息，可能是因為路徑中的網路防火牆 (通常稱為 PMTUD 黑洞) 關係，傳送者並不知道必須降低 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 | 60 | 1.09 | 8.74 |
| 65,535 | 90 | .73 | 5.83 |
| 65,535 | 120 | 55. | 4.37 |
如果封包遺失，TCP 連線的最大輸送量將會降低，而傳送者會重新傳輸已傳送的資料。
TCP 視窗縮放
TCP 視窗縮放是一種可動態增加 TCP 視窗大小的技術，允許在需要確認之前傳送更多資料。 在前一範例中，在需要確認之前可傳送 45 個封包。 如果您增加可在需要確認之前傳送的封包數，即會減少傳送者等待確認的次數，進而增加 TCP 最大輸送量。
下表說明這些關聯性：
| 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 設定：
| AutoTuningLevel | 比例因素 | 比例乘數 | 計算 最大視窗大小的公式 |
|---|---|---|---|
| 停用 | 無 | 無 | 視窗大小 |
| 受限制 | 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 上，不論是作為用戶端或伺服器 (來源 IP：來源連接埠 + 目的地 IP：目的地連接埠)，在 TCP 的正常作業期間，指定的通訊端最後會處於 TIME_WAIT 狀態並持續一段很長的時間。 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 大小和類型，各有不同的效能功能組合。 其中一項功能就是網路輸送量 (或頻寬)，量值單位是 Mb/秒 (Mbps)。 因為虛擬機器裝載於共用硬體，因此使用相同硬體的虛擬機器必須公平共用網路容量。 相較於較小的虛擬機器，大型虛擬機器會配置較多的頻寬。
配置給每個虛擬機器的網路頻寬是依據從虛擬機器的流出 (輸出) 流量來計量。 所有離開虛擬機器的網路流量都會計算到配置的限制，不會因為目的地不同而有差異。 例如，如果虛擬機器有 1,000 Mbps 的限制，則無論輸出流量的目的地是相同虛擬網路中的另一部虛擬機器，或是 Azure 之外的虛擬機器，皆會套用該限制。
輸入則不會直接計量或限制。 但是還有其他因素，例如 CPU 和儲存體限制可能會影響虛擬機器處理內送資料的能力。
加速網路旨在改善網路效能，包括延遲、輸送量和 CPU 使用率。 加速網路可提升虛擬機器的輸送量，但不能超過虛擬機器的配置頻寬。
Azure 虛擬機器必須至少有一個連接的網路介面。 可能會有數個連接的網路介面。 配置給虛擬機器的頻寬，是連接該機器的所有網路介面上所有輸出流量的總和。 換句話說，配置的頻寬是以每個虛擬機器為基礎，跟連接該機器的網路介面有多少個無關。
預期的輸出輸送量和每個 VM 大小支援的網路介面數目，皆詳細列在 Azure 中 Windows 虛擬機器的大小。 若要查看最大輸送量，請選取類型，例如一般用途，然後在產生的頁面上尋找有關大小系列的區段 (例如「Dv2 系列」)。 每個系統都會有一張表格說明，並在最後一個資料行中提供網路規格，其標題為「最大 NIC/預期的網路頻寬 (Mbps)」。
輸送量限制適用於虛擬機器。 輸送量不受下列因素影響：
網路介面數目：頻寬限制會套用到虛擬機器的所有輸出流量總計。
加速網路：雖然此功能有助於達到已發佈的限制，但不會變更限制。
流量目的地：所有目的地都會計入輸出限制。
通訊協定：通過所有通訊協定的所有輸出流量都會計入限制。
如需詳細資訊，請參閱虛擬機器網路頻寬。
網際網路效能考量
如本文所述，網際網路上的因素和 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 效能微調，您可能會想要閱讀規劃虛擬網路的其他考量，或深入了解如何連線和設定虛擬網路。