基于TCP的数据传输方法和TCP代理装置

摘要

本发明提供了一种基于TCP的数据传输方法和TCP代理装置，其中，基于TCP的数据传输方法包括：TCP代理接收本端的接入层发送的通知消息；TCP代理根据通知消息中携带的可用数据传输资源的数据长度的信息，按照TCP分组的序号，顺序从缓存的TCP分组中选择至少一个TCP分组发送给接入层，选择TCP分组的长度总和小于等于可用数据传输资源的数据长度，且，选择的各个TCP分组的序号小于或等于本端的TCP层当前连续已发或待发的TCP分组的最大序号值加一；TCP代理针对发送给接入层的TCP分组构造确认报文，并反馈给TCP层。通过本发明，避免了长期演进网络中无线链路不稳定性对传输控制协议分组数据传输的影响。

说明书

技术领域

本发明涉及通信技术领域，特别是涉及一种长期演进(Long TimeEvolution，LTE)网络下的基于传输控制协议(Transmission Control Protocol，TCP)的数据传输方法和传输控制协议代理装置。

背景技术

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC793定义，包括排序、重复包丢弃、丢包重传、流控制和拥塞控制等主要功能。

在LTE网络中使用TCP进行数据传输时，TCP为数据负载的每一个字节都编上序号。当数据发送端(本端)发出一个TCP报文时，会将该报文数据负载的第一个字节序号填入首部的SEQ字段；同时，数据接收端(对端)在收到一个TCP报文后，会将当前它已连续接收的最大字节序号加1填入ACK字段，并将该值填入一个确认包中反馈给数据发送端。TCP报文的数据发送端始终能够根据本端已发送报文的SEQ信息，以及收到的对端ACK信息，计算出当前已发出而未确认的数据字节总量(称之为空中数据)。TCP报文的数据发送端维护着一个发送窗口的变量，并始终保持空中数据量小于等于发送窗口大小。

在数据传输过程中，TCP通过发送窗口值的调整来实现流量控制和拥塞控制两大功能。其中，对于流量控制，TCP报文的数据发送端根据TCP报文的数据接收端返回的反馈包中的WIN字段获悉数据接收端的接收缓存剩余空间(被称为通告窗口)，并与本端的空中数据量进行比较，如果空中数据量达到通告窗口大小，则暂时不再发送数据(否则可能会造成对端接收缓存溢出)，一直等到空中数据量减少(由于反馈的ACK值更新)或者通告窗口增大(由于反馈的WIN值变大)才会发送新传报文。在实际TCP业务中，通告窗口的最大值不应该设置得很小，即不能够使接收缓存大小成为速率的瓶颈，因为在稳定状态下数据传输的平均速率等于窗口值除以往返时延(Round-Trip Time，RTT)。

TCP报文的数据发送端还维护着一个被称为拥塞窗口CWND的相关变量，这个拥塞窗口和通告窗口的最小值就是TCP报文的数据发送端的发送窗口值。CWND会随着反馈包ACK信息的更新而不断增大，一开始CWND值很小，并以二次方的指数方式快速增大，此阶段为慢启动状态；当增大到一定门限时，CWND按照线性方式增大，此阶段为拥塞避免状态。另一方面，如果TCP报文的数据发送端判断遇到了重传事件，则认为网络中发生了拥塞，就需要收缩拥塞窗口即减慢发送速率以缓解拥塞。

TCP拥塞控制是在传统以太网络中很重要的一种机制，TCP协议认为在以太网络中，造成丢包和乱序的原因是拥塞，即TCP发送窗口过大速率过高，超过了网络链路中间设备的缓存而造成丢包。然而在LTE网络环境中，物理信道波动普遍存在，即便在良好的物理信道环境下，丢包和乱序现象也时有发生，这并不是由于速率过高产生拥塞，而是由于LTE链路的不可靠性导致的。因此，传统以太网络中的TCP拥塞控制机制并不适用于LTE网络，在LTE网络环境波动导致出现丢包乱序时，使用传统以太网络中的TCP拥塞控制机制会导致不适当的触发TCP的拥塞窗口收缩，进而影响LTE网络中的数据传输。

发明内容

本发明提供了一种基于传输控制协议的数据传输方法和传输控制协议代理装置，以解决传统以太网络中的传输控制协议拥塞控制在长期演进网络环境波动导致出现丢包乱序情况下，导致不适当的触发传输控制协议的拥塞窗口收缩，进而影响长期演进网络中的数据传输的问题。

为了解决上述问题，本发明公开了一种基于传输控制协议的数据传输方法，包括：传输控制协议代理接收本端的长期演进接入层发送的通知消息；所述传输控制协议代理根据所述通知消息中携带的可用数据传输资源的数据长度的信息，按照传输控制协议分组的序号，顺序从缓存的传输控制协议分组中选择至少一个传输控制协议分组发送给所述接入层，其中，选择的所述至少一个传输控制协议分组的长度总和小于或等于所述可用数据传输资源的数据长度，且，选择的各个所述传输控制协议分组的序号小于或等于本端的传输控制协议层当前连续已发或待发的传输控制协议分组的最大序号值加一；所述传输控制协议代理针对发送给所述接入层的所述传输控制协议分组构造确认报文，并将所述确认报文反馈给向所述传输控制协议代理发送传输控制协议分组的传输控制协议层。

为了解决上述问题，本发明还公开了一种基于传输控制协议的传输控制协议代理装置，所述装置包括：接收模块，用于接收本端的长期演进接入层发送的通知消息；选择发送模块，用于根据所述通知消息中携带的可用数据传输资源的数据长度的信息，按照传输控制协议分组的序号，顺序从缓存的传输控制协议分组中选择至少一个传输控制协议分组发送给所述接入层，其中，选择的所述至少一个传输控制协议分组的长度总和小于或等于所述可用数据传输资源的数据长度，且，选择的各个所述传输控制协议分组的序号小于或等于本端的传输控制协议层当前连续已发或待发的传输控制协议分组的最大序号值加一；反馈模块，用于针对发送给所述接入层的所述传输控制协议分组构造确认报文，并将所述确认报文反馈给向所述传输控制协议代理装置发送传输控制协议分组的传输控制协议层。

