当在同一个网络上的两台主机互相进行通信时,该网络的 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。
不幸的是, 当使用新型的纠错和压缩调制解调器时, 这样的计算就更难了。 这些调制解 调器所采用的压缩方法使得在线路上传输的字节数大大减少, 但纠错机制又会增加传输的时 间。不过,这些计算是我们进行合理决策的入口点。
