如果你每天都和他吵架 延遲、卡頓和高延遲你並不孤單。在線上遊戲、視訊通話或遠端辦公體驗不佳的背後，有一個非常明確的罪魁禍首：你的家庭網路以及你的裝置和伺服器上 TCP/IP 協定的配置方式。
最佳化 TCP/IP 延遲 這不僅僅是調整幾個“神奇”設定那麼簡單。你需要理解諸如此類的概念是如何運作的。 MTU、MSS、TCP視窗、延遲或緩衝區膨脹然後對您的電腦、路由器、Wi-Fi 網絡，甚至雲端伺服器或虛擬機器進行相應的更改。讓我們一步一步地來，但要注重實際操作：了解每項操作的作用，以及您可以採取哪些措施來加快連接響應速度。
影響延遲的關鍵 TCP/IP 概念
為了充分利用您的網路連接，了解一些事情會很有幫助。 TCP/IP 基本參數 直接影響遊戲、視訊通話或遠端存取的延遲、穩定性和效能。
MTU、碎片化和LSO
La MTU（最大傳輸單元） 這是封包在不被分片的情況下可以從網路介面發出的最大大小（以位元組為單位）。在絕大多數乙太網路（以及 Azure 或 Google Cloud 上的虛擬機器）中，預設值為 1500 字節，其中包括網路頭部和資料。
當資料包超過最大傳輸單元 (MTU) 時，IP 層會將其拆分成幾個較小的片段。 IP碎片化 這會增加CPU和記憶體的使用，無論是在資料分片的機器上，還是在資料碎片到達後重新組裝碎片的機器上。這會導致額外的延遲和效能損失，尤其是在高流量情況下。
此外，還有那段著名的插曲。 「不要分裂」（DF） 在 IP 標頭中。如果啟用此功能，且中間路由器收到一個大於其 MTU 的封包，則不會對其進行分片，而是將其丟棄並發送 ICMP「需要分片」訊息。這用於… MTU路由偵測（PMTUD）但如果防火牆阻止了這些 ICMP 封包，發送者將繼續嘗試發送過大的封包，從而導致延遲和重傳。
在 Azure 或 Google Cloud 等環境中，碎片化的軟體包也往往會失去其優勢。 加速網路SR-IOV 和 SmartNIC。它們透過虛擬機器管理程式的慢速路由進行處理，並且更多 抖動延遲更高，每秒資料包數量更少。因此，一般建議是： 透過適當調整 MTU 和 MSS 來避免碎片化。 如果中間有防火牆或 VPN，則不要過度增加 MTU。
另一方面，函數 大型發送卸載 (LSO) 這使得作業系統的 TCP/IP 協定堆疊能夠產生大型“超級資料包”，然後由網路卡根據 MTU 值進行內部分片。這顯著降低了 CPU 負載，儘管在流量擷取中可能會看到看似巨大的幀，但這並不意味著網路分片，而是表示分片發生在網路卡內部。
MSS、PMTUD 和 VPN
El TCP MSS（最大段大小） 這定義了每個 TCP 段（不包括 IP 和 TCP 頭部）中可容納的可用資料位元組數。通常，系統會以以下方式計算 MSS：
MSS = MTU - (tamaño cabecera IP + tamaño cabecera TCP)
MTU 為 1500，IPv4+TCP 標頭為 20+20 字節，典型的 MSS 為 1460字節這個值是在 TCP 三次握手期間協商確定的，每一端都會提出自己的值。連接最終會採用兩者中較低的值。
然而，途中可能會遇到一些設備（防火牆、路由器等）。 VPN網關等等）使用較小的 MTU，這實際上會強制降低 MSS。這就是… 路徑 MTU 發現 (PMTUD)當路由器無法轉送封包（因為封包太大且設定了 DF 位元）時，它會丟棄該封包，並傳送 ICMP「需要分片」訊息，指示其支援的最大 MTU，以便來源伺服器減小封包的大小。
如果這些 ICMP 封包被阻塞，連線就會進入轉送和丟包的循環，導致… 延遲、重傳和無止盡的載入時間因此，在不檢查整個路徑或防火牆策略的情況下，隨意增加電腦或虛擬機器的 MTU 並不總是明智之舉。
在社群媒體上 IPsec VPN 對於其他隧道，額外的頭部會減少可用於資料的空間，因此建議使用較小的 MTU 和 MSS（例如，典型隧道中的 MTU 為 1400，MSS 為 1350），以避免隧道碎片化和相關的延遲。
延遲、往返時間 (RTT) 和 TCP 窗口
著名的「叮」聲只不過是… 往返延遲（RTT） 在兩點之間。從物理層面來說，它受限於光在光纖中的傳播速度（約200公里/毫秒）以及資料實際傳輸的路徑。它很少是直線。
在 TCP 協定中，單一連線的最大理論吞吐量由以下基本公式決定：
rendimiento máximo ≈ tamaño de ventana TCP / RTT
La TCP視窗 這是發送方在尚未收到確認 (ACK) 的情況下可以「傳輸」的資料量。如果視窗大小為 65.535 字節，最大共享大小 (MSS) 為 1460，則在等待 ACK 之前只能傳送約 45 個封包。如果往返時間 (RTT) 較高（例如，洲際之間的往返時間為 80-160 毫秒），則未縮放的視窗大小遠不足以充分利用高容量連結。
預設情況下，TCP 標頭中的視窗欄位為 16 位，其最大值限制為 65.535 位元組。對於現代網路而言，這顯然不合理，因此多年前就引入了[此處資訊缺失，可能指特定功能或方法]。 TCP視窗縮放它將乘數 2^na 應用於該值，從而允許數百 MB 甚至 GB 的視窗。
在 Windows 或 Linux 等系統中，視窗縮放由預定義設定自動管理（自動調整），可以使用諸如 `tfs` 之類的命令查看或修改。 Get-NetTCPSetting o sysctl更激進的等級（例如，「實驗性」）允許使用更大的窗口，並且可以大大提高長距離網路的效能，前提是丟包率不太高。
加速網路、RSS 和 GRO/TSO
在雲端平台（Azure、Google Cloud 等）上，傳統網路介面嚴重依賴主機 CPU 來處理每個封包、應用程式規則、封裝和解封裝。這導致… 對虛擬機器管理程序的巨大壓力 當網路流量很大時，會產生不穩定的延遲。
這就是為什麼所謂的 加速網路這些方案是基於SR-IOV和具有FPGA的智慧網卡等技術。其理念是，軟體定義網路協定堆疊的大部分運作在網路卡硬體上，資料流量幾乎可以直接從虛擬機器傳輸到網路卡，繞過主機的虛擬交換器。
這提供了幾個 優點：
- 延遲越低，幀速率越高。
- 減少抖動
- 降低主機和虛擬機器的 CPU 佔用率。
然而，還有一些重要的細節需要考慮。例如，許多加速網路系統不會透過快速路由處理分片資料包；如果存在 IP 分片，則該流量會透過慢速路由傳輸，從而影響效能。
在客戶作業系統方面，啟用諸如此類的技術至關重要。 接收端縮放 (RSS)它將傳入資料包的處理分配到多個 CPU 核心上，並進行分段和聚合下載，例如： TSO（傳輸分段卸載）和 GRO/LRO（通用接收卸載）這樣就減少了 CPU 需要直接處理的資料包數量。
TIME_WAIT 和套接字重複使用
另一個鮮為人知但至關重要的 TCP 效能因素是狀態。 等待時間當 TCP 連線正常關閉時，發送最後一個 ACK 的端點會進入 TIME_WAIT 狀態，持續數十秒甚至數百秒。在此期間，系統會保留該套接字，以確保來自舊連接的延遲資料包不會重新出現並與新會話混淆。
在高負載的伺服器或機器上，很容易積累 TIME_WAIT 中存在成千上萬個套接字這可能會耗盡臨時連接埠的範圍，並在建立新連線時導致錯誤。因此，許多系統允許使用者調整 TIME_WAIT 的持續時間、連接埠範圍以及某些重複使用策略。
一種更激進的技術，由某些核心（例如 Azure 上的 Windows Server）支持，稱為 TIME_WAIT 暗殺如果收到序號遠高於舊連線的新 SYN 封包，系統可以在 TIME_WAIT 期間強制關閉套接字並立即接受新連線。這提高了可擴展性，但如果配置錯誤，則可能導致 互通性問題 以及某些較保守的 TCP 協定棧。
為什麼ping在你的日常生活中如此重要
除了理論層面，延遲對我們如今幾乎所有的線上活動都有直接影響。光是擁有「600 Mbps」的網路速度是不夠的；如果回應速度慢，使用者體驗就會大打折扣。讓我們來看一些例子： 一個「正常」的ping值至關重要。.
線上遊戲和“可玩”的延遲水平
在競技遊戲中，每一毫秒都至關重要。 ping 值低於 20 毫秒 這幾乎是理想狀態：操作幾乎是即時回應，你幾乎感覺不到任何延遲。延遲在 20 到 50 毫秒之間時，體驗非常流暢。當延遲達到 50 到 100 毫秒時，你可能會注意到輕微的同步問題，尤其是在連接遠距離伺服器時。
來自 100-300毫秒 嚴重的問題開始出現：射擊延遲、動作延遲、賽車遊戲中車輛「彈跳」等等。超過 300 毫秒後，遊戲體驗就變成了一種折磨，尤其是在射擊遊戲、賽車遊戲或運動遊戲中。
遊戲類型也有很大影響。 第一人稱射擊遊戲和賽車遊戲 要想在競技遊戲中取得好成績，延遲必須低於 50 毫秒；在線上運動遊戲中，最好也保持在 30-40 毫秒以下。然而，在 大型多人線上遊戲或回合製策略遊戲即使延遲在 150-200 毫秒之間，遊戲也能勉強流暢運行，不會影響遊戲體驗。如果你在 Windows 系統上玩遊戲，或許會想了解具體方法。 減少 Windows 11 中的輸入延遲 提高競技遊戲中的反應速度。
視訊通話、螢幕分享和 VoIP 通話
在使用 Zoom、Teams、Skype 或類似平台進行視訊通話時，ping 值也至關重要。理想情況下，ping 值應該穩定在… 20-40毫秒對話流暢自然，互不干擾。大多數使用者能容忍大約 100 毫秒的延遲，但說話時即使是輕微的延遲也能被察覺。
當 ping 值超過 100毫秒你開始無意間打斷對方。對方的回應會短暫地出現“迴聲”，尷尬的沉默也變得頻繁。此外，如果網路連線頻寬有限或Wi-Fi訊號差，也會出現視訊和音訊中斷的情況。
同 螢幕分享或遠端控制 效果類似。每次點擊和滑鼠移動都需要時間才能在遠端螢幕上顯示。延遲過高時，會感覺電腦運作緩慢。這對於任何想要高效工作的人來說都極其令人沮喪。
物聯網、家庭自動化和遠距辦公
在生態系統中 物聯網和智慧設備 （例如揚聲器、燈泡、攝影機、插座、機器人、寵物餵食器等），延遲也起著關鍵作用。雖然500毫秒的開燈延遲並不明顯，但當需要連續執行多個操作或與語音助理（例如Alexa、Google Assistant）互動時，這種延遲就會變得非常明顯。
遠端辦公時，存取遠端桌面、伺服器或雲端應用程式時持續的延遲會讓任何任務都變得異常繁瑣。許多人認為這是“速度不夠快”，但實際上他們遇到的問題是… 高延遲和/或高度不穩定的延遲（抖動） 由 WiFi 擁塞、路由器故障或伺服器路由錯誤所引起。
延遲和安全性：間接影響
高延遲本身並不意味著 直接安全風險然而，這也會帶來一些副作用。如果監控系統、入侵偵測系統或防火牆接收訊息過晚，它們可能對攻擊的反應也太慢，甚至會錯過關鍵事件。
此外，當用戶對網路延遲感到絕望時，他們往往會「繞過」安全控制： 他們會停用防火牆、卸載防毒軟體或隨意開啟連接埠。 在路由器上進行設定以嘗試使其“更快”。糟糕的網路體驗最終可能會為真正的威脅打開不必要的便利之門。
家庭網路高延遲的主要原因
你在遊戲或測速中看到的延遲是多種因素的總和：運營商、互聯網路由、目標伺服器……但在家裡，有很多常見問題是你可以自己控制的。
WiFi覆蓋範圍差且存在幹擾
現在我們大多數人幾乎完全透過Wi-Fi連接網絡，而問題也由此開始。 訊號微弱或充滿幹擾 它不僅會降低速度，還會增加延遲和抖動，因為設備需要重新傳輸資料包、降低調變、等待頻道空閒等等。
如果你離路由器很遠，隔著好幾堵牆，或者周圍都是使用同一頻道的鄰近網絡，你的延遲就會很高。此外，連接到存取點的用戶端越多，每個用戶端「輪流」通訊的等待時間就越長。而速度慢的客戶端也會對其他客戶端造成負面影響。 查看您的 WiFi 網路上有多少台設備 識別問題客戶。
這些功能在這裡非常有用。 通話時間公平它會在設備間分配通話時間，避免速度較慢的設備獨佔無線電資源。即便如此，在玩遊戲和使用固定電話辦公時，如果可能，還是應該使用[替代方案]。 以太網電纜 把WiFi留給其他人吧。
過時或過載的路由器
老舊的路由器，尤其是韌體過時或硬體配置非常基礎的路由器，可能會成為嚴重的效能瓶頸。當路由器的處理器因管理NAT、防火牆、QoS和P2P流量而過載時，就會出現問題。 隊列延遲和緩衝區膨脹資料包會在巨大的緩衝區中積聚，並以明顯的延遲發送出去，從而破壞 ping 測試結果。
更新韌體，停用不必要的功能，如有必要，請向運營商申請更換設備或購買新設備。 最強大的中立路由器 這通常標誌著一個轉折點。偶爾重啟一下程式也是個好主意，這樣可以清除記憶體狀態和潛在的記憶體洩漏。
下載和其他消耗頻寬的設備
如果您的網路中有多台裝置正在進行大量下載（P2P 下載、更新、4K 串流媒體播放、雲端備份），這是正常的。 你的延遲峰值問題不在於“兆位元組用完了”，而是路由器如何管理出站佇列。
解決方案包含兩條路徑：
- 一方面，更能控制後台下載的內容（PC、手機、遊戲機、NAS…）。
- 另一方面，啟動並正確調整 服務品質和反緩衝膨脹 從路由器發出請求，以便互動式流量（遊戲、VoIP、視訊通話）優先於大量下載。
VPN、代理、防火牆和後台程序
該 VPN 它們對於加密流量或繞過地理限制非常有用，但幾乎總是會增加延遲，因為你的連線會經過中間伺服器。如果 VPN 是免費的或品質很差，則可能會嚴重影響網路延遲。某些 VPN 也存在同樣的問題。 代理.
無論是電腦上的防火牆或路由器上的防火牆，都會檢查每個封包，從而增加延遲；如果設定錯誤，也會嚴重降低連線速度。另外… 後台程序 （Windows 更新、雲端用戶端、遊戲下載補丁等）會在不知不覺中佔用大量頻寬。
惡意軟體和受感染的設備
感染惡意軟體的電腦可能會產生隱藏流量（垃圾郵件、DDoS 攻擊、挖礦、資料下載）或消耗大量 CPU 和磁碟資源，進而影響連線品質。如果您發現 所有操作都很慢，而且延遲會無緣無故地飆升。建議使用可信賴的防毒軟體對所有裝置進行全面掃描。此外，建議遵循以下最佳實務： 維護健康的網路基礎設施 並避免使用受損設備。
用於測量延遲和檢測問題的工具
在進行任何更改之前，請務必進行精確測量。不要只依賴瀏覽器的速度測試：有一些專門的工具可以幫助您精確定位延遲飆升的原因，並確定問題出在您的本地網路、網路服務供應商還是目標伺服器上。
基本 ping 和 traceroute
效用 平所有作業系統都具備此功能，這是起點。只需簡單操作即可。 ping 8.8.8.8 例如，您可以查看到特定目的地的平均延遲、最小延遲和最大延遲，以及是否有丟包。如果您 ping 路由器的網關，則可以獲得本地網路的延遲。
如果你添加一個 -t 在 Windows 上（ping 8.8.8.8 -t你可以讓它運行一段時間，看看是否有任何峰值、丟包或抖動。而且 traceroute/tracert 你要檢查資料包經過了哪些躍點，以及延遲在哪個點開始出現異常增加。
進階工具：WinMTR、PingPlotter 等
像這樣的程序 溫米特 它們結合了路由追蹤和連續ping測試，顯示訊號損失百分比以及每一跳的最小、平均和最大回應時間。這些工具對於確定問題是出在你的網路服務供應商的第一跳、中間骨幹網路還是遊戲伺服器本身非常有用。
其他實用程序，例如 網路延遲視圖 (NirSoft) 可以測量您電腦開啟的 TCP 連線的實際延遲。還有一些類似的軟體套件。 NetScan 工具 整合了圖形化 ping 工具、連接埠掃描器、路由追蹤和 DNS 解析功能。所有功能合一。
測量行動裝置的延遲：適用於 Android 和 iOS 的應用程式
在智慧型手機和平板電腦上，您還可以使用諸如 之類的應用程式來測量延遲。 Fing，He.net 網路工具，NetX 或使用 iOS 上的特定 ping 工具。這些工具非常適合檢查問題是出在特定房間的 Wi-Fi、行動網絡，還是固定電話本身的品質不佳。
伺服器和雲端上的進階 TCP/IP 最佳化
如果您管理伺服器、雲端虛擬機器或要求嚴格的 Web 項目，則可以調整更多 TCP/IP 和核心參數。 降低延遲，提高效能。 尤其是在高速網路上。
Linux 核心和 TCP 協定棧設置
在 Linux 系統上，使用 sysctl 和工具之類的 tc o ethtool 您可以套用進階最佳化，例如：
- 降低最低RTO（恢復營運時間）。 (
net.ipv4.tcp_rto_min_us在低延遲的內部網路中，延遲時間應設定為安全值，例如 5000 微秒（5 毫秒），以便更快地從丟包中恢復。 - 激活 公平排隊（FQ） 同
tc qdisc replace dev <iface> root fq.為了更好地在不同資料流之間分配頻寬，避免單一連線產生過多的突發流量。 - 禁用 不活動後啟動緩慢 (
net.ipv4.tcp_slow_start_after_idle=0對於使用持久連線的伺服器，這樣做可以避免每次從睡眠模式喚醒後都從極低的頻寬重新開始連線。 - 禁用有問題的部分 HyStart Cubic TCP 中的 ACK 序列偵測。防止擁塞誤報減緩視窗成長速度。
- 增加 TCP緩衝區 (
tcp_rmem, tcp_wmem, rmem_max, wmem_max為了能夠在具有高 RTT 的鏈路上維持高吞吐量，防止套接字記憶體不足。 - 限制
tcp_notsent_lowat這樣可以防止內核中累積過多的未發送數據，從而保護系統免受過度記憶體消耗的影響。 - 啟用 硬體 GRO/LRO 在相容的網路卡上（
ethtool -K <iface> rx-gro-hw on）將資料包分組，以減少每次中斷的 CPU 負載。
大 MTU 和高效能網絡
在提供支援的內部雲端網路（例如，Google Cloud VPC）中 巨型 MTU 最大可達約 8900 位元組強烈建議增加 MTU（例如增加到與 4 KB 記憶體頁相容的約 4082 位元組），以減少每秒處理的資料包數量並提高 CPU 效率。
但是，對於出站到互聯網或通過 VPN 的流量，您必須格外小心：在這種情況下，最好保持 1500 的標準 MTU 值，或根據路由進行調整（ip route change 同 mtu y advmss) 以便外部通訊不會因封包過大而出現碎片化或遺失。
Web伺服器、HTTP/2/3和快取
在 Web 伺服器（Nginx、Apache 等）上，除了調整 TCP 之外，還可以透過啟用以下功能來大幅降低感知延遲： HTTP/2 與 HTTP/3 (QUIC)這樣就可以透過單一連線複用多個請求，從而降低握手成本。
啟用 GZIP 壓縮或 Brotli， 用 記憶體快取 （Redis、Memcached），壓縮 CSS/JS 並透過以下方式提供靜態內容 CDN 與附近的接入點 對使用者而言，TTFB（首字節回應時間）和網路 RTT 節省的每一毫秒，都會讓網站在訪客眼中回應得「更快」。
持續監控和延遲指標
最後，如果你真的重視績效，就需要持續不斷地衡量它。像 ApacheBench、wrk、JMeter 或者，可觀測性套件（Prometheus + Grafana、New Relic、Datadog 等）可讓您進行監控 往返時間 (RTT)、第一位元組到達時間 (TTFB)、延遲百分位數、吞吐量和錯誤率 在負載下。
當 TTFB 超過某些閾值、服務之間的內部 ping 值出現峰值或丟包率增加時設定警報，有助於在延遲到達最終用戶之前主動檢測網路問題、CPU 飽和、路由變更或瓶頸。
考慮到所有這些概念和設置，從 MTU 和 MSS 到路由器 QoS、加速雲端網路和 Web 伺服器配置，很明顯，延遲並非單一因素造成的。它是眾多網路元件以及 TCP/IP 協定本身共同作用的結果。只有當這些組件和協議進行適當調整時，才能確保遊戲、視訊通話、遠端辦公和網站都能流暢回應。 即時感 這是我們所有人都在追求的，而這往往是透過調整和理解網路來實現的，而不是簡單地增加「更多兆位元」。
