rfc1191.txt

很多RFC的中文文档

 
5. 主机对老式报文的处理
   在这一节中，我们概述几种主机接收来自没有修改的路由器所发出的数据报太大报文（即，下一跳的MTU字段为0的数据报太大报文）所遵守的策略。这一节不是协议规范的一部分。

    主机响应这种报文所作的最简单的事就是假定PMTU是当前假定的PMTU和576之中的最小值，和停止设置在这条路径上发送的数据报的DF比特位。这样，主机会得到和当前实现中选择的相同的PMTU（见"Requirements for Internet Hosts -- Communication Layers" [1]的3.3.3节）。这种策略的优点就是它终止很快，不差于现存的其他实现。它的缺点就是在一些情况下避免分段失败，在另一些情况不能最有效利用因特网。

   更先进复杂的策略包含对一个精确PMTU估计值的“搜索”，当改变它们的尺寸时，继续发送带有DF比特位的数据报。一个好的搜索策略在执行过程中不必产生很多被丢弃的包就可以得到正确的路径MTU估计值。

   一些可能的策略采用前一次估计PMTU的算法函数来产生一个新的估计值。例如，可以用一个常数（比如说，0.75）来乘旧的估计值，得到一个新的估计值。我们不推荐使用这种方法；它要么汇聚的太慢，要么则过多地低估了真正的PMTU。

    一个更高级的方法是在包尺寸上作二进制搜索。这种方法汇聚得快了一些，尽管如此，它从FDDI MTU汇聚到以太网MTU仍然需要4至5步。一个严重的缺点就是当数据报到另一端的时候（指出当前的估计值太小）为了识别它需要一个复杂的实现。我们也不推荐使用这种方法。
 
   从观察中发现有一种策略工作的相当好，实际上，相对较少的值使用在因特网中。 因此，与其盲目搜索任意选择的值，不如只搜索那些可能出现的值。而且，因为设计者倾向于用相似的方法选择MTU，所以，可能收集到成组的相似的MTU值，使用组中的最小值作为“参考点”。（显然，低估MTU的百分之几比高估MTU甚至一个字节也要好）。

   在第七节，我们描述了怎样使用在PMTU估计中有代表性的MTU参考点的表。使用这张表，在最坏情况下汇聚也与二进制搜索一样好，在普通的情况下则更好（例如，只花费两次往返的时间就从FDDI MTU到了以太网MTU）。因为参考点位于接近2的次幂的地方，所以如果一个MTU在表中没有描述，这个算法也不会低估它超过一个2的因数。

    为了选择下一个值，任何搜索策略都必须记住以前的估计值。一种方法就是使用当前缓冲区来保存路径MTU的估计值，但是，实际上在数据报太大报文本身也包含较好的可用信息。所有ICMP目的不可达报文，包括这一种报文，都包含着原始数据报的IP首部， 此IP首部包含着这个太大的不能分片转发的数据报的长度。因为总长度可能比当前估计的PMTU小，但是比实际的PMTU大，它对于选择下一个PMTU估计值的方法来说可能是一个好的输入。
 
         注意：基于源自4.2BSD Unix实现的路由器对于原始IP数据报的总长度发送一个不正确的值。这些路由器发送的值是原始总长度与原始首部长度的总和（用字节表示）。 因为收到数据报太大报文的主机不可能知道报文是否是由这种路由器中的一个发出的，所以主机必须保守的假定它是的。如果返回的总长字段不小于当前PMTU估计值，它必须减去返回的首部长度字段值的4倍
         
我们推荐的策略是使用小于返回总长字段的最大的参考值来作为下一个PMTU的估计值（如果必要，根据上面的注意事项进行修改）。
6. 主机实现
    在这一节中，我们讨论PMTU发现怎样在主机软件中实现。这不是一个规范，而是一组建议。

   要点包括：
         －PMTU发现实现在哪一层或者哪几层？
