CN101369877B - 无线传输控制协议处理方法和设备 - Google Patents
无线传输控制协议处理方法和设备 Download PDFInfo
- Publication number
- CN101369877B CN101369877B CN2008102120500A CN200810212050A CN101369877B CN 101369877 B CN101369877 B CN 101369877B CN 2008102120500 A CN2008102120500 A CN 2008102120500A CN 200810212050 A CN200810212050 A CN 200810212050A CN 101369877 B CN101369877 B CN 101369877B
- Authority
- CN
- China
- Prior art keywords
- tcp
- ack
- transmitting terminal
- tcp transmitting
- receiving terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明实施例提供一种无线传输控制协议处理方法和设备。该方法包括：判断需要加速所述TCP接收端和TCP发送端之间的数据发送；对所述TCP接收端向所述TCP发送端发送的响应包ACK或重复响应包DupACK进行处理并发送给所述TCP发送端，以加速所述TCP接收端和TCP发送端之间的数据发送。通过使用本发明的实施例，缩短了TCP发送端慢启动所持续的时间，加速恢复了TCP发送端的数据发送能力。
Description
技术领域
本发明涉及通信技术领域，尤其涉及一种无线传输控制协议处理方法和设备。
背景技术
TCP(Transmission Control Protocol，传输控制协议)协议是为有线网络设计的一种在主机间实现高可靠性的包交换传输协议，是面向连接的端到端的协议。基于TCP协议的传输过程中，TCP接收端向TCP发送端发送ACK(响应包)用于对接收到的一组TCP分组包进行确认操作，表示当前以及之前的TCP分组包都被正确接收。当发生报文乱序(报文顺序错位或报文丢失)时，TCP接收端生成DupACK(重复响应包)并向TCP发送端发送，DupACK的个数由乱序报文个数决定。
在目前的无线移动网络中，仍会使用TCP协议进行数据传输，但是由于无线网络固有的特性，如时变的信道条件、不对称的带宽、传输往返时延大、误码高且抖动大，为有线网络而设计的TCP协议无法很好的应用于无线领域。
虽然当前WCDMA(Wideband Code Division Multiple Access，宽带分码多工存取)***的RNC(Radio Network Controller，无线网络控制器)/RLC(RadioLink Control，无线链路控制)协议层能够通过PDU(Protocol Data Unit，协议数据单元)重传来保证数据的完整性，但是仍然不可避免地使得TCP发送端发生超时而进入慢启动。TCP发送端发生超时的原因为：TCP发送端每发送一个分组包，就为该分组包启动一个计时器，当计时器超时但仍未收到TCP接收端对该分组包的ACK时则发生超时。TCP发送端进入慢启动后，发送窗口减到了初始值(通常为2个报文大小)，需要多个RTT(Round Trip Time，往返时间)时间才能恢复到发生慢启动之前的发送窗口值，如果有线侧时延和无线侧时延均较大，即RTT较大，那么意味着需要很长的时间，TCP发送端才能恢复到 慢启动之前的发送能力。TCP发送端一旦进入慢启动，网络中的数据量马上减少，在单线程下载时，RLC(Radio Link Control，无线链路控制)缓存将通常发生排空，并直接导致部分空口资源空闲。而实际的瞬时吞吐量也将出现低值甚至为0，此外端到端RTT越大，低值持续时间就越长，当然文件下载时间也将越长。
发明人在实现本发明的过程中，发现现有技术至少存在以下缺点：
在TCP发送端判断发生分组包丢失后，将进入慢启动阶段并立即减小发送窗口的大小。慢启动阶段的持续时间与以下因素有关：当从TCP接收端接收到一定数量的ACK时，脱离慢启动阶段进入拥塞避免阶段。或在接收到TCP接收端发送的一定数量(通常为3个)的DupACK时，进入快速重传阶段。但是如果端到端时延较大，则TCP接收端不能及时的将DupACK或ACK发送到TCP发送端，那么TCP发送端将长时间的处于慢启动阶段，这将降低TCP数据传输的性能。
发明内容
本发明实施例提供一种无线传输控制协议处理方法和设备，用于缩短TCP发送端慢启动所持续的时间，加速恢复TCP发送端的数据发送能力。
本发明的实施例提供一种无线传输控制协议TCP处理方法，应用于TCP发送端与TCP接收端间的代理，包括：
TCP发送端进入慢启动时，判断需要加速所述TCP接收端和TCP发送端之间的数据发送；
对所述TCP接收端向所述TCP发送端发送的响应包ACK进行处理，包括：
接收到TCP接收端向TCP发送端发送的响应包ACK，对所述ACK进行***；
将所述ACK***成多个ACK并向所述TCP发送端发送。
本发明的实施例提供一种无线传输控制协议TCP处理方法，应用于TCP发送端与TCP接收端间的代理，其特征在于，包括：
TCP发送端进入慢启动时，判断需要加速所述TCP接收端和TCP发送端之间的数据发送；
所述对TCP接收端向所述TCP发送端发送的重复响应包DupACK进行处理，包括：
创建DupACK或复制从所述TCP接收端接收的DupACK；
将所述创建或复制的DupACK向所述TCP发送端发送。
本发明的实施例还提供一种代理功能实体，应用于TCP处理，包括：
代理判断单元，用于TCP发送端进入慢启动时判断需要加速所述TCP接收端和TCP发送端之间的数据发送；
代理处理单元，用于对所述TCP接收端向所述TCP发送端发送的响应包ACK进行处理，所述代理处理单元包括：第一判断子单元，用于判断需要对所述TCP接收端向所述TCP发送端发送的ACK进行***；***处理子单元， 用于对所述需要进行***的ACK进行***处理，将所述ACK***成多个ACK；
代理发送单元，用于将所述处理后的响应包ACK或重复响应包DupACK发送给所述TCP发送端，以加速所述TCP接收端和TCP发送端之间的数据发送。
本发明的实施例还提供一种代理功能实体，应用于TCP处理，其特征在于，包括：
代理判断单元，用于TCP发送端进入慢启动时判断需要加速所述TCP接收端和TCP发送端之间的数据发送；
代理处理单元，用于对所述TCP接收端向所述TCP发送端发送的重复响应包DupACK进行处理，所述代理处理单元包括：第二判断子单元，用于判断是否需要创建DupACK或复制从所述TCP接收端接收的DupACK；复制处理子单元，用于所述第二判断子单元判断为需要复制DupACK时，复制所述DupACK，并将所述DupACK和复制的DupACK向所述代理发送单元发送；创建处理子单元，用于所述判断单元判断为需要创建DupACK时，创建DupACK，并将TCP接收端发送的ACK和创建得到的DupACK向所述代理发送单元发送；
代理发送单元，用于将所述处理后的重复响应包DupACK发送给所述TCP发送端，以加速所述TCP接收端和TCP发送端之间的数据发送。
与现有技术相比，本发明的实施例具有以下优点：
在使用代理的情况下，通过对接收端向发送端发送的ACK或DupACK的处理，缩短了TCP发送端慢启动所持续的时间，加速恢复TCP发送端的数据发送能力。
附图说明
图1是本发明实施例中***ACK的流程图；
图2是本发明实施例中ACK的具体***方法的流程图；
图3是本发明实施例中创建/复制DupACK方法的流程图；
图4是本发明实施例中代理功能实体的示意图；
图5是本发明实施例中代理功能实体的示意图。
具体实施方式
下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述：
本发明的实施例提供了一种无线传输控制协议处理方法，目的在于增强TCP性能，适用于在网络中位于TCP发送端与TCP接收端之间不同位置的代理，包括如互联网中部署的代理、核心网中部署的代理、移动网RAN(RadioAccess Network)侧部署的代理等，该代理的具体形式在本发明实施例中不做限定。该TCP发送端和TCP接收端可以分别为服务器和用户终端，以及用户终端和服务器。
具体的，本发明的实施例提供的无线传输控制协议处理方法应用于TCP发送端与TCP接收端间的代理，该方法包括：
判断需要加速所述TCP接收端和TCP发送端之间的数据发送；
对所述TCP接收端向所述TCP发送端发送的响应包ACK或重复响应包DupACK进行处理并发送给所述TCP发送端，以加速所述TCP接收端和TCP发 送端之间的数据发送。
具体的，上述处理包括：通过使用***ACK技术对TCP接收端向TCP发送端发送的ACK报文进行***；或创建/复制DupACK报文向TCP发送端发送。从而通过上述处理方式提升TCP发送端的数据发送能力。以下对这两种处理方式分别进行描述。
本发明的实施例提供了一种TCP性能增强方法，通过使用***ACK技术对TCP接收端向TCP发送端发送的ACK进行***，进而通过增加TCP发送端接收到的ACK数量，快速提升TCP发送端的数据发送能力。其实现原理如下：
要维持TCP发送端高的数据发送能力，则必需在TCP发送端维持高的拥塞窗口(Congestion window，以下简称cwnd)；而拥塞窗口的增长速度和TCP发送端接收到的ACK数量相关。具体的，考虑到TCP发送窗口＝min(发送端拥塞窗口，接收端通告窗口)，使用代理后，TCP发送窗口＝min(发送端拥塞窗口，代理通告窗口)，代理通告窗口的大小由代理的缓存决定。所以，当发送端拥塞窗口大于等于代理通告窗口时，才能达到最大的数据发送能力。在进入慢启动阶段时，cwnd的初始值为2个MSS(Max Segment Size，TCP发送端所能发送的最大TCP分组包的长度)大小，之后TCP发送端每收到一个ACK，cwnd就增加一个MSS，一直增加到cwnd等于慢启动门限ssthresh或发生分组包丢失为止。在cwnd等于慢启动门限ssthresh后则进入拥塞避免阶段，在拥塞避免阶段，TCP发送端每收到一个ACK，拥塞窗口cwnd将线性增加。因此，当拥塞窗口的值较小时，使用***ACK技术可以加速拥塞窗口cwnd的增加，快速的将发送端拥塞窗口提升到大于等于代理通告窗口。
***ACK的主要方法是代理接收到TCP接收端向TCP发送端发送的ACK时，将该ACK***为多个ACK发送到TCP发送端。本发明实施例中***ACK的基本流程如图1所示，包括如下步骤：
步骤s101、代理接收到TCP接收端向TCP发送端发送的ACK。
步骤s102、代理判断需要对该ACK进行***处理。
本发明的实施例中还需要对于是否使用***ACK进行监控。采用监控的 原因如下：使用***ACK能够加速拥塞窗口增长，但是因为使用代理后，TCP发送端的TCP发送窗口＝min(发送端拥塞窗口，代理通告窗口)，因而，当发送端拥塞窗口大于代理通告窗口时，再增加发送端拥塞窗口并不能增大TCP发送端的发送窗口，反而会增加TCP发送端到TCP接收端的ACK数目。所以，需要在代理中跟踪TCP发送端拥塞窗口cwnd的大小。
该监控的实现方法如下：在代理处维护一个TCP发送端cwnd的估计值TPE_cwnd，同时也维护一个TCP发送端慢启动门限ssthresh的估计值TPE_ssthresh。
设置TPE_cwnd的初始值为2个MSS(Max Segment Size，TCP发送端所能发送的最大TCP分组包的长度)大小，TPE_ssthresh的初始值为TCP接收端的接收窗口大小。
如果代理从TCP发送端接收到的数据在代理缓存中已经存在，或TCP发送端发送的数据先前已经得到确认，则代理认为TCP发送端进入了慢启动，并将TPE_cwnd的值置为2个MSS大小。此后，在慢启动阶段中，代理每向TCP发送端发送一个ACK，TPE_cwnd的值就增加一个MSS大小。当TPE_cwnd大于等于TPE ssthresh时，代理就认为TCP发送端进入了拥塞避免阶段。拥塞避免阶段中，代理每向TCP发送端发送一个ACK，TPE_cwnd就递增MSS*MSS/TPE_cwnd大小。
获取TPE_cwnd后，根据以下准则判断是否对TCP接收端向TCP发送端发送的ACK进行***处理：当TPE_cwnd小于代理缓存大小时，那么执行***ACK行为；否则，不进行***ACK行为，将ACK直接向TCP发送端发送。
除了根据上述准则进行是否需要***ACK外，在以下情况也不进行ACK***，而将ACK直接向TCP发送端发送：(1)如果从TCP接收端接收的ACK请求的分组包在代理缓存中不存在且本地缓存不为空，则不对该TCP ACK进行***；(2)对第三次握手ACK不进行***；(3)和之前序号重复的ACK或DupACK，包括窗口更新包，都不进行***。
步骤s103、代理将ACK***后向TCP发送端发送。
该ACK的具体***方法如图2所示，包括以下步骤：
步骤s201、设置ACK***的数目和请求序号。
当代理向TCP发送端发送ACK时，为了不失一般性，假设从TCP接收端接收到的该ACK请求的分组包的序号是N，记为ACK(N)，分组包大小为MSS，那么在代理向TCP发送端发送ACK(N)之前，由代理创建L(≥1)个***ACK，该类ACK具有这样的特征：这L个ACK的应答号均在((N-MSS)，N)范围内，并各不相同，其中N>MSS)。将这L个ACK的请求序号分别设置为N-L，N-L+1，...N-X，...N-2，N-1(1≤X≤L<MSS)。
步骤s202、设置***ACK(N-X)与ACK(N)的包头信息。
根据TCP连接对应的代理本地缓存大小设置各个***ACK的通告窗口值，假设每个代理实体缓存大小为M bytes，那么，对于***ACK(N-X)和ACK(N)，其通告窗口都设置为M bytes。
步骤s203、向TCP发送端发送***后的ACK。
发送时，按照ACK(N-L)、ACK(N-L+1)，...，ACK(N-X)，...ACK(N-1)，ACK(N)的顺序，一起发送给TCP发送端。
在慢启动阶段，TCP发送端每收到一个***ACK，窗口均将增加1个MSS大小；在拥塞避免阶段，TCP发送端每收到一个***ACK，窗口均将增加MSS*MSS/cwnd大小。
除上述步骤s201～s203外，由TCP巴克利算法可知，TCP接收端通常是每收到2个TCP分组包后反馈一个ACK，那么当代理收到TCP接收端的ACK后准备向TCP发送端发送ACK时，可以先分析该ACK累积确认了TCP接收端接收的哪几个TCP分组包。然后，对确认的最后一个TCP分组包之前的几个TCP分组包分别发送ACK进行确认。例如，以TCP接收端为UE为例，代理上一次发送的应答包为ACK代理(S1)，此时从TCP接收端收到的应答的序号为ACKUE(S2)。当S2>S1时，通过查看连接对应的代理缓存就可知有多少个TCP分组包被TCP接收端累积确认，设确认的最大序号包Data(S3)，那么代理将为序号小于S3的每个被累积确认TCP分组包发送确认，如果累积确认的分组包共有Y个，那么经过此操作将增加了Y-1个ACK，这些新增ACK和累积确认ACKUE(S2) 到达TCP发送端后，将加速源端拥塞窗口的膨胀，这可认为***ACK实现的特殊情况。另外，可以根据上述***ACK触发原则对这些ACK，再进行***。
上面叙述的是非捎带ACK被***的情况，对于捎带ACK(指ACK本身搭载了数据)，本身数据长度非0，仍然按照上述***方法进行***，得到的***ACK载荷长度为0。发送顺序也是小确认序号ACK在前，大确认序号ACK在后，一起发送给TCP发送端。
本发明的实施例还提供了一种TCP处理方法，目的在于增强TCP传输性能，应用于在TCP发送端与代理之间发生分组包丢失时，通过创建DupACK快速将TCP发送端由慢启动快速进入对丢失分组包的快速重传，并在快速重传后的快速恢复阶段中通过对从TCP接收端收到的DupACK进行一定量的复制，提升快速恢复阶段TCP发送端的数据发送能力。原因如下：
现有技术中，TCP发送端收到TCP接收端发出的3个DupACK后才会进入快速重传，以恢复丢失的分组包。因此，在代理检测到分组包丢失后，直接创建DupACK发送给TCP发送端，则可加速丢失分组包的重传，缩短重传所花费的时间。另外，快速重传阶段完成后，通常会进入快速恢复阶段。在快速恢复阶段，TCP发送端每收到一个TCP接收端发出的DupACK，cwnd将递加一个报文大小。因而对从TCP接收端收到的DupACK进行一定量的复制，可提升快速恢复阶段TCP发送端的数据发送能力。
本发明的实施例中，使用了代理缓存排序技术和代理分组包丢失检测，在此基础上进行复制DupACK。
本发明实施例中使用的代理缓存排序方法如下：
在进行DupACK创建之前，首先要检测分组包丢失，所以本方案在代理上对从TCP发送端过来的数据进行排序。具体的排序的原则为：
目前TCP使用的SN(Sequence Number，序列号)是一个32位的计数器，从0-4294967295(即232-1)。TCP为每一个连接选择一个ISN(Initial SequenceNumber，初始序列号)，为了防止因为延迟、重传等扰乱三次握手，ISN不能随便选取，不同***有不同算法。当分组包序号大于ISN而小于最大序号 4294967295时，代理每收到一个分组包，将根据其序号值，按照从小序号在前，大序号在后的顺序(即从队头往队尾，分组包序号是从小到大)，在代理缓存链表中找到对应位置***。特殊地，对于TCP发送端重传的分组包，如果链表中已经存在，直接丢弃。当收到发生序号回绕的分组包时，插在最大序号分组包的后面。
该代理缓存排序是代理检测分组包丢失的前提，它能够避免到达TCP接收端的分组包发生乱序，从而避免由于乱序而导致TCP接收端发送不必要的DupACK。
本发明实施例中使用的代理分组包丢失检测方法如下：
要判别哪些TCP分组包需要由TCP发送端重传，有下面几个规则：
规则1：IP或TCP层CRC校验失败的TCP分组包在代理处将直接丢弃，并由TCP发送端重传。
规则2：代理缓存溢出的TCP分组包，将由TCP发送端重传。
规则3：针对一个已经排序的代理缓存队列，当代理准备下发某个分组包时，如果发现TCP接收端返回ACK所请求的序号(设为K)在代理缓存中不存在，没有到达的原因可能是该分组包仍然滞留在TCP发送端所在网络中，也有可能在传输过程中丢失，这里，代理将其按照丢失处理，即也将由TCP发送端重传。
基于上述代理缓存排序技术和代理分组包丢失检测方法，本发明的实施例中，得到分组包丢失信息后，执行复制DupACK功能，如图3所示，具体流程如下：
步骤s301、代理接收到TCP接收端向TCP发送端发送的ACK或DupACK，判断需要根据该ACK创建DupACK、或复制接收到的DupACK。
具体的，判断需要创建DupACK的方法为：
接收到ACK时，若本地缓存不为空且该ACK所请求的分组包在本地缓存中不存在时，则判断为分组包在TCP发送端与代理之间丢失，需要创建DupACK并向TCP发送端所送。
具体的，判断需要复制DupACK的方法为：
接收到TCP接收端向TCP发送端发送的DupACK，判断所述TCP发送端将进入快速恢复阶段，此时如果估计所述TCP发送端的拥塞窗口大小小于代理本地缓存大小，则根据所述DupACK复制出新的DupACK并向所述TCP发送端发送。
估计所述TCP发送端的拥塞窗口大小的方法具体为：
在代理处维护一个TCP发送端cwnd的估计值TPE_cwnd，同时维护一个TCP发送端慢启动门限ssthresh的估计值TPE ssthresh.。设置TPE_cwnd的初始值为2个MSS大小，TPE ssthresh.的初始值为TCP接收端的接收窗口大小。
当代理向TCP发送端发送DupACK(即TCP发送端与代理间发生分组包丢失)时，TCP发送端将准备重传该丢失的分组包。此时，代理将TPE_cwnd和TPE ssthresh变为min(TPE_cwnd，代理通告给TCP发送端的窗口)/2，后续如果进入了快速恢复阶段，代理每向TCP发送端发送一个DupACK，TPE_cwnd就增加1个MSS大小。随后，代理收到重传分组包的确认后，则认为TCP发送端将进入拥塞避免过程，此时，代理每向TCP发送端发送一个ACK，TPE_cwnd就递增MSS*MSS/TPE_cwnd大小。
因此，当TCP发送端处于快速恢复阶段时，根据估计得到的TCP发送端的拥塞窗口大小TPE_cwnd，可以判断是否复制DupACK：当TPE_cwnd小于代理缓存大小时，那么执行复制DupACK行为；否则，不进行复制DupACK行为。
步骤s302、需要创建DupACK时，代理根据接收的ACK创建DupACK、并向TCP发送端发送。
根据TCP接收端的请求ACK，检测到分组包丢失后，将其携带的通告窗口大小设置为对应于该连接的代理缓存大小，然后按照该ACK创建3个DupACK，并一起发给TCP发送端，使得TCP发送端快速重传该丢失的分组包。上面描述的是非捎带ACK情况，对于捎带ACK情况，通过复制该ACK的TCP/IP头部来进行创建。
步骤s303、需要复制DupACK时，代理根据接收的DupACK复制DupACK并向TCP发送端发送。
对于从TCP接收端发送的DupACK，将窗口修改为和前面复制的3个 DupACK一样，然后判断是否执行复制DupACK，如果执行，那么对该DupACK复制一定量(如1个)的DupACKs，然后将该DupACK和复制DupACK一起发送给TCP发送端，对于后续到达代理的其它DupACK执行和上面相同的操作。上面描述的是非捎带ACK情况，对于捎带ACK情况，通过复制该DupACK的TCP/IP头部来进行复制DupACK。
步骤s304、代理接收到TCP接收端的对该重传分组包的应答后，将窗口修改为对应代理的缓存大小，然后发送给TCP发送端。
当重传分组包从TCP发送端到达代理后，需判断代理是否已经收到过该序号的分组包：如果该序号的分组包已经在代理缓存中，这表明第一次传输该分组包发生了乱序，但仍在重传分组包之前到达代理，这种情况下，直接丢弃到达的重传分组包。如果该序号的分组包不在代理缓存中，那么说明该分组包在TCP发送端所在网络发生了丢弃。此时，代理收到该重传分组包后，同样将按照序号顺序***到代理缓存队列中的相应位置，如果队列中所有分组包的序号均大于该重传分组包，那么直接将该重传分组包***到队头。
通过使用本发明的实施例提供的方法，通过ACK***加速了TCP发送端拥塞窗口的增长，从而缩短了TCP发送端的慢启动过程，提高了拥塞避免阶段TCP发送端的发送速度；另外使得TCP发送端在发送窗口降低后，能够快速恢复到最大值。
通过创建/复制DupACK，从而缩短了TCP发送端的慢启动过程，加速了TCP发送端快速重传所丢失的分组包，并在快速恢复阶段为空口提供了更加充足的数据，从而更大程度地避免空口没有数据可传的现象发生。
如果有线侧时延越大，那么***ACK、创建/复制DupACK带来的有益效果就越明显。
本发明的实施例还提供一种代理功能实体，应用于TCP处理，如图4所示，包括：
接收单元11，用于接收到TCP接收端向TCP发送端发送的ACK；
判断单元12，用于判断是否需要对所述接收单元接收的ACK进行***；
***处理单元13，用于将所述ACK***成多个ACK，并将所述***后 的ACK和所述ACK发送给TCP发送端。
其中，***处理单元进一步包括：
***数目设置子单元131，用于设置ACK***的数目、请求序号；
包头信息设置子单元132，用于设置***得到的ACK的包头信息；
发送子单元133，用于将所述***后的ACK发送给TCP发送端。
本发明的实施例还提供一种代理功能实体，应用于TCP处理，如图5所示，包括：
接收单元21，用于接收TCP接收端向TCP发送端发送的ACK、或DupACK；
判断单元22，用于判断是否需要对所述接收单元接收的ACK创建DupACK、或判断是否需要对所述接收单元接收的DupACK进行复制；
创建处理单元23，用于创建DupACK，并将所述ACK和创建得到的DupACK向所述TCP发送端发送。
复制处理单元24，用于复制所述DupACK，并将所述DupACK和复制得到的DupACK向所述TCP发送端发送。
该代理功能实体还包括：
缓存排序单元25，用于在本地缓存中对TCP发送端发送的分组包进行缓存排序；
丢包检测单元26，用于获取需要请求TCP发送端重传的分组包。
该代理功能实体还包括：
重传包接收单元27，用于接收到所述TCP发送端发送的重传分组包后，判断是否已经收到过所述序号的分组包：所述序号的分组包已经在本地缓存时直接丢弃；否则按照所述分组包的序号按照序号顺序***到本地缓存队列中的相应位置，如果队列中所有分组包的序号均大于所述重传分组包，则直接将所述重传分组包***到队头。
本发明的实施例中还提供一种代理功能实体，应用于TCP处理，包括：
代理判断单元，用于判断需要加速所述TCP接收端和TCP发送端之间的数据发送；
代理处理单元，用于对所述TCP接收端向所述TCP发送端发送的响应包ACK或重复响应包DupACK进行处理；
代理发送单元，用于将所述处理后的响应包ACK或重复响应包DupACK发送给所述TCP发送端，以加速所述TCP接收端和TCP发送端之间的数据发送。
上述代理处理单元可以具体包括：
第一判断子单元，用于判断需要对所述TCP接收端向所述TCP发送端发送的ACK进行***；***处理子单元，用于对所述需要进行***的ACK进行***处理，将所述ACK***成多个ACK。
上述代理处理单元还可以具体包括：
第二判断子单元，用于判断是否需要创建DupACK或复制从所述TCP接收端接收的DupACK；复制处理子单元，用于所述第二判断子单元判断为需要复制DupACK时，复制所述DupACK并将所述DupACK和复制的DupACK向所述代理发送单元发送；创建处理子单元，用于所述判断单元判断为需要创建DupACK时，创建DupACK，并将TCP接收端发送的ACK和创建得到的DupACK向所述代理发送单元发送。
通过使用本发明的实施例提供的设备，通过ACK***加速了TCP发送端拥塞窗口的增长，从而缩短了TCP发送端的慢启动过程，提高了拥塞避免阶段TCP发送端的发送速度。另外使得TCP发送端在发送窗口降低后，能够快速恢复到大值。
通过创建/复制DupACK加速TCP发送端快速重传发送端侧丢失的分组包，能够为空口提供更加充足的数据，从而更大程度地避免空口没有数据可传的现象发生。
如果有线侧时延越大，那么***ACK、创建/复制DupACK带来的有益效果就越明显。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案 本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该获取机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备执行本发明各个实施例所述的方法。
以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
Claims (7)
1.一种无线传输控制协议TCP处理方法，应用于TCP发送端与TCP接收端间的代理，其特征在于，包括：
TCP发送端进入慢启动时，判断需要加速所述TCP接收端和TCP发送端之间的数据发送；
对所述TCP接收端向所述TCP发送端发送的响应包ACK进行处理，包括：
接收到TCP接收端向TCP发送端发送的响应包ACK，判断对所述ACK进行***；
将所述ACK***成多个ACK并向所述TCP发送端发送；
所述判断对ACK进行***包括：估计TCP发送端的拥塞窗口大小，当所述拥塞窗口大小小于本地缓存大小时，判断对所述ACK进行***。
2.如权利要求1所述的方法，其特征在于，所述估计TCP发送端的拥塞窗口大小包括：
在代理处维护所述TCP发送端的拥塞窗口大小的估计值TPE_cwnd，以及TCP发送端慢启动门限的估计值TPE_ssthresh，并设置初始值；
从所述TCP发送端接收到的数据在代理本地缓存中已存在，或TCP发送端发送的数据已得到确认时，判断所述TCP发送端进入慢启动阶段，在所述慢启动阶段，每向所述TCP发送端发送一个ACK，所述TPE_cwnd增加MSS bytes；
当TPE_cwnd大于等于TPE_ssthresh时，判断所述TCP发送端进入拥塞避免阶段，在所述拥塞避免阶段，每向所述TCP发送端发送一个ACK，TPE_cwnd递增MSS*MSS/TPE_cwnd bytes；
其中所述MSS为所述TCP发送端所能发送的最大TCP分组包的大小。
3.如权利要求1所述的方法，其特征在于，所述将ACK***成多个ACK包括：
设置ACK***的数目和请求序号，以及***得到的ACK的包头信息；
将ACK***成多个ACK。
4.如权利要求3所述的方法，其特征在于，所述设置ACK***的数目和 请求序号包括：
对于从TCP接收端接收到的请求序号为N的ACK(N)，由代理创建L个***ACK，将所述L个ACK的请求序号分别设置为N-L，N-L+1，...N-X，...N-2，N-1。
5.如权利要求3所述的方法，其特征在于，所述设置***得到的ACK的包头信息包括：
根据TCP连接对应的代理本地缓存大小，设置各个***ACK的包头信息中的通告窗口值。
6.如权利要求1至5任一项所述的方法，其特征在于，所述将ACK***成多个ACK并向所述TCP发送端发送后，还包括：
根据所述TCP接收端的ACK，分析所述ACK累积确认了所述TCP接收端接收的TCP分组包，对所述确认的最后一个TCP分组包之前的各TCP分组包分别发送ACK。
7.一种代理功能实体，应用于TCP处理，其特征在于，包括：
代理判断单元，用于TCP发送端进入慢启动时判断需要加速所述TCP接收端和TCP发送端之间的数据发送；
代理处理单元，用于对所述TCP接收端向所述TCP发送端发送的响应包ACK进行处理，所述代理处理单元包括：第一判断子单元，用于判断需要对所述TCP接收端向所述TCP发送端发送的ACK进行***；***处理子单元，用于对所述需要进行***的ACK进行***处理，将所述ACK***成多个ACK；
代理发送单元，用于将所述处理后的响应包ACK发送给所述TCP发送端，以加速所述TCP接收端和TCP发送端之间的数据发送；
所述判断需要对所述TCP接收端向所述TCP发送端发送的ACK进行***包括：估计TCP发送端的拥塞窗口大小，当所述拥塞窗口大小小于本地缓存大小时，判断对所述ACK进行***。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008102120500A CN101369877B (zh) | 2007-12-27 | 2008-09-16 | 无线传输控制协议处理方法和设备 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710301784.1 | 2007-12-27 | ||
| CN200710301784 | 2007-12-27 | ||
| CN2008102120500A CN101369877B (zh) | 2007-12-27 | 2008-09-16 | 无线传输控制协议处理方法和设备 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210286713.XA Division CN102891883B (zh) | 2007-12-27 | 2008-09-16 | 无线传输控制协议处理方法和设备 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101369877A CN101369877A (zh) | 2009-02-18 |
| CN101369877B true CN101369877B (zh) | 2012-08-22 |
Family
ID=40413527
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210286713.XA Expired - Fee Related CN102891883B (zh) | 2007-12-27 | 2008-09-16 | 无线传输控制协议处理方法和设备 |
| CN2008102120500A Expired - Fee Related CN101369877B (zh) | 2007-12-27 | 2008-09-16 | 无线传输控制协议处理方法和设备 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210286713.XA Expired - Fee Related CN102891883B (zh) | 2007-12-27 | 2008-09-16 | 无线传输控制协议处理方法和设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (2) | CN102891883B (zh) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8509080B2 (en) | 2009-06-29 | 2013-08-13 | The Chinese University Of Hong Kong | Network traffic accelerator |
| CN102195941B (zh) * | 2010-03-11 | 2014-03-12 | 鼎桥通信技术有限公司 | 一种改进的传输控制协议代理实现方法及装置 |
| CN103339909A (zh) * | 2011-12-21 | 2013-10-02 | 华为技术有限公司 | 文件初始传输速率的确定方法、装置和*** |
| CN104125159B (zh) * | 2014-07-29 | 2017-09-12 | 福建星网锐捷网络有限公司 | 一种拥塞带宽检测方法、装置及*** |
| JP2016063382A (ja) * | 2014-09-18 | 2016-04-25 | 富士通株式会社 | 通信システム、通信方法、および、転送装置 |
| WO2016095198A1 (zh) | 2014-12-19 | 2016-06-23 | 华为技术有限公司 | 一种防止tcp连接中断的装置、***及方法 |
| CN107491356A (zh) * | 2017-08-28 | 2017-12-19 | 广州市百果园信息技术有限公司 | 基于序号的消息处理方法、终端设备和服务器 |
| WO2019104725A1 (zh) * | 2017-12-01 | 2019-06-06 | 华为技术有限公司 | 报文传输方法、装置及*** |
| CN111669431B (zh) * | 2020-05-07 | 2021-11-19 | 深圳华锐金融技术股份有限公司 | 消息传输方法、装置、计算机设备和存储介质 |
| CN112491871B (zh) * | 2020-11-25 | 2023-07-28 | 北京宝兰德软件股份有限公司 | 一种tcp重组方法、装置、电子设备及存储介质 |
| CN114629856B (zh) * | 2022-05-16 | 2022-07-26 | 湖南戎腾网络科技有限公司 | 拥塞控制方法、装置、电子设备及可读存储介质 |
| CN116566914B (zh) * | 2023-07-07 | 2023-09-19 | 灵长智能科技(杭州)有限公司 | 旁路tcp加速方法、装置、设备及介质 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101114999A (zh) * | 2007-08-26 | 2008-01-30 | 上海华为技术有限公司 | 数据发送控制方法及数据传输设备 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001510957A (ja) * | 1997-07-14 | 2001-08-07 | ノキア ネットワークス オサケ ユキチュア | テレコミュニケーションネットワークの流れ制御 |
| US6958997B1 (en) * | 2000-07-05 | 2005-10-25 | Cisco Technology, Inc. | TCP fast recovery extended method and apparatus |
| AU2002253437A1 (en) * | 2002-04-12 | 2003-10-27 | Nokia Corporation | System, device and method for improving throughput in a communication network, preferably a mobile ipv6-based network |
| US7593338B2 (en) * | 2003-06-27 | 2009-09-22 | Samsung Electronics Co., Ltd. | Congestion control method and system for reducing a retransmission timeout count in a transmission control protocol |
| CN100550891C (zh) * | 2003-09-05 | 2009-10-14 | 华为技术有限公司 | 提高无线网络传输性能的方法 |
-
2008
- 2008-09-16 CN CN201210286713.XA patent/CN102891883B/zh not_active Expired - Fee Related
- 2008-09-16 CN CN2008102120500A patent/CN101369877B/zh not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101114999A (zh) * | 2007-08-26 | 2008-01-30 | 上海华为技术有限公司 | 数据发送控制方法及数据传输设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101369877A (zh) | 2009-02-18 |
| CN102891883A (zh) | 2013-01-23 |
| CN102891883B (zh) | 2014-12-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101369877B (zh) | 无线传输控制协议处理方法和设备 | |
| JP5523350B2 (ja) | Ｔｃｐフロー制御のための方法及び装置 | |
| KR100785293B1 (ko) | 다중 ｔｃｐ확인응답을 이용한 ｔｃｐ 혼잡 제어 시스템및 그 방법 | |
| JP4283589B2 (ja) | 通信装置、通信制御方法及びプログラム | |
| US7965674B2 (en) | Sub-segment based transport layer protocol for wireless medium | |
| EP2068510B1 (en) | Communication system, communication device, and communication method | |
| US7496038B2 (en) | Method for faster detection and retransmission of lost TCP segments | |
| JP2002152308A (ja) | データ通信システム、その通信方法及びその通信プログラムを記録した記録媒体 | |
| US7593338B2 (en) | Congestion control method and system for reducing a retransmission timeout count in a transmission control protocol | |
| US20070223492A1 (en) | Methods and apparatus for optimizing a TCP session for a wireless network | |
| JP5080654B2 (ja) | 通信装置、通信方法 | |
| KR20130065619A (ko) | 송신 노드로부터 목적지 노드로의 데이터 전송 방법 | |
| CN102769520A (zh) | 基于sctp协议的无线网络拥塞控制方法 | |
| JP7067544B2 (ja) | 通信システム、通信装置、方法およびプログラム | |
| EP1278348A1 (en) | Long-lived TCP connection using ICMP messages in wireless mobile communications | |
| CN104580171B (zh) | Tcp协议的传输方法、装置和*** | |
| KR100913897B1 (ko) | 재전송 타임아웃 수를 줄이기 위한 전송 제어 프로토콜혼잡제어방법 | |
| KR101231793B1 (ko) | Ｔｃｐ 세션 최적화 방법 및 네트워크 노드 | |
| West et al. | TCP enhancements for heterogeneous networks | |
| JP2003224547A (ja) | フロー制御方法 | |
| KR20100034553A (ko) | Ｔｃｐ 혼잡제어 장치, 그 방법 및 그 프로그램이 기록된기록매체 | |
| JPH10257092A (ja) | 輻輳制御方法 | |
| Cho et al. | Enhanced response algorithm for spurious TCP timeout (ER-SRTO) | |
| Miyake et al. | TCP Enhancement Using Recovery of Lost Retransmissions for NewReno TCP | |
| JP2004222271A (ja) | 伝送制御方法、通信装置、通信システム及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20120822 Termination date: 20210916 |