基于TCP／IP协议栈的数据包分片技术

孙卫佳， 许永康

（长春工业大学 计算机科学与工程学院，吉林 长春 130012）

0 引 言

随着Internet的飞速发展，在网络上看电影、电视剧，以及网络视频聊天等传输音视频数据非常常见，但是目前的网络环境并不理想，使得用户一旦处在网络环境不太好的时间段或者空间段，音视频应用的性能急剧降低，让用户觉得“很卡”。

为此，文中尝试开发了一个音视频聊天系统，使用TCP／IP协议栈的分片技术把数据包进行分片，并在接收端对其进行重组。众所周知，TCP／IP本身是有内部分片的［1］，但是其大小不能大于65 535字节，并且只能按照默认的1 514字节的大小在以太网中进行传输，但是，网络传输时延、路由器处理时延、丢包率等网络参数均与数据包长度相关［2］，1 514字节的长度在网络环境良好时，可以使音视频应用具有良好的效果，这一点在我们的音视频聊天系统中可以看到，但是一旦网络环境不好，可用带宽减小的时候，只依靠IP本身的分片已经难以满足用户的需求［3］。

1 相关工作

文中的主要工作是先构建一个音视频聊天系统，可以让用户在系统中进行音视频聊天，在这个过程中，自然会涉及到音视频数据的大量传输。本系统视频使用FFMPEG的类库对视频从摄像头进行采集，将其解码为YUV420P的数据，然后使用H.264编码，将一帧一帧的视频数据通过分片传输使用Winpcap类库中的pcap＿sendpacket（）函数构建一个发送队列［4］，将其发送到客户端，因为pcap＿sendpacket（）是发送的数据包队列，该队列保存在内核级的缓冲区，可以减少I／O上下文的交换，客户端首先进行重组，将之前自己分片的数据重组为完整的一帧H.264数据，然后将其解码，将H.264的数据变为YUV数据，然后再将YUV数据通过SDL类库根据用户的需要显示到MFC中的Picture控件中，当然也可以使用SDL本身的窗口进行播放。

音频方面使用Windows的API，Waveinopen（）打开音频设备，采集到PCM格式的音频数据，设置好采样率、信道、双工／非双工，再次使用FFEPEG中的函数编码为AAC格式的数据，同样用上文所描述的方法传输到客户端，客户端进行重组之后，通过回调函数将收到的重组完的AAC数据解码为PCM数据，同样通过SDL播放出来。

2 核心技术

核心技术为基于TCP／IP协议栈的分片以及重组。

2.1 分片技术

TCP／IP协议栈本身有一个重要功能，对数据量过大的数据进行分片，IP首部之内有三个字段与分片相关：标识字段，MF位，片偏移。其中标识字段是区分不同的数据包的，具体到系统中就是用来区分一帧与下一帧的视频数据，其中有P帧、B帧，在分片的时候是一视同仁的，只是大小不同而已。但是在编码的时候这个比较重要。

MF位代表还再不再分片，我们分片的前几片，MF位为0X01，表示还有分片，片偏移是一个能被8整除的数，标识距离第一片的偏移位，当然最后一片的片偏移达到最大，MF位为0，表示不再分片。

数据包分片情况如图1所示。

图1 数据包分片情况

图1 为在WIRESHARK中截取到的图片，通过Winpcap编程将每一片的以太网首部（14字节）、IP首部（一般为20字节）、UDP首部以及UDP伪首部加入到数据前面，封装为一个完整的数据包，其中以太网首部由Windows API中的函数SENDARP获得，其中源MAC可以由Winpcap所提供的链表由本机IP所获得，GetAdaptersInfo（pAdapterInfo，＆ulOutBufLen）［5］，由此函数可得所需要的IP以及MAC，因为一个网卡都可能有不同的IP，假如使用Windows的API中的函数通过计算机名称获得IP的话，可能存在你所用的IP和链表获得的IP不一致的情况，至于对方的IP地址，是根据用户需要选择的，Mac地址则可以通过SENDARP获得，在以太网首部中，还需要填充IP协议类型，一般为IPV4。

在IP首部中，协议类型中可以指定为UDP，因为UDP相对于TCP可以比较实时地传输音视频数据，TTL为数据包的生存时间，表示允许经过的路由器跳数，片偏移则由数据部分的大小和首部长度共同决定，并且需要计算校验和［6］。如果校验不正确，是发送不成功的。在UDP首部中，可以指定IP地址、源端口和目的端口等信息，本系统暂时是提前定好的端口号。IP地址等信息同上方式［7］。

本系统中，由编码好的H.264视频数据以及AAC音频数据传到分片的方法int fragment（unsigned char＊temp，int size22）中，数据包总大小MTU的限制的算法会在后文中介绍，由此大小可以计算出分片的个数，并为每一片指定一个索引号INDEX，这里分两种情况：

1）普通情况：数据部分总大小不能被MTU整除。

其中fragment为每一片的大小，到最后一片的时候该变量为总大小与分片大小的余数，并且把FLAGM值设为TRUE。

