《基于链路聚合的并行数据传输设计实现16000字（论文）》

[11]在在列车控制与网络服务（traincontrolandservicenetwork,TCSN）中,根据列车网络的特点,在分析加权公平队列调度算法（weightedfairqueuing,WFQ）的基础上,提出了一种基于队列长度的动态加权公平队列调度算法（dynamicweightedfairqueuingbasedonqueuelength,DQLWFQ）。该算法根据不同业务队列中的数据包数量,依据队列的优先级采用动态权重调整策略,在每一次更新时间内对队列进行重新赋权值调整,使得数据传输能够高效进行。最后利用仿真软件NS2对正常和有突发的两种情况分别在WFQ与DQLWFQ算法下进行对比,结果表明改进的算法无论是在正常还是有突发业务流的情况下,均在降低重要业务的时延与丢包率上有显著改善。本文在轮询调度算法的基础上提出了权重轮询平滑自适应调度算法（WeightedRound-SmoothAdaptiveAlgorithm,WR-SAA），总体思路是初始化若干个速率挡位阈值，主机通过自检测多个链路的速率性能进行挡位设置，检测间隔时间根据实际状况进行调整，同一主机下的多个链路以环形的方式依次发送对应挡位的数据包。平滑处理的思想是避免出现速率挡位短时间剧烈变化的现象。主机的某条链路在某时刻速率突然增大，这时会相应设置其速率挡位陡增，在下一时刻由于瞬间高发包量而导致该链路拥堵，进而导致挡位猛降。这种恶性循环会导致链路出现振荡效应，因此要根据链路状况平滑增加挡位。WR-SAA算法能够根据链路的性能合理的动态平滑调整优先级，也就是对主机的链路发包量进行流量控制管理，即不会出现“饿死”现象，同时能够减小多链路下的丢包率，提高系统的吞吐量，满足一定的公平性。3无线多链路聚合实验网络与软件工具3.1网络连接拓扑结构本课题共使用两台服务器，对应链路中的服务端（Server）和客户端（Client）。服务端将客户端访问因特网的数据进行转发，并将因特网的反馈信息转发给客户端。拓扑结构如图2所示：图2多链路传输拓扑结构从上图看出，客户端与服务器的通讯可通过彼此的两张物理网卡进行完成，相对应的两张物理网卡（S-em1与C-em1）处于同一子网中，可以随时进行数据直传，反之不在同一网段下的的物理网卡之间是不可通信的。在本项目中，Client上的两张网卡C-em1、C-em2的IP地址分别为0以及0，而Server上的两张网卡S-em1以及S-em2的IP地址则为以及。因此，C-em1网卡不能与S-em2网卡通讯，C-em2网卡也不能与S-em1网卡通讯，只有相对应的一对网卡才可以进行通讯。括而言之，两台主机将四张物理网卡分成两个子网组成两条完全独立的物理链路，本文通过算法程序将这两条的物理链路组成为一条逻辑链路。除此之外，Client和Server各有一张网卡em3与因特网的连接，S-em3和C-em3的IP地址分别为03以及02，该子网对应了对外网关所属的192.168.1.*网段。但是，为了实现Client与外界的通讯通过Server的转发，因此Client必须关闭em3网卡，从而断开与因特网的直接联系，仅通过Server的两个物理网卡进行数据代转发，进而与外界通讯。3.2协议栈上层发包工具iperf3iperf3被广泛用来对TCP、UDP、SCTP等网络的带宽进行测量，能够调节数据包的格式和传输带宽，并可导出详细的测试数据等优点。在本实验中，建立于客户端和服务器间的通信模型中，当客户端向服务器发送大量报文时，服务器会回复相应的报文。这正是iperf3软件所具有的功能，该工具可在服务端和客户端使用，并统一IP和端口使两端联通。在iperf3的命令选项中，命令行中“-s”表示在服务器上运行，iperf3会监听是否从对方客户端接收信息，并在下层提交报文后，做出相应的回应。iperf3作为在传输层分析协议栈数据的工具，首先要指定传输和接收端口。此端口必须匹配服务器和客户端，是两端的端口统一，从而保证通信的顺利进行。除此之外，IP地址的正确是建立连接的关键，它是物理网卡的IP地址，也可以是虚拟网卡的地址，但是需要注意的是虚拟网卡本身是不能独立完成数据包的发送和接受。其次，发送报文的时间间隔，本层协议栈可实现的最大报文长度和最大预期传输速度等相关信息也需要客户端指定。如果iperf3被指定为TCP模式，则需要考虑到窗口大小的设定，因为所指定的窗口大小将影响传输和接收速度，反之小窗口对应的就是低带宽，更大窗口将带来更大的带宽。即使在发送端确认信息没有很快到达，而发送的报文滞留在缓存中，这使由于缓存空间不足，下一批报文没有被记录在协议栈上层的几率变小。因此，接收端即使某一条报文没有到达，从而使该报文无法被记录在协议栈上层，下一个报文由于他们滞留后的空间不足而无法被丢弃。这样做可以相应的降低丢包率和接收端的传输效率，但是需要大量的内存用于存放这些未能正常上报的数据。在此次实验中的具体实施中，最常使用的指令是“iperf3-c-u-p10002-t1000-b17000M”。该实验中，iperf3主要在客户端用于向服务端发送数据，其中“-c”是用于指定从客户端传输数据。“”则是要发送的目的IP地址。“-u”指定该发送过程使用UDP协议而不是TCP协议。“-p”用于指定监听的端口。“-t”用于指定以秒为单位的传输时间，默认值为10s。“-b”用于指定目标带宽，其中UDP协议的默认带宽为1mbit/sec，TCP没有带宽限制，除此之外，还可以以Kbps，Mbps和Gbps的速率传输。除了常用的指令外，以下提到的指令也起到了重要的作用。例如“-l”用于读写缓冲区的大小，“-w”用于指定窗口或者socket的缓冲大小。另外，为了使服务端和客户端的监听端口统一，在服务端也要使用iperf3工具进行配置。最常用的命令是“iperf3-s-p10002”，首先最基础的“-s”命令用于指定以服务器模式启动，默认TCP方式，也可使用“-u”改为UDP方式。“-D”即daemon，在后台以守护进程启动服务器。“-B”即可给服务端绑定IP地址，与客户端相同“-p”用于绑定端口。3.3抓包工具Wireshark在实际项目中，经常会出现数据包丢失的现象。当驱动程序或环境配备不正确时，物理网卡或虚拟网卡此时不能收发到对应的报文，这种情况下就需要抓包工具来检测某一端主机的网卡是否有发送或接收到报文。作为一款抓包工具，Wireshark功能强大，可以抓取所有协议的包。它可以通过过滤算法很快的得到自己想要的报文。本项目中有两种主要的报文，一种是探测链路性能的数据包，IP源地址是物理网卡地址，另外一种是真实的数据包的IP源地址都是该主机的虚拟网卡IP。使用软件对报文的IP地址进行设定筛选后，可以快速准确地分辨出众多发送报文中是否存在某种特定的报文。比如，为了解决Client与Internet之间的通讯问题，就可以在Server的对外网卡S-em3以及Client的网卡C-em1和C-em2上设置对应的过滤器。Wireshark的具有如下工作流程。开始时，先确定Wireshark的位置并选择合适的捕获接口，确定正确的位置才能使该软件抓取到自己所需的网络封包。随后，该软件会使用两种过滤器对捕获的文件进行处理。捕获过滤器可以避免捕获到的文件过大，从而避免了影响其他数据，并节约了用户的时间。显示过滤器可以让所显示的数据包更加详细和细致。下一步，即使用着色规则，以突出显示某一个所需的对话，并且构建图表，更加清晰的展现某一网络中捕获数据的详细变化情况，方便之后的分析。最后，Wireshark会对数据进行重组，由于在传输过程中，会出现某个文件过大的问题，这是想要查看整个文件的详细信息，则需要Wireshark对分布在多个数据包的信息进行重组。4基于链路聚合的并行数据传输设计实现4.1链路聚合并行数据传输方案链路聚合分为协议栈的两层。分割线在传输层和网络层之间，上层是传输层及其以上，下是网络层及其以下。图3协议栈结构示意图如图3所示，链路部分的数据传输主要是两个部分，一个是来自传输层之上灌包软件iperf3产生的用户数据，另一个是链路维持与性能状态检测的探测数据报文，该报文由Client端生成并进行发送经Server记录相应数据后回传。对iperf3方向上的用户数据进行分析，由于iperf3处于传输层之上，可知用户端向服务器端发送数据，而服务器端不产生应答信息以回复用户端。换而言之，该部分数据是通过Client与Server的虚拟网卡tun组成的一条链路发送，不存在多条链路的情况。对于传输层方向上的数据进行分析，Linux系统内核中的tun显示为单个网卡，因此只能维护单链路数据传输的工作。传输层执行类似物理网卡的的工作机制，负责接收tun上发的数据，或将数据下发到tun网卡，并负责维护拥塞控制，流量控制等。对于传输层下面的tun进行分析，tun将依靠check函数计算的内容选择适当的IP链路，并在通过该链路发送实际存入内存中的数据。当接收数据时，tun先将数据从socket中读出并存入到内存，然后经过简单的排序，将排序后的数据写入tun的维持文件中，上层程序发现文件修改则会取走相应的数据。对于Check函数进行分析，探测数据包是物理链路的主要数据源。Check函数会在Client两个网卡上轮询发送检测报文，通过Server回传后得到链路延迟，接受和发送数据量等数据，根据这些数据计算各条链路的性能,也就是采用2.2.2节中讨论的WR-SAA算法。4.2链路维持与状态判断在初始系统环境的搭建中，编程实现的驱动程序需要有多径链路的建立与维持，在服务器和客户端都安装好该驱动程序和加载的条件下，两端通信的链路则会建立，但是若长时间内没有数据包的交互则会导致socket套接字自动关闭，从而使建立的连接自动断开。因此本文选用在两端都持续发送少量的维持报文来保证链路的活性，同时在维持报文中存入该主机一定时间段内的数据总发送量与总接收量，以及当前系统的时间，用于计算该链路上数据传输的延迟，通过维持报文的收发数据量与延迟来得知链路的好坏，同时还能为发送数据时选择链路提供判断依据。4.2.1链路维持报文的处理过程Client与Server关于探测报文的收发机制是不完全相同的,且只有Client会主动发探测包。Client：Client每经过0.5S，会轮询Server的两个物理网卡状态，并对应链路上发送探测报文，报文type为CHK_ASK。报文的数据部分存放Client在0.5s内发送和接收的数据总量以及系统时间，Server接收到探测报文会修改IP地址等属性，然后回传到Client。当Client接收到Server回传后的探测包后，记录下系统时间，与之前Client发送时的系统时间相减，便可大致获得探测包在此链路上的往返时间。判断某条链路无效的两种方式，一种是链路对端主机的数据接收总量和本地主机数据发送总量都为零；另一种是链路对端主机的数据发送量和本地主机的数据总接收量都为零。Server：Server接收到Client的发送的type为CHK_REPLY的报文后，先修改包类型，然后验证链路是否有效。Client每隔0.5s会进行一次探测包发送，Server和Client都会将0.5S内的收发信息存入到探测包中，可以更加及时判定链路的性能，选择是否继续使用此链路进行数据传输。确定链路有效程序：计算链路延时程序：探测报文结构体：4.2.2链路维持参数的计算与作用state：某链路是否有效的标志位，用来标志该条物理链路能否发送和接收数据。snd_number：主机某段时间内的数据发送量，在主机发送各类报文前，snd_number都会累加本次发送的数据长度。rcv_number：主机某段时间内的数据接收量，在主机接受各类报文后，rcv_number都会累加本次接受的数据长度。4.3虚拟网卡建立与数据转发实现4.3.1虚拟网卡初始化虚拟网卡发送数据可以看做是上层协议栈将数据写入发送端的虚拟网卡，虚拟网卡分发到物理网卡进行处理，将数据传输到物理链路上进行实际发送；接收部分则可以看做接收端多块物理网卡上接收的数据写入接收端虚拟网卡，虚拟网卡再提交给用户空间，完成数据传输。为此，可以通过创建一个虚拟IP地址，将计算机上多块物理网卡整合为一块虚拟网卡，在Linux操作系统中主要包括tap和tun两种，tun是一个点对点的虚拟设备，模拟网络层设备处理三层报文，如IP报文；tap是一个普通的网络设备，模拟数据链路层设备处理二层报文，如以太网帧。无论是虚拟网卡还是物理网卡，只要有一个唯一的IP地址，在TCP或者UDP协议下传输数据时都对应着唯一的一条传输链路，因为这些协议只关心数据报文中的源地址和目的地址，将数据从源地址发送到目的地址即可完成数据传输任务。虚拟网卡不会直接与实际存在的物理网卡之间发生数据交换，而是允许在用户空间向内核空间拷贝数据的这一过程中对数据进行处理。由于本文选择在网络层进行研究，而tun正好是处理三层报文的虚拟设备，于是选用tun来实现虚拟网卡。4.3.2虚拟网卡配置关于虚拟网卡tun的配置，上层协议栈操作的文件描述符对应的不再是物理网卡，而是虚拟网卡的记录文件。主机在发送数据前，需要虚拟网卡会先从记录中拿出数据，再存放到指定内存，然后选择合适的传输链路进行数据的发送。在需要接收这些数据时，tun会从套接字socket中读取数据至内存中并将其写入tun的记录文件，上层程序则会监视此文件并读取其中的数据内容。实际代码实现时定义一个主机信息表的结构体host_info，里面存放着有关主机信息的所有参数变量及相关自定义函数，结构体中部分成员变量如下所示。其中的host_type变量表明该主机是客户端还是服务器，这样在后续的代码处理上有一定的区别；字符数组dev_name中存放的是虚拟网卡的文件位置，便于对虚拟网卡tun进行操作；dev_fd变量是用于管理虚拟网卡对应设备的文件描述符，如使用open函数创建并打开设备文件，然后使用ioctl函数来控制虚拟网卡设备的开启与关闭，并配置设备端到端的各种属性；dev_flags变量用于虚拟网卡的系统参数配置；字符数组ip_addr中存放着32位的ipv4地址，用于配置虚拟网卡的IP地址；udp_port变量用于存放UDP报文的端口号信息等等。由于虚拟网卡tun相对于用户空间而言是一个网卡设备，因此在初始化的时候同样需要设置网卡对应的接口地址、子网掩码、网关等信息。经过上述一系列操作后，多块物理网卡整合完成，相当于已建立好多链路传输的基础，只需为发送端和接收端整合后的虚拟网卡分配物理链路即可，屏蔽掉物理网卡的差异后与单链路传输并无太大差别。发送端用户空间发送的数据通过虚拟网卡分发到多块物理网卡并经过一系列路由到达目的IP地址后，接收端转发给上层进行下一步处理，实现多链路传输。回过头来看图1中所表示的虚拟网卡工作流程，可以发现从用户应用程序下发的数据两次穿过了TCP/IP网络协议栈，也即在用户态和内核态之间进行了三次数据拷贝，相较于正常的数据传输而言多了两次数据拷贝的额外开销，增加了计算机系统的数据处理量。基于此种原因，本文所设计的多链路数据传输方案目前还无法支持15Gbps以上高速率级别的数据传输。4.3.3虚拟网卡发送数据在本设计中有两条物理链路，虚拟网卡tun在发送数据时会选择一条合适的链路进行数据包的发送。发送数据的重要参数：scale和sndid。scale：链路的速率挡位，根据链路的挡位进行数据包的数量的分配，使性能差的链路减少占用时间。scale的值是对端成功接收的数据包数量与链路延时的比值，值会在探测包到达任意主机时进行更新。本文中的判定标准是，商大于当前挡位阈值，scale加一；商小于当前挡位阈值时，scale减一。sndid：链路发送能力的评估，确定待发包数量。只有当值为0时，才将scale赋值给sndid。每次发包后，sndid自减一，当值变成零后此链路不再发送数据包。当上述两个参数取值后，若链路一和链路二的sndid都有值时，则虚拟网卡会通过轮询的方式进行依次发包，直到某个链路的sndid值为0时停止数据包发送，并用scale对其复制。在初始情况下，两条链路的初始挡位都为1，发包量都为0。因此，如果所有的链路在初始情况是不允许发送数据包的，只有当链路检测有效后，才会轮询所有的链路。当每次数据包选择好相应的物理链路后，本次发送的数据包长度将存入在该链路的总传输中，用于下一轮链路状态更新。发送前需要对数据包进行标好顺序，方便后续接收到进行排序上传，方式为将相应用户的序号写入到发送IP包头ID序号中。4.3.4虚拟网卡接收数据本实验在驱动程序中注册了一个hook函数，每当数据包到达主机时，就会主动调用该函数。该函数首先会检查该报文IP源地址是对端哪个的网卡，如果是物理网卡则不需要对包进行排序，根据第4.2节中描述的程序进行处理后，直接全部提交。如果是虚拟网卡地址，则需要对包进行排序，因为这样的包都是数据包。图4排序算法流程图排序程序中只有一个消息队列与指针，排序算法如图4。需要提的一点是此程序只能保证单条链路中的报文正常排序的。接收端的排序算法是以消耗时间为代价而进行，当报文错序较多时则会导致消耗极多的时间。同时，由于此算法在寻找报文是没有强制推出的，因此有几率会存在陷入死循环的现象，因此该算法也是以后需要重点优化的。4.4ARP协议解析及实现在前面3.1节中提到实验室共有两台服务器，分别对应Server和Client，由于为实现Server可以转发Internet数据到Client，因此断掉了C-em3连通外界的网卡。本节将阐述Client使用物理网卡协助虚拟网卡进行数据的发送，进而实现与外界的通信。为实现虚拟网卡的数据转发，需要先完成Server物理网卡对Client物理网卡的数据转发。4.4.1物理网卡实现数据转发在未实现转发数据前，在Client的终端中Ping“”时，显示“ping:unknownhost”，主机无法访问该网站，也就是不能与外界通讯。当再次PingClient的本地网关时，出现“DestinationHostUnreachable”。经过查阅资料和路由器表信息如表2所示，发现是由于Server接收到Client物理网卡em1和em2的ARP报文后没有转发出去。因此导致了Client的ARP缓存表没有缓存对应外界网络的IP地址。表2Client路由表信息DestinationGatewayGenmaskIface*em1*em2Link-local*em4Defaultem1Client中发送到Server端的所有报文中，除了目的IP地址是和之外的报文，都会经过。但是由于没有物理网卡会对该地址进行解析，因此需要人为修改默认网关，使其等于Server端物理网卡em1和em2的IP地址。更新路由表如表3所示:表3客户端主机路由表更新信息DestinationGatewayGenmaskIface*em2*em1Link-local*em4Defaultem2Defaultem1当Client重新设置路由表并重启后，即可成功访问因特网。4.4.2解决过程分析Linux中的虚拟网卡不会主动转发ARP报文，导致Server虚拟网卡收到Client的ARP报文后不主动转发到S-em3网卡，从而导致Client无法得到有效地址与外界通讯。但可以将Client的网关地址修改为Server的网卡，这时当Client发送ARP报文后，会按照路由规则直接转发到S-em3中，不再需要通过Server的转卡进行简介转发。4.4.3虚拟网卡实现数据转发如前文所述，本节要实现虚拟网卡对外界的通讯，也就是从虚拟网卡“发送”与外界通讯的报文。所以，需要将Client的默认网关修改成虚拟网卡tun设备。路由表的设置如表4所示。表4客户端主机路由表更新信息DestinationGatewayGenmaskIface*em2*em*tun1Link-local*em3Defaulttun1若要完成虚拟网卡的数据转发，需要进行重新配置以及修改代码逻辑。首先，链路选择完成后，代码需要对目的IP地址进行比较。如果目标地址不是对方虚拟网卡的地址，则该报文是千万提到的探测链路报文，直接交由上册处理，若是虚拟网卡IP地址，需要选择合适的物理网卡对其转发，即修改源IP地址。5基于链路聚合的并行数据传输测试5.1系统测试组网方法实验室共有两台服务器，安装的是CentOS6.5系统，内核属于为Linux4.15.0，内存为128G，网卡传输速率40Gbps。分别作为本次实验的客户端和服务端，将两者对应的两块物理网卡分别用网线直接连接起来，实现网络互通，后续改为WLAN无线连接。先对网卡的速度不进行限制，进行测试。通过命令ethtool-seth1speed40000duplexfullautonegon将网卡1设置为40G速率工作模式，也就是对网卡进行了相应的限速，使其收发最大速率为40Gbps，对所有网卡实现相同限速后进行后续实验。需要完成的工作：配置网卡，在客户端主机上执行vim/etc/network/interfaces,旧的配置文件可以先备份,仅对em1、em2进行修改：autoem1、ifaceem1inetstatic、address0、netmask、gateway；autoem2、ifaceem2inetstatic、address0、netmask、gateway。在服务端主机上执行vim/etc/network/interfaces,对em1、em2进行修改：autoem1、ifaceem1inetstatic、address0、netmask、gateway；autoem2、ifaceem2inetstatic、address0、netmask、gateway。之后执行ifconfig查看是否修改成功，如未成功重启网卡或服务器。连接两台服务器，使用网线连接两台服务器，在客户端主机中ping可以判断两端的em1是否连接成功，再连接em2，一定确保两条链路都能ping通；在客户端主机修改client1_conf.c中下图部分，分别为”em1”，”em2”对应刚刚对网卡的配置，如果使用其他网卡，也可以参照这个配置在Server修改server_conf.c中下图部分，分别为”em1”，”em2”对应刚刚对网卡的配置；在Server执行ifconfig查看连接互联网的网卡的名字，修改script/server.sh中OUTNC相应的名字，并在两个服务器都执行aptinstalliperf3；在Client和Server上都执行make命令，查看是否有报错，然后都执行insmodkernel-5g.ko查看是否有报错；在Client执行ping查看是否能通，如果不能通，分别执行ifconfig、route、dmesg-c进行问题的排查；在Server执行iperf3-s-p10000，在Client执行iperf3-c-p10000-t1000-b40000M，这里的-b是设置发送速度，可以根据需要进行调整；测试完后rmmodkernel-5g.ko可以卸载内核模块；5.2系统测试结果与分析在客户端和服务端分别加载代码驱动后，并通过iperf3网络测试工具进行灌包操作，数据传输结果如表5所示。表540G网卡多链路传输数据结果链路1带宽链路2带宽总带宽带宽利用率丢包率单链路15.3Gbits/s15.3Gbits/s38.3%0%双链路8.1Gbits/s8.2GMbits/s16.3Gbits/s20.4%0%同时根据表5中的结果可以看到，当数据传输速率在40G时，单链路传输的带宽达不到最大吞吐量的一半，在增加多条链路后带宽利用率仅仅达到20%，但是其丢包率都为0%，首先可以认定接收端处理数据包不存在丢包的问题。通过分析发现，这是由于发送服务端灌包软件iperf3对应的线程CPU达100%，相当于已经不能产生更多的数据包，因此会出现该现象。为了证明是因为发送端不能产生对应速率的数据包，做了以下的测试。在不限制网卡速率的前提下，客户端在终端打开两个iperf3软件分别对服务端的两个物理网卡同时灌包可以得到以下表格。表640G网卡单链路双卡并行传输数据结果网卡1网卡2带宽带宽15.3Gbits/s15.1Gbits/s带宽利用率38.3%37.8%丢包率0%0%通过表6可以看出与之前的猜想相符，当不对网卡进行限速时，实验数据吞吐率上不去，这在前文已经说明过，主要是由于软件代码实现中产生了很多额外开销所导致的，这也是未来需要改进的一个方向。再次通过命令ethtool-seth1speed1000duplexfullautonegon将多块物理网卡都限速为千兆速率模式，并进行多链路传输对比及后续实验，结果如表7所示。相较于表5中的结果，可以看到千兆网卡速率工作模式情况下多链路传输带宽利用率均高于40G网卡速率工作模式。表7千兆网卡多链路传输数据结果链路1带宽链路2带宽总带宽带宽利用率丢包率单链路1000Mbits/s1000Mbits/s100%0%双链路1000Mbits/s1000Mbits/s2000Mbits/s100%0%其中当使用两条物理链路进行数据传输时的实时带宽速率结果曲线如图5所示，由于两条物理链路均为网线直连，且都是使用iperf3工具进行灌包操作，因此两条链路各自的传输带宽基本均分总带宽。图5两条链路数据传输实时带宽曲线最后，实际效果如图6所示。可以看到右侧显示器上的3D视频传输业务较为流畅，左侧上左屏幕展示的是实时传输速率，上中及上右屏幕展示的是Qt绘制的两个业务的实时带宽曲线。图6链路聚合实际演示6总结与展望6.1总结本文主要研究和分析了在网络层实现的一种多链路数据传输技术，通过将终端上多块物理网卡整合为一块虚拟网卡，数据收发时通过虚拟网卡来进行传输。这样做的好处是，它可以屏蔽不同网络的差异，在上层提供了统一的网络接口，完全兼容现有的IP网络架构，传输层可以沿用传统的TCP和UDP协议。并且本次软件代码是在Linux用户空间实现的，为调用虚拟网卡驱动而多次穿过内核空间的TCP/IP协议栈，造成多次数据拷贝的开销，这些开销累积起来的影响就是无法通过该软件实现Gbps高速率级别的数据传输。通过系统实验验证，多链路数据传输确实优于传统的单链路传输，能够带来更高的传输速率和带宽，且整个传输系统更加稳定。最后，数据包乱序在多链路数据传输系统中是一个并未完全解决的问题。由于采用了多条链路共同传输一组数据包，在链路状态相近的时候数据传输还算正常，而如果某条链路陡然变差导致该链路时延增大，必然就会出现乱序接收的情况，这是无法避免的。针对该问题，目前研究中的解决方案是在提前预知链路时延状态的情况下，根据反馈来改进发送端发送数据时的链路分配策略，对于时延超过某一阈值的链路直接不予采用，而低于该阈值且时延较大的链路，则分配较少的序列号靠后的数据包，在时延较小的链路上分配较多序列号靠前的数据包，以此来抵消不同链路间时延的影响，使得接收端所接收到的数据包能够按序到达。该方案理论上可以缓解数据包乱序问题，但实现时需要准确快速预测链路状态，因此实际应用时难度和复杂度较大。另外，也有研究利用先入后出FILO多缓存区方案，来减小接收数据包乱序问题，仿真验证了可以提高视频流传输的效果。除此之外，考虑一种简单的“插入式”队列排序方案，在接收端设置一个缓冲区，将接收到的数据包根据序列号插入到队列中的相应位置，然后将队列中的数据包整体向上层提交，实验证明能够改善数据接收的乱序率。6.2展望本文对无线多链路聚合和并行数据传输技术进行