ip包分片研究-以UDP为例

                                                                                                                                                                                                                    测试环境: 利用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_RF0x8000U  /* reserved fragment flag */

#define IP_DF0x4000U  /* dont fragment flag */

#define IP_MF0x2000U  /* 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就不行了。上次测试时由于走了代理，而代理里面有限制，因此可发送值测试不准确，如果直接用iOS发送，可发送最多9244大小的ip包。这是因为ios默认的socket send buf为9216，即udp载荷数据为9216。