与现有技术相比，本发明具有以下优点：

本发明的数据传输方案中，利用传输控制协议代理来优化端到端传输控制协议的性能。传输控制协议代理根据长期演进接入层发送的通知消息，获取可用数据传输资源的数据长度的信息；进而，根据该可用数据传输资源的数据长度，按照一定的规则从缓存中选择传输控制协议分组发送给长期演进接入层；并且，在发送传输控制协议分组的报文后，构造并向传输控制协议层反馈确认报文。传输控制协议代理针对发出的传输控制协议分组构造并向本端的传输控制协议层发送相应的确认报文，使得本端的传输控制协议层认为所发出的传输控制协议分组总是被对端正确的接收，从而使传输控制协议层发送窗口始终保持增长的态势，并且稳定连续地将数据发送到传输控制协议代理，从而避免了长期演进网络中无线链路不稳定性对传输控制协议分组数据传输的影响，使得移动终端在进行各种数据传输业务时，传输性能能够达到系统带宽的极限，解决了传统以太网络中的传输控制协议拥塞控制在长期演进网络环境波动导致出现丢包乱序情况下，导致不适当的触发传输控制协议的拥塞窗口收缩，进而影响长期演进网络中的数据传输的问题。

附图说明

图1是根据本发明实施例一的一种基于TCP的数据传输方法的步骤流程图；

图2是根据本发明实施例二的一种基于TCP的数据传输方法的步骤流程图；

图3是根据本发明实施例三的一种基于TCP的数据传输方法的步骤流程图；

图4是根据本发明实施例五的一种基于TCP的传输控制协议代理装置的结构框图；

图5是根据本发明实施例六的一种基于TCP的传输控制协议代理装置的结构框图；

图6是使用本发明的数据传输方案的FTP上下行业务速率效果图；

图7是使用本发明的数据传输方案的IperfTCP上下行业务速率效果图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

为便于描述，本发明实施例中，使用SND表示TCP(传输控制协议)层当前连续已发或待发的TCP分组的最大序号值加一，使用RCV表示TCPAgent(传输控制协议代理)从TCP层接收到的TCP分组的最大序号值加一，使用UNA表示已被TCP分组接收端连续确认的TCP分组的最大序号值，使用WIN表示TCP分组接收端反馈的ACK报文(确认报文)中的win字段值，即通告窗口大小。

实施例一

参照图1，示出了根据本发明实施例一的一种基于TCP的数据传输方法的步骤流程图。

本实施例的基于TCP的数据传输方法包括以下步骤：

步骤S102：TCPAgent接收本端的LTE接入层发送的通知消息。

其中，所述通知消息中携带有可用数据传输资源的数据长度的信息。

步骤S104：TCPAgent根据通知消息中携带的可用数据传输资源的数据长度的信息，按照TCP分组的序号，顺序从缓存的TCP分组中选择至少一个TCP分组发送给所述接入层。

其中，选择的至少一个TCP分组的长度总和小于或等于可用数据传输资源的数据长度，且，选择的各个TCP分组的序号小于或等于本端的SND(即TCP层当前连续已发或待发的TCP分组的最大序号值加一)。

例如，LTE网络中，每当接入层使用PUSCH(物理上行共享信道)上行空口资源之后，会发给TCPAgent一个通知，该通知的内容中包含有可用数据传输资源的数据长度的信息，TCPAgent根据该长度从缓存中选择若干TCP分组发给接入层。

步骤S106：TCPAgent针对发送给所述接入层的TCP分组构造确认报文(如ACK报文)，并将所述确认报文反馈给向TCPAgent发送TCP分组的TCP层。

在一个包含若干TCP分组的TCP报文发给接入层之后，TCPAgent需要针对该报文中的最后一个TCP分组构造一个确认报文回复给本端的TCP层，以通知TCP层该TCP报文已被正确接收而可以正常增长发送窗口，该确认报文的确认字段值与所发TCP分组的最大序号值加1相等。

通过上述过程，使得TCPAgent回复确认报文的速率与LTE带宽相一致，这能使本端TCP窗口稳步增长。一方面，本端数据的立即响应有利于窗口的快速增大，但另一方面缓存数据量的不断加大使得所缓存报文被发出的时机越来越迟，即本端观测到的RTT越来越大，从而减缓了窗口增长的速度。这正反两方面因素达到合理的平衡点，与LTE的带宽速率最终相统一。

通过本实施例，利用TCPAgent来优化端到端TCP的性能。TCPAgent根据LTE接入层发送的通知消息，获取可用数据传输资源的数据长度的信息；进而，根据该可用数据传输资源的数据长度，按照一定的规则从缓存中选择TCP分组发送给LTE接入层；并且，在发送TCP分组的报文后，构造并向TCP层反馈确认报文。TCPAgent针对发出的TCP分组构造并向本端的TCP层发送相应的确认报文，使得本端的TCP层认为所发出的TCP分组总是被对端正确的接收，从而使TCP层发送窗口始终保持增长的态势，并且稳定连续地将数据发送到TCPAgent，从而避免了LTE网络中无线链路不稳定性对TCP分组数据传输的影响，使得移动终端在进行各种数据传输业务时，传输性能能够达到系统带宽的极限，解决了传统以太网络中的TCP拥塞控制在LTE网络环境波动导致出现丢包乱序情况下，导致不适当的触发TCP的拥塞窗口收缩，进而影响LTE网络中的数据传输的问题。

实施例二

参照图2，示出了根据本发明实施例二的一种基于TCP的数据传输方法的步骤流程图。

本实施例的数据传输方法包括以下步骤：

步骤S202：TCPAgent接收本端TCP层发送的TCP分组。

在本发明实施例中，本端TCP层不是直接将TCP分组发送给对端，而是首先发送给本端的TCPAgent进行缓存。

步骤S204：TCPAgent判断TCP层发送的TCP分组的序号是否与TCPAgent已缓存的TCP分组的序号重复；若重复，则执行步骤S206；若不重复，则执行步骤S208。

