CN108881008A - 一种数据传输的方法、装置和系统 - Google Patents

Abstract

本申请记载一种基于多路径传输控制协议MPTCP的报文反馈方法，该方法用于数据包的收端，该方法包括：通过一MPTCP连接中的第一路径，接收第一数据包；通过所述第一路径向所述发端发送第一ACK包，所述第一ACK包包括所述第一数据包的序列号和第二数据包的序列号，所述第二数据包是所述收端在接收所述第一数据包时，通过所述MPTCP连接中的第二路径已接收的最后一个数据包，其中，所述第一路径的链路状态好于所述第二路径的链路状态。这样，收端在接收到数据后，能够更充分利用多条路径的网络资源向发端反馈数据包的接收情况，从而提高多路径传传输的性能。

Description

一种数据传输的方法、装置和系统

技术领域

本发明涉及通信领域，尤其涉及一种数据传输的方法、装置和系统。

背景技术

自2013年1月，国际互联网工程任务组(IETF，Inernet Engineering Task)制定了第一个多路径传输控制协议(MPTCP，Multiple Path Transmission Control Protocol)以来，关于MPTCP技术的研究已遍布框架制定、安全分析、coupled拥塞控制(RFC6356)、接口分析、用例讨论以及中间件使能等方面。目前，MPTCP技术是通过多条路径并行传输来实现吞吐量的提升，例如Apple公司的siri业务，或者通过多路径来实现业务的连续性及可靠性。例如三星公司与韩国电信布局的手机到网关MPTCP代理这一段网络。MPTCP可以支持多路径传输，也就是将传统的TCP数据分流，分别在不同的TCP子流上传输，这样TCP连接中的两个地址间有多条路径，从而降低地址不可达的风险，也使得在增加或者变化传输路径的过程中，TCP连接不中断。例如这多条子流可以包括WiFi网络和蜂窝网络，该蜂窝网络可以是5G网络，4G网络，如长期演进网络(LTE，Long Term Evolution)、或者3G网络，如码分多址(CDMA，Code Division Multiple Access)网络，或者2G网络等。

由于MPTCP技术涉及多条子流，这多条子流的传输时延很难完全相同，例如，在传输速率，往返时延(RTT,Round-time Trip),丢包率以及带宽等方面都可能存在差异，这种差异反而会影响MPTCP的传输性能。现有技术无法在多条子流的传输时延存在差异的情况下很好地利用这多条子流的传输资源，例如，当报文承载的数据成功到达收端之后，相应的反馈或通知(例如确认字符ACK，即Acknowledgement)无法及时地发送端或者丢失，使得多路径的传输资源无法充分利用，甚至会使得吞吐率下降。在有些场景下，对一个TCP连接，使用MPTCP传输数据的性能，甚至不如使用该MPTCP技术中传输时延最好的TCP子流传输数据的性能。

发明内容

有鉴于此，本发明实施例提供了一种通过发端与收端之间的多条路径进行数据传输方法和装置，使得收端在接收到数据后，能够更充分利用多条路径的网络资源向发端传输反馈的信息，从而提高多路径传传输的性能。

第一方面，本发明实施例提供一种的通过发端与收端之间的多条路径进行数据传输方法，所述路径为所述发端与所述收端之间的链路，所述方法包括：所述收端通过一多路径传输控制协议MPTCP连接中的第一路径，接收来自所述发端的第一数据包；通过所述MPTCP连接中的第二路径，接收来自所述发端的第二数据包；通过所述第一路径向所述发端发送第一确认ACK包，所述第一确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号，其中，所述第一路径的传输时延小于所述第二路径的传输时延。

需理解的是，发端就是MPTCP连接中发送数据包以及接收确认包的一端，收端就是MPTCP连接中接收数据包以及发送确认包的一端。这样，传输时延较好的路径上传输的确认包中携带从两条路径传输的数据包的反馈信息(即确认包中两个数据包的序列号)，就可以使传输时延较好的路径帮助传输时延较差的路径传输反馈信息，使得发端能够更好地确认数据包是否被成功接收，改善数据的传输性能。

一种实现方式下,所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在接收所述第一数据包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

应当理解的是，设备接收数据包需要调用硬件，也需要软件进行处理，这个过程是有一定时间的。第二数据包可以是在这个过程中通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。也可以是在未在该过程中接收到，而在接收该第一数据包前，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大数据包。

一种实现方式下,所述第二数据包的序列号包括子流序列号SSN，所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

当然，这是一种结果性的描述。能满足这种条件的第二数据包，显然从将第二数据包的序列号加入到第一确认包到发送该第一确认包，都未再从第二路径成功接收数据包。也就是说，该第二数据包是在添加第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包的序号到第一确认包时，该收端确定的满足从第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大这一条件的数据包。

一种实现方式下,所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

应理解，由于确认包是设备由于接收到一个数据包而被触发生成的，而生成一个确认包需要一定的软件处理时间，在这个过程中，收端会将确定出的与该确认包数据包的序列号加入。故生成所述第一确认包时，指的是在生成第一确认包过程中，应考虑收端的处理时间。另一方面，生成所述第一确认包时，指的也不是该第一确认包生成完成时。

应理解，上述三种情况中，成功接收指的是收端的协议栈解析出数据包的序列号且确定该数据包携带的数据正确。应理解，上述三种情况中，通常该第二数据包是在接收第一数据包前接收到的。

上述三种情况下，都可以使第二数据包的序列号通过传输时延更小的第一路径向发端传输，从而加快了发端获得传输时延较大的路径传输的数据包的反馈信息，提升了传输性能。

一种实现方式下，所述传输时延通过带宽、往返时延RTT以及丢包率中的至少一个参数表示。该传输时延也可以使用其他参数来表示。

应理解，显然，在传输时延通过RTT来表示的情况下，该方法还包括，收端确定该第一路径和第二路径的RTT。可以是通过解析发端发送的报文中携带的第一路径的RTT的值和第二路径的RTT的值。

一种实现方式下，所述方法还包括根据所述接收到的第一数据包，通过所述第二路径向所述发端发送第二确认包，所述第二确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第二确认包包括所述第一数据包的序列号和所述第二数据包的序列号。

也就是说，从第一路径收到第一数据包，却触发从第二路径发送的第二确认包。

一种实现方式下，所述方法还包括：通过所述第一路径，接收来自所述发端的第三数据包；通过所述第一路径向所述发端发送第三确认包，所述第三确认包包括所述第三数据包的序列号，所述第三确认包用于表示所述收端已接收所述第三数据包，其中，所述第三确认包还包括丢包指示位以及第四数据包的序列号，所述第三确认包中的丢包指示位的值表示所述第三确认包携带丢失的数据包的信息，所述第四数据包是所述收端已确定的通过所述第二路径传输的丢失的数据包。

这样，确认包中携带的丢失的数据包的序列号可被发端识别，且该序列号就可以通过传输时延较小的路径传输，能够使发端更快地确定丢失的数据包，更快地触发重传。

一种实现方式下，通过所述第二路径，接收来自所述发端的第五数据包；根据从所述第二路径发送来的所述第五数据包，通过所述第一路径向所述发端发送第五确认包，所述第五确认包用于表示所述收端已接收所述第五数据包，所述第五确认包包括所述第五数据包的序列号。也就是说，从另一条路径上接收的数据包也可以触发传输时延更好的链路发送该数据包的反馈信息。

一种实现方式下，所述第一确认包还包括协议版本指示位，所述第一确认包中的协议版本指示位的值用于指示所述发端解析所述第二数据包的序列号。具体的，该协议版本指示位为保留字段(reserved)中的前两个bit。

一种实现方式下，所述第一数据包的序列号包括所述第一数据包的数据序列号DSN和所述第一数据包的子流序列号SSN，所述第二数据包的序列号包括所述第二数据包的子流序列号SSN。

第二方面，本发明实施例记载了一种通过发端与收端之间的多条路径进行数据传输方法，所述路径为所述发端与所述收端之间的链路，所述方法包括：所述发端通过一多路径传输控制协议MPTCP连接中的多条路径，向收端发送多个数据包，所述多条路径包括第一路径和第二路径，其中，所述多个数据包中的第一数据包是所述发端从所述第一路径发送的，所述第二数据包是所述发端从所述第二路径发送的；接收所述收端通过所述第一路径发送来的第一确认包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号其中所述第一路径的传输时延小于所述第二路径的传输时延。

应当理解，第二方面描述的是第一方面的对端所执行的与第一方面相应的方法，也就是MPTCP连接的发端，相应的在第二方面中涉及到的与第一方面相同的说明和技术效果不再赘述。

一种实现方式下，所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在接收所述第一数据包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包；或者所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

关于第二数据包的相关描述，请参见第一方面。

一种实现方式下，所述传输时延通过带宽、往返时延RTT以及丢包率中的至少一个参数表示。

一种实现方式下，所述方法还包括：接收所述收端从所述第二路径发送来的第二确认包，所述第二确认包包括所述第一数据包的序列号和所述第二数据包的序列号。

一种实现方式下，所述第一确认包表示所述收端已接收所述第一数据包和所述第二数据包，所述方法还包括：根据所述第一数据包的序列号，增加所述第一路径的拥塞窗口；以及根据所述第二数据包的序列号，增加所述第二路径的拥塞窗口。这样，就可以增加两条路径的拥塞窗口，能够更迅速地增大拥塞窗口，更好地利用MPTCP连接的网络资源。

一种实现方式下，所述第一确认包还包括丢包指示位，所述第一确认包的丢包指示位的值表示所述第一确认包携带丢失的数据包的信息，所述方法还包括：根据所述第二数据包的序列号，通过所述第二路径，向所述收端重传所述第二数据包，所述第二数据包为在传输过程中丢失的数据包。

一种实现方式下，在通过所述第一子流接收到三次所述第一数据包的序列号的情况下，通过所述第一子流向所述收端重传丢失的数据包。

一种实现方式下，所述第一确认包还包括协议版本指示位，所述第一确认包中的协议版本指示位的值用于指示所述发端解析所述第二数据包的序列号。

一种实现方式下，所述第一数据包的序列号包括所述第一数据包的数据序列号DSN和所述第一数据包的子流序列号SSN，所述第二数据包的序列号包括所述第二数据包的子流序列号SSN。

第三方面，本发明实施例记载一种的通过发端与收端之间的多条路径进行数据传输的装置，所述路径为所述发端与所述收端之间的链路，所述装置包括：接收单元，所述接收单元用于过一多路径传输控制协议MPTCP连接中的第一路径，接收来自所述发端的第一数据包；以及通过所述MPTCP连接中的第二路径，接收来自所述发端的第二数据包；发送单元，通过所述第一路径向所述发端发送第一确认ACK包，所述第一确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号，其中，所述第一路径的传输时延小于所述第二路径的传输时延。

应理解，第三方面是第一方面对应的装置，也就是上述的收端，即一MPTCP连接中接收数据包和发送确认包的一端，其各种具体的实现方式、说明以及技术效果不再赘述。

第四方面，本发明实施例记载一种通过发端与收端之间的多条路径进行数据传输的装置，所述路径为所述发端与所述收端之间的链路，该装置包括：发送单元，所述发送单元用于通过一多路径传输控制协议MPTCP连接中的多条路径，向收端发送多个数据包，所述多条路径包括第一路径和第二路径，其中，所述多个数据包中的第一数据包是所述发端从所述第一路径发送的，所述第二数据包是所述发端从所述第二路径发送的；接收单元，所述接收单元用于接收所述收端通过所述第一路径发送来的第一确认包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号其中所述第一路径的传输时延小于所述第二路径的传输时延。

