首页> 中国专利> 一种广域网TCP单边加速的方法及系统

一种广域网TCP单边加速的方法及系统

摘要

本发明公开了一种广域网TCP单边加速的方法及系统,其中,该方法包括:采集传输控制协议TCP数据包的往返延迟,并从TCP协议栈获取丢包信号;根据所述往返延迟以及丢包信号,计算出预期的拥塞控制窗口大小,并且根据预期的拥塞窗口大小,在下一个RTT周期内进行拥塞控制窗口大小的调整,从而实现广域网TCP单边加速。通过采用本发明公开的方法及系统,使得TCP连接能够更加充分的利用广域网链路的带宽资源,进而提升用户体验。

著录项

  • 公开/公告号CN104158760A

    专利类型发明专利

  • 公开/公告日2014-11-19

    原文格式PDF

  • 申请/专利权人 中国科学技术大学;

    申请/专利号CN201410437208.X

  • 发明设计人 陆世亮;朱明;

    申请日2014-08-29

  • 分类号H04L12/807(20130101);H04L12/26(20060101);

  • 代理机构11260 北京凯特来知识产权代理有限公司;

  • 代理人郑立明;郑哲

  • 地址 230026 安徽省合肥市包河区金寨路96号

  • 入库时间 2023-12-17 03:36:34

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2018-08-03

    授权

    授权

  • 2014-12-17

    实质审查的生效 IPC(主分类):H04L12/807 申请日:20140829

    实质审查的生效

  • 2014-11-19

    公开

    公开

说明书

技术领域

本发明涉及互联网信息传输技术领域,尤其涉及一种广域网TCP单边加速的方法及系 统。

背景技术

近十年来,互联网飞速发展,互联网信息内容在急剧的膨胀,人们对互联网的依赖 也日益强烈,但是与之不成比例的是数据传输的速率仍然非常有限,用户对于快速数据 传输的需求与实际有限的数据传输速率之间的矛盾正在制约着互联网的发展速度。

关于如何提升广域网的链路带宽使用率,加速用户访问互联网资源的速率,方法有 多种,TCP单边加速方案则是一种简单易行容易部署的途径,而TCP单边加速的主要实 现方式是改良旧的拥塞控制算法,或者设计新的拥塞控制算法,传统的针对高带宽和大 延迟广域网的TCP拥塞控制算法包括new reno,vega,cubic等。

下面将分别介绍Tahoe,NewReno,Vegas以及Cubic四种现有的TCP(传输控制协 议)拥塞控制算法。

1、Tahoe算法是TCP的早期版本。它的核心思想是:在初始阶段,让cwnd(拥塞窗 口)以指数增长方式迅速逼进可用信道容量,当cwnd大于阈值之后,再减小cwnd的增长 速度,进行乘性增,缓慢的逼近可用信道容量。Tahoe包括3个基本的拥塞控制算法: “慢启动”、“拥塞避免”和“快速重传”。

(1)慢启动:避免了连接建立时突发数据流对网络的冲击。初始设置cwnd为1,并按 指数型方式增长,也就是每收到一个确认(ACK),cwnd增大1,直至cwnd超过阈值 ssthresh。当cwnd>=ssthresh时,Tahoe进入拥塞避免阶段。

(2)拥塞避免:限制传输过程中无限制的速率增长,避免由此可能导致的拥塞。cwnd 以线性方式增长,这里所谓的线性方式增长,是指,收到上一个RTT内的所有确认之后, 才把cwnd加大1,如果发生超时或者连续收到3个重复ACK,Tahoe认为发生了拥塞。对 于超时,置ssthresh为当前拥塞窗口的一半,cwnd=1,转入慢启动,开始指数的增大 cwnd的值,如果收到3个连续ACK,则Tahoe进入快速重传阶段。

(3)快速重传:根据3个重复的应答报文来判断丢包,减少了超时重传的发生,加快 了源端对拥塞的响应,使得拥塞能快速消除。立即重传丢失的分组,同时置ssthresh为当 前拥塞窗口的一半,cwnd=1,转入慢启动。可以看出,tahoe算法对于超时以及重复确 认的处理是基本相似的。

Tahoe算法存在着不足之处:在收到3个重复ACK或在超时的情况下,Tahoe置cwnd 为1,然后进入慢启动阶段。这一方面会引起网络的激烈振荡,另一方面大大降低了网络 的利用率。

2、NewReno算法。该算法对Reno中“快速恢复”算法进行了补充,它考虑了一个 发送窗口内多个报文同时丢失的情况。在Reno算法中,发送方收到一个不重复的应答后 就退出“快速恢复”状态。而在NewReno中,只有当进入快速重传/快速恢复阶段的那一 刻的发送窗口内的所有报文都被应答后才退出“快速恢复”状态。

