當在同一個網絡上的兩臺主機互相進行通信時,該網絡的 M T U是非常重要的。 但是如果 兩臺主機之間的通信要通過多個網絡,那么每個網絡的鏈路層就可能有不同的 M T U。重要的 不是兩臺主機所在網絡的 M T U的值,重要的是兩臺通信主機路徑中的最小 M T U。它被稱作路 徑MTU。
兩臺主機之間的路徑 M T U不一定是個常數。 它取決于當時所選擇的路由。 而選路不一定 是對稱的(從A到B的路由可能與從B到A的路由不同),因此路徑MTU在兩個方向上不一定是 一致的。
RFC 1191[Mogul and Deering 1990]描述了路徑MTU的發現機制,即在任何時候確定路徑 M T U的方法。我們在介紹了 I C M P和I P分片方法以后再來看它是如何操作的。
如果線路速率是9600 b/s,而一個字節有8 bit,加上一個起始比特和一個停止比特,那么 線路的速率就是960 B/s(字節/秒)。以這個速率傳輸一個1024字節的分組需要1066 ms。如果用S L I P鏈接運行一個交互式應用程序,同時還運行另一個應用程序如 F T P發送或接收1 0 2 4字 節的數據,那么一般來說就必須等待一半的時間( 533 ms)才能把交互式應用程序的分組數 據發送出去。
假定交互分組數據可以在其他“大塊”分組數據發送之前被發送出去。大多數的 S L I P實 現確實提供這類服務排隊方法, 把交互數據放在大塊的數據前面。 交互通信一般有 Te l n e t、 Rlogin以及FTP的控制部分(用戶的命令,而不是數據)。
這種服務排隊方法是不完善的。它不能影響已經進入下游(如串行驅動程序)隊 列的非交互數據。同時,新型的調制解調器具有很大的緩沖區,因此非交互數據可能 已經進入該緩沖區了。
對于交互應用來說,等待 533 ms是不能接受的。 關于人的有關研究表明, 交互響應時間 超過1 0 0~200 ms就被認為是不好的 [Jacobson 1990a]。 這是發送一份交互報文出去后, 直到 接收到響應信息(通常是出現一個回顯字符)為止的往返時間。
?把S L I P的M T U縮短到 2 5 6就意味著鏈路傳輸一幀最長需要 266 ms,它的一半是 133 ms (這是一般需要等待的時間)。這樣情況會好一些,但仍然不完美。我們選擇它的原因(與 6 4 或1 2 8相比)是因為大塊數據提供良好的線路利用率(如大文件傳輸)。假設C S L I P的報文首 部是5個字節,數據幀總長為 2 6 1個字節, 2 5 6個字節的數據使線路的利用率為 9 8 . 1 %,幀頭占 了1 . 9 %,這樣的利用率是很不錯的。如果把 M T U降到2 5 6以下, 那么將降低傳輸大塊數據的 最大吞吐量。
點對點鏈路的MTU是296個字節。假設數據為256字節, TCP和 I P首部占4 0個字節。由于 M T U是I P向鏈路層查詢的結果,因此該值必須包括通常的 T C P和I P 首部。這樣就會導致IP如何進行分片的決策。 IP對于CSLIP的壓縮情況一無所知。
我們對平均等待時間的計算(傳輸最大數據幀所需時間的一半)只適用于 S L I P鏈路(或 P P P鏈路)在交互通信和大塊數據傳輸這兩種情況下。當只有交互通信時,如果線路速率是 9600 b/s,那么任何方向上的 1字節數據(假設有 5個字節的壓縮幀頭)往返一次都大約需要 12.5 ms。它比前面提到的100~200 ms要小得多。需要注意的是,由于幀頭從 40個字節壓縮到 5個字節,使得1字節數據往返時間從85 ms 減到12.5 ms。
不幸的是, 當使用新型的糾錯和壓縮調制解調器時, 這樣的計算就更難了。 這些調制解 調器所采用的壓縮方法使得在線路上傳輸的字節數大大減少, 但糾錯機制又會增加傳輸的時 間。不過,這些計算是我們進行合理決策的入口點。