应理解，第四方面是第二方面对应的装置，也就是上述的发端，即一MPTCP连接中发送数据包和接收确认包的一端，其各种具体的实现方式、说明以及技术效果不再赘述。

第五方面，本发明实施例记载理电路、通信接口和存储介质，所述存储介质中存储有协议栈程序，所述通信接口用于通过执行所述协议栈程序与其他设备收发数据包，所述处理器用于通过运行所述存储介质中的指令通过所述通信接口，以实现权第一方面及第一方面各种实现方式所述的通过发端与收端之间的多条路径进行数据传输方法，所述路径为所述发端与所述收端之间的链路，所述设备为所述收端。

一种实现方式下，该设备为终端。

应理解，第五方面是第一方面或者第三方面对应的装置，也就是上述的收端，其各种具体的实现方式、说明以及技术效果不再赘述。

第六方面，本发明实施例接收确认包的设备，所述设备包括：处理电路、通信接口和存储介质，所述存储介质中存储有协议栈程序，所述通信接口用于通过执行所述所述协议栈程序与其他设备收发信息，所述处理器用于通过运行所述存储介质中的指令通过所述通信接口，以实现第二方面以及第二方面各种实现方式所述的通过发端与收端之间的多条路径进行数据传输方法，所述路径为所述发端与所述收端之间的链路，所述设备为所述发端。

应理解，第六方面是第二方面或者第四方面对应的装置，也就是上述的收端，其各种具体的实现方式、说明以及技术效果不再赘述。

一种实现方式下，第五方面和第六方面中的至少一个设备为终端。

第七方面，本发明实施例提供一种的通过发端与收端之间的多条路径进行数据传输的系统所述系统包括发端和收端，所述发端用于通过一多路径传输控制协议MPTCP连接中的多条路径，向所述MPTCP连接的收端发送多个数据包，所述多条路径包括第一路径和第二路径，所述多个数据包中的第一数据包是所述发端从所述第一路径发送的，所述第二数据包是所述发端从所述第二路径发送的；所述收端用于通过所述第一路径，接收来自所述发端的第一数据包；以及通过所述第一路径向所述发端发送第一确认ACK包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号，其中，所述第一路径的传输时延小于所述第二路径的传输时延；所述发端还用于接收所述收端通过所述第一路径发送来的第一确认包。

一种实现方式下，所述传输时延通过带宽、往返时延RTT以及丢包率中的至少一个参数表示。

一种实现方式下，所述系统中的所述收端还用于通过所述MPTCP连接中的第二路径，接收来自所述发端的第二数据包；所述第一确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第二数据包的序列号包括子流序列号SSN，其中，所述第二数据包为在接收所述第一数据包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包；或者所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

一种实现方式下，所述收端还用于根据所述接收到的第一数据包，通过所述第二路径向所述发端发送第二确认包，所述第二确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第二确认包包括所述第一数据包的序列号和所述第二数据包的序列号。

一种实现方式下，所述第二数据包是所述收端在接收所述第一数据包时，通过所述MPTCP连接中的第二路径已接收的最后一个数据包，所述第二数据包的反馈信息表示所述第二数据包已到达所述收端，所述发端还用于根据所述第一数据包的序列号，增加所述第一路径的拥塞窗口；以及根据所述第二数据包的序列号，增加所述第二路径的拥塞窗口。

一种实现方式下，所述第一确认包还包括丢包指示位，所述第一确认包的丢包指示位的值表示所述第一确认包携带丢失的数据包的信息，所述发端还用于根据所述第二数据包的序列号，通过所述第二路径，向所述收端重传所述第二数据包，所述第二数据包为在传输过程中丢失的数据包。

一种实现方式下，所述发端还用于在通过所述第一子流接收了三次所述第一数据包的序列号的情况下，通过所述第一子流向所述收端重传丢失的数据包。

一种实现方式下，所述收端还用于根据从所述第二路径发送来的所述第五数据包，通过所述第一路径向所述发端发送第五确认包，所述第五确认包用于表示所述收端已接收所述第五数据包，所述第五确认包包括所述第五数据包的序列号。

一种实现方式下，第七方面中的收端和发端中的至少一个是终端，或者，第七方面中的收端和发端中的至少一个是支持MPTCP协议的网关。

应理解，第七方面中的收端可以为第五方面记载的发送确认包的设备或者第三方面中的多路径传输控制协议MPTCP确认包的发送装置。第七方面中的发端可以是第六方面记载的接收确认包的设备或者第四方面中的多路径传输控制协议MPTCP确认包的接收装置。

应理解，关于第七方面中系统的相关说明和技术效果，请参见第一方面和第二方面的相关叙述，此处不再赘述。

第八方面，提供一种计算机程序产品，所述计算机程序产品中存储有用于存储可以实现第一方面中各种实现方式中任意一种的方法的程序代码，或者用于存储可以实现第二方面中各种实现方式中任意一种的方法的程序代码。

第九方面，提供一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得所述计算机执行第一方面中各种实现方式中任意一种的方法，或者第二方面中各种实现方式中任意一种的方法。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为三种可使用本发明实施例所记载的方法组网系统；

图2为本发明实施例提供的一种支持MPTCP技术的终端架构示意图；

图3为本发明实施例提供的终端与服务器之间通过MPTCP技术进行通信的示意图；

图4为本发明实施例提供的数据从发端应用层传输到收端应用层的示意图；

图5为本发明实施例提供的一种MPTCP报文头结构示意图；

图6为本发明实施例提供的一种MPTCP协议确认包的报文头结构示意图；

图7为本发明实施例提供的一种数据传输方法的流程示意图；

图8为本发明实施例提供的一种发送确认包或者接收确认包的装置的结构示意图；

图9为本发明实施例提供的一种设备的结构示意图。

具体实施方式

本发明实施例提供了一种基于多路径传输控制协议MPTCP的报文反馈方法、装置和系统，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面解释本申请出现的一些名词。

A和/或B：表示A和B,或者A或B。

主机(host):用于发起或者接收一MPTCP连接的端节点，即一个MPTCP连接的发端或者收端。例如，该主机可以运行在终端或者服务器上。

路径(path):路径是发端(sender)与收端(reciever)之间的链路(link)。路径可以用四元组来标识，该四元组用于表示源地址(和/或端口)和目的地址(和/或端口)对。应理解，支持MPTCP技术的收端和发端，都可以在其主机(host)中准备多个地址，以便标识多条路径。以及，一对收端和发端之间的多条路径可以共享一个或者多个路由器(router)。子流(subflow)：在单个路径(path)上运行的TCP段(segment)的流。子流是一MPTCP连接的一部分。子流的启动(start)和终止(terminate)与常规(regular)的TCP连接相似。

MPTCP连接：通过(over)一个应用，在两个主机(host)间可以通信的一组子流，该组子流包括多个子流。其中，连接和应用的接口(socket)之间有一一映射。

包(packet)：带有头部(header)的一包(package)数据，该头部可以是逻辑上完整或者不完整的。通常，是一物理上打包(physical packaging of data)的数据，当然，也可以是一逻辑上打包的数据(logical packaging of data)。包这个概念用于描述数据在一主机(host)以及与该主机相连的网络之间的交互。

ACK包：也称为确认包、确认报文、ACK(Acknowledgement)、ACK包，反馈报文、通知，该本申请中，确认包可用于收端向发端反馈接收到或者未接收到的数据包的信息，确认包中包括反馈信息，也称为ACK信息，例如某一数据包的序列号。一个数据包的反馈信息在现有技术中通常指收端通知发端已已接收到该数据包。

关于主机(host)、路径(path)、链路(link)、子流(subflow)以及MPTCP连接的相关内容，可以参考IETF标准组织的文件RFC.6824。拥塞窗口(CWND congestion window)，指TCP数据传输中，数据的源端在拥塞控制情况下一次最多能发送的数据包的数量。应理解，拥塞窗口简写为cwnd或者CWND都是可以的。例如在某些代码中，使用cwnd来表示。RTT(Round-trip Time)，往返时延。表示发送端从发送数据开始，到接收到接收端发送的对应该数据的接收确认信息(如ACK或者NACK)的过程，经历的时延。应理解，在一种实现方式下，接收端收到数据后便立即发送该数据对应的确认信息，其中，“立即”应理解为包括接收端从接收到数据直至发送确认消息的必要的处理时间。应理解，往返时延简写为RTT或者rtt都可以。例如在某些代码中，使用rtt表示。

目前常见的多路径传输场景，往往是两条子流，也就是蜂窝网络和WIFI网络，但是，可以预见，多于两条子流的传输场景会越来越普及。例如，可以是在广域网中，某个区域有多个运营商，导致该区域支持多于两条子流进行TCP数据传输，再例如，一个数据中心中，也可以通过等价多路径(Equal-Cost MultiPath routing，ECMP)路由技术实现支持三条及以上子流进行多路径的TCP数据传输。

MPTCP技术(也称多径传输技术)可以用在多种组网系统中，通常，若要通过MPTCP技术传递信息，信息的发送端和接收端之间应至少有一段链路支持MPTCP技术。图1简单列举了三种可使用该技术的组网系统，为了描述方便，图1中示意性画出了该多路径系统中的两条路径，分别使用WiFi技术(以路由器表示)和蜂窝网络(以基站表示)，其中，云端示意性地画出了几个云端服务器，应理解，图中只示意性表示云端与其他设备的连接，不明确表示云端的哪个服务器与其他设备连接。图1中的系统一是终端与云端之间进行通信，云端中与终端通信的设备不支持MPTCP技术，而终端支持该技术，或者则云端的设备支持MPTCP技术，而终端不支持，则要使用该技术，不支持该技术的一侧就需要通过支持MPTCP技术的代理设备(proxy，例如网关)，与另一侧交互。图1中的系统二中，云端与终端均支持MPTCP技术。图1中的系统三中，描述的是两个云端之间进行通信的场景，这两个云端中，可以均支持该多径传输技术，也可以有至少有一端不支持该技术，不支持该技术的一端借助支持MPTCP技术的代理设备(例如网关)即可，如图1中，示意的就是两个云端都借助支持MPTCP技术的代理设备，使得两侧网关之间使用该技术进行通信。

其中，云端可以包括多种设备，例如服务器等，通常，对一个涉及云端的TCP连接，是该云端的某一设备与对端进行通信。

本申请主要改进的是对端接收到数据后，向发端发送反馈或者通知的过程。该改进需要在双端施行，即生成该MPTCP报文的反馈或者通知的一端，以及生成该MPTCP报文的一端。或者说，本申请实施例所提出的改进方案，适用于一个TCP连接中的MPTCP报文的产生端和MPTCP报文的解析端。也就是对多条链路中的中间路由器和交换机不需要改动。也就是说可以是在支持MPTCP技术的端设备上，如果一端端设备不支持MPTCP，要使用MPTCP技术传递报文，则必然会使用支持MPTCP技术的代理设备，则本申请的技术方案就用在支持MPTCP的代理设备上。具体可以参考图1的几种组网形式。具体就是用在支持MPTCP协议的云端设备，例如服务器；支持MPTCP协议的终端，例如台式机、笔记本电脑、平板电脑、蜂窝电话、智能手表、智能手机或PDA等等；以及支持MPTCP协议的代理，例如网关。

