无法对单个-软件无线电原理与应用第二版

11.8 采用 UDP 的路径 MTU 发现

下面对使用 UDP 的应用程序与路径 MTU 发现机制之间的交互作用进行研究。看一看如果应用程序写了一个对于一些中间链路来说太长的数据报时会发生什么情况。

例子：由于我们所使用的支持路径 MTU 发现机制的唯一系统就是 Solaris 2.x，因此，将采用它作为源站发送一份 650 字节数据报经 slip。由于 slip 主机位于 MTU 为 296 的 SLIP 链路后，因此，任何长于 268 字节（296－20－8）且“不分片”比特置为 1 的 UDP 数据都会使 bsdi 路由器产生 ICMP“不能分片”差错报文。图 11-13 给出了拓扑结构和 MTU。

使用 UDP 进行路径 MTU 发现的系统可以用下面的命令行来产生 650 字节 UDP 数据报，每两个 UDP 数据报之间的间隔是 5 秒：

solaris % sock -u -i -n10 -w650 -p5 slip discard

图 11-14 是 tcpdump 的输出结果。在运行这个例子时，将 bsdi 设置成在 ICMP“不能分片”差错中，不返回下一跳 MTU 信息。在发送的第一个数据报中将 DF 比特置 1（第 1 行），其结果是从 bsdi 路由器发回我们可以猜测的结果（第 2 行）。令人不解的是，发送一个 DF 比特置 1 的数据报（第 3 行），其结果是同样的 ICMP 差错（第 4 行）。我们预计这个数据报在发送时应该将 DF 比特置 0。第 5 行结果显示，IP 已经知道了发往该目的地址的数据报不能将 DF 比特置 1，因此，IP 进而将数据报在源站主机上进行分片。这与前面的例子中，IP 发送经过 UDP 的数据报，允许具有较小 MTU 的路由器（在本例中是 bsdi）对它进行分片的情况不一样。

由于 ICMP“不能分片”报文并没有指出下一跳的 MTU，因此，看来 IP 猜测 MTU 为 576 就行了。第一次分片（第 5 行）包含 544 字节的 UDP 数据、8 字节 UDP 首部以及 20 字节 IP 首部，因此，总 IP 数据报长度是 572 字节。第 2 次分片（第 6 行）包含剩余的 106 字节 UDP 数据和 20 字节 IP 首部。不幸的是，第 7 行的下一个数据报将其 DF 比特置 1，因此 bsdi 将它丢弃并返回 ICMP 差错。这时发生了 IP 定时器超时，通知 IP 查看是不是因为路径 MTU 增大了而将 DF 比特再一次置 1。我们可以从第 19 行和 20 行看出这个结果。将第 7 行与 19 行进行比较，可以看出 IP 每过 30 秒就将 DF 比特置 1，以查看路径 MTU 是否增大了。这个 30 秒的定时器值看来太短。RFC 1191 建议其值取 10 分钟。可以通过修改 ip_ire_pathmtu_interval（E.4 节）参数来改变该值。同时，Solaris 2.2 无法对单个 116 使用 TCP/IP 详解，卷 1：协议下载在这里运行 tcpdump 命令将 DF 比特置 1 的 650 字节 UDP 数据报 ICMP 不能分片差错。