plp mtu discovery

plp-mtu-發現

執行路徑 MTU 發現，而不依賴通常不會傳遞的 ICMP 錯誤。

該程式執行 RFC 4821 中所述的分組層路徑 MTU 發現，這是在存在 ICMP 黑洞的情況下檢測 MTU 大小的更可靠方法。

基本原理

雖然 TCP 連線會根據各種指標（網路效能、封包遺失、ICMP 錯誤訊息等）自動調整 MTU 大小，但無連線協定的情況並非如此。

當效能至關重要時，吞吐量、封包分段和路由可靠性是需要分析的三個關鍵指標，以優化串流效能。由於路由可靠性並不總是取決於我們，因此我們應該努力最大化吞吐量，同時不執行資料包分段，這會嚴重降低效能^[1] 。

路徑 MTU 發現的最初提議依賴於當設定了「不分段」欄位的 IPv4 封包太大而無法傳播時， ICMP Fragmentation Needed封包。不幸的是，有些路由器不會產生此類錯誤，而是選擇默默地忽略大數據包。客戶端無法確定丟包的原因。

更安全的方法

由於所有主機都必須支援 ICMP_ECHO 查詢，因此我們可以利用 ICMP 訊息接受任意數量的資料並將不同大小的資料包發送到我們的伺服器的事實。如果我們開啟 IPv4 封包中的「不分段」欄位並偵聽回應，我們實際上是在等待 ACK（以 ICMP_ECHOREPLY 封包的形式）確認此 MTU 大小有效。

現在我們只需對封包的大小執行二分查找即可找到該路由支援的最大 MTU 大小。

ICMP模式

當處於ICMP模式時，會產生一些不同大小的ICMP_ECHO請求。

• 如果收到伺服器的回應，則該 MTU 大小被視為有效，並且閾值會提高。
• 如果多次嘗試後未收到回應或收到某種錯誤（例如ICMP Fragmentation Needed ），則該 MTU 大小將被聲明為無效並降低閾值。

ICMP 模式的唯一要求是主機必須能夠回覆 ping 訊息。

UDP模式

相同的演算法適用於 UDP 封包，但您需要在接收主機上執行伺服器 ( udp_server.py ) 才能傳回確認訊息。

編譯運行

該程式應該可以在大多數 Linux 發行版和 OSX 上正常運作。

 gcc -Wall -Wextra mtu_discovery.c mtu.c -o plpmtu

它不應報告警告/錯誤。如果是這樣，請打開一個問題。

如果您想在ICMP 模式下運行，請鍵入：

 sudo ./plpmtu -p icmp -s <server-ipaddr>

如果您想運行UDP 模式：

 sudo ./plpmtu -p udp -s <server-ipaddr:port>

需要管理員權限才能使用原始套接字。

命令列參數

說明符	描述
-p {icmp/udp}	選擇要運行的模式。
-s <位址[:連接埠]>	指定伺服器位址。如果在 UDP 模式下運行，則必須透過附加 ':port' 來指定目標連接埠（例如-s 8.8.8.8:12345 ）
-l <位址：連接埠>	選修的。選擇要綁定的位址();用於UDP模式；可能會被刪除。
-t <超時>	選修的。選擇等待伺服器回應的最長時間，預設為1秒；時間以毫秒錶示。
-r <最大要求>	選修的。選擇聲明 MTU 大小無效所需的最大失敗嘗試次數，預設為 3 次嘗試。

範例

 sudo ./plpmtu -p icmp -s 184.12.26.131

使用 184.12.26.131 執行 MTU 發現（ICMP 模式）。

 sudo ./plpmtu -p udp -s 184.12.26.131:24000 -t 1500 -r 5

使用184.12.26.131在24000埠進行MTU發現（UDP模式）。

文件

• RFC 791：網際網路協定版本 4（1981 年 9 月）
• RFC 792：網際網路控制訊息協定（1981 年 9 月）
• RFC 1191：路徑 MTU 發現（1990 年 11 月）
• RFC 4821：分組層路徑 MTU 發現（2007 年 3 月）
• ¹碎片被認為是有害的（1987 年 12 月）