应当理解，在本申请记述的技术方案使用在代理设备的情况下，代理设备还应当将收到的MPTCP数据包重包装为TCP数据包传递该数据包的五元组中携带的目的地址所指的设备，对MPTCP确认包也是类似。

图2以终端为例，详细描述为本发明实施例所涉及的支持MPTCP技术的终端的总体架构图，其中按照逻辑架构的层次关系示意性地包括了终端各层次的结构，其中也包括实现虚拟网卡技术的部件或者模块。需要说明的是，虚拟网卡技术可以基于一个无线电硬件虚拟出多个虚拟网卡，并可以用在各种终端设备或者网关等网络通信设备上，并可扩展到任何操作系统。应理解，图2所示的架构，尤其是对所涉及的传输层的描述，对云端设备以及MPTCP代理设备同样适用。

具体的，该终端包括：

物理层，包括一个或多个无线电硬件设备，如天线等射频器件，用于完成物理层通信，无线电硬件设备是终端实现通过多个无线网络与服务器进行数据传输的硬件基础。需要说明的是，这些终端可以具有两个或者两个以上的无线电硬件设备，但是仍然可以通过配置，优选其中一个无线电设备参与通信和数据传输。物理层还包括存储器和处理器等其他硬件设备。

硬件驱动层，例如可以采用微软虚拟网卡技术，安装了微型端口驱动器，该驱动包括MP播放器，用于控制驱动器与操作系统之间的交互；MP/端口接口，用于处理MP层与多个端口之间的通信；多个端口以及与其中每个端口所对应的一个虚拟网卡(Virtual NetworkInterface Card，VNIC)，每一个端口可以与对应的无线网络相关联，且因此控制无线电硬件与对应的无线网络之间的通信，每个端口维持无线客户机与对应无线网络连接所需的介质访问控制层(Media Access Control,MAC)状态，该MAC状态相对于其它端口是唯一的；VNIC提供其对应端口需要的所有硬件层服务，一个VNIC对应的端口打开则这个VNIC也打开，VNIC与硬件虚拟化层(Hardware Virtual Layer，HVL)通信，该层多路复用或者多路分解各VNIC与物理无线电之间的信号，以允许VNIC将状态从VNIC传送到无线电硬件，并将无线电硬件用于代表对应端口与对应网络进行无线通信。综上，在图2所示的硬件驱动层中，微型端口驱动器可以将一个无线电硬件虚拟出多个虚拟网卡VNIC和多个端口，不同的端口和VNIC可以接入不同的接入节点，从而终端可以同时保持与多个接入节点的连接。而且，微型端口驱动的内部结构对应用层是透明的，应用层只知道终端有多个网卡，应用层只需要利用微型端口驱动提供的接口就可以控制每个端口和VNIC的通断，并使各个端口和VNIC接入指定的AP。当然，终端也可以从硬件上配备多块网卡。应理解，图2只是硬件驱动层的一个示例，本发明实施例对硬件驱动层具体的结构不做限定。

传输层，用于运行传输协议，维护与网络侧服务器建立的TCP连接。支持MPTCP技术的设备传输层也包括MPTCP协议的内容。本申请涉及的对各种设备的改进就是在传输层。

应用层，用于操控和协调其他层的结构或模块完成任务及实现功能，包括终端上安装的应用软件及客户端，如通讯录、时钟、Yutube客户端、微信(Wechat)客户端等。

本申请中发送的数据，就是从发端的应用层下发到传输层，通过传输层中的MPTCP技术将数据分配到各个TCP子流上，通过发端的硬件驱动层使用物理层的无线电硬件，将数据发送到网络，再经过网络的传输，由支持MPTCP技术的对端硬件接收后上报传输层，在传输层解析和整合后上报给对端应用层，从而完成数据的传输。

特别的，在本发明实施例中，传输层包括支持多路径传输控制协议(MultipathTransport Control Protocol，MPTCP)的模块，MPTCP协议是传统TCP协议的扩展，即在传输层上使用多条路径实现同时进行数据传输的协议。传统TCP协议的通信只能在一对地址间建立连接，当连接中的任一个地址不可达时，连接必须中断，而为了恢复数据传输智能重新建立连接。MPTCP可以支持多路径传输，则使得TCP连接中的两个地址间有多条路径，从而降低地址不可达的风险，也使得在增加或者变化传输路径的过程中，TCP连接不中断。MPTCP协议的拥塞机制决定了其数据吞吐量的提高，一个多路径传输的实际吞吐量不能低于单个最优路径传输的最大吞吐量。MPTCP层可以将传统的TCP数据分流，分别在不同的TCP子流上传输，多个路径就意味着多个TCP子流，而本发明实施例使一个物理无线电虚拟出多个虚拟网卡，从而使多个TCP子流能通过一个物理网卡进行传输。一旦检测到有多个可用的虚拟网卡已经接入了网络，则MPTCP协议将TCP连接的数据分流成多个子流对应到多个到可用的网卡，从而实现了单个TCP连接下的多条传输链路的聚合。例如图3所示，终端的应用层客户端与服务器的应用层之间建立了MPTCP连接，终端应用层通过端口1，接入节点1到服务器端口1’到服务器应用层，可以认为是路径1，以及终端应用层通过端口2，接入节点2到服务器端口2’到服务器应用层，可以认为是路径2。MPTCP协议是与TCP协议完全兼容的协议，MPTCP的所有管理信息都是通过TCP选项字段来传输，所以只要数据交互双方设备均支持MPTCP协议，则初始连接时交换MP_CAP(Multipath Capable)选项。也就是说，MPTCP连接建立的流程与TCP连接类似，为三次握手，在三次握手的报文中都携带有MP_CAP(Multipath Capable)，双方交换以示收发两端设备均支持MPTCP协议。

MPTCP技术基于TCP技术，在TCP技术中，收端接收到数据都要向发端确认包，确认包中会携带接收到的数据的信息，发端接收到确认包，发端才可能确定该确认包对应的数据对端已经成功接收，否则就会认为该数据包丢失，在接收到确认包前，发端无法确认触发该确认包传输的数据包是否被收端接收。发端的传输层的缓存不会清除该已发送的数据，应用层新的待发送数据无法下发到该缓存，尤其是对于连接级，由于在确认已发送的数据时，要求反馈得到的连接级的数据编号是按顺序的，而多个子流的传输，显然对连接级确认已发送的数据的速度有更大的影响，导致子流的拥塞窗口无法向前滑动。而这样，则无法充分利用带宽资源，甚至导致这个TCP数据流饿死。另外通常发端认为丢包是网络传输过程中发生的，也就是传输时延不好，那么就可能导致拥塞窗口(cwnd)不能快速持续地增长，甚至由于反馈信息的丢失导致发送端错误地认为数据包丢失从而进入拥塞控制阶段，这种误判会造成吞吐量的下降。因此，一种能够及时令发端收到对端的反馈的机制，能够更快速将收端收到的数据包的相关信息传递给发端，对提升网络资源的利用率，例如提高网络的吞吐量非常有效。

而对于MPTCP技术，由于一个TCP连接通过更多的子流传输。每个子流的传输时延不一，情况较TCP技术更复杂，也就更容易无法及时令发端收到对端的反馈，这使得某些场景下，对一个TCP连接，使用多路径技术传输数据的性能甚至不如单独使用该多条路径中传输时延最好的一条链路。本申请实施例中,将一个TCP连接中发送数据包的一端称为发端,将接收数据包以及发送该数据的确认包(如确认包)的一端称为收端。

对同一个TCP连接，要传输的数据会进行切分，例如分为多个分组，使用TCP协议传输会存在队头(HoL)阻塞现象，也就是说，如果一分组中有部分数据在传输中丢失，其他被接收的数据将被保存在缓存器中直到丢失的该部分数据重传成功才会上报给应用层。也就是说，传输层要确认解析出整个分组的数据，且该分组的数据能够按顺序组成该完整的数据，才会将这组数据上报给应用层。例如，一个分组长度为16K，在传输过程中有1K的数据丢失，则剩余的15K数据需要等待该1K数据重传成功后，才会将该分组的数据提供给应用层。一个分组中包括的若干数据片段(fragment)可以称为分片数据，每个分片数据可以被封装成一个数据包，在每个数据包的报文中，会携带该数据包中的数据在该分组中的编号，该编号可以表示该段数据在该分组数据中的顺序。显然，由于这个编号是用来标识一个应用的待传输数据的，这个编号是MPTCP连接级的编号，因此，例如下文提及的DSN(Data SequenceNumber,数据序列号)就可以实现这个功能。多数情况下，一个从应用下发的数据会按照某个预设的长度切分成片，数据被切分后最后一段的数据量可能不足该预设长度，则可用一个分片数据在该数据中的相对地址来作为该分片数据的编号，可以是该分片数据的起始位置的相对地址，或者终止位置的相对地址。例如，预设的长度为1K(即KB)，编号可以是1K，表示这段数据是该分组中从0到1023B或者(1K-1)的这段数据，5K，表示这段数据是该分组中从4K到5119B(或者5K-1)的这段数据。而对于MPTCP协议，如图4所示，则发端的MPTCP协议栈的发送缓存(send buffer)保存从应用层下发的数据，如数据1，其中该数据已分片，如图4中数据1被分片成DSN＝1和DSN＝2的两个数据，分片的数据被分发到TCP协议栈的各个子流(子流1和子流2)对应的端口(端口1和端口2)以便发送，分片的数据经过封装就是一个个数据包如数据包A和数据包B，其中A和B是这两个数据在各子流上的编号，例如SSN(SubflowSequence Number，子流序列号)，每个数据包包括该数据的DSN和SSN，而经过传输，收端通过各子流的端口从各子流接收到相应的数据包，TCP协议栈经过解析，将解析出的数据A和数据B提供给接收缓存(receive buffer),在接收缓存中进行排序，在这组数据均被解析出来后，就可组合成完整的数据1上报给应用层。

需要说明的是，在一个MPTCP连接建立的三次握手的过程中，交换的一个信息是初始序列号(ISN，initial sequence number)，一旦连接双方设定了ISN之后，接下来发端发送的数据包所包含的序列号都会在该ISN基础上增加载荷值，从而得到下文中所述的DSN。

发端的传输层会将应用层下发的属于同一个MPTCP连接的数据编号，该编号用DSN表示，可用于表示该数据在属于该MPTCP连接的数据中的顺序。然后将这些数据分配到多条子流上，这些数据中的每个数据将被封装为一个报文，每个子流对各自子流待传输的数据再进行独立的编号，该编号表示为SSN，可用于表示该数据在该子流中的顺序，也就是说这些数据中的每个数据都具有2个序列号，即DSN和SSN。相应的，每个子流上的数据到达接收端后，接收端的反馈信息(如ACK报文)中包括对上述两个序列号的确认，因此，每个子流发送的确认包携带对应本子流的ACK信息(在报文中可以表示为subflow_ACK字段)，以及TCP连接级别的ACK信息(在报文中可以表示为data_ACK字段)，即subflow_ACK对SSN进行确认，data_ACK对DSN进行确认。实际上，一种实现方式下，subflow_ACK字节携带的内容就可以是SSN，data_ACK字段携带的内容就可以是DSN。当然，该subflow_ACK字节携带的内容也可以是其他用于表示数据包在子流的序列号，该data_ACK字节携带的内容也可以是其他用于表示数据包在该MPTCP连接的序列号，本申请不做限制。