通过判断接收的TCP分组的序号是否与已缓存的TCP分组重复，可以避免TCP分组的重复缓存，减轻缓存负担和占用空间。

步骤S206：若TCP层发送的TCP分组的序号与TCPAgent已缓存的TCP分组的序号重复，则丢弃该TCP分组，转步骤S210执行。

步骤S208：若TCP层发送的TCP分组的序号与TCPAgent已缓存的TCP分组的序号不重复，则TCPAgent缓存该TCP分组，转步骤S210执行。

步骤S210：TCPAgent接收本端的LTE接入层发送的通知消息。

其中，所述通知消息中携带有可用数据传输资源的数据长度的信息，可用数据传输资源的数据长度可以通过多种方式设定，一种优选方式为：由接入层根据设定次数的发送TCP分组使用的资源均值和设定的放大系数确定。

也即，TCPAgent接收LTE接入层发送的、携带了发送TCP分组的可用数据传输资源的数据长度的信息的通知消息；其中，可用数据传输资源的数据长度由所述接入层根据设定次数的发送TCP分组使用的资源均值和设定的放大系数确定。但不限于此，其它设定可用数据传输资源的数据长度的方式也同样适用，如，根据发送通知消息时的实际可用数据传输资源的数据长度设定等。而由接入层根据设定次数的发送TCP分组使用的资源均值和设定的放大系数确定，一方面可以灵活地适应资源变化情况，另一方面也能够为传输TCP分组提供充足的传输资源。

步骤S212：TCPAgent根据通知消息中携带的可用数据传输资源的数据长度的信息，按照TCP分组的序号，顺序从缓存的TCP分组中选择至少一个TCP分组发送给LTE接入层。

其中，选择的至少一个TCP分组的长度总和小于或等于可用数据传输资源的数据长度，且，选择的各个TCP分组的序号小于或等于本端的SND。

一般情况下，可用数据传输资源能够传输一至多个TCP分组，此时，该一至多个TCP分组的数据长度总和应小于或等于可用数据传输资源的数据长度。

但需要说明的是，在某些情况下，有可能出现待传输的TCP分组的数据长度大于可用数据传输资源的数据长度的情况，也即，可用数据传输资源的数据长度小于该TCP分组的数据长度，此时，则选择序号最小的TCP分组发送给LTE接入层。为有效处理这种情况，优选地，在步骤S210之后，即：TCPAgent接收本端的LTE接入层发送的通知消息之后，TCPAgent还可以判断可用数据传输资源的数据长度是否小于缓存的TCP分组中序号最小的TCP分组的长度；若是，则选择序号最小的TCP分组发送给LTE接入层；若否，则执行本步骤S212，即，TCPAgent根据可用数据传输资源的数据长度的信息，按照TCP分组的序号，顺序从缓存的TCP分组中选择至少一个TCP分组发送给LTE接入层。通过这种处理，避免了某个数据长度较大的TCP分组长时间无法得到传输资源，提高了数据传输效率。

步骤S214：TCPAgent针对发送给接入层的TCP分组构造确认报文，并将所述确认报文反馈给向TCPAgent发送TCP分组的TCP层。

其中，TCPAgent针对发送给接入层的TCP分组构造确认报文可以采用以下方式。

方式一：

当TCPAgent从缓存的TCP分组中选择了多个TCP分组时，TCPAgent针对发送给所述接入层的TCP分组构造确认报文的步骤包括：TCPAgent仅针对多个TCP分组中的最后一个TCP分组构造纯确认报文。

其中，纯确认报文中的确认字段值等于多个TCP分组中的最后一个TCP分组的序号值加一；对于纯确认报文中的窗口字段值，当RCV与UNA的差大于或等于TCP分组接收端的通告窗口值时，即RCV－UNA>＝WIN时，所述纯确认报文中的窗口字段值设置为0，以通知TCP层暂停向TCPAgent发送TCP分组；反之，所述纯确认报文中的窗口字段值为TCP接收端的通告窗口值WIN。

方式二：

不管TCPAgent从缓存的TCP分组中选择了一个还是多个TCP分组，TCPAgent均可针对发送给所述接入层的每个TCP分组构造纯确认报文。

其中，所述纯确认报文中的确认字段值等于与所述纯确认报文相对应的TCP分组的序号值与该TCP分组的长度之和再加一；对于所述纯确认报文中的窗口字段值，当RCV与UNA的差大于或等于TCP分组接收端的通告窗口值WIN时，所述纯确认报文中的窗口字段值设置为0，以通知TCP层暂停向TCPAgent发送TCP分组；反之，所述纯确认报文中的窗口字段值为TCP分组接收端的通告窗口值。

优选地，本实施例还提供了针对TCP分组接收端发送的捎带确认报文的处理方案。为此，TCPAgent中还设置有捎带确认报文计数器，该捎带确认报文计数器用于对向TCP层透传TCP分组接收端的捎带确认报文的次数计数，则在步骤S214的TCPAgent将确认报文反馈给向TCPAgent发送TCP分组的TCP层的步骤之后，还包括：TCPAgent接收到TCP分组接收端发送的捎带确认报文；判断缓存中是否存在待发送的TCP分组；若存在，且捎带确认报文计数器的计数值为3时，则构造纯确认报文，将该纯确认报文的确认字段值设置为所述缓存中的当前连续已发或待发的传输控制协议分组的最大序号值加一，向TCP层发送该纯确认报文并透传该捎带确认报文，将捎带确认报文计数器置0；若不存在，则透传该捎带确认报文，将捎带确认报文计数器加1。

在此基础上，为了提高确认报文构造效率，优选地，在TCPAgent针对发送给LTE接入层的每个TCP分组构造纯确认报文的步骤之前，还包括：判断是否已为当前TCP分组构造过纯确认报文；若已构造过，则不再为当前传输控制协议分组构造的纯确认报文。未构造过，才进行纯确认报文构造。