－PMTU信息缓存在哪里？
－陈旧的PMTU信息怎样被删除？
－传输层和更高层必须做什么？
6.1 分层
     在IP体系中，选择发送数据报的尺寸在IP层上层的协议执行。我们把这样一种协议称作“打包协议”。打包协议通常是传输层协议（例如 TCP）,但是也可能是更高层的协议（例如，建立在UDP上层的协议）。
 
    在打包层实现PMTU发现使层内部的一些问题简化，但是也有一些缺点： 实现可能必须在每一个打包协议中再重做一遍，在不同的打包层之间很难共享PMTU信息，由一些打包层保持的面向连接的状态不容易扩展来长时间的保存PMTU信息。

   因此我们认为IP层应该存储PMTU信息，ICMP层应该处理收到的数据报太大报文。       通过改变它们发送的数据报的尺寸，打包层必须仍然能够响应路径MTU的改变，也必须能确定设置了DF比特位的数据报被发送。我们不想IP层简单的在每一个包中都设置DF比特位，因为，打包层，也许是核心外部的UDP应用程序可能不能改变它的数据报的尺寸。包含有意分片的协议有时是成功的（NFS是最主要的例子），我们不想打破这种协议。
 
   为了支持分层，打包层需要定义在[1]中的IP服务接口的扩展：

         一种得知MMS_S值改变的方法是“最大发送传输层报文尺寸”，
         它通过路径MTU减去最小IP首部尺寸得到。
6.2 存储PMTU信息
     通常，IP层应该与它从一条特定的路径获得的每一个PMTU值联系起来。一条路径是由一个源地址，一个目的地址和一个IP服务类型共同确定的。（一些实现不记录路径的源地址；这对于单宿主主机是可接受的，这种主机仅有一个可能的源地址。）

         注意：一些路径可以通过不同的安全分类来进一步区分。
         这种分类的详情超过了本备忘录的范围。
 
    存储这些联合的明显的地方是在路由表的条目中作为一个字段。主机不会对每一个可能的目的地都有一个路由，但是对每一个活动的目的地都应该缓存一条主机路由。（必要的条件是需要处理ICMP重定向报文。）
 
   当给主机路由不存在的主机发送第一个数据报的时候，一条路由从一组网络路由中或者从一组默认路由中选出。 在路由条目中的PMTU字段应该被初始化为关联的第一跳数据链路的MTU，而且在PMTU发现过程中不再被改变（PMTU发现仅仅创建或者改变主机路由条目）。关联于最初选择路由的PMTU被假定为正确的，直到接收到数据报太大报文。

   当收到一个数据报太大报文时，ICMP层为路径MTU决定一个新的估计值（要么来自包中的下一跳MTU中的非0值，或者使用第五节描述的方法）。如果这条路径的主机路由不存在，那么将创建一个（几乎就象主机ICMP重定向被处理一样；新的路由使用与当前路由一样的第一跳路由器）。如果与主机路由关联的PMTU估计值比新值高，那么此路由条目中的PMTU值将改变。
 
   打包层必须被通知PMTU减小。任意正在使用这条路径的打包层实例（例如，TCP连接）必须在PMTU估计值减小的时候被通知。

        注意：即使数据报太大报文包含一个引用UDP包的源数据报首部，如果有的TCP连接使用这条给定的路径，TCP层也必须被通知。
 
    同样，发送引起数据报太大报文的数据报的实例应该被通知它的数据报已经被丢弃了，即使PMTU估计值没有改变。这是为了它可以重传丢弃的数据报。

        注意：这种通知机制与ICMP源路由抑止提供的通知机制是类似的。在一些实现中（诸如源自4.2BSD的系统），现在存在的通知机制不能识别特别的相关连接，所以，一个附加的机制是必要的。
 
        作为选择，一种实现能够避免使用对于PMTU减小的异步通知机制， 这种机制是通过延迟通知直到下一次尝试发送一个比PMTU估计值大的数据报。在这种方法中，当尝试发送一个带有DF比特位设置的数据报，并且这个数据报比PMTU估计值大，SEND函数会失败，返回一个适当的错误指示。这种方法可能更适合于非连接的打包层（例如使用UDP的打包层），它（在一些实现中）可能很难从ICMP层通报。在这种情况下，正常的基于超时的重传输机制被使用于从丢失的数据报中恢复。

     应该知道打包层实例使用的PMTU改变路径的通知与包被丢弃的特别通知有区别，   了解这一点很重要。后者是比较实用的（即，从打包层实例的观点来看是异步的），而前者可能有延迟直到打包层实例想创建一个包。仅当已知包丢失，才应该重传，这由数据报太大报文指定。
