CN102891883B - 无线传输控制协议处理方法和设备 - Google Patents
无线传输控制协议处理方法和设备 Download PDFInfo
- Publication number
- CN102891883B CN102891883B CN201210286713.XA CN201210286713A CN102891883B CN 102891883 B CN102891883 B CN 102891883B CN 201210286713 A CN201210286713 A CN 201210286713A CN 102891883 B CN102891883 B CN 102891883B
- Authority
- CN
- China
- Prior art keywords
- tcp
- dupack
- transmitting terminal
- ack
- tcp transmitting
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (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发送端发送的响应包ACK或重复响应包DupACK进行处理并发送给所述TCP发送端,以加速所述TCP接收端和TCP发送端之间的数据发送。
本发明的实施例还提供一种代理功能实体,应用于TCP处理,包括:
代理判断单元,用于判断需要加速所述TCP接收端和TCP发送端之间的数据发送;
代理处理单元,用于对所述TCP接收端向所述TCP发送端发送的响应包ACK或重复响应包DupACK进行处理;
代理发送单元,用于将所述处理后的响应包ACK或重复响应包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 (6)
1.一种无线传输控制协议TCP处理方法,应用于TCP发送端与TCP接收端间的代理,其特征在于,包括:
TCP发送端进入慢启动时,判断需要加速所述TCP接收端和TCP发送端之间的数据发送;
当所述TCP接收端向所述TCP发送端发送响应包ACK时,根据所述ACK创建重复响应包DupACK;或
当所述TCP接收端向所述TCP发送端发送DupACK时,复制从所述TCP接收端接收的所述DupACK;
将所述创建或复制的DupACK向所述TCP发送端发送。
2.如权利要求1所述的方法,其特征在于,所述创建DupACK包括:
接收到所述ACK时,若本地缓存不为空且所述ACK所请求的分组包在本地缓存中不存在时,则判断为所述分组包在TCP发送端与代理之间丢失,创建DupACK并向所述TCP发送端发送。
3.如权利要求1所述的方法,其特征在于,所述复制DupACK包括:
接收到所述DupACK时,判断所述TCP发送端将进入快速恢复阶段,此时如果估计所述TCP发送端的拥塞窗口大小小于本地缓存大小,则根据所述DupACK复制出新的DupACK并向所述TCP发送端发送。
4.如权利要求3所述的方法,其特征在于,所述估计TCP发送端的拥塞窗口大小包括:
在本地维护所述TCP发送端的拥塞窗口大小的估计值TPE_cwnd、以及TCP发送端慢启动门限的估计值TPE_ssthresh,并设置初始值;
创建一定数量的DupACK发送给所述TCP发送端后,使得所述TCP发送端进入快速重传阶段,将TPE_cwnd和TPE_ssthresh设置为min(TPE_cwnd,代理通告给TCP发送端的窗口)/2;所述TCP发送端进入快速恢复阶段;
在所述快速恢复阶段,每向所述TCP发送端发送一个包括DupACK和复制DupACKs在内的DupACK,TPE_cwnd增加MSSbytes;从TCP接收端收到对重传分组包的确认后,所述TCP发送端进入拥塞避免过程,每向所述TCP发送端发送一个ACK,TPE_cwnd递增MSS*MSS/TPE_cwnd。
5.如权利要求1所述的方法,其特征在于,所述将创建或复制的DupACK向所述TCP发送端发送包括:
根据所述TCP接收端的ACK检测到分组包丢失后,将其携带的通告窗口大小设置为对应于所述TCP连接的本地缓存大小,并按照所述ACK创建多个DupACK,将所述ACK和所述创建的DupACK一起向所述TCP发送端发送;
对于后续从TCP接收端收到的DupACK,将所述通告窗口大小修改为和前面创建DupACK相同的通告窗口的大小,对所述DupACK复制一定量的DupACKs,然后将所述DupACK和复制DupACKs一起发送给TCP发送端。
6.一种代理功能实体,应用于TCP处理,其特征在于,包括:
代理判断单元,用于TCP发送端进入慢启动时判断需要加速所述TCP接收端和TCP发送端之间的数据发送;
代理处理单元,用于对所述TCP接收端向所述TCP发送端发送的响应包ACK或重复响应包DupACK进行处理,所述代理处理单元包括:第二判断子单元,用于判断是否需要根据所述ACK创建DupACK或复制从所述TCP接收端接收的DupACK;复制处理子单元,用于所述第二判断子单元判断为需要复制DupACK时,复制所述DupACK,并将所述DupACK和复制的DupACK向所述代理发送单元发送;创建处理子单元,用于所述判断单元判断为需要创建DupACK时,创建DupACK,并将TCP接收端发送的ACK和创建得到的DupACK向所述代理发送单元发送;
代理发送单元,用于将所述处理后的重复响应包DupACK发送给所述TCP发送端,以加速所述TCP接收端和TCP发送端之间的数据发送。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210286713.XA CN102891883B (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 | ||
CN201210286713.XA CN102891883B (zh) | 2007-12-27 | 2008-09-16 | 无线传输控制协议处理方法和设备 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2008102120500A Division CN101369877B (zh) | 2007-12-27 | 2008-09-16 | 无线传输控制协议处理方法和设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102891883A CN102891883A (zh) | 2013-01-23 |
CN102891883B true CN102891883B (zh) | 2014-12-31 |
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 After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2008102120500A Expired - Fee Related CN101369877B (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 | 鼎桥通信技术有限公司 | 一种改进的传输控制协议代理实现方法及装置 |
WO2013091180A1 (zh) * | 2011-12-21 | 2013-06-27 | 华为技术有限公司 | 文件初始传输速率的确定方法、装置和系统 |
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加速方法、装置、设备及介质 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU745204B2 (en) * | 1997-07-14 | 2002-03-14 | Nokia Networks Oy | Flow control in a telecommunications network |
US6958997B1 (en) * | 2000-07-05 | 2005-10-25 | Cisco Technology, Inc. | TCP fast recovery extended method and apparatus |
WO2003088609A2 (en) * | 2002-04-12 | 2003-10-23 | 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 | 华为技术有限公司 | 提高无线网络传输性能的方法 |
CN101114999B (zh) * | 2007-08-26 | 2010-08-04 | 上海华为技术有限公司 | 数据发送控制方法及数据传输设备 |
-
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
Also Published As
Publication number | Publication date |
---|---|
CN101369877B (zh) | 2012-08-22 |
CN102891883A (zh) | 2013-01-23 |
CN101369877A (zh) | 2009-02-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102891883B (zh) | 无线传输控制协议处理方法和设备 | |
JP4283589B2 (ja) | 通信装置、通信制御方法及びプログラム | |
JP5523350B2 (ja) | Tcpフロー制御のための方法及び装置 | |
CN109327288B (zh) | 数据传输加速方法、装置及系统 | |
KR100785293B1 (ko) | 다중 tcp확인응답을 이용한 tcp 혼잡 제어 시스템및 그 방법 | |
JP4587053B2 (ja) | 通信装置、通信システム、パケット欠落検出方法、およびパケット欠落検出プログラム | |
US7505412B2 (en) | Transmission control method and system | |
JP2002152308A (ja) | データ通信システム、その通信方法及びその通信プログラムを記録した記録媒体 | |
KR102046792B1 (ko) | 송신 노드로부터 목적지 노드로의 데이터 전송 방법 | |
WO2008044653A1 (fr) | Système, périphérique et procédé de communication | |
Natarajan et al. | Non-renegable selective acknowledgments (NR-SACKs) for SCTP | |
JP2002527935A (ja) | データ通信用方法とシステム | |
JPWO2010064421A1 (ja) | 通信装置、通信方法 | |
JP7067544B2 (ja) | 通信システム、通信装置、方法およびプログラム | |
EP1435704B1 (en) | Transmission control method and system | |
JP3893247B2 (ja) | データ配信管理装置 | |
CN104580171B (zh) | Tcp协议的传输方法、装置和系统 | |
CN102201901A (zh) | 数据重传方法及装置 | |
CN115866095A (zh) | 数据传输方法、装置、电子设备及存储介质 | |
JP2003264579A (ja) | パケット転送システム、このシステムに用いる制御装置、及び移動端末、並びに、パケット転送プログラム | |
CN106100797B (zh) | 一种基于ltp异步加速重传策略的深空文件传输方法 | |
Donckers et al. | Enhancing energy efficient tcp by partial reliability | |
KR101933175B1 (ko) | 서버와 클라이언트간 통신을 중개하는 중개장치 | |
Daniel et al. | The performance of multiple TCP flows with vertical handoff | |
Liqing et al. | TCP optimization implementation of a small embedded system |
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 |
Granted publication date: 20141231 Termination date: 20210916 |
|
CF01 | Termination of patent right due to non-payment of annual fee |