上述捎带确认报文(即捎带ACK报文)的处理极大地减小了修改每一个捎带ACK数据包带来的巨大开销。采用修改数据的方案带来的开销，主要是对每一个报文都重新计算并修改TCP校验和，这需要对整个数据内容进行遍历和数值计算，CPU消耗极大。而采用本方案，报文无需修改，也不是每一个捎带ACK都会触发纯ACK的构造，更重要的是即使构造纯ACK，因为纯ACK字节少且大部分内容使用的是保存的数据模板，CPU消耗极小。

通过本实施例，可以使TCP分组发送端的TCP层发送窗口始终保持增长的态势，并且稳定连续地将数据发送到TCPAgent，从而避免了LTE网络中无线链路不稳定性对TCP分组数据传输的影响，使得移动终端在进行各种数据传输业务时，传输性能能够达到系统带宽的极限。

实施例三

参照图3，示出了根据本发明实施例三的一种基于TCP的数据传输方法的步骤流程图。

本实施例着重从冗余确认报文(如冗余ACK报文)处理方面对本发明的数据传输方案进行说明，其它部分请参照前述实施例的相应部分，本实施例中不再进行详细描述。

本实施例的基于TCP的数据传输方法包括以下步骤：

步骤S302：TCPAgent接收本端TCP层发送的TCP分组。

步骤S304：TCPAgent判断TCP层发送的TCP分组的序号是否与TCPAgent已缓存的TCP分组的序号重复；若重复，则执行步骤S306；若不重复，则执行步骤S308。

步骤S306：若TCP层发送的TCP分组的序号与TCPAgent已缓存的TCP分组的序号重复，则丢弃该TCP分组，转步骤S310执行。

步骤S308：若TCP层发送的TCP分组的序号与TCPAgent已缓存的TCP分组的序号不重复，则TCPAgent缓存该TCP分组，转步骤S310执行。

步骤S310：TCPAgent接收本端的LTE接入层发送的通知消息。

步骤S312：TCPAgent根据通知消息中携带的可用数据传输资源的数据长度的信息，按照TCP分组的序号，顺序从缓存的TCP分组中选择至少一个TCP分组发送给LTE接入层。

步骤S314：TCPAgent针对发送给接入层的TCP分组构造确认报文，并将所述确认报文反馈给向TCPAgent发送TCP分组的TCP层。

步骤S316：TCPAgent接收TCP分组接收端反馈的确认报文。

步骤S318：TCPAgent判断当前接收到的所述反馈的确认报文中的确认字段值是否大于本端当前记录的UNA；若是，则执行步骤S320，若否，则执行步骤S322。

步骤S320：TCPAgent将本端当前记录的UNA更新为当前收到的所述反馈的确认报文中的确认字段值，并将TCP分组的序号值小于更新后的UNA的所有TCP分组删除，转步骤S324执行。

步骤S322：TCPAgent将重传计数器加1，并且，当重传计数器达到3时，确定发生确认报文冗余事件，根据反馈的确认报文确定冗余类型，根据确定的冗余类型进行TCP分组重传，并在重传后将重传计数器清0。

其中，根据反馈的确认报文确定冗余类型，根据确定的冗余类型进行TCP分组重传的步骤包括：

确定反馈的确认报文为选择性确认报文(即SACK报文)，且，该选择性确认报文指示TCP分组接收端接收的TCP分组发生乱序或丢包，则将TCPAgent缓存的、UNA与SND之间的、除该选择性确认报文指示的已被TCP分组接收端接收到的TCP分组之外的所有TCP分组重传给TCP分组接收端；

或者，

确定反馈的确认报文为选择性确认报文(即SACK报文)，且，该选择性确认报文指示TCP分组接收端接收的TCP分组发生重复，则不做处理；

或者，

确定反馈的确认报文为确认报文(即ACK报文)，且，该确认报文指示TCP分组接收端接收的TCP分组发生丢包，则将TCPAgent缓存的、该确认报文中的确认字段值至SND之间的所有TCP分组重传给TCP分组接收端。

SACK报文是目前TCP常用的一种新增特性(RFC2018/2883)，SACK报文的相关字段位于反馈包的TCP首部选项中，通过SACK报文能够将重复和乱序这两种情况反映出来。对于重复情况，SACK报文的序号范围沿是重复报文的序号范围且小于ACK字段值，ACK不应被当做冗余ACK被处理因为它并不对应着乱序或丢包。对于乱序情况，SACK的序号范围是ACK字段值之后已经连续接收到的一个或多个报文对应的序号范围，此ACK是一个冗余ACK。借助于SACK报文，能够从冗余ACK中筛选掉由重复包引发的情况，减少由此产生的不必要的重传；也能够明确指示需要重传的范围，有利于无线带宽的利用率。通过上述对SACK报文的支持处理，能够让重传范围控制在更为精确的序号区间。

假如LTE系统的空中接口有报文丢失发生，则该报文之后的窗口内连续报文会触发大量冗余ACK事件。为了减少不必要的重传规模，在第一次较激进的重传策略之后，如果继续发生在同一UNA值上的冗余ACK事件，则采取保守的重传策略，即仅仅重传UNA值对应的一个TCP分组。

也即，一种优选方案为，在确定发生确认报文冗余事件之后，根据所述反馈的确认报文确定冗余类型，根据确定的冗余类型进行TCP分组重传之前，还可以包括：

判断确认报文冗余事件是否是发生在UNA上的首次冗余事件；

若是首次冗余，则将TCPAgent缓存的、UNA与SND之间的、除所述选择性确认报文指示的已被TCP分组接收端接收到的TCP分组之外的所有TCP分组重传给TCP分组接收端(针对SACK报文)；或者，则将TCPAgent缓存的、确认报文中的确认字段值至SND之间的所有TCP分组重传给TCP分组接收端(针对ACK报文)；

若不是首次冗余，则仅重传UNA加一后对应的TCP分组。

步骤S324：TCPAgent判断上述反馈的确认报文的类型；若反馈的确认报文为纯确认报文，则丢弃；若反馈的确认报文为捎带确认报文，则将捎带确认报文透传至TCP层。