也就是说，一个数据包从哪个子流发送到收端，该数据包的反馈信息(如ACK包)就会从该子流回传。回传指的就是收端收到一个数据包后，将该数据包的反馈信息传给发端，使发端接收到该反馈信息。当然，本发明实施例对数据包的反馈信息的具体形式不做限制，例如可以是文中提及的SSN和DSN，或者与这两种参数有类似功能，能够标识该数据包的其他信息。

应理解，现有技术中，当发端在超过预设的时间仍未收到一个数据包的反馈信息，则发端认为该数据包没有被收端收到。一种情况下，当发端先后收到三个确认包，这三个确认包携带相同的SSN和相同的DSN，则发端认为收端没有收到该确认包对应的数据包的编号之后的那个数据包。例如，发端依次发送了数据包1,2,3,4，收端收到数据包1，返回用于反馈数据包1的确认包1，其中数据包2丢失，即使收端收到数据包3，仍然返回数据包1对应的确认包1，即收端收到确认包仍然携带数据包1的SSN和DSN，后续收端收到数据包4，也返回数据包1对应的确认包1，即收端收到确认包仍然携带数据包1的SSN和DSN，这样发端收到三个携带数据包1的SSN和DSN，就可以知道数据包2丢失了，则发端就会重传数据包2。显然，这种方式使得发端要经过较长的时间才能确定出哪些包被接收了，哪些包丢失了。

另一方面，应理解，现有技术中，收端接收到一个数据包，根据该数据包生成一个用于反馈该数据包信息已收到的确认包，也就是说只有接受到一个数据包，才可能相应地发送一个确认包。

本申请为了解决了现有的多径反馈机制中反馈信息(如数据包的序列号)回传效率低的问题，提出了一种传递应答信息的方法，从而能够提高确认包(如ACK)回传效率，进一步的，能减少发送端的发送缓存不能被及时清空，减少拥塞误判，提高吞吐量。

应当理解，MPTCP技术中，一个TCP连接有至少两条子流，为了描述方便，本申请实施例以一个TCP连接对应两条子流来描述，而实际上，多于两条子流的情况同样适用，在多于两条子流的情况下，至少一条子流也携带另一条子流的数据包的序列号。一种实现方式下，至少一条子流只携带另外一条子流的数据包的序列号；另一种实现方式下，每条子流都只携带另外一条子流的数据包的序列号；又一种实现方式下，至少一条子流会携带多条子流的数据包的序列号。本申请实施例对多于两条子流的情况下如何携带其他子流的数据包的序列号不做限制。

本申请记载的传递应答信息的方法，通过对确认包的改进，使得确认包中增加了其他子流的数据包的序列号。例如，该其他子流的数据包的序列号是在该确认包发送时，收端最近收到的其他子流中的报文对应的数据包的序列号。当然，为了能够生成这样的报文，应当对数据的收端或者该数据的收端对应的MPTCP代理进行改进；而另一方面，对数据的发端，或者该数据的发端对应的MPTCP代理也应进行改进，从而使得能够解析出被改进的确认包中的其他子流的数据包的序列号。

另一方面，可以在TCP连接建立的握手过程中，连接中使用MPTCP协议的两端可以通过报文确定出该TCP连接所使用的协议。为了能使收发双端都能识别改进后的确认包，在传输数据之前，收发双端可以通过确定协议的版本，确定确认包的格式，例如通过报文中的一个协议指示位来标识。这样，就可以在接下来的数据传输过程中，使用本申请提及的被改进的确认包了。例如，可以通过三次握手的过程来确定MPTCP的协议。该过程中，使用的报文头的格式和现有的开源MPTCP协议没有区别，均如图5所示，应理解，图5不是完整的报文。其中，第一行的4个标识了0到7的方块各表示一个字节，不是报文头的一部分。其中的版本(version)字段用于指示使用的MPTCP协议，该字段长4个bit。如为0000，则为现有的开源MPTCP，如果version字段为0001，则是包括本申请提出的携带多路径的反馈信息的确认包在内的改进版MPTCP协议。或者使用version字段(长4个bit)来表示建链的MPTCP连接使用的协议版本号。

在本申请的一个实施例中，在多个子流链路间存在传输时延的差异的情况下，使用传输时延较小的路径帮助传输时延较大的路径进行数据确认。具体的，传输时延可以以RTT(Round-trip time,往返时延)、带宽或者丢包率等参数中的任意一个来衡量。至于采用何种参数来考量传输时延，可以根据需求，如时延，准确性等来选择，本申请的实施例不做限制。以下以RTT为例进行描述。

应理解,在通过RTT来考量传输时延的实施例中，还应包括发端测试或者估计各子流的RTT的步骤，以及将得到的RTT发送给收端。应理解，发端可以周期性地检测RTT,以及周期性地向收端提供测得的RTT,这样，收端就可以及时地根据网络的传输时延的变化，对生成确认包和发送确认包的过程进行调整。

例如，对一个TCP连接，有两个子流，为子流1和子流2，子流1的往返时延为RTT1，子流2的往返时延为RTT2，其中RTT1>RTT2，则可将通过子流1发送的数据的ACK携带在子流2的确认包中发送给发端，从而可以缩短子流1对数据的确认时间。假定子流的正反向时延一致(即从发端传输报文到收端的时延和从收端传输报文到发端的时延一致)，且原本在子流1发送的确认包的信息，通过子流2发送，发送过程不会有明显的附加的时延，则对子流1中一个数据包，使用子流2帮助回传该数据包的序列号，则这个数据包的往返时延RTT1’可以用下式表示：

这样，就可以加速对质量差的路径上传输的数据的确认，即反馈信息能尽快传回发端，降低了差链路对系统吞吐的负面性能影响，另一种实现方式下，子流的确认包中可以互携带另一个子流的ACK信息，例如，该另一个子流的ACK信息可以是另一子流一数据的SSN编号，这样还可以解决由于某个子流上的确认包丢失造成发送端的拥塞误判概率。

其中，可以在现有的确认包的基础上做一些改进，从而得到适用于本申请所记载的方案的确认包。以下举个例子进行说明，一种实现方式下，改进后的确认包有关MPTCP协议的格式如图6所示，图6表示的是一个从子流1传输而携带从子流2传输的数据的信息的确认包的报文头，并不是个完整个报文结构。也就是说，完整的报文结构中还应包括TCP报文格式的部分，该部分中携带的从子流1传输的数据的反馈信息，图6并未画出，其中，第一行的4个标识了0到7的方块各表示一个字节，不是报文头的一部分。可见，采用改进后的报文，则每个子流上发送的确认包的报头都使用一个解析标记位，来表示该报文中是否要解析另一条子流的反馈信息，或者该报文中是否携带另一子流的反馈信息。如图中的flag位。该flag占用保留字段reserved(例如该字段长7个bit)中的两比特(bit)该另一条子流的反馈信息为报文的第8到第11个字节，即图6中的subflow2 ACK，表示子流2的反馈信息。这样flag置01，则表示发端需要解析对应另一条子流的反馈信息的的第8到第11个字节，应理解的是，图6中，表示种类(Kind)的是第0个字节。若置00则无需解析，或者说对发端来说，相当于该确认包携带另一子流的反馈信息。也就是说，flag的取值实际上也表示了这个确认包是否适用本文中改进的MPTCP协议来处理，与前文中的version字段功能类似。其中,flag为01，表明采用的是本申请描述的多径反馈机制,该确认包带有另外一条子流路径的反馈信息，flag为00表明为现有的开源的MPTCP。可见，有了flag，就可以现有的确认包和改进的确认包混传，例如收端和发端间有两条MPTCP连接，一条使用现有技术，一条使用本申请所记载的改进的方案，或者发端或者收端是其他使用现有技术的MPTCP连接的一端。现有的确认包不包括另一子流的反馈信息，比改进的确认包短。显然，使用解析标记位使得对现有的报文格式的改动较小，更有利于兼容现有的通信系统。另外，图中的Data ACK(数据响应)字段用于承载连接级的数据反馈信息，如前文提到的DSN。

下面简单描述本申请可能涉及的到的收端接收到一个数据后的处理过程。收端可以在接收到数据包后将能够表示该数据包的信息(如标识，具体可以是SSN)管理起来，以便生成确认包时使用。由于每个子流在处理各自的数据包的过程是独立的，对每个子流都对应有用于存储接收到的数据包的信息的局部变量，例如，在从一子流收到一数据包后，对应于该子流的线程或进程使用该数据包的SSN更新该子流的局部变量，现有技术中，对应于每个子流分别使用各自的局部变量构造确认包；而对于本申请的确认包，需要携带两个子流最近接受到的数据包的信息，故对应于一子流的进程或者线程需要读取对应该子流局部变量中的值，以及对应另一子流的局部变量的值，确认包中将携带这两个值。另一方面，对于一个TCP连接，也会有一个变量来存储如DSN这样的对应TCP连接的接收到数据的信息，以便加入确认包，但是应理解，这个变量要在收端确定一数据以及该数据的DSN之前所有的数据都已接收的情况下，才会将该变量的值更新为该数据的DSN，在收端的传输层解析出一个数据分组的所有数据片段并按照顺序正确组装出该数据分组对应的数据后，将该数据上报应用层。这样,就可以在生成一个本申请涉及的确认包的过程中，将从多个子流上接收的数据的ACK信息(如SSN)加入确认包。

下面简单描述本申请可能涉及到的发端接收到一个确认包后的处理过程。在发端收到一个确认包后,经过解析可知确认包中携带的SSN和DSN，发端的协议栈可根据解析得到的信息进行以下处理：具体可以是根据确认包中携带的通过两个子流传输的数据的SSN确认这些SSN对应的数据已被成功接收,显然,这就可以确定哪条子流成功传输了哪些数据,而根据确认包中携带的DSN就可以确认在TCP连接级成功接收了该DSN对应的数据,也就是通过该TCP连接成功传输了什么数据。对本申请记载的方案，具体可以是将一子流收到的确认包中对应另一子流的数据的ACK信息(如SSN)提供给该另一子流对应的线程或进程，以便另一子流确认。再进一步的确认该报文中在TCP连接级别的标识，该标识表示在该标识例如DSN，也就是确认该TCP连接成功传输到哪个数据，应理解，DSN编号表示该DSN编号对应的数据以及该编号之前的数据都已被接收。再进一步的可以是将发端的发送缓存(sendbuffer)中已确定被成功接收的数据清空(例如当一个数据对应的所有数据分组都被接收后，清除这组数据片段)以及增大至少一个子流的拥塞窗口。应理解，一般一个TCP连接只有一个发送缓存，清除该发送缓存中的数据是根据连接级的标识，如DSN来操作的。对两个子流相互携带对方子流传输的数据包的ACK信息的情况，很明显，对质量差的路径上传输的数据的确认，改善效果更明显。

结合上文的描述,以发送端知道自己用的协议类型，但是不知道接收端的协议类型为例，简单描述一下一种实现方式下，本申请的技术方案涉及收端与发端之间的交互过程。

发送端发起建链过程，也就是三次握手。发端向收端发送建链请求，该建链请求包括MP_CAPABLE选项，选项的version的4个bit表示协议的版本号，例如若为0001则表示使用的是本申请涉及的改进后的协议版本，该协议支持多路径反馈机制。如果version为0000，则说明该协议不支持改进后的多路径反馈机制，则发送端和接收端的传输协议就使用现有的开源的MPTCP。

