下面对使用UDP的应用程序与路径MTU发现机制之间的交互作用进行研究。看一看如果应用程序写了一个对于一些中间链路来说太长的数据报时会发生什么情况。
例子
由于我们所使用的支持路径MTU发现机制的唯一系统就是Solaris 2.x，因此，将采用它作为源站发送一份6 5 0字节数据报经SLIP。由于SLIP主机位于MTU为2 9 6的S L IP链路后，因此，任何长于2 6 8字节（2 9 6－2 0－8）且“不分片”比特置为1的UDP数据都会使bsdi路由器产生ICMP“不能分片”差错报文。图11 - 1 3给出了拓扑结构和MTU。
可以用下面的命令行来产生6 5 0字节UDP数据报，每两个UDP数据报之间的间隔是5秒：
solaris % sock -u -i -n10 -w650 -p5 slip discard
图11 - 1 4是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为5 7 6就行了。第一次分片（第5行）包含5 4 4字节的UDP数据、8字节UDP首部以及2 0字节IP首部，因此，总IP数据报长度是5 7 2字节。第2次分片（第6行）包含剩余的1 0 6字节UDP数据和2 0字节IP首部。
不幸的是，第7行的下一个数据报将其DF比特置1，因此bsdi将它丢弃并返回ICMP差错。这时发生了IP定时器超时，通知IP查看是不是因为路径MTU增大了而将DF比特再一次置1。我们可以从第1 9行和2 0行看出这个结果。将第7行与1 9行进行比较，可以看出IP每过3 0秒就将DF比特置1，以查看路径MTU是否增大了。
这个3 0秒的定时器值看来太短。R F C 11 9 1建议其值取1 0分钟。可以通过修改i p _ i r e _ p a t h m t u _ i n t e r v a l（E . 4节）参数来改变该值。同时，Solaris 2.2无法对单个UDP应用或所有UDP应用关闭该路径MTU发现。只能通过修改i p _ p a t h _ m t u _ d i s c o v e r y 参数，在系统一级开放或关闭它。正如在这个例子里所能看到的那样，如果允许路径MTU发现，那么当UDP应用程序写入可能被分片数据报时，该数据报将被丢弃。
(点击查看原图)
s o l a r i s的IP层所假设的最大数据报长度（ 5 7 6字节）是不正确的。在图11 - 1 3中，我们看到，实际的MTU值是2 9 6字节。这意味着经s o l a r i s分片的数据报还将被bsdi分片。图11 - 1 5给出了在目的主机（ SLIP）上所收集到的tcpdump对于第一个到达数据报的输出结果（图11 - 1 4的第5行和第6行）。
(点击查看原图)
在本例中，s o l a r i s不应该对外出数据报分片，它应该将DF比特置0，让具有最小MTU的路由器来完成分片工作。
现在我们运行同一个例子，只是对路由器bsdi进行修改使其在ICMP“不能分片”差错中返回下一跳MTU。图11 - 1 6给出了tcpdump输出结果的前6行。
与图11 - 1 4一样，前两个数据报同样是将DF比特置1后发送出去的。但是在知道了下一跳MTU后，只产生了3个数据报片，而图11 - 1 5中的bsdi路由器则产生了4个数据报片。
(点击查看原图)
更多内容请看PCdog.com--UDP协议专题
