IPv4协议中的UDP分片问题

IPv4协议

分片可能引起的问题

参考文章

IPv4协议

先看一个流传得比较多的图，这里直入主题，只说与分片相关的字段。

标识(identification):占16位。IP软件在存储器中维持一个计数器，每产生一个数据报，计数器就加1,并将此值赋给标识字段。

标志(flag):占3位，但目前只有两位有意义。最低位记为MF (More Fragment)。MF = 1即表示后面“还有分片” 的数据报。MF = 0表示这已是若千数据报片中的最后一个。标志字段中间的一位记为DF (Don’t Fragment),意思是“不能分片”。只有当DF = 0时才允许分片。

片偏移 :占13位。片偏移指出：较长的分组在分片后，某片在原分组中的相对位置。也就是说，相对于用户数据字段的起点，该片从何处开始。片偏移以8个字节为偏移单位。这就是说，每个分片的长度一定是8字节（64位）的整数倍。

总长度:总长度指数据报的长度，单位为字节。总长度字段为16位，因此数据报的最大长度为2^16 - 1 = 65535字节。然而实际上传送这样长的数据报在现实中是极少遇到的。

UDP单个数据包的长度由于总长度的原因，不会超过65535字节。而由于MTU的原因，udp数据包超过某一长度（为MTU的值，通常为1500字节）后，会分片传输。

举个例子，主机A向主机B发送一个长度为8000字节的udp数据包，假设mtu为1500，那么数据报将会如何分片传送呢？

假设MTU是1500，实际上每个数据包要包括20字节固定大小的IP头开销，且第一个分片需要包括UDP协议头（8字节），其它分片只需要伪首部即可。所以实际的数据分片载荷为首包1472字节，中间6包1480字节，尾包608字节。

接收端根据包标识+片偏移组包，源地址与标识相同的认为是同一个数据包，使用片偏移排序，最后使用第一个包的udp头校验和检验数据正确性，如果通过校验，则分片组包成功，数据包通知到应用层。如果分片包超过一段时间未完整组包，或是校验不通过，则数据丢弃。

分片可能引起的问题

由于包标识字段是自增的，所以这个验证是不会有问题，乍一看，感觉简直完美。

而实际上，标识字段只有16位，最多只能表示65536个不同的udp数据包。假设分片组包超时的时间为t秒，那么t秒内，如果发送的udp数据包超过了65536会出现什么问题呢？

当然，正常情况下是不会有问题的，我们假设一种异常的情况，一个udp包被分成了两个分片，在包标识为N的时候，分片1没有被接收端接收到，分片2接收到并保留在接收端的内存中，等待超时时间t秒内，又接收到不一样的数据，而标识为N的分片1，这时内存中第一次接收到的分片2就与第二次接收到的分片1组包。由于数据本身不一致，udp校验和不通过，该包丢弃。接下来第二次的分片2又停留在内存中，等待已经被丢弃并永远不会到来的正确的分片1，超时时间又从0开始计时。假设数据发送端一直以相同的速率发送数据，那么第二次分片2等待到的只会是第三次的分片1，然后丢弃。第三次的分片2等待到第四次的分片1，丢弃。。。。。。如此便是一个恶性循环。标识为N的数据包永远都是一个结果：被丢弃。

有人会觉得这不是一个问题，你把超时时间t设置小一点不就万事大吉了吗？然而很不幸，windows 2000之后的内核都是对t值是硬编码，t=60秒，不可改变。
所以如果不是特殊需求的话，最好不要让udp数据包的长度超过mtu的值。如果不得不这样做的话，还有另外一种方法，可以在特定环境下曲线解决这个问题。这里就不详细说明了。

还有另一种情况，当别有用心的客户端每次发送一个不完整的分片到指定windows服务器，服务器一直等待超时，那么服务器内存能否撑满呢？（以下仅为理论上的推测，未进行相关的测试。）

假设一个数据包是1514字节（mtu1500字节+14字节数据链路头）。一个发送端理论上至少可在60秒内发送65535个不同标识的不完整数据包（或多个同一个标识的不完整分片。65535*（（最大UDP数据长度）%（MTU）个）,所以最多能发送4266459570字节≈4GB的数据，这些数据是常驻内存的。理想情况下，只需要16个不同的客户端，就能对一个开放了UDP端口的且内存64GB以下的Windows 2000以上版本的服务器进行拒绝服务攻击。

当然，这只是理想情况。实际呢，服务器可能设置了不允许udp分片，或者udp缓存本身很小、网络丢包、带宽限制、防火墙等因素也可能导致了攻击不可行。

[经过2018-12-31实际测试win7 x64系统，使用大量分片并不会导致目标系统的内存暴涨或宕机，而对网络占用和CPU的增长是存在的。所以此类攻击在新版系统中的影响是有限的]

参考文章

IP协议头详解

ip分片组包超时

欢迎提问