6.3 清除过时的PMTU信息
   互联网网络拓扑结构是动态变化的；路由随着时间改变。如果新的路由开始被使用，对指定目的地已发现的PMTU可能是错误的。 因此，在主机中缓存的PMTU信息可能变得过时。

因为使用PMTU发现的主机总是设置DF比特位，如果过时的PMTU值太大，一旦一个数据报被发送给指定的目的地，就会立即发现这种情况。认为过时的值太小的机制不存在，所以一个实现应该使缓冲值“变老”。当一个PMTU值一段时间内没有减少（在预订的10分钟内），PMTU估计值应该被设置为第一跳数据链路MTU，打包层应该被通知这种改变。 这将导致完全的PMTU发现过程再次发生。
 
       注意：实现应该提供改变超时持续时间的方法，包括设置它为“无限”。          例如，连接在FDDI网络上的主机通过一条低速的串行线接入因特网将不会发现一个新的非本地的PMTU，所以它们不必忍受每十分钟丢弃数据报。
 
   在响应PMTU估计值增长的时候，上层不必重传数据报。因为在响应丢弃数据报的指示的时候，增长从不发生。
 
   一种实现PMTU老化的方法是在路由表条目中加入时间戳字段。这个字段初始化为一个“保留”值，表明PMTU从没改变过。当响应一个数据报太大报文，PMTU减少的时候，时间戳被设置为当前时间。
 
   通过时间驱动的过程将立即处理路由表，对于时间戳不是“保留”并且比超时时间间隔老的条目：

       － PMTU估计值被设置为第一跳的MTU。
       － 使用路由的打包层被通知这种增长。
 
   如果主机路由被删除，PMTU估计值可能从路由表中消失； 这可能发生在响应一个ICMP重定向报文的情况中，或者因为某些路由表守护程序在几分钟后删除了旧的路由。在一个多宿主主机上拓扑改变也可能导致使用不同的源接口。当这种情况发生，如果打包层没有被通知，那么它可能继续使用对现在来说太小的缓冲PMTU值。一种解决方法就是当重定向报文导致路由改变和路由从路由表中删除时通知打包层PMTU可能改变。

      注意：检测PMTU增长的更高级复杂的方法在7.1节中描述。
