android 项目开发linux 网络编程程序员

ip包分片研究-以UDP为例

2017-03-30  本文已影响203人  勤奋happyfire

                                                                                                                                                                                                                    测试环境: 利用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。

上一篇下一篇

猜你喜欢

热点阅读