也即，TCPAgent在根据反馈的确认报文确定冗余类型，根据确定的冗余类型进行上述的TCP分组重传之后，最后还要对该反馈的确认报文进行后续处理，包括：判断反馈的确认报文的类型；若反馈的确认报文为纯确认报文，则丢弃；若反馈的确认报文为捎带确认报文，则将捎带确认报文透传至TCP层。

通过本实施例，在使TCP分组发送端的TCP层发送窗口始终保持增长的态势，并且稳定连续地将数据发送到TCPAgent，避免了LTE网络中无线链路不稳定性对TCP分组数据传输的影响，使得移动终端在进行各种数据传输业务时，传输性能能够达到系统带宽的极限的基础上，针对冗余报文进一步提供了处理方案，不仅能够让重传范围控制在更为精确的序号区间，而且减少了不必要的重传规模。

在TCP数据传输过程中，还需要对连接进行维护，对其它一些相关报文进行支持，因此，在上述实施例一至实施例三的方案的基础上，本发明进一步提供了包括对连接进行监测和对其它相关报文进行处理的连接维护方案。

该连接维护方案可以包括以下至少之一：

(1)针对结束报文(即FIN报文)

包括：TCPAgent确定接收到TCP层的结束报文，则进入本地关闭状态，丢弃所述结束报文之后收到的TCP层发送的TCP分组，并且，将缓存的所有剩余TCP分组发送给TCP分组接收端且被TCP分组接收端确认后，将所述结束报文发送给TCP分组接收端；

或者，

TCPAgent确定接收到TCP分组接收端发送的结束报文，则将所述结束报文透传给TCP层。

(2)针对复位报文(即RST报文)

包括：TCPAgent确定接收到复位报文，则立即清空TCPAgent缓存的所有TCP分组，并将所述复位报文透传给TCP层。

(3)针对窗口探测报文

包括：TCPAgent在针对发送给LTE接入层的TCP分组构造确认报文之后，当确定接收到TCP层发送的窗口探测报文；则构造纯确认报文回复TCP层，并丢弃所述窗口探测报文，其中，构造的纯确认报文的确认字段值为SND，窗口字段值为0。

(4)针对连接监测

包括：TCPAgent确定维护的对TCP分组接收端连接进行监控的分钟量级监控定时器超时，则立即清空TCPAgent缓存的所有TCP分组，并构造复位报文透传给TCP层和TCP分组接收端。

通过上述报文处理，使得本发明的TCP代理对TCP连接的维护方案更为完善，通过上述的连接监测，能够使TCPAgent能够长期稳定的工作。

实施例四

本实施例以具体实例的形式，对本发明的基于TCP的数据传输方案进行说明。

本实施例在终端中设置了TCPAgent，对终端的TCP协议进行代理，它可以部署于终端的LTE AS之上。这个TCPAgent能够针对本端TCP层发出的数据包构造相应的ACK应答包(即确认报文)，使得本端的TCP层认为所发出的数据包总是被对端正确的接收，从而使TCP发送窗口始终保持增长的态势并且稳定连续地将数据包发到TCPAgent。对于对端的TCP，这个TCPAgent将来自本端TCP层的报文缓存，并根据对端的ACK/SACK(确认报文/选择性确认报文)反馈信息，去判断一个已缓存报文是否已经被收到或需要被重传。TCPAgent还能够拦截来自对端的纯ACK(纯确认报文)以及放行携带数据负载的捎带ACK(捎带确认报文)。

此外，本实施例还提供了流量控制机制，以避免仅仅按照上述实现，有可能发生的本端TCP层源源不断地发出数据包并超出了TCPAgent或者LTE的缓存能力而造成大量的拥塞丢包的情况。本实施例中采用的流控机制，是通过LTE当前的缓存量来逐渐增大TCPAgent回复ACK的时延，当LTE缓存量越大，TCPAgent越迟回复所构造的ACK。最终达到平衡时，本端TCP的窗口大小与LTE缓存报文量相一致。

本实施例从多个方面分别对本发明的数据传输方案进行说明，在此之前，本实施例中设定：

RCV：该值记录着TCPAgent当前从本端TCP层已接收到的TCP分组的最大序号值加1；

SND：该值记录着本端TCP层当前连续的已发或待发的TCP分组的最大序号值加1，SND之前的报文序号都是TCPAgent层已缓存的连续序号范围；

UNA：该值记录着已经被对端连续确认的TCP分组的最大序号值；

WIN：该值记录着对端ACK中的win字段值，即通告窗口大小。

本实施例的数据传输的业务逻辑都是基于一条TCP连接的，每一条TCP连接都维护着上面的一系列参数。

以下，从不同方面对本实施例的数据传输方案进行说明，包括：

(1)TCPAgent接收到本端TCP层新传数据的流程：

在此过程中TCPAgent需要进行一些检查，包括：冗余检查，即检查该新传数据是否与已有的一个已缓存报文的TCP序号范围(通过序号字段和负载长度字段判断)是否完全重复；和/或，交叠检查，类似于冗余检查，针对的是TCP序号范围与已缓存报文有局部重复的情况，当新达报文的序号范围能够被已缓存的若干报文的序号范围完全覆盖时，也认为该报文重复。被判定重复的报文会被丢弃，即既不缓存也不发给对端。

对于非重复报文，TCPAgent会将其缓存在本地，但并不立即递交给LTEAS发出，这个操作需等待AS的通知。如果该报文连续，则更新SND值。

(2)TCPAgent发包指示流程：

发包指示指的是AS发送给TCPAgent的通知消息，如每当AS使用PUSCH上行空口资源之后，会发给TCPAgent一个通知，该通知的内容包含了最近若干次(比如50次，可调整)的上行资源均值再乘以一个放大系数，表示为数据长度的形式。TCPAgent根据该长度从缓冲中选择若干TCP分组发给AS，选取规则如下：

(A)这些TCP分组的长度总和不超过通告数据长度；

(B)该TCP分组序号范围不超过SND值。

在一个TCP分组报文发给AS之后，需要针对该报文构造一个纯ACK回复给本端TCP层，以通知其该报文已被正确接收而可以正常增长发送窗口，该ACK报文的ack字段值与所发数据报文的最大序号值加1相等。在构造ACK时，可以采用类似于TCP的DelayedACK机制，即减少纯ACK报文数，对一次发包指示中选取的多个TCP分组报文，仅针对对于最后一个分组报文构造纯ACK。

