tcp和udp的mtu路径发现.pdf

小宝系列教程之 TCP 和 UDP 的 MTU 路径发现 - 1 - TCP 和和 UDP 的的 MTU 路径发现路径发现 路径MTU的概念：这是当前在两个主机之间的路径上任何网络设备上的最小 MTU路径MTU发现在IP首部中继承并设置“不要分片（DF）”比特，来发现当前 路径上的路由器是否需要对正在发送的IP数据报进行分片 物理网络层一般要限制每次发送数据帧的最大长度 任何时候IP层接收到一 份要发送的IP数据报时，它要判断向本地哪个接口发送数据（选路），并查 询该接口获得其MTUIP把MTU与数据报长度进行比较，如果需要则进行分片分 片可以发生在原始发送端主机上，也可以发生在中间路由器上把一份IP数据报 分片以后，只有到达目的地才进行重新组装（这里的重新组装与其他网络协议不 同，它们要求在下一站就进行进行重新组装，而不是在最终的目的地）重新组 装由目的端的IP层来完成， 其目的是使分片和重新组装过程对运输层 （TCP和UDP） 是透明的，除了某些可能的越级操作外已经分片过的数据报有可能会再次进行 分片（可能不止一次） IP首部中包含的数据为分片和重新组装提供了足够的信息 尽管IP分片过程看起来是透明的，但有一点让人不想使用它：即使只丢失一片数 据也要重传整个数据报。

为什么会发生这种情况呢？因为IP层本身没有超时重传 的机制——由更高层来负责超时和重传（TCP有超时和重传机制，但UDP没有一 些UDP应用程序本身也执行超时和重传） 当来自TCP报文段的某一片丢失后， TCP 在超时后会重发整个TCP报文段，该报文段对应于一份IP数据报没有办法只重 传数据报中的一个数据报片事实上，如果对数据报分片的是中间路由器，而不 是起始端系统， 那么起始端系统就无法知道数据报是如何被分片的 就这个原因， 经常要避免分片 ICMP不可达差错信息（需要分片）不可达差错信息（需要分片）type=3,code=4：： 先了解一下路径发现要用到 ICMP 中的错误信息（type＝3，code＝4） ICMP 域： 类型：3 代码： 0=网络不可达； 1=主机不可达； 2=协议不可用； 3=端口不可达； 小宝系列教程之 TCP 和 UDP 的 MTU 路径发现 - 2 - 4=需要分段和 DF 设置； 5=源路由失败； 发生ICMP不可达差错的另一种情况是，当路由器收到一份需要分片的数据报，而 在IP首部又设置了不分片（DF）的标志比特 上图是 ICMP 不可达信息的包头格式 如果路由器没有提供这种新的ICMP差错报文格式，那么下一站的MTU就设为 0。

新版的路由器需求RFC[Almquist1993]声明，在发生这种ICMP不可达差错时， 路由器必须生成这种新格式的报文,现在的路由器一般都支持新报文，也就是说 返回的时候能返回下一跳网络接口的MTU TCP 的路径的路径 MTU 发现：发现： TCP 的路径 MTU 发现按如下方式进行：和对端 tcp 建立连接的程序时候，双 方要在第一个 syn 中通报自己接口的 mtu， （在 ip 包 tcp 部分的 optional 中） 然后采用双方中最小的那个 mtu 传输数据，如果一方没有通报 mtu，协商不 成功的时候，就用默认的 mtu576 来传输数据一旦选定了起始的报文段大小， 在该连接上的所有被 TCP 发送的 IP 数据报都将被设置 DF 比特 如果某个中间路 由器的接口不能发送 1500 的 ip 包的时候则需要对一个设置了 DF 标志的数据报 进行分片，它就丢弃这个数据报，并产生一个 ICMP 的“不能分片”差错 如果发送端收到这个 ICMP 差错，TCP 就减少段大小并进行重传： 如果路由器产生的是一个较新的该类 ICMP 差错，则报文段大小被设置为下一跳 的 MTU 减去 IP 和 TCP 的首部长度。

如果是一个较旧的该类 ICMP 差错，则必须尝试下一个可能的最小 MTU 由于路由可以动态变化，因此在最后一次减少路径 MTU 的一段时间以后，可以尝 试使用一个较大的值（直到等于对端声明的 MSS 或用新版 icmp 输出接口 MTU 的 最小值） RFC1191 推荐这个时间间隔为 10 分钟 我们来看一个例子， 这是摘自 TCP/IP 详解中的一个例子， 是用 tcpdump 抓的包， 可能看的时候有点难度，不过没关系，我详细解释一下 小宝系列教程之 TCP 和 UDP 的 MTU 路径发现 - 3 - 我们从最右边的主机solaris（支持路径MTU发现机制）到最左边的主机slip建立 一个连接并发送512字节的数据包 在这里我们已经把slip接口的MTU设置为552， 而不是通常的296这使得slip通告一个512的MSS但是在bsdi上的SLIP链路上 的MTU为296，这就引起超过256的TCP报文段被分片于是就可以观察在solaris 上的路径MTU发现是如何进行处理的 我们在主机sun上用tcpdump抓包看看： 我们先注意第1和第2行的MSS值 第一个是solaris在syn包中包含了自己的mss值是1460 第二个是slip回应的ack包中发送了自己的mss是512 接着第三个是solaris发送一个包含512字节的数据和对SYN的确认报文段 那么协商成功后就开始传输数据 这就在第4行产生了一个ICMP差错，我们看到路由器bsdi产生较新的、包含输出 接口MTU 296的ICMP差错。