收端根据建链请求向发端返回带有MP_CAPABLE选项以及收端的密钥(key)的报文，其中，如果接收端也支持改进后的协议，那么发送的MP_CAPABLE的version赋值为0001。需理解的是，如果收端不支持该改进后的协议版本，version的值为其他，例如0000。

发送端根据收端的报文向收端发送一个携带MP_CAPABLE选项、收端密钥以及发端密钥的ACK。

MPTCP连接建立后的数据传输阶段。发端使用该MPTCP连接的多条子流传输数据，以及通过该多条子流接收确认包，如确认包。发送端收到子路径返回的确认包，在解析报文的过程中，检查报文头里的flag是否为01，如果为01则去解析ACK选项中第8-11个字节的内容，该第8-11个字节代表另一子流上数据包的反馈信息，即需要按照改进后的方案进行包，具体请参见上文。接收端收到子路径发送过来的数据包，需要在解析报文的过程中，检查报文头里的flag是否为01，如果为01，则在创建确认包的时候在第8-11个字节写入另一子流上数据包的反馈信息。

综上，参见图7，本申请记载一种基于通过发端与收端之间的多条路径进行数据传输方法，所述路径为所述发端与所述收端之间的链路，该方法包括：

S701：通过一多路径传输控制协议MPTCP连接中的多条路径，向所述MPTCP连接的收端发送多个数据包，所述多条路径包括第一路径和第二路径，所述多个数据包中的第一数据包是所述发端从所述第一路径发送的，所述第二数据包是所述发端从所述第二路径发送的。

其中的第一路径可以对应本申请提到的子流1，第二路径可对应本申请提到的子流2。

具体的，用于表示所述传输时延的参数包括带宽，往返时延RTT和丢包率中的至少一个。

S702：通过所述第一路径，接收来自所述发端的第一数据包；以及通过所述第一路径向所述发端发送第一确认ACK包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号，其中，所述第一路径的传输时延小于所述第二路径的传输时延

S703：发端还接收所述收端通过所述第一路径发送来的第一确认包。

其中，一种实现方式下，数据包的序列号包括该数据包的SSN。

显然，一种实现方式下，通过所述MPTCP连接中的第二路径，接收来自所述发端的第二数据包；所述第一确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第二数据包的序列号包括子流序列号SSN，

其中，所述第二数据包为在接收所述第一数据包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包；或者所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。例如，在下文的例子中，确认包3中携带的数据包2的SSN，确认包4中携带的数据包3的SSN，以及确认包5中携带的数据包3的SSN。

则，收端就根据所述第一数据包的序列号，增加所述第一路径的拥塞窗口；以及根据所述第二数据包的序列号，增加所述第二路径的拥塞窗口。

一种实现方式下，在收端第一次接收到所述第一数据包的反馈信息以及所述第二数据包的反馈信息的情况下，才根据所述第一数据包的序列号，增加所述第一路径的拥塞窗口；以及根据所述第二数据包的序列号，增加所述第二路径的拥塞窗口。

另一种实现方式下，收端发现该第二数据包丢失。所述第一确认包还包括丢包指示位，所述第一确认包的丢包指示位的值表示所述第一确认包携带丢失的数据包的信息，所述发端还用于根据所述第二数据包的序列号，通过所述第二路径，向所述收端重传所述第二数据包，所述第二数据包为在传输过程中丢失的数据包。收端根据所述第二数据包的序列号，通过所述第二路径，向所述收端重传所述第二数据包。

应理解，可以是所有携带两个数据包的序列号的确认包中都包括一个丢包指示位，其中，在一些确认包中，该丢包指示位置置第一值，该第一值表示这些确认包携带的两个数据包的序列号都是收端成功接收的数据包的序列号。而在另一些确认包中，该丢包指示位置置第二值，该第二值表示这些确认包携带的两个数据包的序列号中，有一个序列号是丢失的数据包。另一种情况下，也可以是只有在包括丢失的数据包的序列号的确认包中，才有该丢包指示位，如一个flag,可以是确认包中某特定的位被置了特定的值，该丢包指示位表示确认包中的一个序列号是丢失的数据包的序列号。例如可以参见下文对确认包的具体描述。

这样，传输时延较好的路径上传输的确认包中携带从两条路径传输的数据包的反馈信息，就可以使传输时延较好的路径帮助传输时延较差的路径传输反馈信息，使得发端更迅速地收到反馈信息。以及更快地做出反应，如重传或者增加拥塞窗口等。

可选的，该方法还包括收端在接收到所述第一数据包后，通过所述第二路径向所述发端发送第二确认包，所述第二确认包包括所述第一数据包的序列号和所述第二数据包的序列号。

这样，从任意一条路径接收到接收到一个报文，都可以使得两条路径发送确认包，且确认包中均携带该报文的反馈信息，能够更好地保障反馈信息传输到发端而不在发送过程中丢失。

更进一步的，该方法还包括根据从所述第二路径发送来的所述第五数据包，通过所述第一路径向所述发端发送第五确认包，所述第五确认包用于表示所述收端已接收所述第五数据包，所述第五确认包包括所述第五数据包的序列号。

该方法还包括在通过所述第一子流接收了三次所述第一数据包的反馈信息的情况下，通过所述第一子流向所述收端重传丢失的数据包。这样，就可以减少对丢包的误判。

图7和下文所述的方法，可以使用在传输多路径传输控制协议MPTCP的确认包系统中，该系统括收端和发端。收端和发端可以实现为例如图8和图9对应的装置或者设备。该确认包系统中可传输具有例如图5和图6所示的报文头的MPTCP报文。该系统中的收端和发端中的至少一个可以是终端或者网关或者云端的服务器或者服务器。另外，该系统具体的组网形式和传输形式、以及该系统中报文的生成和下发都可以参见本申请前文描述的内容和相关的附图。

下面描述几种实现方式下，两条子流间如何互相携带反馈信息(如数据包的序列号)。为了描述方便，以下几种实现方式都采用这样一种场景，一个TCP连接，收端和发端之间有两个TCP子流，为子流1和子流2，子流1的往返时延为RTT1，子流2的往返时延为RTT2。发端的发送缓存队列中存储着数据包1到数据包5(即设数据包1到数据包5的DSN为1到5)，发端向收端按顺序连续发送数据包1到数据包5，其中子流2传输数据3，设子流2的SSN编号为a,b,c,d,…，设数据3的SSN编号为a；子流1按顺序传送传输数据包1，数据包2，数据包4以及数据包5。应理解，该TCP连接还可以继续发送数据包6，数据包7等等，这里只是以数据包1到5进行举例说明。子流1的SSN编号为A，B，C，D…,数据包1，数据包2，数据包4以及数据包5的SSN编号为A，B，C，D。另一方面RTT1<RTT2,且若几个数据包的在该TCP连接中的编号(如DSN)相差不大，例如数据包2与数据包6，数据包3和数据包5等，则RTT对数据包传输时间的影响大于编号，即发端虽然先发送数据包3后发送数据包5，但数据包5的反馈消息先于数据包3。收端收到子流1发来的数据包1和数据包2，然后收到子流2发来的数据包3，最后收到子流1发来的数据4以及数据包5。应当理解，对于收端，一般是一收到数据包，做了必要的解析后就会立即生成确认包，以及将该报文发出，因此，一般收端先收到的报文的顺序与发送这些报文的反馈的顺序一致。上述5个数据包的确认包都会携带一个对应DSN的ACK信息，即data_ACK，以及用于表示该确认包所对应的数据包的SSN的ACK信息，即subflowX_ACK，其中X表示编号为X的子流，如subflow1_ACK表示编号为1的子流。

本申请实施例中，收端生成的一种经过改进的确认包，这种确认包携带生成该确认包时，从各自的子流已收到的数据包的信息；以及生成该确认包时，从另一条子流已收到的数据包的信息。例如，该另一子流的数据的标识是收端在生成该确认包时收到的最后一个从该另一子流传输来的数据的标识。该标识可以是子流序列号DSN。该另一子流子流1和子流2在回复确认包。这样，一个确认包中，就可以携带两条子流的反馈信息，例如可以是自两条，发端接收到一个确认包，可从中更多的反馈信息，从而确定更多的报文被接收，另外，这样也增加了反馈信息传输的次数，有利于更大概率地保障该反馈信息成功传输到发端。一种实现方式下，收端与现有技术一样，只在一子流收到数据包后生成该改进的确认包，以及，该改进的确认包仍然在收到该数据包的该子流上传输。

另外，需要理解的是，在一个确认包包括来自两条子流的数据包的信息的情况下，该确认包的格式相对于现有技术会作改变，改进的格式中会用不同的字段去携带触发该确认包的数据包在一子流中的标识(如SSN)，以及另一条子流上接收到的数据包在该子流中的标识，另外，该确认包中还会携带触发该确认包的数据包在该TCP连接中的标识，如DSN。故使用改进后的确认包后，一个确认包在连接级对应该DSN对应的数据包，而在子流级，由于一些确认包携带两个数据的反馈信息，而各子流确认自身子流数据包被成功传输的过程是独立的，这些确认包就对应两个数据包了。

例如以上述场景为例来描述，接收端按照接收到的数据包的顺序依次返回相应的确认包。设数据包1到数据包5对应的确认包为确认包1到确认包5。应理解，一种实现方式下，发端发送确认包m(1≤m≤5)，则意味着发端接收到了数据包1至数据包m中的每个报文。

也就是说，在连接级，数据包1对应的确认包1中，携带数据包1在子流1中对应的信息，例如数据包1的SSN，即subflow1_ACK(A)，这时收端还未通过子流2接收到数据，则确认包1中不携带通过子流2传输的数据包的信息。

在连接级，数据包2对应的确认包2中，携带数据包2在子流1中对应的信息，例如数据包2的SSN，即subflow1_ACK(B)，这时收端还未通过子流2接收到数据，则确认包2中不携带通过子流2传输的数据包的信息。

在连接级，数据包3对应的确认包3中，携带数据包3在子流2中对应的信息，例如数据包3的SSN，即subflow2_ACK(a)，这时收端已经通过子流1接收到数据包1和2，则确认包2中还携带有通过子流2传输的数据包的信息，由于数据包2是生成确认包3时(也是接收数据包3时)，子流1成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包，故携带的是数据包2的信息，例如数据包2的SSN，即subflow1_ACK(B)。故对子流1，数据包2对应确认包3，对子流2，数据包3对应确认包3。

在连接级，数据包4对应的确认包4中，携带数据包4在子流1中对应的信息，例如数据包4的SSN，即subflow1_ACK(C)，这时收端已经通过子流1接收到数据包1、数据包2以及数据包4，且通过子流2接收了数据包3，则确认包4中还携带有通过子流2传输的数据包的信息，也就是数据包3的信息，例如数据包3的SSN，即subflow2_ACK(a)。因为数据包3是生成确认包4时(也是接收数据包3时)，子流2成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。对子流1，数据包4对应确认包4，对子流2，数据包3对应确认包4。

