MTU探测原理

MTU探测原理
mtu路径探测，方式主要有两类：

1. 给报文设置不可分片标记，向终点发送探测包（既可以udp包也可以icmp包，rfc中没有明确限制），当由于报文大小超过MTU被丢弃时，该路由会反馈icmp（Packet Too Big），并带上下一跳的MTU长度，发送端通过该报文来减少包大小，多次持续该过程可以探测到全路径的最小MTU。
参照：
RFC 1191 - Path MTU discovery
RFC 8201 - Path MTU Discovery for IP version 6
一般具体实现流程如下：
● 发送标记为don't fragmemt(不可分片)的数据包
● 遇到小于路径的mtu后，数据包会被丢弃，并返回一个类型为Packet Too Big的icmp报文给发送端，并带上下一跳的MTU（有些老的接口没实现该规范的话，可能不会带上下一跳的MTU，需要发送端进行自己的算法处理这种场景）。
● 调整MTU大小，继续发送探测包。
● 如果遇到更小的MTU接口，则重复降低探测包大小发送

具体icmp报文格式如下：

rfc8899 里记录这类MTU探测方式可能存在的问题：
● icmp可能会被防火墙拦截
● NAT对icmp处理如果有问题的话，也会影响探测。
● icmp 生成可能会被限制频率导致没有回复。
● .......

2. 在传输层（quic/udp/tcp）做路径mtu检测，而不依赖于icmp的packet too big报文反馈。当前quic的MTU探测使用的是这种方式。基本原理是依赖传输层的反馈，调整包大小，通过定时器是否超时来判断是否超过MTU，该方案接受端反馈需要用户自己实现。

其具体探测流程状态转换为如下状态流程图：
引用自：
RFC 8899 - Packetization Layer Path MTU Discovery for Datagram Transports

其具体实现流程如下(结合quic 实现)：
base阶段：
● 链接建立处于base阶段，此时的包大小设置为一个初始较小的BASE_MTU，这个MTU理论上是经过连接性检查，保证可以互通的（但如果这个BASE_MTU也不能实现互通的话，可能会降低BASE_MTU，对于QUIC，初始MTU如果也不能互通，则会关闭链接）

search阶段：
● 开启探测时会设置一个目标MTU做为探测目标最大MTU，进入Search阶段。
● search阶段会发送MTU探测包，并逐渐增加MTU探测包大小去趋进实际链路MTU。（quic为二分法实现：如果MTU探测包被应答，则增加当前发送端的MTU估计值，如果定时器超时，则会选择包大小增长量为一半的探测包重新探测）
● 一次探测结束后会定时启动下一次检测。（quic实现是根据间隔包数量超过一定大小来启动）
● 当探测次数超过3次，则停止探测，使用当前探测值做为发送端的MTU。进入Search_Complete阶段

Search_Complete阶段：
● 进入Search_complete阶段后，会进行所谓的“黑洞检测”，检查是否进入“MTU受限”场景，如果则确认是MTU受限，减少MTU估计值，探测状态重新恢复到base阶段。 rfc中是建议： 1. 可以定时发送当前MTU大小的探测包，如果数次探测都未被确认。2. 也可以根据icmp的Packet Too Big的消息确认是否MTU受限。 (quic应该是通过定时器探测长时间没有新数据ack，则会进入进行MTU回退）