所构造的纯ACK中的win字段值，一般情况下直接采用WIN值即可。因为发端发出的数据量可能超出win字段值造成对端本地缓存拥塞丢包，所以当RCV-UNA>＝WIN，即潜在的空中数据量总和占满通告窗口时，TCPAgent进入zero-win状态。在此状态下收到的所有新传数据，在构造ACK时需要将win字段值设置为0，以通知本端暂停发包。

(3)TCPAgent接收到对端报文的流程：

TCPAgent首先解析对端报文中的首部信息：对ACK和SACK的解析，需要将ack字段值以及多个SACK分段中的选择性确认序号区间记录下来；对win字段解析，总是将字段值记录到本地WIN变量中。

对于非冗余ACK的正常情况(即ACK大于UNA)，则报文中必不包含SACK丢包信息，此时将UNA值更新为ACK。同时，要将新旧UNA值之间覆盖到的所有TCP分组进行删除(考虑到存在交叠的分组，故须要某分组的SN全部范围都落入应删除范围，才能删除)

对于连续冗余ACK的事件，包含如下几种情形：

A).非SACK报文：在同一个UNA值上发生了连续三次重复的ACK，认为此UNA处发生了丢包，将从UNA到SND之间的所有TCP分组(但总数不超过Nretx个，Nretx值可调整，比如20个)全部重传给对端。

B).SACK重复报文：该类型报文表示对端声称收到了一个已经连续接收的重复分组，对于此情况什么都不处理。

C).SACK乱序/丢失报文：该类型报文表示对端声称收到了一个未连续接收的分组，当在同一个UNA值上连续发生三次之后，将从UNA到SND之间的并且处于SACK声称分组之外的所有分组(也不超过Nretx个)全部重传给对端。

假如空中接口有报文丢失发生，则该报文之后的窗口内连续报文会触发大量冗余ACK事件。为了减少不必要的重传规模，在第一次较激进的重传策略之后，如果继续发生在同一UNA值上的冗余ACK事件，则采取保守的重传策略，即仅仅重传UNA值对应的一个TCP分组。

当TCPAgent处于zero-win状态时，并且UNA的更新使得RCV-UNA<WIN时，则进入正常状态。此时需要构造一个纯ACK报文，其中ack字段为SND值，win字段则是WIN值。该报文通知本端重新恢复已暂停的发包流程。

最后针对该报文的后续处理：若该报文是纯ACK则会被丢弃；如果该报文是携带数据负载的捎带ACK，则不修改报文的任何内容直接透传给本端TCP层。

(4)连接维护：

如果TCPAgent收到本端的FIN报文，则进入本地关闭状态。该状态下将丢弃之后收到的任何本地新传数据(即位于RCV之后的数据)，并且要一直把缓存中的所有数据全部被对端确认接收之后，才将该FIN报文发给对端。如果收到对端的FIN报文，则将该FIN报文透传给本端TCP层即可。

TCPAgent不管在哪一端上收到了RST报文，立即清空该报文对应的本地缓存，并透传该报文。

除了正常的连接关闭流程，为了增强本发明的健壮性，TCPAgent需要对连接进行监测。

TCPAgent维护一个对端连接监控定时器(时长可配，在分钟量级)，每当收到对端的任何报文时重启该定时器。如果该定时器超时则认为与对端的连接断开，此时会清空该连接对应的本地缓存，并且构造RST报文发给本端与对端。

在长期处于zero-win的情况下，TCPAgent有可能会收到本端TCP层发送的窗口探测包，其中包含了长度为1的数据。针对该报文立刻构造ACK进行回复，其中ack字段为SND值，win字段为0。

(5)TCPAgent对捎带ACK的特殊处理：

当TCPAgent接受到对端的捎带ACK，是不修改该报文内容的，但因为在有数据缓存时，该ACK值必定是小于当前已回复的最大ACK值，即SND，所以这个捎带ACK必定会被认为是一个冗余ACK。针对这种情况，本方案提出了一种特殊处理。首先维护一个计数器，计数值在透传一个捎带ACK会加一，在完成一次(2)中的纯ACK流程会重置为0。当该计数值达到3时，即表明此次透传操作将会触发本端TCP层的快速恢复算法。此时如果发送缓存中有待发数据，则需要在透传之前构造一个纯ACK，该纯ACK的ack字段值，采用发送缓存中SND值对应的第一个报文的数据最大序号值加1。如果发送缓存没有数据，说明没有业务，无需构造纯ACK。

另外如果发生了以上纯ACK的构造，那么当以后(2)中的流程再需要构造相同ack字段值的纯ACK时，就不需要再构造了。

通过本实施例，提供了一种提高LTE系统中TCP数据传输性能的方案，该方案通过避免无线链路不稳定性对TCP传输协议的影响，从而使得TCP业务的传输性能能够达到系统带宽的极限。

为了简化本方案的实现复杂度，可以将TCPAgent部署于LTE系统内部，作为LTE系统软件的一部分放置在AS之上，或者，将TCPAgent放在PC侧终端网口驱动之中，以在性能上引入的额外开销可以集中到系统资源更加充裕的PC系统中。

通过本方案中的TCPAgent发包指示机制，使得TCPAgent回复ACK的速率与LTE带宽相一致，这能使本端TCP窗口稳步增长。一方面，本端数据的立即响应有利于窗口的快速增大，但另一方面缓存数据量的不断加大使得所缓存报文被发出的时机越来越迟，即本端观测到的RTT越来越大，从而减缓了窗口增长的速度。这正反两方面因素达到合理的平衡点，与LTE的带宽速率最终相统一。

通过本方案中的TCPAgent对捎带ACK的特殊处理，极大地减小了修改每一个捎带ACK数据包带来的巨大开销。采用修改数据的方案带来的开销，主要是对每一个报文都重新计算并修改TCP校验和，这需要对整个数据内容进行遍历和数值计算，CPU消耗极大。而采用本方案，报文无需修改，也不是每一个捎带ACK都会触发纯ACK的构造，更重要的是即使构造纯ACK，因为纯ACK字节少且大部分内容使用的是保存的数据模板，CPU消耗极小。