在连接级，数据包5对应的确认包5中，携带数据包5在子流1中对应的信息，例如数据包5的SSN，即subflow1_ACK(D)，这时收端已经通过子流1接收到数据包1、数据包2以及数据包4和数据包5，且通过子流2接收了数据包3，则确认包2中还携带有通过子流2传输的数据包的信息，也就是数据包3的信息，例如数据包3的SSN，即subflow2_ACK(a)。因为数据包3是生成确认包5时(也是接收数包5时)，子流2成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。同理。对子流1，数据包5对应确认包5，对子流2，数据包3对应确认包5。

一种实现方式下，收端发送确认包的机制和现有技术类似，即收端在接收到数据包后,只会将生成的确认包从接收该数据包的子流向发端发送，即数据包从哪条子流发送过来，该数据包触发的确认包就只从该条子流发送回去。

为便于理解，以上文描述的场景为例，收端收到数据包1，则通过子流1发送确认包1；收到数据包2，则通过子流1发送确认包2；收到数据包3，则通过子流2发送确认包3；收到数据包4，则通过子流1发送确认包4；收到数据包5，则通过子流1发送确认包5。由于RTT1<RTT2,确认包5先于确认包3到达发端。

由于确认包5中携带了来自子流1的数据包5的信息，例如subflow1_ACK(D)，以及来自子流2的数据包3的信息，例如subflow2_ACK(a)。则发端收到确认包5，通过解析即可确认子流1收到了数据包5，子流2收到了数据包3，通过其中携带的DSN,可确认该TCP连接收到了数据包5。

这样一来，传输时延较好的子流1就帮助传输时延较差的子流2传输了子流2收到的数据包的反馈信息，例如上述场景中，现有技术要等到反馈数据包3已收到的报文被发端解析，发端才能确认数据包1到5都被接收了，而本申请方案则只要收到确认包5，就能够根据确认包5中数据包3和数据包5的信息确认数据包1到5都被接收了，也就是说，可以更快地让发端确认收端成功接收了一组数据，有助于发端能够更快地开始处理下一组数据，更好地利用了传输时延较好的子流的资源。

另一种实现方式下，一旦收端接收到数据包，不论该数据包来自哪条子流，收端在至少两条子流上发送该数据包的确认包，其中，一条为传输该数据包的子流。应理解，具体的实现方式下，总可以有一部分数据包的确认包也能在一条传输时延小于传输这些数据包的子流的子流中传输。这样，该子流的信息就可以利用传输时延更好的子流的网络资源，更快地传递该子流的反馈信息，且可以使确认包更大概率地传输到发端。一种具体的实现方式下，在收端与发端间有两条子流的情况下，收端接收到数据包，就在两条子流上都发送确认包，应理解，确认包是本申请中描述的改进的确认包，其中携带至少两个子流中数据包的信息，若TCP连接只有两条子流，则携带该两条子流中数据包的信息。

这种情况下，生成的确认包中可以定义一个字段，该字段的功能类似一个触发标识或者触发标记位，用于指示该确认包是由哪条子流传输来的报文所触发产生的。这样，发端就可以根据这个触发标识确定该确认包是否与触发产生该确认包的数据报文是通过同一子流传输的。例如，可以在确认包中预留1bit作为标记位，例如可以是报文中的reserved字段中的一个比特位。例如，在上述场景中，reserved字段中一位置0表示该确认包是由从子流1传输来的报文触发产生的，而置1表示该确认包是由从子流2传输来的报文触发产生的。例如，若reserved字段中比特位的标号是从第0位到第6位，则为其中第3位，若reserved字段中比特位的标号是从第1位到第7位，则为其中第4位。本发明实施例对该触发标识如何实现或者如何表示不做限制。

这样，不仅仅当一个子流中有数据包到达才能在该子流上传输确认包，而是任一条子流上有数据到达，都会触发在多条子流发送确认包，能够更大几率地使得传输时延较好的子流帮助传输时延较差的子流发送确认包，又由于确认包中携带了传输时延较差的子流中传输的数据包的信息，故能够加速这一部分反馈信息的传递。另一方面由于一个数据包的反馈信息至少会被携带在两个从不同子流发送的确认包中，故可以提高反馈信息传输的成功率，减少确认包丢包对发端确认反馈信息的影响。

具体的，以上述场景为例，收端从子流1接收到数据包1，则在子流1和子流2都发送确认包1，其中包括数据包1的信息，例如subflow1_ACK(A)。对接收到从子流1传输的数据包2,3,4,5，也类似的在子流1和子流2都发送相应的确认包。并且，由于收端接收数据包的顺序是数据包1到5，那么子流1和子流2上传输确认包的顺序也都是确认包1到确认包5。且由于RTT1＜RTT2，显然对同一数据包的确认包，子流1上传输的确认包比子流2上的更早到达发端。

可见，相比于前一种实现方式中收端首次收到数据包3的反馈信息是在子流1传输的确认包5，在这种实现方式下，收端可以在子流1中传输的确认包3就接收到数据包3的反馈信息，进一步地提前了发端接收数据包3的反馈信息。

另一方面，由于本申请提供的方案中，一个确认包会携带至少两个数据包的反馈信息，那么对于一个数据包，其反馈信息往往会携带在多个确认包中，发端会在多个确认包中重复解析出该数据包的反馈信息。如果按照现有技术，收端会重复处理这多次收到的反馈信息对应的数据(如将反馈信息对应的数据从发送缓存中清除等)，显然对发端的资源是一种浪费，也降低了处理效率。一种实现方式下，发端接收到一确认包后，会确认该确认包中包括的反馈信息对应的数据是否已被处理。也就是说，发端在处理过一数据包的反馈信息，之后再解析出到相同的反馈信息就不再处理。具体可以是，当发现该确认包中携带的SSN和DSN中任一标识对应的数据已被确认过，就忽略该确认过的标识对应的数据不再处理，具体可以是从一子流接收确认包中携带两个SSN，对应本子流的数据的SSN，如果已确认过收包，就增加对该子流SSN接收次数的计数，但不再次进行对该SSN对应的数据的确认收包以及确认该数据对应的DSN，在该子流确认收到三次该SSN的情况下，确定该SSN的后一个SSN对应的数据在传输中发生丢包；而对应另一个子流的数据的SSN，如果已将该SSN提供给过该另一子流对应的线程或者进程进行处理，则不再将收到该SSN的信息传递给该另一子流对应的线程或者进程，从而避免浪费资源和丢包误判。也就更不会根据该报文中的SSN和DSN去清除发送缓存和增加拥塞窗口了。

可见，在上述提到的各种实现方式中，利用传输时延较小的路径加速传输时延较大的路径的数据确认。一种情况下，传输时延较小的路径只携带一条传输时延较大的路径的数据包的信息。在收端接收到确认包后，收端通过解析可以知道至少两条链路传输的数据包的反馈信息，可以按照现有技术，收端从哪条子流上接收到确认包，就根据该报文中承载的从该条子流上发送的数据包的信息，增加该条子流的拥塞窗口(cwnd)的值，以及滑动拥塞窗口。例如，在上文所述的场景中，从子流1收到确认包4和确认包5，其中携带有来自子流1的数据包5的信息，以及来自子流2的数据包3的信息，发端可以根据数据包5的SSN得知从子流1又已成功传输了1个数据包，故增加子流1的拥塞窗口，例如增加一个segment,以及滑动子流1的拥塞窗口。例如滑动一个segment。但是并不会调整子流2的拥塞窗口。

而在一种实现方式中，在接收到的确认包中携带对应两个子流的数据包的信息情况下，调整该两个子流的拥塞窗口。具体为增大该两个子流的拥塞窗口，以及滑动该两个子流的拥塞窗口，即将该两个子流的拥塞窗口后移。一种实现方式下，收端通过一个确认包确定了几个报文已被接收，则根据这几个报文所携带的数据量，对该确认包涉及到的多个子流的拥塞窗口进行调整。

下面描述一种实现方式下，发端如何根据确认包中多条子流的信息调整拥塞窗口。可以类似前文对收端的局部变量，发端也可以给每个子流定义一局部变量，该变量可以保存在各子流的Socket中。该局部变量用于存储一子流接收到到确认包中对应本子流的数据在本子流的标识例如SSN，以及在每次接收到新的确认包，就根据新的确认包中携带的数据在各子流中的标识对多个子流的局部变量进行更新。收端的一个子流接收到确认包，在更新局部变量过程中，该子流根据确认包中携带的该子流SSN的值和该子流的局部变量中存储的值的差，增大该子流的拥塞窗口，该差值就是增大该子流的拥塞窗口的值，之后，将该子流的局部变量中存储的值更新为该确认包中携带的该子流SSN的值。另一方面，该子流会将对应另一子流的数据标识，如SSN传递给对应另一子流的进程或者线程。类似的，另一子流的进程或者线程根据该另一子流的SSN和该另一子流的局部变量的差，增大该子流的拥塞窗口，该差值就是增大该另一子流的拥塞窗口的值，之后，将该子流的局部变量中存储的值更新为该确认包中携带的该子流SSN的值。

例如，在上文所述的场景中，从子流1收到确认包4和确认包5，其中携带有来自子流1的数据包5的信息，以及来自子流2的数据包3的信息，发端可以根据数据包5的SSN得知从子流1又已成功传输了1个数据包，故增加子流1的拥塞窗口，例如增加一个片段(segment)，以及滑动子流1的拥塞窗口。并且，根据确认包5中的数据包3的SSN，增加子流1的拥塞窗口，例如将子流2的拥塞窗口增加1个片段(segment)，因为从数据包3的SSN可知子流2已成功传输一个数据包；以及滑动子流2的拥塞窗口。而此时，DSN对应数据包3的报文还并没有从子流2传输到发端，但发端却可以根据确认包5调整子流2的拥塞窗口，而现有技术中，确认包从哪条子流传输，发端就只能调整该条子流的拥塞窗口，能够更加快速和符合实际的报文传输情况地调整一个TCP连接的拥塞窗口。

这样，传输时延好的子流不但可以帮助传输时延差的子流传输反馈信息，还可以使得发端可以根据报文中多条子流的信息，调整多条子流的拥塞窗口，由于传输时延好的子流携带的反馈信息能使得发端更快速地确认传输时延差的子流传输报文的情况(例如上文中子流1的确认包5先于子流2的确认包3到达)，故使得对一个TCP连接，拥塞窗口能够更及时更符合实际传输情况地被增大，从而更好地利用网络的传输资源，提高链路的吞吐率。

另一方面，按照现有技术，发端会在多个确认包中重复解析出该数据包的反馈信息，还有可能带来丢包的误判，因为正如前文所说，对一个数据包，收到三次该数据包的反馈信息，即可认为该数据包后一个数据包未被收端成功接收。应理解，正如前文所描述的，发端会将待传输的数据进行切分，从而封装成一个个数据包，切分后的一组数据分组有序列号，该序列号往往是根据该数据片段的大小和在该数据中的位置确定的，例如，本文提及的DSN就有该序列号的功能。

因此，使用本申请记载的改进的报文，可以采用其他改进的方式来判断丢包。也就是收端只有在从该数据包发送的子流上接收到三次该数据包的反馈信息，如SSN，该重复的反馈信息又被称为重复反馈(dup ACK，即duplicate ACK)，才会确定该子流中发生丢失，而从其他子流上接收到的该数据包的反馈信息则不用于丢包判断。事实上，如果该子流已确认过该SSN对应的数据包收到，其他子流上接收到的反馈信息可以不传递给该子流，这样，在计算收到数据包的反馈信息的次数时，非发送该数据包的子流上接收的该数据包的反馈信息不计入。对应本子流的数据的SSN，如果已确认过收包，就增加对该子流SSN接收次数的计数，但不再次进行对该SSN对应的数据的确认收包以及确认该数据对应的DSN，在该子流确认收到三次该SSN的情况下，确定该SSN的后一个SSN对应的数据在传输中发生丢包；而对应另一个子流的数据的SSN，如果已将该SSN提供给过该另一子流对应的线程或者进程进行处理，则不再将收到该SSN的信息传递给该另一子流对应的线程或者进程，从而避免浪费资源和丢包误判。

