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就不行了

你可能感兴趣的:(Linux,&,网络编程,network,ip,udp)