通过本方案中的TCPAgent通过zero-win状态避免了空中数据量超过通告窗口的情况出现；通过对SACK机制的支持能够让重传范围控制在更为精确的序号区间；对通过连接的监控能让TCPAgent能够长期稳定的工作。

实施例五

参照图4，示出了根据本发明实施例五的一种基于TCP的TCPAgent(传输控制协议代理)装置的结构框图。

本实施例的基于TCP的TCPAgent装置用于在TCP数据传输中的TCP代理，该装置包括：

接收模块402，用于接收本端的LTE AS层发送的通知消息；

选择发送模块404，用于根据通知消息中携带的可用数据传输资源的数据长度的信息，按照TCP分组的序号，顺序从缓存的TCP分组中选择至少一个TCP分组发送给所述AS层，其中，选择的至少一个TCP分组的长度总和小于或等于所述可用数据传输资源的数据长度，且，选择的各个TCP分组的序号小于或等于本端的SND；

反馈模块406，用于针对发送给所述AS层的TCP分组构造确认报文，并将所述确认报文反馈给向TCPAgent装置发送TCP分组的TCP协议层。

通过本实施例的TCPAgent装置，针对发出的TCP分组构造并向本端的TCP层发送相应的确认报文，使得本端的TCP层认为所发出的TCP分组总是被对端正确的接收，从而使TCP层发送窗口始终保持增长的态势，并且稳定连续地将数据发送到TCPAgent装置，从而避免了LTE网络中无线链路不稳定性对TCP分组数据传输的影响，使得移动终端在进行各种数据传输业务时，传输性能能够达到系统带宽的极限，解决了传统以太网络中的TCP拥塞控制在LTE网络环境波动导致出现丢包乱序情况下，导致不适当的触发TCP的拥塞窗口收缩，进而影响LTE网络中的数据传输的问题。

实施例六

参照图5，示出了根据本发明实施例六的一种基于TCP的实施例六装置的结构框图。

本实施例的基于TCP的TCPAgent装置用于在TCP数据传输中的TCP代理，可设置于LTE系统内部的AS层之上，或者，将TCPAgent装置放在PC侧终端网口驱动装置之中。

本实施例的TCPAgent装置包括：

接收模块502，用于接收本端的LTE AS层发送的通知消息；

选择发送模块504，用于根据通知消息中携带的可用数据传输资源的数据长度的信息，按照TCP分组的序号，顺序从缓存的TCP分组中选择至少一个TCP分组发送给所述AS层，其中，选择的至少一个TCP分组的长度总和小于或等于所述可用数据传输资源的数据长度，且，选择的各个TCP分组的序号小于或等于本端的SND；

反馈模块506，用于针对发送给所述AS层的TCP分组构造确认报文，并将所述确认报文反馈给向TCPAgent装置发送TCP分组的TCP层。

优选地，本实施例的TCPAgent装置还包括：

判断模块508，用于在接收模块502接收本端的LTE AS层发送的通知消息之后，判断所述可用数据传输资源的数据长度是否小于所述缓存的TCP分组中序号最小的TCP分组的长度；

所述选择发送模块504，用于若判断模块508的判断结果为是，则选择所述序号最小的TCP分组发送给所述AS层；若判断模块508的判断结果为否，则根据所述可用数据传输资源的数据长度的信息，按照TCP分组的序号，顺序从缓存的TCP分组中选择至少一个TCP分组发送给所述AS层。

优选地，当选择发送模块504从缓存的TCP分组中选择了多个TCP分组时，所述反馈模块506，用于仅针对所述多个TCP分组中的最后一个TCP分组构造纯确认报文，以及，将构造的纯确认报文反馈给向TCPAgent装置发送TCP分组的TCP层；

其中，

所述纯确认报文中的确认字段值等于所述最后一个TCP分组的序号值加一；

当RCV与UNA的差大于或等于TCP分组接收端的通告窗口值时，所述纯确认报文中的窗口字段值设置为0，以通知TCP层暂停向TCPAgent装置发送TCP分组；反之，所述纯确认报文中的窗口字段值为TCP分组接收端的通告窗口值。

优选地，反馈模块506，用于针对发送给所述AS层的每个TCP分组构造纯确认报文，并将构造的所述纯确认报文反馈给向TCPAgent装置发送TCP分组的TCP层；

其中，

所述纯确认报文中的确认字段值等于与所述纯确认报文相对应的TCP分组的序号值与该TCP分组的长度之和加一；

当RCV与UNA的差大于或等于TCP分组接收端的通告窗口值时，所述纯确认报文中的窗口字段值设置为0，以通知TCP层暂停向TCPAgent装置发送TCP分组；反之，所述纯确认报文中的窗口字段值为TCP分组接收端的通告窗口值。

优选地，本实施例的TCPAgent装置中设置有捎带确认报文计数器，用于对向TCP层透传TCP分组接收端的捎带确认报文的次数计数；

所述TCPAgent装置还包括：

捎带确认报文处理模块510，用于在反馈模块506将所述确认报文反馈给向TCPAgent装置发送TCP分组的TCP层之后，接收到TCP分组接收端发送的捎带确认报文；判断缓存中是否存在待发送的TCP分组；若存在，且所述捎带确认报文计数器的计数值为3时，则构造纯确认报文，将该纯确认报文的确认字段值设置为所述缓存中的当前连续已发或待发的TCP分组的最大序号值加一，向TCP层发送该纯确认报文并透传所述捎带确认报文，将所述捎带确认报文计数器置0；若不存在，则透传所述捎带确认报文，将所述捎带确认报文计数器加1。

优选地，本实施例的TCPAgent装置还包括：

报文判断模块512，用于在反馈模块506针对发送给所述AS层的每个TCP分组构造纯确认报文之前，判断是否已为当前TCP分组构造过纯确认报文；若已构造过，则不再为当前TCP分组构造的纯确认报文。

