云南龙网

  1. 首页 > 云知道 > >

路径MTU发现( 三 )

云知道


0123
01234567890123456789012345678901
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
类型=3代码=4校验和
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
未使用=0下一跳MTU
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet首部 原始数据报中的前64bit
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
在下一跳MTU字段中的值是：
沿着原始数据报的路径，在此路由器上不需分段能够转发的最大数据报的用字节表示的尺寸，这个尺寸包含IP首部和IP数据，不包含任何低层的首部 。
这个字段不会包含小于68字节的值，因为每一个路由器都“必须不分段转发68字节的数据报”[8] 。
5.主机对老式报文的处理
在这一节中，我们概述几种主机接收来自没有修改的路由器所发出的数据报太大报文（即，下一跳的MTU字段为0的数据报太大报文）所遵守的策略 。这一节不是协议规范的一部分 。
主机响应这种报文所作的最简单的事就是假定PMTU是当前假定的PMTU和576之中的最小值，和停止设置在这条路径上发送的数据报的DF比特位 。这样，主机会得到和当前实现中选择的相同的PMTU（见"RequirementsforInternetHosts--CommunicationLayers"[1]的3.3.3节） 。这种策略的优点就是它终止很快，不差于现存的其他实现 。它的缺点就是在一些情况下避免分段失败，在另一些情况不能最有效利用因特网 。
更先进复杂的策略包含对一个精确PMTU估计值的“搜索”，当改变它们的尺寸时，继续发送带有DF比特位的数据报 。一个好的搜索策略在执行过程中不必产生很多被丢弃的包就可以得到正确的路径MTU估计值 。
一些可能的策略采用前一次估计PMTU的算法函数来产生一个新的估计值 。例如，可以用一个常数（比如说，0.75）来乘旧的估计值，得到一个新的估计值 。我们不推荐使用这种方法；它要么汇聚的太慢，要么则过多地低估了真正的PMTU 。
一个更高级的方法是在包尺寸上作二进制搜索 。这种方法汇聚得快了一些，尽管如此，它从FDDIMTU汇聚到以太网MTU仍然需要4至5步 。一个严重的缺点就是当数据报到另一端的时候（指出当前的估计值太小）为了识别它需要一个复杂的实现 。我们也不推荐使用这种方法 。
从观察中发现有一种策略工作的相当好，实际上，相对较少的值使用在因特网中 。因此，与其盲目搜索任意选择的值，不如只搜索那些可能出现的值 。而且，因为设计者倾向于用相似的方法选择MTU，所以，可能收集到成组的相似的MTU值，使用组中的最小值作为“参考点” 。（显然，低估MTU的百分之几比高估MTU甚至一个字节也要好） 。
在第七节，我们描述了怎样使用在PMTU估计中有代表性的MTU参考点的表 。使用这张表，在最坏情况下汇聚也与二进制搜索一样好，在普通的情况下则更好（例如，只花费两次往返的时间就从FDDIMTU到了以太网MTU） 。因为参考点位于接近2的次幂的地方，所以假如一个MTU在表中没有描述，这个算法也不会低估它超过一个2的因数 。
为了选择下一个值，任何搜索策略都必须记住以前的估计值 。一种方法就是使用当前缓冲区来保存路径MTU的估计值，但是，实际上在数据报太大报文本身也包含较好的可用信息 。所有ICMP目的不可达报文，包括这一种报文，都包含着原始数据报的IP首部，此IP首部包含着这个太大的不能分片转发的数据报的长度 。因为总长度可能比当前估计的PMTU小，但是比实际的PMTU大，它对于选择下一个PMTU估计值的方法来说可能是一个好的输入 。
注重：基于源自4.2BSDUnix实现的路由器对于原始IP数据报的总长度发送一个不正确的值 。这些路由器发送的值是原始总长度与原始首部长度的总和（用字节表示） 。因为收到数据报太大报文的主机不可能知道报文是否是由这种路由器中的一个发出的，所以主机必须保守的假定它是的 。假如返回的总长字段不小于当前PMTU估计值，它必须减去返回的首部长度字段值的4倍

推荐阅读


上一篇：云是怎么漂浮在空中的

下一篇：交通信号包括那几类