赞
踩
本文介绍了一种动态路径最大MTU发现的机制。介绍了路由器产生一种特殊icmp报文。
1、主机先尝试发送一个576字节的报文,并把DF置位(dont fragment)。
这样如果路由器无法分片,会发送一个目的不可达icmp报文。
主机收到后,会减小MTU并继续尝试PMTU发现。
2、一旦主机发现PMTU小到不需要分片即可达到对端,PMTU发现过程结束。
3、路由器需要对报文太大的icmp中,需要报告MTU限制
1、当主机收到一个报文太大信息,主机必须减小其预估的对应路径上的PMTU。
2、由于路径MTU不一定随时变化,所以主机不能频繁做路径MTU发现。间隔不能小于5分钟
3、主机需要能灵活应对还不支持 next-hop MTU的报文太大消息。
4、路径MTU不得小于68
5、主机不能用增加估计的PMTU来响应报文太大消息。
TCP MSS选项
当收到一个DF置位,且超过下一条MTU的报文时,路由器需要发送一个目的不可达消息给主机。
并带上需要分片且DF置位
为了支持PMTU发现,还需要带上低16bit下一跳MTU的字段。Next-Hop MTU字段不能小于68
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Code = 4 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused = 0 | Next-Hop MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + 64 bits of Original Datagram Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
本章介绍主机处理来自未修改的路由器发出的报文太长信息。
1、最简单的办法是假设PMTU是PMTU和576的最小值,并停止DF置位。
2、复杂的方式继续搜索,将包长乘以0.75,并继续发送PMTU发现报文。但不太建议这样做。
3、更复杂的方法是二分法搜索,大概需要4-5次才能知道FDDI到MTU的网络。
4、使用设定好的参考值。只搜索这些点。即使MTU没有出现在表格中,搜索出来的也不会低于这2个因数。
5、每一次的搜索,都需要记录前一次的MTU。
我们推荐的策略是使用小于返回总长字段的最大的参考值来作为下一个 PMTU 的估计值(如果必要,根据上面的注意事项进行修改)。
IP层存储MTU信息,ICMP层用于处理报文太大消息。
IP层也能控制报文是否需要将DF bit置位。
IP层需要将获得的MTU信息和路径联系起来。路径信息可以是source,dest或IP类型。
将MTU信息存储在路由表中。
第一个报文创建的路由信息,MTU和上一条一致。如果PMTU估值比现在MTU高,则更新。
需要支持老化机制,超过10分钟没有出现MTU下降,就恢复上一条MTU。
需要提供设定时长无限的选项。
上层对PMTU过程的报文不能重传。
路由表中,添加时间戳栏位,当设定为保留时,说明MTU没有变化。一旦变化,更新时间戳。
通过时间驱动的过程将立即处理路由表,对于时间戳不是“保留”并且比超时时间间隔老的条目:
-PMTU估计值被设置为第一跳的MTU。
-使用路由的打包层被通知这种增长。
TCP层必须追踪目的地址的PMTU变化。TCP层直接从IP层获取MTU。
TCP层还必须存储从对方发来的MSS值。
当收到报文太大消息时,TCP层仅需要等待超时并重传该数据报文。如果PMTU发现过程开始,连接需要等待一段时间。
同样,当收到报文太大消息后,可以立刻通知TCP层,仅改连接进行重传。
注意:不能对每个报文太大消息做重传,因为多个分片会引起多个报文太大消息。如果新的PMTU还是过大。
这个过程会成倍的增加分片的报文。TCP层需要能识别PMTU发现过程结束。
现在TCP实现通过拥塞避免和慢启动来提升性能,报文太大消息不能改变拥塞窗口,而应该触发慢启动动作。
PMTU发现不会影响TCP MSS选项。
建议实现提供共用程序:
Plateau MTU Comments Reference ------ --- -------- --------- 65535 Official maximum MTU RFC 791 65535 Hyperchannel RFC 1044 65535 32000 Just in case 17914 16Mb IBM Token Ring ref. [6] 17914 8166 IEEE 802.4 RFC 1042 8166 4464 IEEE 802.5 (4Mb max) RFC 1042 4352 FDDI (Revised) RFC 1188 4352 (1%) 2048 Wideband Network RFC 907 2002 IEEE 802.5 (4Mb recommended) RFC 1042 2002 (2%) 1536 Exp. Ethernet Nets RFC 895 1500 Ethernet Networks RFC 894 1500 Point-to-Point (default) RFC 1134 1492 IEEE 802.3 RFC 1042 1492 (3%) 1006 SLIP RFC 1055 1006 ARPANET BBN 1822 1006 576 X.25 Networks RFC 877 544 DEC IP Portal ref. [10] 512 NETBIOS RFC 1088 508 IEEE 802/Source-Rt Bridge RFC 1042 508 ARCNET RFC 1051 508 (13%) 296 Point-to-Point (low delay) RFC 1144 296 68 Official minimum MTU RFC 791
6.3提到的周期性增加PMTU方式,其实就是重新发现的过程。不能过于频繁。
更好的方法是,周期性增加PMTU到一个更高值。
如果PMTU增加了,建议使用更短的老化时间,加快增加的过程。
如果PMTU变小了,建议使用更长的老化时间,避免周期性丢包的发生。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。