优选地，接收模块502，用于接收所述AS层发送的、携带了发送TCP分组的可用数据传输资源的数据长度的信息的通知消息；其中，所述可用数据传输资源的数据长度由所述AS层根据设定次数的发送TCP分组使用的资源均值和设定的放大系数确定。

优选地，本实施例的TCPAgent装置还包括：

重复判断模块514，用于在接收模块502接收本端的LTE AS层发送的通知消息之前，判断TCP层发送的TCP分组的序号是否与TCPAgent装置已缓存的TCP分组的序号重复；若重复，则丢弃该TCP分组；若不重复，则缓存该TCP分组。

优选地，本实施例的TCPAgent装置还包括：

第一确认报文处理模块516，用于在反馈模块506将所述确认报文反馈给向TCPAgent装置发送TCP分组的TCP层之后，接收TCP分组接收端反馈的确认报文；判断当前接收到的所述反馈的确认报文中的确认字段值是否大于本端当前记录的UNA；若是，则将本端当前记录的UNA更新为当前收到的所述反馈的确认报文中的确认字段值，并将TCP分组的序号值小于更新后的UNA的所有TCP分组删除；若否，则将重传计数器加1，并且，当重传计数器达到3时，确定发生确认报文冗余事件，根据所馈的确认报文确定冗余类型，根据确定的冗余类型进行TCP分组重传，并在重传后将重传计数器清0。

优选地，第一确认报文处理模块516在根据反馈的确认报文确定冗余类型，根据确定的冗余类型进行TCP分组重传时：

确定反馈的确认报文为选择性确认报文，且，所述选择性确认报文指示TCP分组接收端接收的TCP分组发生乱序或丢包，则将TCP代理缓存的UNA与SND之间的、除所述选择性确认报文指示的已被TCP分组接收端接收到的TCP分组之外的所有TCP分组重传给TCP分组接收端；

或者，

确定反馈的确认报文为选择性确认报文，且，所述选择性确认报文指示TCP分组接收端接收的TCP分组发生重复，则不做处理；

或者，

确定反馈的确认报文为确认报文，且，所述确认报文指示TCP分组接收端接收的TCP分组发生丢包，则将TCPAgent装置缓存的、所述确认报文中的确认字段值至SND之间的所有TCP分组重传给TCP分组接收端。

优选地，本实施例的TCPAgent装置还包括：

保守重传模块518，用于在第一确认报文处理模块516确定发生确认报文冗余事件之后，根据反馈的确认报文确定冗余类型，根据确定的冗余类型进行TCP分组重传之前，判断确认报文冗余事件是否是发生在UNA上的首次冗余事件；

若是首次冗余，则将TCPAgent装置缓存的、UNA与SND之间的、除所述选择性确认报文指示的已被TCP分组接收端接收到的TCP分组之外的所有TCP分组重传给TCP分组接收端，或者，则将TCPAgent装置缓存的、所述确认报文中的确认字段值至SND之间的所有TCP分组重传给TCP分组接收端；

若不是首次冗余，则仅重传UNA加一后对应的TCP分组。

优选地，本实施例的TCPAgent装置还包括：

第二确认报文处理模块520，用于在第一确认报文处理模块516根据反馈的确认报文确定冗余类型，根据确定的冗余类型进行TCP分组重传之后，判断反馈的确认报文的类型；若反馈的确认报文为纯确认报文，则丢弃；若反馈的确认报文为捎带确认报文，则将捎带确认报文透传至TCP层。

优选地，本实施例的TCPAgent装置还包括：

第一连接维护模块(图中未示出)，用于确定接收到TCP层的结束报文，则进入本地关闭状态，丢弃结束报文之后收到的TCP层发送的TCP分组，并且，将缓存的所有剩余TCP分组发送给TCP分组接收端且被TCP分组接收端确认后，将结束报文发送给TCP分组接收端；

或者，

用于确定接收到TCP分组接收端发送的结束报文，则将结束报文透传给TCP层。

优选地，本实施例的TCPAgent装置还包括：

第二连接维护模块(图中未示出)，用于确定接收到复位报文，则立即清空TCPAgent装置缓存的所有TCP分组，并将复位报文透传给TCP层。

优选地，本实施例的TCPAgent装置还包括：

第三连接维护模块(图中未示出)，用于确定维护的对TCP分组接收端连接进行监控的分钟量级监控定时器超时，则立即清空TCPAgent装置缓存的所有TCP分组，并构造复位报文透传给TCP层和TCP分组接收端。

优选地，本实施例的TCPAgent装置还包括：

第四连接维护模块(图中未示出)，用于在反馈模块506针对发送给所述AS层的TCP分组构造确认报文之后，确定接收到TCP层发送的窗口探测报文；构造纯确认报文回复TCP层，并丢弃窗口探测报文，其中，构造的纯确认报文的确认字段值为SND，窗口字段值为0。

本实施例的TCPAgent装置用于实现前述多个方法实施例中相应的基于TCP的数据传输方法中的TCPAgent的功能，并具有相应的有益效果，在此不再赘述。

通过本发明的TCPAgent，终端设备的LTE网口速率能够立刻达到与LTE带宽的理论上限，而LTE网络不稳定性造成的速率波动不会对网口速率产生影响。使用本发明的TCPAgent进行FTP和Iperf TCP两种场景进行上下行业务速率对比分别如图6和图7所示。

其中，图6是FTP上下行业务速率对比效果图，在图6中，未使用本发明的TCPAgent的平均速率是下行60.2+上行5.68mbps，使用本发明的TCPAgent的平均速率是下行60.5+上行15.4mbps。

图7是IperfTCP上下行业务速率对比效果图，在图7中，未使用本发明的TCPAgent的平均速率是下行47.1+上行9.08mbps，使用本发明的TCPAgent的平均速率是下行53.4+上行15.3mbps。

从图6和图7中可以看出，传统的TCP数据传输业务尤其是上行业务存在非常明显抖动，这严重影响了均值速率的表现，而通过本发明的方案，有效减少了业务抖动，提高了均值速率。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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