2）整除情况：这种情况发生的比较少，但是由于数据量大，还是会经常发生：

此时，最后一片大小与前几片一样。然后加上IP首部、以太网首部、UDP首部，至于添加的方法上文已经提到，不再赘述。下面将IP首部中的重要参数进行实时变化，例如非最后一片的时候，MF位为1，并且指定本分片的实际大小。

将IP首部、以太网首部、UDP首部放到计算校验和的函数中，得出结果。这是其中的一片，然后用Winpcap的数据包发送函数，pcap＿sendpacket（）或者pcap＿sendqueue＿queue将数据包发送出去，其中第一个函数为简单的发送单个数据包，比较简单，但是效率不如下面那个函数，第二个发送数据包队列的函数，先构建一个发送队列，然后将其发送，其中队列保存在内核级缓冲区，减少上下文交换，发送完毕后，将队列所申请的资源清零［8］。

至此，我们完成了数据包的手动分片，可以将音视频数据任意分割大小，至于MTU，Maximum Transmission Unit（最大传输单元）这个数值的设定，多少合适，文中应用了统计学中的线性回归的方法，通过大量的测量，将不同长度的数据包在不同的网络环境下的延迟插入到SQLSERVER数据库中。

数据包延迟关系如图2所示。

图2 数据包延迟关系

测量了将近10万条数据，然后用线性回归的方法回归出一个函数：MTU＝timeout／0.003 5；并且根据此式可以实时地调整数据包的大小。通过VPS算法，每隔一段时间发送一个探测报文，测试延迟，然后通过SETTIMER函数调整数据包的大小，并且定义回调函数来计算MTU的值，数据线性回归如图3所示。

图3 数据线性回归

图中：X轴为数据包大小，Y轴为延迟的大小。

2.2 重组技术

文中手动进行了分片，自然就要进行重组，因为IP协议栈并不会帮你完成这件事，由于文中用Winpcap发送，也用Winpcap进行接收，使用Winpcap过滤的时候需要先设定打开数据包的网络接口为混杂模式，表示接收一切流过网卡的数据包，还有捕获数据包的字节数，读取超时时间，这里设定为－1表示不管有没有数据包都立即返回，设置为0表示不接收到数据包则不会返回，当然，为了符合用户的不同网络环境，也可以根据延迟设定此值。然后要进行过滤条件的编译，Winpcap中的过滤条件是已声明的谓词为词法基础，他包含了一个过滤表达式，pcap＿compile（）把这个表达式编译成过滤器，如果没有给出表达式，那么网络中所有数据包均会被过滤引擎所认可，关于表达式原语以及编译表达式的技巧，我们会在另一篇文章中加以说明［9］。然后打开网卡设备，进行过滤，通过非回调的方式获得网卡的句柄，并且由res＝pcap＿next＿ex（fp1，＆header，＆pkt＿data）这个函数进行捕获我们之前分片的数据包，获得正确的数据之后，即可通过MEMCPY进行重组［10］。

3 结果分析

此系统有两个版本：

1）没有经过手动分片的，直接用数据包套接字进行收发，通过实验可知，在网络较好时，表现不错。但是网络不是很好的时候，会有卡的情况，占用的网络带宽为1.5Mbps；

2）我们分片重组的版本，不管网络如何都不会出现卡顿的情况，并且占用的网络带宽较小。

4 结 语

分片重组技术在网络日益重要的今天具有很好的应用前景，可以在一定程度上缓解网络状况，使用户获得更好的体验。

［1］ Richard Stevens W.TCP／IP协 议 详 解 卷 二［J］.2014，110（1）：121－161.

［2］ 陈敏.网络实时视频传输研究［D］.广州：华南理工大学，2004.

［3］ Lowerkamp B，Tierney B，Cotterll L，et al.A hierarchy of network performance charcteristics for grid applications and services［J］.Proposed Recommendation，2003，95（2）：1110－1115.

［4］ Wang Y.Error control and concealment for video communicaion：AReview［J］.Proceding of the IEEE，2000，502（2）：1100－1156.

［5］ Monetesino F，Pouzols.Comparative analysis of active bandwidth estimation tools procof passive and active measurement workshop［M］.New York：ACM，2004：175－184.

［6］ 王小凡.复杂网络及其应用［J］.科学技术哲学，2004（8）：58－70.

［7］ Issberg D S.Rise of the stupid network［J］.Computer Telephony，2009（2）：60－65.

［8］ Downey A B.General aspects of quality of service and network performance indigital networks［J］.Including ISDNs，2007（1）：22－25.

［9］ Paxon V，Almes G，Mahdavi J，et al.Frmework for IP performance［J］.METRICS Ietf.Rfc.，1998（1）：2330－2340.

［10］ ZHANG Y.Duffield N on the constrancy of internet path properties［C］／／Proceedings of the 1st ACM SIGCOMM Workshop on INTERNET Measruement.2010（1）：3045－3056.