例如，对上文中描述的数据包从哪条子流发送过来，该数据包触发的确认包就从该条子流发送回去的实现方式，显然可以根据确认包中携带的DSN以及SSN序号确定出该确认包是由哪个数据包触发发送的，自然也就可以明确发送该数据包的子流，这样就可以确定确认包中的哪个SSN序号要用来确定是否丢包。再例如，对上文中描述的接收到的数据包会触发至少两条子流发送确认包，就需要通过该确认包中传输字段来确认，该传输字段用于表示传输该报文的子流，例如是在报文的reserved字段中的某个比特(bit)。例如，若reserved字段中比特位的标号是从第0位到第6位，则为其中第2位，若reserved字段中比特位的标号是从第1位到第7位，则为其中第3位。在该例如以前文中的场景举例发端解析出字段reserved的值，为0则该确认包是由从子流1传输来的报文触发产生的，而置1表示该确认包是由从子流2传输来的报文触发产生的，再根据DSN以及SSN序号确定出该确认包是由哪个数据包触发发送的，从而明确发送该数据包的子流，这样就可以确定确认包中的哪个SSN序号要用来确定是否丢包。

另一种实现方式下，使用本申请记载的改进的报文，也可以采用其他改进的方式来判断丢包。收端可以在构造确认包的过程中，使用一个丢包指示信息来指示该确认包中携带了另一子流中传输过程中丢失的数据包的信息。例如，该丢包指示信息可以是定义的一个指示位，一种实现方式下可以是确认包的reserved字段中的某个字节，占1比特(bit)，例如，该字节置1表示该确认包中携带了另一子流丢的数据包的信息，也就是说，置1，则该确认包中携带的另一子流的数据包的信息，例如SSN，或者在本该携带另一子流的数据包信息的位置携带的数据包的信息，就是在另一子流丢失的数据包的信息，而携带该信息的字段是原改进的确认包中用于携带另一子流已传输的数据包的信息的字段。置0则不携带另一子流丢的数据包的信息，也就是说，该确认包中携带的另一子流的数据包的信息，例如SSN，就是前文所述的从另一子流传输成功的数据包的信息。

这是由于收端可以根据已收到的数据包的序列号(如SSN或者DSN)，判断是否有数据包在传输过程中丢失。一种实现方式下，在收端从一条子流接收到3个不是期望序列号的数据包的情况下，则认为该子流有数据包丢失，就可以在反馈信息中将中加入上述的1bit丢包指示信息。一种实现方式下，直到收端成功接收到重传的该丢失的数据包，该丢失的数据包的标识才不会再在确认包中携带。例如，在上述场景下，收端发现数据包3丢失，由于在收端发送确认包4和5时，还未收到重传的数据包3，则至少在确认包4以及确认包5中，携带数据包3的标识。

发端接收到确认包，判断丢包指示信息的标志位是否置1，在置1的情况下，根据携带的丢失的数据包的信息进行重传。

这样，由于确认包中可以携带另一条子流丢失的数据包的信息，传输时延较好的子流就可以帮助传输时延较差的子流更迅速地反馈丢包信息。使得发端能够更及时地根据丢包信息重传丢失的包。

需要说明的是，本申请描述的基于多路径传输控制协议MPTCP的报文反馈方法中，收端和发端中的至少一个都可以是终端，或者支持MPTCP协议的网关，或者支持MPTCP协议的服务器。应理解，在执行本发明实施例中所述的方法前，收端和发端应安装了支持MPTCP协议的操作系统以及微型端口的驱动。

需要说明的是，本发明实施例中，收端和发端通过接入节点接入网络。其中，接入节点专指无线网络的接入节点，具体的，可以是无线WI-FI网络的接入点(Access Point,AP)、路由器、或者Winmax网络的接入点或者无线蜂窝移动网络的基站等等，本发明不限定无线网络的种类以及无线网络的接入节点具体的形式。并且，同一类型的无线网络是指同属于无线WI-FI网络的接入节点，或者同属于Winmax网络，或者同属于无线蜂窝网络的接入节点如2G网络、3G网络或者4G网络或者5G网络等等。

图8描述了本发明实施例提供的装置的结构示意图，该装置包括接收单元801以及发送单元802。该装置的结构示意图表示一种通过发端与收端之间的多条路径进行数据传输的装置，所述路径为所述发端与所述收端之间的链路。具体可以表示一种多路径传输控制协议MPTCP确认包的发送装置的结构。这种情况下，该装置是一种多路径传输控制协议MPTCP确认包的发送装置。其中，接收单元801用于过一多路径传输控制协议MPTCP连接中的第一路径，接收来自所述发端的第一数据包；以及通过所述MPTCP连接中的第二路径，接收来自所述发端的第二数据包；发送单元802用于通过所述第一路径向所述发端发送第一确认ACK包，所述第一确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号，其中，所述第一路径的传输时延小于所述第二路径的传输时延。

这样，传输时延较好的路径上传输的确认包中携带从两条路径传输的数据包的序列号，就可以使传输时延较小的路径帮助传输时延较大的路径传输序列号，使得接收确认包的装置更好地收到反馈信息。

这种发送确认包的装置对应本申请记载的MPTCP连接的收端，该发送装置的其他实现方式、技术效果、以及在该装置为发送确认包的装置的情况下，接收单元和发送单元的其他功能，请参见前文(包括发明内容)的描述和解释，此处不再赘述。

另一种实现方式下，该装置是一种多路径传输控制协议MPTCP确认包的接收装置。其中发送单元802用于通过一多路径传输控制协议MPTCP连接中的多条路径，向收端发送多个数据包，所述多条路径包括第一路径和第二路径，其中，所述多个数据包中的第一数据包是所述发端从所述第一路径发送的，所述第二数据包是所述发端从所述第二路径发送的；接收单元801用于接收所述收端通过所述第一路径发送来的第一确认包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号其中所述第一路径的传输时延小于所述第二路径的传输时延。

这样，传输时延较小的路径上传输的确认包中携带从两条路径传输的数据包的反馈信息，就可以使传输时延较小的路径帮助传输时延较大的路径传输反馈信息，使得接收确认包的装置更迅速地收到反馈信息。

这种接收确认包的装置对应本申请记载的MPTCP连接的发端，该发送装置的其他实现方式、技术效果、以及在该装置为发送确认包的装置的情况下，接收单元和发送单元的其他功能，请参见前文(包括发明内容)的描述和解释，此处不再赘述。

图9描述了本发明实施例提供的装置的结构示意图，本发明实施例所述的方法适用于终设备900。该设备900包括：至少一个处理电路901，通信接口904，通信接口904包括至少一个物理网卡，这个物理网卡对应多个虚拟网卡，所述多个虚拟网卡与多个端口一一对应，图中未标出，存储介质905，至少一个通信总线902。通信总线902用于实现这些组件之间的连接通信。

一种实现方式下，该设备900可以是终端设备，在是终端设备的情况下，可选的包含用户接口903，包括显示器(例如，触摸屏、LCD、CRT、全息成像(Holographic)或者投影(Projector)等)，键盘或者点击设备(例如，鼠标，轨迹球(trackball),触感板或者触摸屏等)。存储介质905可以包括只读存储器和随机存取存储器，并向处理电路901提供指令和数据。存储介质905的一部分还可以包括非易失性随机存取存储器(NVRAM)。

在一些实施方式中，例如该设备为终端或服务器的情况下，存储介质905存储了如下的元素，可执行模块或者数据结构，或者他们的子集，或者他们的扩展集:操作系统9051，包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；应用程序模块9052，包含各种应用程序，例如桌面(launcher)、媒体播放器(Media Player)、浏览器(Browser)等，用于实现各种应用业务。而在该设备为网关的情况下，该存储介质905可以只存储用于执行上文所述的方法(例如包括接收或发送数据包，以及接收或发送确认包，以及接收到的数据包或分析接收到的确认包等)所需要的程序代码。

该设备可以是终端，网关或者服务器，具体的可以参见图1到图4中的信息，例如，该设备为终端的情况下，可以参见图2对应的终端架构图和相关说明。该设备可以通过处理电路901调用存储介质905中的程序，使得处理电路901通过通信接口904，执行上述图中的方法及实施例，例如可以是MPTCP连接的发端或者收端。具体的实现方式、相关说明和有益效果，请参见上文，此处不再赘述。例如，处理电路901通过通信接口904，可以实现图8所示的装置中的发送单元802和接收单元801的功能。例如，发送单元802和接收单元801可以是由不同的进程或者线程调用的通信接口。

本申请的另一个实施例还记载一种芯片。这种芯片可以放置在上文所述的收端，用于执行本申请中描述的方法，以解析和处理本申请上述方法中所述的改进的确认包。这种芯片还可以放置在上文所述的发端，用于执行本申请中描述的方法。例如是接收数据包后，生成本申请上述方法中所述的改进的确认包。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件(例如处理器)来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

以上为本发明实施例所提供的一种终端的数据传输方法和装置，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本发明的限制。

Claims (44)

1.一种的通过发端与收端之间的多条路径进行数据传输方法，所述路径为所述发端与所述收端之间的链路，其特征在于，所述方法包括：

所述收端通过一多路径传输控制协议MPTCP连接中的第一路径，接收来自所述发端的第一数据包；

通过所述MPTCP连接中的第二路径，接收来自所述发端的第二数据包；

通过所述第一路径向所述发端发送第一确认ACK包，所述第一确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号，其中，所述第一路径的传输时延小于所述第二路径的传输时延。

2.根据权利要求1所述的方法，其特征在于，所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在接收所述第一数据包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包；

或者所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

3.根据权利要求1或2所述的方法，其特征在于，所述传输时延通过带宽、往返时延RTT以及丢包率中的至少一个参数表示。

4.根据权利要求1到3任一所述的方法，其特征在于，所述方法还包括：

根据所述接收到的第一数据包，通过所述第二路径向所述发端发送第二确认包，所述第二确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第二确认包包括所述第一数据包的序列号和所述第二数据包的序列号。

5.根据权利要求1到4任一所述的方法，其特征在于，所述方法还包括：

通过所述第一路径，接收来自所述发端的第三数据包；

通过所述第一路径向所述发端发送第三确认包，所述第三确认包包括所述第三数据包的序列号，所述第三确认包用于表示所述收端已接收所述第三数据包，其中，所述第三确认包还包括丢包指示位以及第四数据包的序列号，所述第三确认包中的丢包指示位的值表示所述第三确认包携带丢失的数据包的信息，所述第四数据包是所述收端已确定的通过所述第二路径传输的丢失的数据包。

6.根据权利要求1到5任一所述的方法，其特征在于，所述方法还包括：

通过所述第二路径，接收来自所述发端的第五数据包；

根据从所述第二路径发送来的所述第五数据包，通过所述第一路径向所述发端发送第五确认包，所述第五确认包用于表示所述收端已接收所述第五数据包，所述第五确认包包括所述第五数据包的序列号。