具体执行过程是:在快速恢复期间,TCP发送端收到一个ACK后,发送端通过此 ACK应答推断出下一个丢失的数据包序列号,并且立即重传那个数据包。这样, NewReno在每个RTT内重传一个丢失的数据包,直到发生多个数据包丢失的窗口中所有 丢失数据包被重传,而不是等到超时在这个期间如果还有其它重复的ACK到来,则继续 快速恢复算法,直到在快速恢复初始时所有未确认数据包都被确认。

尽管对Reno算法进行了完善,但是由于缺乏足够的信息来对链路拥塞状态进行预 判,NewReno仍然会在TCP连接过程中导致周期性的丢包,以及随着而来的拥塞窗口的 锐减,最后导致链路带宽的浪费。

3、Vegas算法。该算法是一个得到普遍认可,但是未能获得广泛应用的算法。 Vegas与上述介绍的算法不同,它以rtt样本值的变化作为拥塞信号,调节源端的发送速 率。在算法的执行过程中,vegas会不断地采集得到rtt样本值,在每一个RTT结束的关 头,会进行rtt样本值的分析,如果发现rtt样本值变大,Vegas就认为网络发生拥塞,开始 减小cwnd;如果rtt样本值变小,Vegas则解除拥塞,再次增加cwnd,最关键的是,在链 接的初始阶段,vegas会根据得到的rtt样本值,判断拥塞的提前到来,进而提前的转入拥 塞避免阶段,这样,在理想情况下,cwnd值会稳定在一个合适的范围内。

这里需要注明的是,rtt样本值是针对单个tcp数据包而言的,对于每个发送的tcp数据 包,都会计算它的往返延时,这个往返延时就是要采样的rtt样本值,而RTT是针对tcp发 送队列而言的,该RTT在某个特定的时刻指代的是该发送队列中的一块数据,只有这块数 据都被接收方确认了,那么当前RTT才算结束,进而转入下一个RTT,这时候针对的又是 后面的一部分数据了。

Vegas的重传策略与上述算法也不同,它是在收到一个重复ACK后,比较数据包发出 的时间和当前时间,然后决定是否重发。这样能更及时地重传丢失的数据包,提高响应 速度。但是,由于Vegas与其它算法在竞争带宽方面存在不公平现象,因此未能在 Internet上普遍采用,还需不断改进。

4、cubic算法是基于丢包的拥塞控制算法,核心是一个立方体公式:

W=C(t–K)3+Wmax

其中K=Wmax*p/C的开三次方。

该公式在实现中的逻辑就是,当发生丢包的时候,记录下此时的拥塞控制窗口大 小,记为Wmax,然后将该窗口大小减小p倍,也就是减小Wmax*p,然后进入丢包恢复 阶段,随着有新的ack到来,根据上面的公式,不断地增加拥塞窗口的大小,该公式的特 点就是,在上升至Wmax的过程中,增长逐渐减慢,当超过Wmax后,增长逐渐的加快, 直到发生下一次丢包,然后重复上面的过程。但是cubic毕竟仅仅基于丢包,能获得关于 实际网络状况的信息较少,这就导致它绝大多数的时间都处在寻找临界窗口的状态,最 终导致对于带宽的实际使用率受到了限制,不能够充分的利用链路的带宽。

发明内容

本发明的目的是提供一种广域网TCP单边加速的方法及系统,使得TCP连接能够更加 充分的利用广域网链路的带宽资源,进而提升用户体验。

本发明的目的是通过以下技术方案实现的:

一种广域网TCP单边加速的方法,该方法包括:

采集传输控制协议TCP数据包的往返延迟,并从TCP协议栈获取丢包信号;

根据所述往返延迟以及丢包信号,计算出预期的拥塞控制窗口大小,并且根据预期 的拥塞窗口大小,在下一个RTT周期内进行拥塞控制窗口大小的调整,从而实现广域网 TCP单边加速。

一种广域网TCP单边加速的系统,该系统包括:

传输控制协议TCP拥塞控制模块,用于采集TCP数据包的往返延迟,并从TCP协议 栈获取丢包信号;根据所述往返延迟以及丢包信号,计算出预期的拥塞控制窗口大小, 并且根据预期的拥塞窗口大小,在下一个RTT周期内进行拥塞控制窗口大小的调整,从而 实现广域网TCP单边加速。

由上述本发明提供的技术方案可以看出,通过综合使用了往返延时以及丢包等信息作 为拥塞控制的基础,通过合理的建模和设计,有效地解决了现有拥塞控制算法无法有效 利用广域网带宽资源这一问题,进而提升用户体验。

附图说明

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

图1为本发明实施例一提供的一种广域网TCP单边加速的方法的流程图;

图2为本发明实施例一提供的又一种广域网TCP单边加速的方法的流程图;