看来在这个差错回到solaris之前，就发送了FIN（第5行）由于slip从没有收 到被路由器bsdi丢弃的512字节的数据，因此并不期望接收这个序号（513），所 以在第6行用它期望的序号（1）进行了响应 小宝系列教程之 TCP 和 UDP 的 MTU 路径发现 - 4 - 在这个时候，ICMP差错返回到了solaris，solaris用两个256字节的报文段（第7 和第9行）重传了512字节的数据因为在bsdi后面可能还有具有更小的MTU的路 由器，因此这两个报文段都设置了DF比特 接着是一个较长的传输过程（持续了大约15分钟），在最初的512字节变为256 字节以后，solaris没有再尝试使用更大的报文段 UDP的路径的路径MTU发现：发现： Udp 的路径发现其实和 tcp 差不太多，只是 udp 不需要在传输之前建立连接， 也就是说不用 mss 协商来建立双方的分段尺寸Udp 是在传输数据链路上进行动 态协商 我们来结合实例来看看 udp 是如何进行路径发现的： 在此例中solaris向slip发送650字节的udp包 由于slip主机位于MTU为296的SLIP链路后，因此， 任何长于268字节（296－20－8）且“不分片”比特置为1的UDP数据都会使bsdi 路由器产生ICMP“不能分片”差错报文。

小宝系列教程之 TCP 和 UDP 的 MTU 路径发现 - 5 - 在运行这个例子时， 将bsdi设置成在ICMP “不能分片” 差错中， 不返回下一跳MTU 信息就是说bsdi产生一份老格式的icmp报文 在发送的第一个数据报中将DF比特置1（第1行） 第二行bsdi路由器向源端返回一个icmp包，注意这里的mtu是0 源端solaris现在已经知道了发往该目的地址的数据报不能将DF比特置1，因此， IP进而将数据报在源站主机上进行分片，由于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秒的定时器值看来太短RFC1191建议其值取10分钟 solaris的IP层所假设的最大数据报长度（576字节）是不正确的在图中，我们 看到，实际的MTU值是296字节这意味着经solaris分片的数据报还将被bsdi分 片下图给出了在目的主机（slip）上所收集到的tcpdump对于第一个到达数据 报的输出结果（上图的第5行和第6行） 小宝系列教程之 TCP 和 UDP 的 MTU 路径发现 - 6 - 可以看出在slip主机上的收到的包是被bsdi又重新分了片的 第1行是272 第2行是272 第3行是8 第4行是106 现在我们运行同一个例子，只是对路由器bsdi进行修改使其在ICMP“不能分片” 差错中返回下一跳MTU下图给出了tcpdump输出结果的前6行 与上图一样，前两个数据报同样是将DF比特置1后发送出去的但是在知道了下 一跳MTU后，只产生了3个数据报片，而上图的bsdi路由器则产生了4个数据报片， 因为bsdi又重新分了片，这次solaris直接就分好了 好了， 通过上面的介绍应该能知道，在上网的时候为什么有时候浏览网页的时候 不能完全打开或者发邮件时候不能发送等等问题了，有可能就是mtu设置不当造 成。

解决的办法可以有好多 可以用D.r TCP工具改pc的mtu 可以更改路由上的mtu adsl上的一般是1492，可以用一些小工具更改mtu 我们可以用测试工具来测试mtu PC-------------------------Router 192.168.0.12 192.168.0.1 C:\ping -l 1472 -f 192.168.0.1 Pinging 192.168.0.1 with 1472 bytes of data: Reply from 192.168.0.1: bytes=1472 timeping -l 1473 -f 192.168.0.1 Pinging 192.168.0.1 with 1473 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 192.168.0.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\ 1472＋ip头20＋icmp头8字节＝1500字节 第一个说明两端都能通过1500的包 第二个包注意了，这个错误信息是本机产生的，这个ping的icmp包根本就没有到 达路由器也就是包没有发出去（在路由器上debug ip icmp不会看到echo包） ，在 本机就产生出错信息了，因为1473＋20＋8＝1501了，已经超过网卡的mtu了并且 设DF位，所以不会封装这个包。

用dr改一下mtu，改成1499在试试，并且在路由器上打开debug ip icmp监控： 小宝系列教程之 TCP 和 UDP 的 MTU 路径发现 - 8 - C:\ping -l 1472 -f 192.168.0.1 Pinging 192.168.0.1 with 1472 bytes of data: Packet。