我透過更改一個無人知曉的設置,解決了家裡網速慢的問題。

當我們遇到網路速度慢的問題時,幾乎總是會嘗試重新啟動路由器。在某些情況下,這確實有效。 有時,我們會想當然地認為我們的網路服務供應商(ISP)正在限制網路速度。情況也並非總是如此。我們可能只是遇到了一個特殊問題,導致網路體驗不佳,即使所有測速結果都顯示連線速度很快。

我透過更改一個沒人知道的設置,解決了家裡網路速度慢的問題。

我的情況也完全一樣,但最終的解決方案卻出乎我的意料。我只需要將最大傳輸單元 (MTU) 設定為與我的實際連接限制相符即可。設定完成後,延遲就消失了。

MTU 定義了連結可以完整傳輸的最大 IP 負載。

分段和頭部超大規則決定了實際的包裹大小。

附USB介面和LAN介面的無線路由器

MTU(最大傳輸單元)代表網路連接裝置在不進行分片的情況下可以傳輸的最大資料包大小(以位元組為單位)。對於大多數以太網,該值通常設定為 1500 位元組。 1500 這個數字並非隨意設定。您的路由器基於數十年前的乙太網路框架設計限制(其中許多限制至今仍在沿用)假定自身是安全的。

然而,1500 位元組並非只是封包的大小,因為封包本身也攜帶額外的協定開銷資料。在典型的 TCP 流量中,這些開銷通常包括 20 位元組的 IPv4 頭部和 20 位元組的 TCP 頭部。考慮到這些開銷,在 1500 MTU 的環境下,封包的實際最大大小為 1460 位元組。這就解釋了標準網路上 TCP 段大小 (MSS) 最大為 1460 位元組的原因。

當封包大於其必須通過的最大傳輸單元 (MTU) 環境時,就會出現問題。唯一能讓資料包成功通過的方法是路由器將其分割成更小的部分。這個過程會消耗大量資源,需要更多的 CPU 運算和快取空間,因為每個部分都有自己的 IP 頭部,並且必須在目的地重新組裝。雖然這個過程本身不會降低頻寬,但它會增加資料包傳輸的複雜性和敏感度。

現實世界中的網路路徑通常會將可用 MTU 降低到 1500 以下。

包裝和取貨技術會減少可用貨艙空間。

你可能認為 1500 位元組的資料包適用於所有情況,但事實並非如此。 1500 位元組大於許多住宅連接中使用的最大傳輸單元 (MTU)。乙太網路點對點 (PPPoE) 是某些光纖部署和許多 DSL 方案的常用標準。它額外佔用 8 位元組,將有效 MTU 降低到 1492,如果你的路由器必須透過 1492 位元隧道傳輸 1500 位元組的資料包,則必然會進行分片。

只要你的資料需要被封裝在額外的資料包中,它實際上就會影響你的有效載荷空間。例如,VLAN 會提供一個 4 位元組的標籤。雖然這個標籤對於識別流量的虛擬網路是必要的,但它仍然會減少有效載荷。運營商級網路位址轉換 (CGNAT) 和 DS-Lite 也會產生相同的效果。對於 DS-Lite 來說,透過在 IPv6 封包中傳遞 IPv4 流量來路由流量,會在你的 ISP 網路上增加一個額外的頭部。 VPN 會將你的原始資料包作為新資料包的有效載荷,而新資料包需要一個新的頭部。

所有這些情況都像是在一個已經有包裝的盒子上再加一層包裝,卻沒有增加盒子需要通過的路徑的大小。它只有被分割開來才能通過。

在行動網路中,情況會變得更加複雜,因為LTE和5G的MTU基線通常比乙太網路低1500位元組。根據營運商的具體實現方式,MTU值介於1420到1480之間。一般來說,連線限制等於路徑上最小的MTU值,如果路由器無法滿足此限制,就會出現封包分片或靜默丟包的情況。 這是網路速度慢的一個可能原因。.

自動MTU調整機制並非總是能防止故障發生。

MTU路徑偵測、ICMP過濾和黑洞行為

Google Pixel 10 Pro 上的 Wi-Fi 連線列表

有一種自動防碎片化方案,理論上效果很好,叫做路徑 MTU 偵測 (PMTUD)。它的工作原理如下:設備在發送資料包時可能會設定一個「禁止碎片化」位元。這個位元會導致接收路由器發送一條回應訊息。 ICMP 類型 3 代碼 4如果下游資料包大小超過 MTU,則需要進行分片。

問題在於,實際上許多防火牆預設會阻止 ICMP 協定。因此,大資料包會被丟棄,而防火牆的過濾機制會阻止傳送者意識到資料包過大。這種丟包會導致 TCP 重傳,從而產生指數級的回滾計時器。這種情況稱為 MTU 黑洞,即即使流量看似正常,大封包也會持續遺失。

現代作業系統嘗試透過實作 RFC 4821 封包化層路徑 MTU 發現 (PLPMTUD) 來緩解某些故障,PLPMTUD 是一種無需依賴 ICMP 即可偵測封包大小的方法。在某些情況下,路由器、ISP 設備和 VPN 端點無法有效處理分片。這不會反映在速度測試結果中,但實際影響是延遲波動會持續累積。

如果您的路由器正在實施 MSS 安裝,它可能會掩蓋 MTU 不匹配問題而不是修復它,這就是為什麼症狀可能不一致且不持續的原因。

測量和校正 MTU 可以恢復端到端的資料包流。

只要理解了計算方法,找到合適的 MTU 就很容易。如果需要使用 ping 指令進行測試,請注意 IPv4 標頭為 20 字節,ICMP 標頭為 8 字節,總標頭大小為 28 位元組。因此,初始有效載荷為 1472 位元組,加上 IPv4 和 ICMP 的 28 位元組後,總大小變為 1500 位元組。從這一點開始減少有效載荷大小,直到找到一個不會導致分片的值。可用的 MTU 為 28 位元組加上成功傳輸的最大有效載荷大小。

以下是 Windows 指令:

ping 8.8.8.8 -f -l 1472

我使用 `-f` 參數設定「不分片」選項,使用 `-l` 參數指定有效載荷大小。目標是不斷減小有效載荷大小,直到獲得持續的成功回應。等效的 Linux 指令是:

ping -M do -s 1472 8.8.8.8

在 macOS 上,情況略有不同,因為不同版本處理雜湊值的方式並不相同。使用諸如 之類的工具可以獲得更可靠的 MTU 路徑檢查。 地鐵 透過 Homebrew。

測試 MTU 時,請務必使用多個目標 IP 位址,而不僅僅是 8.8.8.8,因為某些路徑上可能存在黑洞情況,而其他路徑上則不存在。

確定所需的固定值後,最好在路由器的 WAN 介面中設定 MTU,這樣就無需單獨設定所有設備。下表列出了不同連接類型的大致 MTU 值:

連接類型您應該預期的典型 MTU 值
標準乙太網路(直連線/光纖,不支援PPPoE)1500
PPPoE(DSL 或某些光纖網路服務供應商)1492
網際網路服務供應商連線標記為 VLAN1496-1500(取決於網路服務供應商的應用程式)
LTE/4G/5G行動網絡約1420-1480年(具體時間因電信公司而異)
IPSec VPN(隧道模式)1380-1460(取決於編碼和包裝)
WireGuard(原廠 MTU 1500)〜1412
OpenVPN(UDP 模式)1300–1450 年(很大程度上取決於具體情況)

 

轉到頂部按鈕