图3为本发明实施例二提供的一种部署广域网TCP单边加速的系统的示意图。

具体实施方式

下面结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地 描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于 本发明的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他 实施例,都属于本发明的保护范围。

实施例一

图1为本发明实施例一提供的一种广域网TCP单边加速的方法的流程图。如图1所 示,该方法主要包括如下步骤:

步骤11、采集传输控制协议TCP数据包的往返延迟,并从TCP协议栈获取丢包信 号。

步骤12、根据所述往返延迟以及丢包信号,计算出预期的拥塞控制窗口大小,并且 根据预期的拥塞窗口大小,在下一个RTT周期内进行拥塞控制窗口大小的调整,从而实现 广域网TCP单边加速。

本发明实施例中,所述计算出预期的拥塞控制窗口大小包括:采用负反馈控制方法 进行计算,具体的:将获取到的丢包信号与往返延迟作为拥塞的信号;其中,将采集到 的TCP数据包的往返延迟中的最大值作为反馈控制的预期输入,将上一个RTT周期内采集 到的最大往返延迟作为实际的反馈控制系统输出。上述丢包信号和往返延迟的使用是并 列的关系,由于整个网络环境是不受任何人控制的,这也导致不可预期的丢包会随时发 生,使用丢包信号作为拥塞的信号,在丢包发生的时候进行拥塞窗口的减小,能够避免 网络陷入持久的拥塞,有助于拥塞的及时解除和负反馈机制的重新使用,丢包信号和往 返延迟本同时作为拥塞的表征信号,是本系统不可或缺的两个信息来源。

同时,还可使用平滑方法进行拥塞控制窗口大小的调整,具体的:利用计算得到的 实际拥塞控制窗口大小和所述预期的拥塞控制窗口大小的差值,作为下一个RTT周期的调 整大小;利用该差值,在下一个RTT周期内进行平摊,减缓拥塞控制窗口的调整速度。

另外,该方法还可利用TCP内核中的拥塞控制算法接口tcp_congestion_ops作为算法 的实现容器,无需修改TCP协议栈;同时,利用TCP拥塞控制算法的模块化加载技术, 还可以实现当前算法的自动热加载。

另一方面,基于该方法在实际工作中的流程图如图2所示,首先,判断当前RTT周期 是否已经结束;如果是,则根据采集到的rtt样本计算出预期的拥塞窗口大小,并且记录下 前后拥塞窗口大小的增量,进而转入下一个RTT周期;如果不是,那么接着采样rtt样本, 并且根据上一个RTT周期末尾记录下来的拥塞窗口增量,调整拥塞窗口的大小。

本发明实施例通过综合使用了往返延时以及丢包等信息作为拥塞控制的基础,通过 合理的建模和设计,有效地解决了现有拥塞控制算法无法有效利用广域网带宽资源这一 问题,进而提升用户体验。

实施例二

本发明实施例提供一种广域网TCP单边加速的系统,该系统主要包括:

传输控制协议TCP拥塞控制模块,用于采集TCP数据包的往返延迟,并从TCP协议 栈获取丢包信号;根据所述往返延迟以及丢包信号,计算出预期的拥塞控制窗口大小, 并且根据预期的拥塞窗口大小,在下一个RTT周期内进行拥塞控制窗口大小的调整,从而 实现广域网TCP单边加速。

进一步,所述计算出预期的拥塞控制窗口大小包括:

采用负反馈控制方法进行计算,具体的:将获取到的丢包信号与往返延迟作为拥塞 的信号;其中,将采集到的TCP数据包的往返延迟中的最大值作为反馈控制的预期输 入,将上一个RTT周期内采集到的最大往返延迟作为实际的反馈控制系统输出。

进一步的,所述在下一个RTT周期内进行拥塞控制窗口大小的调整包括:

使用平滑方法进行拥塞控制窗口大小的调整,具体的:利用计算得到的实际拥塞控 制窗口大小和所述预期的拥塞控制窗口大小的差值,作为下一个RTT周期的调整大小;利 用该差值,在下一个RTT周期内进行平摊,减缓拥塞控制窗口的调整速度。

另外,该系统还可以直接部署在单独的机器上,简单易行,便于管理。如图3所示, 为部署了该系统后实现广域网TCP单边加速的示意图。

需要说明的是,上述系统中包含的各个功能模块所实现的功能的具体实现方式在前 面的各个实施例中已经有详细描述,故在这里不再赘述。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模 块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模 块完成,即将系统的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分 功能。

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例可以 通过软件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理 解,上述实施例的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一 个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得 一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施 例所述的方法。

以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此, 任何熟悉本技术领域的技术人员在本发明披露的技术范围内,可轻易想到的变化或替 换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求书的 保护范围为准。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号