7.根据权利要求1到6任一所述的方法，其特征在于，所述第一确认包还包括协议版本指示位，所述第一确认包中的协议版本指示位的值用于指示所述发端解析所述第二数据包的序列号。

8.根据权利要求1到7任一所述的方法，其特征在于，所述第一数据包的序列号包括所述第一数据包的数据序列号DSN和所述第一数据包的子流序列号SSN，所述第二数据包的序列号包括所述第二数据包的子流序列号SSN。

9.一种通过发端与收端之间的多条路径进行数据传输方法，所述路径为所述发端与所述收端之间的链路，其特征在于，所述方法包括：

所述发端通过一多路径传输控制协议MPTCP连接中的多条路径，向收端发送多个数据包，所述多条路径包括第一路径和第二路径，其中，所述多个数据包中的第一数据包是所述发端从所述第一路径发送的，所述第二数据包是所述发端从所述第二路径发送的；

接收所述收端通过所述第一路径发送来的第一确认包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号其中所述第一路径的传输时延小于所述第二路径的传输时延。

10.根据权利要求9所述的方法，其特征在于，所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在接收所述第一数据包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包；

或者所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

11.根据权利要求9或10所述的方法，其特征在于，所述传输时延通过带宽、往返时延RTT以及丢包率中的至少一个参数表示。

12.根据权利要求9到11任一所述的方法，其特征在于，所述方法还包括：

接收所述收端从所述第二路径发送来的第二确认包，所述第二确认包包括所述第一数据包的序列号和所述第二数据包的序列号。

13.根据权利要求9到12任一所述的方法，其特征在于，所述第一确认包表示所述收端已接收所述第一数据包和所述第二数据包，所述方法还包括：

根据所述第一数据包的序列号，增加所述第一路径的拥塞窗口；以及

根据所述第二数据包的序列号，增加所述第二路径的拥塞窗口。

14.根据权利要求9到12任一所述的方法，其特征在于，所述第一确认包还包括丢包指示位，所述第一确认包的丢包指示位的值表示所述第一确认包携带丢失的数据包的信息，所述方法还包括：

根据所述第二数据包的序列号，通过所述第二路径，向所述收端重传所述第二数据包，所述第二数据包为在传输过程中丢失的数据包。

15.根据权利要求9到14任一所述的方法，其特征在于，所述方法还包括：

在通过所述第一子流接收到三次所述第一数据包的序列号的情况下，通过所述第一子流向所述收端重传丢失的数据包。

16.根据权利要求9到15任一所述的方法，其特征在于，所述第一确认包还包括协议版本指示位，所述第一确认包中的协议版本指示位的值用于指示所述发端解析所述第二数据包的序列号。

17.根据权利要求9到16任一所述的方法，其特征在于，所述第一数据包的序列号包括所述第一数据包的数据序列号DSN和所述第一数据包的子流序列号SSN，所述第二数据包的序列号包括所述第二数据包的子流序列号SSN。

18.一种的通过发端与收端之间的多条路径进行数据传输的装置，所述路径为所述发端与所述收端之间的链路，其特征在于，所述装置包括：

接收单元，所述接收单元用于过一多路径传输控制协议MPTCP连接中的第一路径，接收来自所述发端的第一数据包；以及通过所述MPTCP连接中的第二路径，接收来自所述发端的第二数据包；

发送单元，所述发送单元用于通过所述第一路径向所述发端发送第一确认ACK包，所述第一确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号，其中，所述第一路径的传输时延小于所述第二路径的传输时延。

19.根据权利要求18所述的装置，其特征在于，所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在接收所述第一数据包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包；

或者所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

20.根据权利要求18或19所述的装置，其特征在于，所述传输时延通过带宽、往返时延RTT以及丢包率中的至少一个参数表示。

21.根据权利要求18到20任一所述的装置，其特征在于，所述发送单元还用于根据所述接收到的第一数据包，通过所述第二路径向所述发端发送第二确认包，所述第二确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第二确认包包括所述第一数据包的序列号和所述第二数据包的序列号。

22.根据权利要求18到21任一所述的装置，其特征在于，所述接收单元还用于通过所述第一路径，接收来自所述发端的第三数据包；

所述发送单元还用于通过所述第一路径向所述发端发送第三确认包，所述第三确认包包括所述第三数据包的序列号，所述第三确认包用于表示所述收端已接收所述第三数据包，其中，所述第三确认包还包括丢包指示位以及第四数据包的序列号，所述第三确认包中的丢包指示位的值表示所述第三确认包携带丢失的数据包的信息，所述第四数据包是所述收端已确定的通过所述第二路径传输的丢失的数据包。

23.根据权利要求18到22任一所述的装置，其特征在于，所述接收单元还用于通过所述第二路径，接收来自所述发端的第五数据包；

所述发送单元还用于根据从所述第二路径发送来的所述第五数据包，通过所述第一路径向所述发端发送第五确认包，所述第五确认包用于表示所述收端已接收所述第五数据包，所述第五确认包包括所述第五数据包的序列号。

24.根据权利要求18到23任一所述的装置，其特征在于，所述第一数据包的序列号包括所述第一数据包的数据序列号DSN和所述第一数据包的子流序列号SSN，所述第二数据包的序列号包括所述第二数据包的子流序列号SSN。

25.一种通过发端与收端之间的多条路径进行数据传输的装置，所述路径为所述发端与所述收端之间的链路，其特征在于，所述装置包括：发送单元，所述发送单元用于通过一多路径传输控制协议MPTCP连接中的多条路径，向收端发送多个数据包，所述多条路径包括第一路径和第二路径，其中，所述多个数据包中的第一数据包是所述发端从所述第一路径发送的，所述第二数据包是所述发端从所述第二路径发送的；

接收单元，所述接收单元用于接收所述收端通过所述第一路径发送来的第一确认包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号其中所述第一路径的传输时延小于所述第二路径的传输时延。

26.根据权利要求25所述的装置，其特征在于，所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在接收所述第一数据包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包；

或者所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

27.根据权利要求25或26所述的装置，其特征在于，其中，所述传输时延通过带宽、往返时延RTT以及丢包率中的至少一个参数表示。

28.根据权利要求25到27任一所述的装置，其特征在于，所述接收单元还用于接收所述收端从所述第二路径发送来的第二确认包，所述第二确认包包括所述第一数据包的序列号和所述第二数据包的序列号。

29.根据权利要求25到28任一所述的装置，其特征在于，所述第一确认包表示所述收端已接收所述第一数据包和所述第二数据包，所述装置还包括拥塞窗口调整单元，所述拥塞窗口调整单元用于根据所述第一数据包的序列号，增加所述第一路径的拥塞窗口；以及

根据所述第二数据包的序列号，增加所述第二路径的拥塞窗口。

30.根据权利要求25到28任一所述的装置，其特征在于，所述第一确认包还包括丢包指示位，所述第一确认包的丢包指示位的值表示所述第一确认包携带丢失的数据包的信息，所述发送单元还用于根据所述第二数据包的序列号，通过所述第二路径，向所述收端重传所述第二数据包，所述第二数据包为在传输过程中丢失的数据包。

31.根据权利要求25到30任一所述的装置，其特征在于，所述发送单元还用于在通过所述第一子流接收到三次所述第一数据包的序列号的情况下，通过所述第一子流向所述收端重传丢失的数据包。

32.一种发送确认包的设备，所述其特征在于，所述设备包括：处理电路、通信接口和存储介质，所述存储介质中存储有协议栈程序，所述通信接口用于通过执行所述协议栈程序与其他设备收发数据包，所述处理器用于通过运行所述存储介质中的指令通过所述通信接口，以实现权利要求1到8所述的通过发端与收端之间的多条路径进行数据传输方法，所述路径为所述发端与所述收端之间的链路，所述设备为所述收端。

33.根据权利要求32所述的设备，其特征在于，所述设备为终端。

34.一种接收确认包的设备，其特征在于，所述设备包括：处理电路、通信接口和存储介质，所述存储介质中存储有协议栈程序，所述通信接口用于通过执行所述所述协议栈程序与其他设备收发信息，所述处理器用于通过运行所述存储介质中的指令通过所述通信接口，以实现权利要求9到17所述的通过发端与收端之间的多条路径进行数据传输方法，所述路径为所述发端与所述收端之间的链路，所述设备为所述发端。

35.根据权利要求34所述的设备，其特征在于，所述设备为终端。

36.一种的通过发端与收端之间的多条路径进行数据传输的系统，其特征在于，所述系统包括发端和收端，所述发端用于通过一多路径传输控制协议MPTCP连接中的多条路径，向所述MPTCP连接的收端发送多个数据包，所述多条路径包括第一路径和第二路径，所述多个数据包中的第一数据包是所述发端从所述第一路径发送的，所述第二数据包是所述发端从所述第二路径发送的；

所述收端用于通过所述第一路径，接收来自所述发端的第一数据包；以及通过所述第一路径向所述发端发送第一确认ACK包，所述第一确认包包括所述第一数据包的序列号和第二数据包的序列号，其中，所述第一路径的传输时延小于所述第二路径的传输时延；

所述发端还用于接收所述收端通过所述第一路径发送来的第一确认包。

37.根据权利要求36所述的系统，其特征在于，其特征在于，所述传输时延通过带宽、往返时延RTT以及丢包率中的至少一个参数表示。

38.根据权利要求36或37所述的系统，其特征在于，所述收端还用于通过所述MPTCP连接中的第二路径，接收来自所述发端的第二数据包；所述第一确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第二数据包的序列号包括子流序列号SSN，

其中，所述第二数据包为在接收所述第一数据包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包；或者所述第二数据包的序列号包括子流序列号SSN，所述第二数据包为在生成所述第一确认包时，所述收端通过所述第二路径成功接收的一系列子流序列号连续的数据包中，子流序列号最大的数据包。

39.根据权利要求38所述的系统，其特征在于，所述收端还用于根据所述接收到的第一数据包，通过所述第二路径向所述发端发送第二确认包，所述第二确认包用于表示所述收端已接收所述第一数据包和所述第二数据包，所述第二确认包包括所述第一数据包的序列号和所述第二数据包的序列号。

40.根据权利要求38或39所述的系统，其特征在于，所述发端还用于根据所述第一数据包的序列号，增加所述第一路径的拥塞窗口；以及根据所述第二数据包的序列号，增加所述第二路径的拥塞窗口。

41.根据权利要求36或37所述的系统，其特征在于，所述第一确认包还包括丢包指示位，所述第一确认包的丢包指示位的值表示所述第一确认包携带丢失的数据包的信息，所述发端还用于根据所述第二数据包的序列号，通过所述第二路径，向所述收端重传所述第二数据包，所述第二数据包为在传输过程中丢失的数据包。

42.根据权利要求36或37所述的系统，其特征在于，所述发端还用于在通过所述第一子流接收了三次所述第一数据包的序列号的情况下，通过所述第一子流向所述收端重传丢失的数据包。

43.根据权利要求36或37所述的系统，其特征在于，所述收端还用于根据从所述第二路径发送来的所述第五数据包，通过所述第一路径向所述发端发送第五确认包，所述第五确认包用于表示所述收端已接收所述第五数据包，所述第五确认包包括所述第五数据包的序列号。

44.一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得所述计算机执行如权利要求1至8或者权利要求9到17中任一项所述的方法。