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