Windows 11 25H2 中的 TCP ACK 與延遲 ACK
本頁內容
TcpAckFrequency 與 TcpDelAckTicks 控制特定介面層級的 TCP 確認。參數讀取與範圍已獲確認；縮短 ACK 延遲並不保證能帶來效益，且會增加回程封包數量。
檢查了網路介面的參數路徑、預設值、範圍，以及對 TCP 確認規則的影響。
Windows 11 25H2 build 26200.9168，介面層級 TCP 參數。有丟包的網路、Wi-Fi、VPN 及不同伺服器未納入受控測量。
解析 TCP 元件與系統追蹤、檢查數值轉換，並與 Microsoft 公開文件核對。
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface-GUID}
| Value | Type | Default | 有效範圍 | 角色 |
|---|---|---|---|---|
TcpAckFrequency |
REG_DWORD |
2 |
0..255 |
發出 ACK 前的 full-sized segments 數量 |
TcpDelAckTicks |
REG_DWORD |
2 |
0..6 |
以 100-ms ticks 為單位的 delayed ACK 延遲 |
ACK policy 的運作方式
Section titled “ACK policy 的運作方式”TcpAckFrequency=1 設定為每個完整大小區段都發送 ACK。值 2 保留 TCP 一般的延遲確認規則。TcpDelAckTicks 以 100 毫秒為單位測量：預設值 2 設定約 200 毫秒的上限，而 0 則移除計時器的額外等待。其他 TCP 規則仍可能觸發立即確認。
TCP 堆疊使用針對特定網路介面讀取的值。寫入全域登錄機碼區段並不能取代介面設定。新的 VPN、vEthernet 或臨時介面卡會取得自己的 GUID，並在未針對它設定參數前保留預設值。
縮短 ACK 延遲可能對處理小封包及延遲確認敏感的应用程式有幫助。但同時回程封包數量與網路卡及 CPU 的負載都會增加。結果取決於連線的另一方、壅塞控制與 MTU，因此無法保證能降低網路延遲。
- 介面及其 GUID 的參數路徑。
0..255與0..6的預設值及有效範圍。- 全域登錄機碼區段不能取代特定介面的設定。
- 新的 VPN 或臨時介面卡會取得自己的 GUID 及預設值。
- 降低 ping 或應用程式延遲。
- 與特定伺服器、路由及封包遺失情況下的行為。
- 在 Wi-Fi、VPN 及遊戲中的效益。
請保留預設值。僅在可重現的小封包問題時才縮短 ACK 延遲，並留意回程封包數量與網路負載。
將介面值還原為 2 或刪除項目。變更會套用至新連線。
驗證適用於 Windows 11 25H2。參數讀取、預設值及範圍已獲確認。最終效益未在涵蓋不同伺服器、Wi-Fi 與 Ethernet、MTU 及封包遺失的受控測試中測量。將部分處理卸載至網路卡並不能免除 TCP 確認規則。然而，批次處理、VPN 及連線另一方的行為可能掩蓋或改變可觀察到的效果。
本文不含自身的動態觀察：未測量執行中系統的網路堆疊數值讀取，也未在受控情境下測量實際確認間隔。關於讀取與範圍的陳述依據 TCP 元件解析及 Microsoft 公開文件，而非自身測量。
如何自行執行驗證的動態部分——請參閱如何自行驗證。
研究及所用工具屬於 BoosterX 開發者，因此開發者對結果有直接利益關係。方法與適用範圍已於上文說明，結論可依公開資料及所列公開來源查證。
- TCP/IP registry values，Microsoft Learn，查核於 2026-09-01。
- TCP delayed acknowledgement，Microsoft Learn，查核於 2026-09-01。
公開來源查核於：2026-09-02。
- 2026-09-20： 於方法中新增利益衝突免責聲明及自行動態驗證的連結。
- 2026-09-19： 於限制中明確新增缺乏自身動態觀察及 ACK 間隔測量。
- 2026-09-02： 首次發佈；確認路徑、defaults 及範圍，新增對延遲影響的界限。