ip分片研究-以UDP为例

原文 http://www.jianshu.com/p/741cb12ab0c9

测试环境: 利用iOS的NE从TUN抓取IP packets，如下代码分析ip包：

            uint16_t iphid = IPH_ID(iphdr);
            uint16_t iphflagoff = ntohs(IPH_OFFSET(iphdr));
            uint16_t iphoff = iphflagoff & IP_OFFMASK;
            uint8_t iphflag = iphflagoff >> 13;
            NSLog(@"iphid=%02x, off=%02x, flag=%02x",iphid,iphoff,iphflag);

这儿iphdr是ip包首部，iphflagoff是flag和off所占的16bit。IP_OFFMASK是0x1fffU。

iphoff为实际的offset值

iphflag为flag的3个bit

如果有分片flag不为0，且分别中的包flag为1.

注：flag三个bit分别为 0（保留）； 0（可分片）1（不可分片）；0（最后一个分片的包）1（分片中的包）

可用这三个mask分别取得：

#define IP_RF 0x8000U        /* reserved fragment flag */

#define IP_DF 0x4000U        /* dont fragment flag */

#define IP_MF 0x2000U        /* more fragments flag */

因为前两个bit通常为0（第2bit不可分片为1是什么情况不了解），我直接>>13就是第3个bit，相当于直接&IP_MF。

测试，我发了一个3003的udp数据（payload，不包含udp首部的8字节）,MTU为1500（默认值）

iphid=5cff, off=00, flag=01, len=1500

iphid=5cff, off=b9, flag=01, len=1500

iphid=5cff, off=172, flag=00, len=71

看这三个分包的id是相同的，说明他们是同一个ip包拆分的，注意他们是不一定按顺序到达的。

第一个分包，长度为1500，减去20字节的ip首部和8字节的udp首部，payload数据为1472字节，注意因为offset是以8字节为单位的，所以payload数据（加上udp首部）也必须是8字节的整数倍，这里1472=8*184。所以是可以的。然后第二个分包就应该从185位置开始，看一下0xb9正好就是185。第二个分包的playload为1500-20 = 1480字节，因为只有第一个分包包含udp首部，ip分包对于ip首部后面的数据都是透明的。因为一共3003字节，现在还剩下3003-1472-1480=51个字节需要发送，所以还要发第3个分包。
第三个分包，flag为0说明后面没有分包了，长度为71，正好是20+51。offset为0x172，即370*8=2960=1472+1480+8，就是发送的第三段payload数据的便宜。始终要注意分包是以8字节为单位的。

再测试一下，把MTU改为1600会怎么样，第一个分包会是1600大小吗？
看下发送的log:

iphid=e2be, off=00, flag=01, len=1596
iphid=e2be, off=c5, flag=00, len=1455

第一个包大小为1596！为啥？MTU不是1600吗，4个字节去哪儿了？？
回忆一下上面讲的，ip分包中payload大小(包括udp首部)必须是8的整数倍。1600-20=1580，1580/8=197，减去一个udp首部的8, 实际payload可以发196个8。因此第一个分包大小为20+8+196*8=1596，也可以这么算20+197*8=1596，因为实际udp的8个字节首部也算作ip的payload的。
因此第一个分包少了4字节是因为加上4字节就不满足8倍数payload的条件了，如果多4字节是能满足，但是超过MTU了也不行，所以分包大小为不大于MTU的8的整数倍的字节数。
再看第二个包，off为0xc5即197,没错，就是payload数据中（不算udp header）的第197个8。然后1455=20+（3003-196*8）。发送的payload是从197*8开始的，3003字节剩余的1435字节。

OK，总结几点：
1）MTU为IP包的最大值，但IP分包可能达不到这个值。分包大小为不大于MTU的8的整数倍的字节数
2）IP分包将IP首部后面的所有数据进行分割，并不区别UDP或TCP首部，且分割以8字节为单位。因此只有第一个分包含有UDP/TCP首部。
3）offset是以8字节作为单位的，因此只有13个bit的offset可以表示2^13 * 8 = 65536个字节的偏移，而IP和UDP的最大大小都64k-1，因此足够用了。这里其实是以牺牲偏移的颗粒度为代价换取偏移值的存储空间。

补充一点，虽然通过设置TUN的MTU，可以控制分包大小和数量。但是MTU也不能乱设置的，比如说MTU设置为3200，足够发送我们3003+28的包，log如下：
iphid=de2d, off=00, flag=00, len=3031
确实没有分包，ip包大小为3031。但是我们发现这个包最终并没有被发送出去。
这是因为链路中的MTU小于3031。正常以太网内的MTU是1500，有些链路甚至更小，通常internet中支持的MTU至少为576（来源于512+xxxhead），所以正常UDP发送数据576-28=548以内是没问题的。
实际能发送多大的数据就要看实际情况测试了，我简单测试了一下用例环境，1000多的payload是没问题的，1400就不行了