6.4 TCP层的行为
    TCP层必须追踪连接到目的地的PMTU；不应该发送比它还大的数据报。一个简单的实现可能在每次创建一个新的段的时候，向IP层请求这个值（使用在[1]中描述的GET_MAXSIZES接口），但是这种方法效率不高。而且遵守“慢启动” 避免阻塞算法[4]的TCP实现计算和缓存从PMTU得到的一些其它的值。当PMTU改变的时候接收异步的通知较为简单，以至于这些变量可以更新。

   TCP实现也必须存储从它的对等者那里接收的MSS值（默认为536），不发送任何比MSS大的段，而不管PMTU的值是多少。在源自4.xBSD的实现中，这需要加入一个附加的字段给TCP状态记录。
 
    最后，当收到数据报太大报文的时候，这意味着一个数据报被发送这个ICMP报文的路由器丢弃。把它作为任意其它种类被丢弃的段，等待重传计时器期满导致这个段重传，这样的行为就足够了。如果PMTU发现过程需要一些步骤来估计正确的PMTU，这可能因为要往返许多次数据报而造成连接延迟。
 
    作为选择，重传可以在对路径MTU已改变的通知立即响应时发生，但是这仅仅对于由数据报太大报文指定的特定连接。使用在重传中的数据报尺寸当然应该没有新的PMTU大。

         注意：在响应每一个数据报太大报文的时候一定不要重传相同大小的段，因为特大型的段的突发将造成这样的报文，所以会重传同样的数据。如果新估计的PMTU值仍然错误，这个过程重复，送的多余段的数量将成几何级增长。
 
        这意味着当数据报太大通知实际上减少已经使用在给定的连接中发送数据报的PMTU时，TCP层必须能够识别，并且忽略任何其它的通知。

     现代的TCP实现把“避免阻塞”和“慢启动”算法结合起来提高性能[4]。不象由TCP重传超时导致的重传，由数据报太大报文导致的重传不应该改变拥塞窗口。然而，它应该触发慢启动机制（即，只有一个段将被重传直到确认开始到达）。

   如果发送者最大窗口的尺寸不是使用中段尺寸的准确的倍数（这不是拥塞窗口尺寸，它   总是段尺寸的倍数），TCP性能可能降低。在许多系统中（诸如从4.2BSD中发展的系统），   段尺寸总是设置为1024字节，最大窗口尺寸（“发送空间”）总是1024字节的倍数， 所以，这种适当的关系保持为默认。然而，如果PMTU发现被使用，段尺寸可能不是发送空间的约数，而且它可能在连接中改变；这意味着当PMTU发现改变PMTU值时，TCP层可能需要改变传输窗口尺寸。最大窗口尺寸应该被设置为小于或等于发送者缓冲区空间尺寸的段尺寸(PMTU - 40)的最大倍数。

    PMTU发现不影响在TCP MSS选项中发送的值，因为这个值用在连接的另一端，它可能使用一个不相关的PMTU值。
6.5 其它传输协议的问题
    一些传输层协议（例如ISO TP4 [3]）在重传的时候，不允许重新打包。也就是说，一旦试图传输某种尺寸的数据报，它的内容就不能分成较小的数据报重传。在这种情况下，原始数据报应该不设置DF比特位重传，允许它作必要的分段来到达它的目的地。当第一次传输的时候，后来的数据报应该没有路径MTU允许值大，并且应该设置DF比特位。

   在许多情况下，Sun 网络文件系统（NFS）使用远程过程调用（RPC）协议[11]发送必须分段的数据报，甚至对第一跳链路也是如此。在某些情况下，这可能提高性能，但是众所周知它也导致可靠性和性能的问题，尤其是当客户端和服务器被路由器分开的时候。
 
   当涉及到路由器的时候，我们建议NFS实现使用PMTU发现。大多数NFS实现允许在安装的时候改变RPC数据报尺寸（间接的，通过改变有效文件系统块尺寸），但是可能需要一些修改来支持以后的改变。
 
   而且，因为一个单一的NFS操作不能分开成一些UDP数据报，某些操作（主要是在文件名和目录上的操作）需要可能比PMTU大的最小数据报的尺寸。NFS实现不应该减少数据报的尺寸小于这个极限值，即使PMTU发现建议了一个较小的值。（当然，在这种情况下数据报发送时不应该再设置DF比特位。）
6.6 管理接口
    我们建议实现提供一种适合于系统公用程序的方法：
 
- 确定在给定的路由上没有使用PMTU发现。
- 改变与给定路由相关的PMTU值。
 
    前者通过与路由条目关联一个标志来完成。当一个发送的包经过具有这个标志的路由的时候，IP层把DF比特位清除，而不管上层的请求如何。

    这些特性可以使用在不规则的情况中，或者用在能够得到路径MTU值的路由协议实现中。

   实现应该提供一种方法改变使PMTU信息变老的超时周期。
7. 路径MTU的可能值
   在第五节建议的“搜索”路径MTU空间的算法基于严格限制搜索空间的取值表。我们在这里描述的MTU取值表声明了在因特网中使用的所有主要的数据链路技术。