CN103986548A - 一种确定丢包原因的方法和终端 - Google Patents

一种确定丢包原因的方法和终端 Download PDF

Info

Publication number
CN103986548A
CN103986548A CN201310049693.9A CN201310049693A CN103986548A CN 103986548 A CN103986548 A CN 103986548A CN 201310049693 A CN201310049693 A CN 201310049693A CN 103986548 A CN103986548 A CN 103986548A
Authority
CN
China
Prior art keywords
tcp
packet loss
window
lost
send window
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.)
Granted
Application number
CN201310049693.9A
Other languages
English (en)
Other versions
CN103986548B (zh
Inventor
罗海
胡新宇
魏启坤
谢于明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201310049693.9A priority Critical patent/CN103986548B/zh
Publication of CN103986548A publication Critical patent/CN103986548A/zh
Application granted granted Critical
Publication of CN103986548B publication Critical patent/CN103986548B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Abstract

本发明实施例提供一种确定丢包原因的方法和终端,涉及通信领域,能够简单高效地确定丢包类型,以便根据丢包类型做相应的调整。其方法为:确定传输控制协议TCP发送窗口产生的丢包的数量,当丢包的数量大于门限值时,确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3,当TCP发送窗口产生的全部丢包的数量不大于门限值时,确定TCP发送窗口因拥塞以外的原因而产生丢包,根据丢包原因对拥塞控制窗口和慢启动阈值进行调整。本发明实施例用于确定丢包原因。

Description

一种确定丢包原因的方法和终端
技术领域
本发明涉及通信领域,尤其涉及一种确定丢包原因的方法和终端。
背景技术
在互联网中,随着信息传送量的逐渐增大和网络组成的日益复杂,网络发生拥塞的可能性越来越大。TCP(Transmission ControlProtocol,传输控制协议)拥塞控制机制可以通过对网络容量进行探测,调整本地的拥塞控制窗口。为了提升TCP在无线网络、有线/无线混合网络中的端到端传输速率,现有的优化方法主要分为以下两类:
一是基于宽带估计的方法:以Westwood算法为代表,通过在发送端持续检测接收端发送的ACK(Acknowledgement,确认字符)的到达速率,来获取端到端的BWE(Bandwidth Estimation,有效带宽估计),在发送端检测到丢包时,根据网络的有效宽带自适应的降低拥塞窗口,以此来提高网络传输效率;二是基于拥塞队列估计的方法:以Veno算法为代表,Veno算法可以对丢包进行明显的区分,它通过计算理想的网络传输速率和实际传输速率之差,来间接估计出瓶颈链路处的拥塞队列长度,并根据拥塞队列长度来区分拥塞丢包和链路随机丢包,从而适当的调整拥塞窗口大小来提高网络传输效率。
其中,在基于宽带估计的方法中,需要准确的估计BWE,对时间精度要求高,因此Westwood算法要求TCP支持时间戳选项,而当遇到对端不支持时间戳选项时,该算法的性能就会降低。且该算法在实现过程中,需要用到滤波、除法等,在基于FPGA(Field-Programmable Gate Array,现场可编程门阵列)的实现中,占用资源多,实现起来比较困难。同样,Veno算法要获取RTT(平滑的往返时延)或BaseRTT(最小平滑往返时延),也需要时间戳的支持,且该算法也包含除法,基于FPGA实现较为困难。其次,Veno算法还涉及拥塞队列长度阈值的选择,在不同的网络环境中,需要调整拥塞队列长度阈值,若拥塞队列长度阈值取值不当,对识别丢包类型有较大影响,从而影响TCP性能。
发明内容
本发明的实施例提供一种确定丢包原因的方法和终端,以便能够高效地确定丢包类型。
为达到上述目的,本发明的实施例采用如下技术方案:
第一方面,提供一种确定丢包原因的方法,包括:
确定传输控制协议TCP发送窗口产生的丢包的数量;
当所述丢包的数量大于门限值时,确定所述TCP发送窗口因拥塞而产生所述丢包,所述门限值为1、2或3。
结合第一方面,在第一方面的第一种可能实现的方式中,当所述TCP发送窗口产生的全部丢包的数量不大于所述门限值时,确定TCP发送窗口因拥塞以外的原因而产生所述丢包。
结合第一方面或第一方面的第一种可能实现的方式,在第一方面的第二种可能实现的方式中,所述产生所述丢包包括:
若接收到规定数量的重复的TCP响应ACK,则确定产生所述丢包;或
若重传定时器超时,则确定产生所述丢包。
结合第一方面或第一方面的第一种可能实现的方式或第二种可能实现的方式,在第一方面的第三种可能实现的方式中,所述确定TCP发送窗口产生的丢包的数量包括:
确定所述TCP发送窗口丢掉了第一丢失TCP包,所述第一丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第一个被丢掉的TCP包;
获取恢复序号,所述恢复序号为所述TCP发送窗口在确定所述TCP发送窗口丢掉了第一丢失TCP包时已发送的TCP包中的最大发送序号与1的和;
向接收端重传所述第一丢失TCP包;
接收第一TCP响应ACK,所述第一TCP ACK为所述接收端针对接收到的所述第一丢失TCP包发送的ACK;
确定所述第一TCP ACK的确认序号是否小于所述恢复序号;
若所述第一TCP ACK的确认序号小于所述恢复序号,则确定所述TCP发送窗口丢掉了第二丢失TCP包,所述第二丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第二个被丢掉的TCP包。
结合第一方面或第一方面的第三种可能实现的方式,在第一方面的第四种可能实现的方式中,所述确定TCP发送窗口的丢包数量还包括:
在确定所述TCP发送窗口丢掉了第n丢失TCP包后,向所述接收端重传所述第n丢失TCP包,所述第n丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第n个被丢掉的TCP包;
接收第n TCP ACK,所述第n TCP ACK为所述接收端针对接收到的所述第n丢失TCP包发送的ACK;
确定所述第n TCP ACK的确认序号是否小于所述恢复序号;
若所述第n TCP ACK的确认序号小于所述恢复序号,则确定所述TCP发送窗口丢掉了第n+1丢失TCP包,所述第n+1丢失TCP包为所述TCP发送窗口丢掉的TCP包中的第n+1个被丢掉的TCP包,其中n为自然数,且n≥2。
结合第一方面或第一方面的第二种可能实现的方式至第四种可能实现的方式,在第一方面的第五种可能实现的方式中,当接收到规定数量的重复的TCP ACK时,
若确定所述TCP发送窗口因拥塞而产生所述丢包,则将拥塞控制窗口减半来获取调整后的拥塞控制窗口,并将慢启动阈值减半来获取调整后的慢启动阈值;
若确定TCP发送窗口因拥塞以外的原因而产生所述丢包,则将所述拥塞控制窗口与乘法减小因子相乘,来获取调整后的拥塞控制窗口,并将所述慢启动阈值与所述乘法减小因子相乘,来获取调整后的慢启动阈值。
结合第一方面或第一方面的第二种可能实现的方式至第四种可能实现的方式,在第一方面的第六种可能实现的方式中,当重传定时器超时时,
若确定所述TCP发送窗口因拥塞而产生所述丢包,将所述拥塞控制窗口降为1,并将所述拥塞控制窗口减半后的值作为调整后的慢启动阈值;
若确定TCP发送窗口因拥塞以外的原因而产生所述丢包,则将所述拥塞控制窗口降为1,并将所述拥塞控制窗口与所述乘法减小因子相乘,将相乘后的拥塞控制窗口的值作为调整后的慢启动阈值。
第二方面,提供一种终端,包括:
数量确定单元,用于确定传输控制协议TCP发送窗口产生的丢包的数量;
丢包分析单元,用于当所述丢包的数量大于门限值时,确定所述TCP发送窗口因拥塞而产生所述丢包,所述门限值为1、2或3。
结合第二方面,在第二方面的第一种可能实现的方式中,所述丢包分析单元还用于当所述TCP发送窗口产生的全部丢包的数量不大于所述门限值时,确定TCP发送窗口因拥塞以外的原因而产生所述丢包。
结合第二方面或第二方面的第一种可能实现,在第二方面的方式的第二种可能实现的方式中,包括:
丢包检测单元,用于若接收到规定数量的重复的TCP响应ACK,则确定产生所述丢包;或
若重传定时器超时,则确定产生所述丢包。
结合第一方面或第一方面的第一种可能实现的方式或第二种可能实现的方式,在第二方面的第三种可能实现的方式中,所述数量确定单元具体包括:
第一确定子单元,用于确定所述TCP发送窗口丢掉了第一丢失TCP包,所述第一丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第一个被丢掉的TCP包;
序号获取子单元,用于获取恢复序号,所述恢复序号为所述TCP发送窗口在确定所述TCP发送窗口丢掉了第一丢失TCP包时已发送的TCP包中的最大发送序号与1的和;
第一重传子单元,用于向接收端重传所述第一丢失TCP包;
第一响应子单元,用于接收第一TCP响应ACK,所述第一TCPACK为所述接收端针对接收到的所述第一丢失TCP包发送的ACK;
第一判断单元,用于确定所述第一TCP ACK的确认序号是否小于所述恢复序号;
第一判断单元还用于当所述第一TCP ACK的确认序号小于所述恢复序号,则确定所述TCP发送窗口丢掉了第二丢失TCP包,所述第二丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第二个被丢掉的TCP包。
结合第一方面或第一方面的第三种可能实现的方式,在第二方面的第四种可能实现的方式中,所述数量确定单元还用于:
在确定所述TCP发送窗口丢掉了第n丢失TCP包后,向所述接收端重传所述第n丢失TCP包,所述第n丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第n个被丢掉的TCP包;
接收第n TCP ACK,所述第n TCP ACK为所述接收端针对接收到的所述第n丢失TCP包发送的ACK;
确定所述第n TCP ACK的确认序号是否小于所述恢复序号;
当所述第n TCP ACK的确认序号小于所述恢复序号,则确定所述TCP发送窗口丢掉了第n+1丢失TCP包,所述第n+1丢失TCP包为所述TCP发送窗口丢掉的TCP包中的第n+1个被丢掉的TCP包,其中n为自然数,且n≥2。
结合第一方面或第一方面的第二种可能实现的方式至第四种可能实现的方式,在第二方面的第五种可能实现的方式中,还包括:
第一调整单元,用于当接收到规定数量的重复的TCP响应ACK时,若确定所述TCP发送窗口因拥塞而产生所述丢包,则将拥塞控制窗口减半来获取调整后的拥塞控制窗口,并将慢启动阈值减半来获取调整后的慢启动阈值,若确定TCP发送窗口因拥塞以外的原因而产生所述丢包,则将所述拥塞控制窗口与乘法减小因子相乘,来获取调整后的拥塞控制窗口,并将所述慢启动阈值与所述乘法减小因子相乘,来获取调整后的慢启动阈值。
结合第一方面或第一方面的第二种可能实现的方式至第四种可能实现的方式,在第二方面的第六种可能实现的方式中,还包括:第二调整单元,用于当重传定时器超时时,若确定所述TCP发送窗口因拥塞而产生所述丢包,将所述拥塞控制窗口降为1,并将所述拥塞控制窗口减半后的值作为调整后的慢启动阈值,若确定TCP发送窗口因拥塞以外的原因而产生所述丢包,则将所述拥塞控制窗口降为1,并将所述拥塞控制窗口与所述乘法减小因子相乘,将相乘后的拥塞控制窗口的值作为调整后的慢启动阈值。
本发明实施例提供一种确定丢包原因的方法和终端,通过确定传输控制协议TCP发送窗口产生的丢包的数量,当丢包的数量大于门限值时,确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3,能够简单高效地确定丢包类型,以便根据丢包类型做相应的调整。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种确定丢包原因的方法流程示意图;
图2为本发明另一实施例提供的一种确定丢包原因的方法流程示意图;
图3为本发明又一实施例提供的一种终端结构示意图;
图4为本发明又一实施例提供的又一种终端结构示意图;
图5为本发明又一实施例提供的又一种终端结构示意图;
图6为本发明又一实施例提供的又一种终端结构示意图;
图7为本发明又一实施例提供的又一种终端结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例提供一种确定丢包原因的方法,如图1所示,包括:
101、终端确定传输控制协议TCP发送窗口产生的丢包的数量。
示例性的,在终端向接收端发送TCP窗口时,终端和接收端可以为用TCP(Transmission Control Protocol,传输控制协议)网络来进行端到端数据传输的设备。例如可以为手机、电脑等用户设备。
102、当丢包的数量大于门限值时,终端确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3。
本发明实施例提供一种确定丢包原因的方法,通过确定传输控制协议TCP发送窗口产生的丢包的数量,当丢包的数量大于门限值时,确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3,当TCP发送窗口产生的全部丢包的数量不大于门限值时,确定TCP发送窗口因拥塞以外的原因而产生丢包,能够高效地确定丢包类型。
本发明另一实施例提供一种确定丢包原因的方法,如图2所示,包括:
201、终端确定TCP发送窗口丢掉了第一丢失TCP包,第一丢失TCP包为TCP发送窗口丢掉的TCP包中在顺序上第一个被丢掉的TCP包。
其中,TCP传输用于无线网络、有线/无线混合网络中的数据传输,而该类网络环境中,TCP包丢失的概率很高。假设终端作为发送端,当发送端在TCP网络环境中向接收端发送TCP包的过程中,发生丢包现象时,发送端要对丢失的包进行重传,以便保证发送端与接收端的通信顺畅。
其中,TCP包的丢失可以是由网络拥塞或高误码率等导致的。当发送端向接收端发送TCP包后,接收端在接收到该TCP包后,会向发送端发送ACK(Acknowledgement,确认字符)报文来对已经接收的TCP包进行确认。当TCP包丢失时,发送端会收到重复的ACK报文,当发送端收到规定数量的重复报文时,一般为3个重复的ACK报文,发送端就可以确定TCP发送窗口丢掉了第一丢失TCP包,或者,当发送端向接收端发送TCP包时,发送端的重传定时器同时启动,当发送端的重传定时器超时而未收到接收端返回的该TCP包的ACK报文时,发送端就可以确定TCP发送窗口丢掉了第一丢失TCP包。
这里的第一丢失TCP包中的第一指的是顺序上的第一,也就是说,该TCP发送窗口在丢掉该第一丢失TCP包之前,没有丢掉过TCP包。
而当发送端判断接收到的是第3个重复ACK报文时,可以对cwnd(Congestion Window,拥塞控制窗口)和ssthresh(Slow Startthreshold,慢启动阈值)进行调整,将拥塞控制窗口大小调整为当前拥塞控制窗口的一半,慢启动阈值与调整后的拥塞控制窗口大小相等,即cwndtmp=ssthreshtmp=cwndmax/2,其中,cwndtmp表示调整后的拥塞控制窗口,ssthreshtmp表示调整后的慢启动阈值,cwndmax表示丢包前的拥塞控制窗口;当发送端发送TCP包后重传定时器超时,同样可以对cwnd和ssthresh进行调整,将ssthresh调整为当前拥塞控制窗口大小的一半,将调整后的cwnd降为1,即ssthreshtmp=cwndmax/2,cwndtmp=1。
其中,cwnd拥塞控制窗口的大小取决于网络的拥塞程度,它描述发送端在拥塞控制情况下一次最多能发送的数据包的数量,并且可以动态地在变化,发送端可以使得发送窗口可能小于拥塞控制窗口。ssthresh被用来确定是用慢启动还是用拥塞避免算法来控制数据传送,即为拥塞控制中慢启动阶段和拥塞避免阶段的分界点。
202、终端获取恢复序号,恢复序号为TCP发送窗口在确定TCP发送窗口丢掉了第一丢失TCP包时已发送的TCP包中的最大发送序号与1的和。
示例性的,调整cwnd和ssthresh的同时,发送端可以获取恢复(Recover)序号。假设发送端的TCP发送窗口确定了序号为3的TCP包为第一丢失TCP包时,已经发送了序号为1的TCP包和序号为2的TCP包,以及序号为4的TCP包至序号为10的TCP包,共计10个TCP包至接收端,这样一来,恢复序号为11,即该TCP发送窗口的最大发送序号为10,将最大发送序号10加1即可获取恢复序号为11。
203、终端向接收端重传第一丢失TCP包。
示例性的,在获取并记录了Recover序号后,发送端就向接收端重传一个最早未确认的报文,即第一丢失TCP包,可以用变量ReTxPackets记录重传的TCP包的数量,这时,ReTxPackets=1。
204、终端接收第一TCP响应ACK,第一TCP ACK为接收端针对接收到的第一丢失TCP包发送的ACK。
示例性的,假设发送端向接收端发送了序号为1的TCP包至序号为10的TCP包,仅序号为3的TCP包为第一丢失的TCP包时,发送端向接收端重传了序号为3的TCP包后,接收端针对序号为3的TCP包向发送端返回的第一TCP响应ACK的序号为11,来向发送端告知序号为1至序号为10的TCP包已经由接收端全部接收,接收端希望收到的下一个序号为11的TCP包。
再者,假设发送端向接收端发送了序号为1至序号为10的TCP包,其中序号为3和序号为6的TCP包为丢失的TCP包,序号为3的TCP包为第一丢失TCP包,当发送端重传了序号为3的TCP包后,接收端向发送端返回的第一TCP响应ACK的序号为6,来向发送端告知序号为1至序号为5的TCP包均被接收端接收了,发送端就可以向接收端重传序号为6的TCP包了。
另外,当发送端在向接收端重传了第一丢失TCP包后,若发送端收到的还是重复的ACK报文即第4个及以后的重复的ACK报文时,则发送端增加1个报文段大小,即cwnd++;若收到非重复ACK报文时,对该ACK报文的序号与Recover序号进行比较,若重传TCP包是由发送端收到第3个重复的ACK报文导致的,当发送端未收到该报文对应的ACK报文时,若有新的TCP包要发送,则向接收端发送一个新的TCP包。
205、终端确定第一TCP ACK的确认序号是否小于恢复序号。
206、若第一TCP ACK的确认序号小于恢复序号,则终端确定TCP发送窗口丢掉了第二丢失TCP包,第二丢失TCP包为TCP发送窗口丢掉的TCP包中在顺序上第二个被丢掉的TCP包。
示例性的,基于步骤204中的例子来说,发送端的TCP发送窗口包括序号为1至序号为10的TCP包,Recover序号为11,当序号为3和序号为6的TCP包为丢失的TCP包时,发送端先重传序号为3的TCP包,第一TCP响应ACK的的确认序号为6,小于Recover序号11,这样一来,终端确定该TCP发送窗口存在第二丢失TCP包。其中,这里的第二丢失TCP包是指在顺序上第二个被丢掉的TCP包,即该TCP发送窗口先丢掉第一丢失TCP包,后丢掉第二丢失TCP包,发送端就向接收端重传第二丢失TCP包,变量ReTxPackets=2。
207、终端在确定TCP发送窗口丢掉了第n丢失TCP包后,向接收端重传第n丢失TCP包,第n丢失TCP包为TCP发送窗口丢掉的TCP包中在顺序上第n个被丢掉的TCP包。
示例性的,这里的第n丢失TCP包可以是在顺序上第n个被丢掉的TCP包,也就是说,TCP发送窗口先丢掉第n-1丢失TCP包,后丢掉第n丢失TCP包。
208、终端接收第n TCP ACK,第n TCP ACK为接收端针对接收到的第n丢失TCP包发送的ACK。
209、终端确定第n TCP ACK的确认序号是否小于恢复序号。
210、若第n TCP ACK的确认序号小于恢复序号,则终端确定TCP发送窗口丢掉了第n+1丢失TCP包,第n+1丢失TCP包为TCP发送窗口丢掉的TCP包中的第n+1个被丢掉的TCP包,其中n为自然数,且n≥2。
示例性的,基于步骤206中的阐述,当发送端向接收端发送TCP窗口时,向接收端重传了第n丢失TCP包后,若接收端返回的第nTCP响应ACk的确认序号小于Recover序号,则发送端确定该TCP发送窗口还存在第n+1个丢失的TCP包,发送端便可以向接收端重传第n+1丢失TCP包,其中,n为自然数,且n≥2,这样,变量ReTxPackets=n+1,即丢包的数量为n+1。
211、当丢包的数量大于门限值时,终端确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3。
具体的,若发送端接收到接收端返回的ACK报文的序号大于或者等于Recover序号,即当发送端接收到了接收端返回的全部重传TCP包的确认报文时,丢失的TCP包已经全部由接收端接收,此时,记录重传的TCP包的变量ReTxPackets保持不变。而从发生丢包到对丢失的TCP包进行重传并收到全部确认的ACK报文阶段为快速恢复阶段,而后,发送端从快速恢复阶段退出,进入拥塞避免阶段,可以根据统计的重传的TCP包的数量与门限值进行比较,来判断丢包原因。
其中,门限值可以为a,且a值可以取1、2或3。优选的,a值可以取1。当a值取1时,这是因为一个已发送窗口内链路随机丢包的期望值远小于1。推导过程可以为:若采用标准的TCP拥塞控制算法,则平均的拥塞控制窗口可以为:其中,p表示链路丢包率,cwndavg表示平均的拥塞控制窗口。
且Flight_size≤cwndavg,其中,Flight_size表示已发送窗口大小,这样,在一个已发送窗口内平均丢包数目,即一个已发送窗口内链路随机丢包的期望值可以为: LossPackets avg = p · Flight _ size ≤ p · 3 2 1 p = 3 p 2 , 其中,LossPacketsavg表示已发送窗口内的平均丢包数。
通常情况下,链路丢包率p小于10%,平均丢包数LossPacketsavg远小于1,这样,一个已发送窗口内链路随机丢包的期望值远小于1,当重传报文数ReTxPackets大于1时,就可以将丢包原因确定为拥塞丢包。故将a值取1。
这样,若重传报文数大于门限值,则发送端就可以确定丢包的丢包原因为拥塞丢包。
其中,丢包的原因可以包括因拥塞而产生丢包,或者因拥塞以外的原因产生丢包。拥塞丢包可以是链路中某个或多个节点的入口带宽大于出口带宽,这些节点如路由器则将TCP包进行排队等待,并按照一定的规则将TCP包进行转发或丢弃。例如在路由器中用的最多的排队算法为DropTail方法,即当某个队列满后,后续到达的TCP包直接被丢弃,由于TCP发包存在突发特征,在拥塞时队列尾部报文被丢弃,很容易导致连续丢掉多个TCP包。而非拥塞丢包主要是由于高丢包率引起的,呈随机分布,即主要为链路错误导致的随机丢包,还包括小范围TCP包乱序。
212、当TCP发送窗口产生的全部丢包的数量不大于门限值时,终端确定TCP发送窗口因拥塞以外的原因而产生丢包。
示例性的,若变量ReTxPackets小于或者等于a,则发送端可以将丢包原因确定为因拥塞以外的原因而产生丢包。这样,通过确定性事件来区分丢包原因,比现有的基于参数估计的方法来间接区分丢包原因的方法更可靠。
而后,若终端确认发生丢包是由接收到3个重复的确认报文触发的,则执行步骤213或步骤214;若终端确认发生丢包是由重传定时器超时触发的,则执行步骤215或步骤216。
213、若终端确定TCP发送窗口因拥塞而产生丢包,则将拥塞控制窗口减半来获取调整后的拥塞控制窗口,并将慢启动阈值减半来获取调整后的慢启动阈值。
示例性的,在发送端确定了丢包原因后,可以采取合适的恢复措施。其中,若终端确认发生丢包是由接收到3个重复的确认报文触发的,且发送端根据统计后的重传TCP包数量确认了丢包原因为拥塞丢包,则cwnd=ssthresh=cwndmax/2,其中,cwnd表示恢复措施中拥塞控制窗口调整后的值,ssthresh表示恢复措施中调整后的慢启动阈值,cwndmax表示当前的拥塞控制窗口值。
214、若终端确定TCP发送窗口因拥塞以外的原因而产生丢包,则将拥塞控制窗口与乘法减小因子相乘,来获取调整后的拥塞控制窗口,并将慢启动阈值与乘法减小因子相乘,来获取调整后的慢启动阈值。
示例性的,若终端确认发生丢包是由接收到3个重复的确认报文触发的,且发送端根据统计后的重传TCP包数量确认了丢包原因为拥塞以外的原因,则cwnd=ssthresh=M*cwndmax,其中,cwnd表示恢复措施中调整后的拥塞控制窗口值,ssthresh表示恢复措施中调整后的慢启动阈值,cwndmax表示丢包前的拥塞控制窗口值,M表示乘法减小因子,可以取0.5~1。这样可以适当的降低拥塞控制窗口和慢启动阈值。
215、若终端确定TCP发送窗口因拥塞而产生丢包,将拥塞控制窗口降为1,并将拥塞控制窗口减半后的值作为调整后的慢启动阈值。
示例性的,若终端确认发生丢包是由重传定时器超时触发的,则按照RFC(Request For Comments,注释请求)中的规范,可以将丢包前的拥塞控制窗口cwnd调整为1,这里只需要适当降低慢启动阈值。若发送端根据统计后的重传报文数确认了丢包原因为拥塞丢包,则慢启动阈值与步骤201中的调整后的慢启动阈值相等,即保持不变,ssthresh=cwndmax/2,其中,ssthresh表示恢复措施中调整后的慢启动阈值,cwndmax表示丢包前的拥塞控制窗口值。
216、若终端确定TCP发送窗口因拥塞以外的原因而产生丢包,则将拥塞控制窗口降为1,并将拥塞控制窗口与乘法减小因子相乘,将相乘后的拥塞控制窗口的值作为调整后的慢启动阈值。
示例性的,若终端确认发生丢包是由重传定时器超时触发的,与步骤215相同,则可以将丢包前的拥塞控制窗口cwnd调整为1,再适当的调整慢启动阈值。若丢包的丢包原因为非拥塞丢包,则ssthresh=M*cwndmax,其中,ssthresh表示恢复措施中调整后的慢启动阈值,cwndmax表示丢包前的拥塞控制窗口值,M表示乘法减小因子,可以取0.5~1。
需要说明的是,拥塞丢包也存在只丢一个TCP包的可能性,在这种情况下,将其归类为非拥塞丢包,也是可以接受的。因为此时由于拥塞导致丢失一个TCP包,说明拥塞并不严重,刚刚达到网络容量极限,这个时候可以适当降低拥塞窗口,而不是直接盲目的降为一半,更为合理。
本发明实施例提供一种确定丢包原因的方法,通过确定传输控制协议TCP发送窗口产生的丢包的数量,当丢包的数量大于门限值时,确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3,当TCP发送窗口产生的全部丢包的数量不大于门限值时,确定TCP发送窗口因拥塞以外的原因而产生丢包,根据丢包原因对拥塞控制窗口和慢启动阈值进行调整,能够简单高效地确定丢包类型,以便根据丢包类型做相应的调整。
本发明又一实施例提供一种终端01,如图3所示,包括:
数量确定单元011,用于确定传输控制协议TCP发送窗口产生的丢包的数量。
丢包分析单元012,用于当丢包的数量大于门限值时,确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3。
可选的,丢包分析单元012还可以用于当TCP发送窗口产生的全部丢包的数量不大于门限值时,确定TCP发送窗口因拥塞以外的原因而产生丢包。
可选的,如图4所示,可以包括:丢包检测单元013,用于若接收到规定数量的重复的TCP响应ACK,则确定产生丢包;或
若重传定时器超时,则确定产生丢包。
可选的,如图5所示,数量确定单元011可以包括:
第一确定子单元0111,用于确定TCP发送窗口丢掉了第一丢失TCP包,第一丢失TCP包为TCP发送窗口丢掉的TCP包中在顺序上第一个被丢掉的TCP包。
序号获取子单元0112,用于获取恢复序号,恢复序号为TCP发送窗口在确定TCP发送窗口丢掉了第一丢失TCP包时已发送的TCP包中的最大发送序号与1的和。
第一重传子单元0113,用于向接收端重传第一丢失TCP包;
第一响应子单元0114,用于接收第一TCP响应ACK,第一TCPACK为接收端针对接收到的第一丢失TCP包发送的ACK。
第一判断子单元0115,用于确定第一TCP ACK的确认序号是否小于恢复序号。
第一判断子单元0115还可以用于当第一TCP ACK的确认序号小于恢复序号,则确定TCP发送窗口丢掉了第二丢失TCP包,第二丢失TCP包为TCP发送窗口丢掉的TCP包中在顺序上第二个被丢掉的TCP包。
可选的,数量确定单元011还可以用于:
在确定TCP发送窗口丢掉了第n丢失TCP包后,向接收端重传第n丢失TCP包,第n丢失TCP包为TCP发送窗口丢掉的TCP包中在顺序上第n个被丢掉的TCP包;
接收第n TCP ACK,第n TCP响应ACK为接收端针对接收到的第n丢失TCP包发送的ACK;
确定第n TCP ACK的确认序号是否小于恢复序号;
当第n TCP ACK的确认序号小于恢复序号,则确定TCP发送窗口丢掉了第n+1丢失TCP包,第n+1丢失TCP包为TCP发送窗口丢掉的TCP包中的第n+1个被丢掉的TCP包,其中n为自然数,且n≥2。
可选的,如图6所示,还可以包括:
第一调整单元014,用于当接收到规定数量的重复的TCP响应ACK时,若确定TCP发送窗口因拥塞而产生丢包,则将拥塞控制窗口减半来获取调整后的拥塞控制窗口,并将慢启动阈值减半来获取调整后的慢启动阈值;
若确定TCP发送窗口因拥塞以外的原因而产生丢包,则将拥塞控制窗口与乘法减小因子相乘,来获取调整后的拥塞控制窗口,并将慢启动阈值与乘法减小因子相乘,来获取调整后的慢启动阈值。
可选的,还可以包括:第二调整单元015,用于当重传定时器超时时,若确定TCP发送窗口因拥塞而产生丢包,将拥塞控制窗口降为1,并将拥塞控制窗口减半后的值作为调整后的慢启动阈值;
若确定TCP发送窗口因拥塞以外的原因而产生丢包,则将拥塞控制窗口降为1,并将拥塞控制窗口与乘法减小因子相乘,将相乘后的拥塞控制窗口的值作为调整后的慢启动阈值。
本发明实施例提供一种终端,通过确定传输控制协议TCP发送窗口产生的丢包的数量,当丢包的数量大于门限值时,确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3,当TCP发送窗口产生的全部丢包的数量不大于门限值时,确定TCP发送窗口因拥塞以外的原因而产生丢包,根据丢包原因对拥塞控制窗口和慢启动阈值进行调整,能够简单高效地确定丢包类型,以便根据丢包类型做相应的调整。
本发明又一实施例提供一种终端02,如图7所示,该终端02可以包括:
处理器(Processor)021,通信接口(Communications Interface)022,存储器(Memory)023,通信总线024。
处理器021,通信接口022,存储器023通过通信总线024完成相互间的通信。
通信接口022,用于与网元通信,比如客户端或服务器等。
处理器021,用于执行程序025,具体可以执行上述图1或图2所示的方法实施例中的相关步骤。
具体的,程序025可以包括程序代码,程序代码包括计算机操作指令。
处理器021可能是一个中央处理器CPU,或者是特定集成电路ASIC(Application Specific Integrated Circuit),或者是被配置成实施本发明实施例的一个或多个集成电路。
存储器023,用于存放程序025。存储器023可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。程序025具体可以包括:
数量确定单元011,用于确定传输控制协议TCP发送窗口产生的丢包的数量。
丢包分析单元012,用于当丢包的数量大于门限值时,确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3。
可选的,丢包分析单元还可以用于当TCP发送窗口产生的全部丢包的数量不大于门限值时,确定TCP发送窗口因拥塞以外的原因而产生丢包。
可选的,可以包括:
丢包检测单元013,用于若接收到规定数量的重复的TCP响应ACK,则确定产生丢包;或
若重传定时器超时,则确定产生丢包。
程序025中各单元的具体实现可以参见图3至图5所示实施例中的相应模块,在此不赘述。
本发明实施例提供一种终端,通过确定传输控制协议TCP发送窗口产生的丢包的数量,当丢包的数量大于门限值时,确定TCP发送窗口因拥塞而产生丢包,门限值为1、2或3,当TCP发送窗口产生的全部丢包的数量不大于门限值时,确定TCP发送窗口因拥塞以外的原因而产生丢包,根据丢包原因对拥塞控制窗口和慢启动阈值进行调整,能够简单高效地确定丢包类型,以便根据丢包类型做相应的调整。
在本申请所提供的几个实施例中,应该理解到,所揭露的方法和终端,可以通过其它的方式实现。例如,以上所描述的设备实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
另外,在本发明各个实施例中的中,各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理包括,也可以两个或两个以上单元集成在一个单元中。且上述的各单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read Only Memory,简称ROM)、随机存取存储器(Random Access Memory,简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种确定丢包原因的方法,其特征在于,所述方法包括:
确定传输控制协议TCP发送窗口产生的丢包的数量;
当所述丢包的数量大于门限值时,确定所述TCP发送窗口因拥塞而产生所述丢包,所述门限值为1、2或3。
2.根据权利要求1所述的方法,其特征在于,当所述TCP发送窗口产生的全部丢包的数量不大于所述门限值时,确定TCP发送窗口因拥塞以外的原因而产生所述丢包。
3.根据权利要求1或2所述的方法,其特征在于,所述产生所述丢包包括:
若接收到规定数量的重复的TCP响应ACK,则确定产生所述丢包;或
若重传定时器超时,则确定产生所述丢包。
4.根据权利要求1至3中任一项所述的方法,其特征在于,所述确定TCP发送窗口产生的丢包的数量包括:
确定所述TCP发送窗口丢掉了第一丢失TCP包,所述第一丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第一个被丢掉的TCP包;
获取恢复序号,所述恢复序号为所述TCP发送窗口在确定所述TCP发送窗口丢掉了第一丢失TCP包时已发送的TCP包中的最大发送序号与1的和;
向接收端重传所述第一丢失TCP包;
接收第一TCP响应ACK,所述第一TCP ACK为所述接收端针对接收到的所述第一丢失TCP包发送的ACK;
确定所述第一TCP ACK的确认序号是否小于所述恢复序号;
若所述第一TCP ACK的确认序号小于所述恢复序号,则确定所述TCP发送窗口丢掉了第二丢失TCP包,所述第二丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第二个被丢掉的TCP包。
5.根据权利要求4所述的方法,其特征在于,所述确定TCP发送窗口的丢包数量还包括:
在确定所述TCP发送窗口丢掉了第n丢失TCP包后,向所述接收端重传所述第n丢失TCP包,所述第n丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第n个被丢掉的TCP包;
接收第n TCP ACK,所述第n TCP ACK为所述接收端针对接收到的所述第n丢失TCP包发送的ACK;
确定所述第n TCP ACK的确认序号是否小于所述恢复序号;
若所述第n TCP ACK的确认序号小于所述恢复序号,则确定所述TCP发送窗口丢掉了第n+1丢失TCP包,所述第n+1丢失TCP包为所述TCP发送窗口丢掉的TCP包中的第n+1个被丢掉的TCP包,其中n为自然数,且n≥2。
6.根据权利要求3至5任意一项所述的方法,其特征在于,当接收到规定数量的重复的TCPACK时,
若确定所述TCP发送窗口因拥塞而产生所述丢包,则将拥塞控制窗口减半来获取调整后的拥塞控制窗口,并将慢启动阈值减半来获取调整后的慢启动阈值;
若确定TCP发送窗口因拥塞以外的原因而产生所述丢包,则将所述拥塞控制窗口与乘法减小因子相乘,来获取调整后的拥塞控制窗口,并将所述慢启动阈值与所述乘法减小因子相乘,来获取调整后的慢启动阈值。
7.根据权利要求3至5任意一项所述的方法,其特征在于,当重传定时器超时,
若确定所述TCP发送窗口因拥塞而产生所述丢包,将所述拥塞控制窗口降为1,并将所述拥塞控制窗口减半后的值作为调整后的慢启动阈值;
若确定TCP发送窗口因拥塞以外的原因而产生所述丢包,则将所述拥塞控制窗口降为1,并将所述拥塞控制窗口与所述乘法减小因子相乘,将相乘后的拥塞控制窗口的值作为调整后的慢启动阈值。
8.一种终端,其特征在于,包括:
数量确定单元,用于确定传输控制协议TCP发送窗口产生的丢包的数量;
丢包分析单元,用于当所述丢包的数量大于门限值时,确定所述TCP发送窗口因拥塞而产生所述丢包,所述门限值为1、2或3。
9.根据权利要求8所述的终端,其特征在于,所述丢包分析单元还用于当所述TCP发送窗口产生的全部丢包的数量不大于所述门限值时,确定TCP发送窗口因拥塞以外的原因而产生所述丢包。
10.根据权利要求8或9所述的终端,其特征在于,包括:
丢包检测单元,用于若接收到规定数量的重复的TCP响应ACK,则确定产生所述丢包;或
若重传定时器超时,则确定产生所述丢包。
11.根据权利要求8至10中任一项所述的终端,其特征在于,所述数量确定单元具体包括:
第一确定子单元,用于确定所述TCP发送窗口丢掉了第一丢失TCP包,所述第一丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第一个被丢掉的TCP包;
序号获取子单元,用于获取恢复序号,所述恢复序号为所述TCP发送窗口在确定所述TCP发送窗口丢掉了第一丢失TCP包时已发送的TCP包中的最大发送序号与1的和;
第一重传子单元,用于向接收端重传所述第一丢失TCP包;
第一响应子单元,用于接收第一TCP响应ACK,所述第一TCPACK为所述接收端针对接收到的所述第一丢失TCP包发送的ACK;
第一判断单元,用于确定所述第一TCP ACK的确认序号是否小于所述恢复序号;
第一判断单元还用于当所述第一TCP ACK的确认序号小于所述恢复序号,则确定所述TCP发送窗口丢掉了第二丢失TCP包,所述第二丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第二个被丢掉的TCP包。
12.根据权利要求11所述的终端,其特征在于,所述数量确定单元还用于:
在确定所述TCP发送窗口丢掉了第n丢失TCP包后,向所述接收端重传所述第n丢失TCP包,所述第n丢失TCP包为所述TCP发送窗口丢掉的TCP包中在顺序上第n个被丢掉的TCP包;
接收第n TCP ACK,所述第n TCP ACK为所述接收端针对接收到的所述第n丢失TCP包发送的ACK;
确定所述第n TCP ACK的确认序号是否小于所述恢复序号;
当所述第n TCP ACK的确认序号小于所述恢复序号,则确定所述TCP发送窗口丢掉了第n+1丢失TCP包,所述第n+1丢失TCP包为所述TCP发送窗口丢掉的TCP包中的第n+1个被丢掉的TCP包,其中n为自然数,且n≥2。
13.根据权利要求10至12任意一项所述的终端,其特征在于,还包括:
第一调整单元,用于当接收到规定数量的重复的TCP ACK时,若确定所述TCP发送窗口因拥塞而产生所述丢包,则将拥塞控制窗口减半来获取调整后的拥塞控制窗口,并将慢启动阈值减半来获取调整后的慢启动阈值,若确定TCP发送窗口因拥塞以外的原因而产生所述丢包,则将所述拥塞控制窗口与乘法减小因子相乘,来获取调整后的拥塞控制窗口,并将所述慢启动阈值与所述乘法减小因子相乘,来获取调整后的慢启动阈值。
14.根据权利要求10至12任意一项所述的终端,其特征在于,还包括:
第二调整单元,用于当重传定时器超时,若确定所述TCP发送窗口因拥塞而产生所述丢包,将所述拥塞控制窗口降为1,并将所述拥塞控制窗口减半后的值作为调整后的慢启动阈值,若确定TCP发送窗口因拥塞以外的原因而产生所述丢包,则将所述拥塞控制窗口降为1,并将所述拥塞控制窗口与所述乘法减小因子相乘,将相乘后的拥塞控制窗口的值作为调整后的慢启动阈值。
CN201310049693.9A 2013-02-07 2013-02-07 一种确定丢包原因的方法和终端 Active CN103986548B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201310049693.9A CN103986548B (zh) 2013-02-07 2013-02-07 一种确定丢包原因的方法和终端

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201310049693.9A CN103986548B (zh) 2013-02-07 2013-02-07 一种确定丢包原因的方法和终端

Publications (2)

Publication Number Publication Date
CN103986548A true CN103986548A (zh) 2014-08-13
CN103986548B CN103986548B (zh) 2018-02-23

Family

ID=51278379

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201310049693.9A Active CN103986548B (zh) 2013-02-07 2013-02-07 一种确定丢包原因的方法和终端

Country Status (1)

Country Link
CN (1) CN103986548B (zh)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105141476A (zh) * 2015-08-18 2015-12-09 大唐移动通信设备有限公司 一种tcp报文出错信息的获取方法和装置
CN105791008A (zh) * 2016-03-02 2016-07-20 华为技术有限公司 确定丢包位置和原因的方法和装置
WO2017097201A1 (zh) * 2015-12-09 2017-06-15 华为技术有限公司 一种数据传输方法、发送装置及接收装置
CN107426108A (zh) * 2017-10-09 2017-12-01 武汉斗鱼网络科技有限公司 Tcp拥塞控制方法、装置及服务端
CN107872820A (zh) * 2016-11-22 2018-04-03 中国移动通信集团湖南有限公司 Epc网络数据处理方法、装置及epc网络
CN108270682A (zh) * 2016-12-30 2018-07-10 华为技术有限公司 一种报文传输方法、终端、网络设备及通信系统
CN109104742A (zh) * 2017-06-20 2018-12-28 华为技术有限公司 拥塞窗口调整方法及发送设备
CN109218119A (zh) * 2017-06-30 2019-01-15 迈普通信技术股份有限公司 网络丢包诊断方法及网络设备
CN109818874A (zh) * 2017-11-21 2019-05-28 华为技术有限公司 数据传输方法、设备及计算机存储介质
US10601554B2 (en) 2015-09-21 2020-03-24 Huawei Technologies Co., Ltd. Packet transmission method and user equipment
US10771595B2 (en) 2016-11-02 2020-09-08 Huawei Technologies Co., Ltd. Packet sending method and apparatus, chip, and terminal
CN112492646A (zh) * 2020-11-27 2021-03-12 清华大学 基于拥塞成因识别的拥塞控制方法及装置
CN112953847A (zh) * 2021-01-27 2021-06-11 北京字跳网络技术有限公司 网络的拥塞控制方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1440166A (zh) * 2002-02-04 2003-09-03 松下电器产业株式会社 用于分组丢失区分的方法和实体
CN101102235A (zh) * 2007-07-26 2008-01-09 北京交通大学 一种测量切换时间的方法和设备
CN101686100A (zh) * 2008-09-25 2010-03-31 华为技术有限公司 处理丢包的方法、传输质量控制方法、装置及系统
CN102420676A (zh) * 2011-11-30 2012-04-18 中国人民解放军西安通信学院 一种适用于深空星际卫星网络的高效交互传输方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1440166A (zh) * 2002-02-04 2003-09-03 松下电器产业株式会社 用于分组丢失区分的方法和实体
CN101102235A (zh) * 2007-07-26 2008-01-09 北京交通大学 一种测量切换时间的方法和设备
CN101686100A (zh) * 2008-09-25 2010-03-31 华为技术有限公司 处理丢包的方法、传输质量控制方法、装置及系统
CN102420676A (zh) * 2011-11-30 2012-04-18 中国人民解放军西安通信学院 一种适用于深空星际卫星网络的高效交互传输方法

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105141476A (zh) * 2015-08-18 2015-12-09 大唐移动通信设备有限公司 一种tcp报文出错信息的获取方法和装置
CN105141476B (zh) * 2015-08-18 2018-12-18 大唐移动通信设备有限公司 一种tcp报文出错信息的获取方法和装置
US11153041B2 (en) 2015-09-21 2021-10-19 Huawei Technologies Co., Ltd. Packet transmission method and user equipment
US10601554B2 (en) 2015-09-21 2020-03-24 Huawei Technologies Co., Ltd. Packet transmission method and user equipment
WO2017097201A1 (zh) * 2015-12-09 2017-06-15 华为技术有限公司 一种数据传输方法、发送装置及接收装置
CN105791008B (zh) * 2016-03-02 2019-10-22 华为技术有限公司 确定丢包位置和原因的方法和装置
CN105791008A (zh) * 2016-03-02 2016-07-20 华为技术有限公司 确定丢包位置和原因的方法和装置
US10771595B2 (en) 2016-11-02 2020-09-08 Huawei Technologies Co., Ltd. Packet sending method and apparatus, chip, and terminal
CN107872820A (zh) * 2016-11-22 2018-04-03 中国移动通信集团湖南有限公司 Epc网络数据处理方法、装置及epc网络
CN107872820B (zh) * 2016-11-22 2020-12-04 中国移动通信集团湖南有限公司 Epc网络数据处理方法、装置及epc网络
CN108270682A (zh) * 2016-12-30 2018-07-10 华为技术有限公司 一种报文传输方法、终端、网络设备及通信系统
CN109104742A (zh) * 2017-06-20 2018-12-28 华为技术有限公司 拥塞窗口调整方法及发送设备
CN109218119A (zh) * 2017-06-30 2019-01-15 迈普通信技术股份有限公司 网络丢包诊断方法及网络设备
CN109218119B (zh) * 2017-06-30 2020-11-27 迈普通信技术股份有限公司 网络丢包诊断方法及网络设备
CN107426108A (zh) * 2017-10-09 2017-12-01 武汉斗鱼网络科技有限公司 Tcp拥塞控制方法、装置及服务端
CN109818874A (zh) * 2017-11-21 2019-05-28 华为技术有限公司 数据传输方法、设备及计算机存储介质
CN109818874B (zh) * 2017-11-21 2022-06-28 华为技术有限公司 数据传输方法、设备及计算机存储介质
CN112492646A (zh) * 2020-11-27 2021-03-12 清华大学 基于拥塞成因识别的拥塞控制方法及装置
CN112953847A (zh) * 2021-01-27 2021-06-11 北京字跳网络技术有限公司 网络的拥塞控制方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN103986548B (zh) 2018-02-23

Similar Documents

Publication Publication Date Title
CN103986548A (zh) 一种确定丢包原因的方法和终端
EP3855688B1 (en) Sending node, receiving node, and data transmission system
US7296206B2 (en) Communication device, transmission control method, and program product
US9350663B2 (en) Enhanced large data transmissions and catastrophic congestion avoidance over TCP/IP networks
CN102388584B (zh) 拥塞控制方法及设备
EP2109954B1 (en) Ack prioritization in wireless networks
Lin et al. TCP fast recovery strategies: Analysis and improvements
CN102006230B (zh) 一种有线/无线混合网络中融合三种信息的拥塞控制方法
US10064073B2 (en) Optimizing bandwidth of cognitive radios
CN101369877B (zh) 无线传输控制协议处理方法和设备
CN104243090A (zh) 一种基于无线信道反馈的发送速率调整方法和设备
Paxson et al. TCP congestion control
CN107800638B (zh) 一种拥塞控制方法及装置
CN104125159A (zh) 一种拥塞带宽检测方法、拥塞控制方法、装置及系统
WO2010064421A1 (ja) 通信装置、通信方法
CN105227484B (zh) 一种面向卫星网络的数据传输控制方法
KR20040027176A (ko) 무선 환경에서의 혼잡제어방법 및 기록매체
CN108432287A (zh) 一种数据传输方法及网络侧设备
CN101969432A (zh) 基于随机回退的tcp拥塞窗口的控制方法
CN104980365A (zh) 一种基于连续丢包拥塞判断的tcp传输加速方法
CN105406915A (zh) 一种面向星地链路的文件传输方法
CN104580171B (zh) Tcp协议的传输方法、装置和系统
CN104702531A (zh) 一种网络设备拥塞避免的方法及网络设备
Kamboj et al. Various TCP options for congestion evasion
Altahir et al. Performance evaluation of TCP congestion control mechanisms using NS-2

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant