TCP拥塞控制算法之NewReno和SACK
TCP拥塞控制算法之NewReno和SACK
一、TCP Reno拥塞控制算法回顾
二、基于TCP Reno拥塞控制算法的改进
- 改进原因分析
TCP Reno 提出的快速恢复算法提高了丢失报文后的吞吐量和顽健性,但是:
仅考虑了每次拥塞发生时只丢失一个报文的情形。
实际网络中,一旦发生拥塞,路由器会丢弃大量的报文,即一次拥塞中丢失多个报文的情形很普遍。
下图是Reno算法中快速恢复状态和拥塞避免状态之间的相互转换:
- 一次拥塞中丢失多个报文时若采用Reno算法:(TCP Reno收到新的 ACK就会结束快速恢复,进入拥塞避免阶段)
会多次将拥塞窗口(cwnd)和慢启动阈值(ssthresh)减半,造成TCP的发送速率呈指数降低系统吞吐量急剧下降,(当发送窗口小于3时)无足够的重复ACK可以触发快速恢复,只能等待超时重传。TCP Reno 终端会陷入仅通过传输超时来发现报文丢失的困境中。
- 超时对于TCP的效果有很大的影响:
- 若遗失的数据包无法使用Fast-Retransmit/ Fast-recovery重送,就必须等待超时来触发重送的机制,在等待超时的这段时间,TCP不能重送新的数据,使得链路的使用率很低;
- 超时之后,cwnd的值会被重设为1,大大较低了TCP的传输效果。
所以,网络在一次拥塞中丢弃了多个报文,被TCP Reno错误地分析为传输中发生了多次拥塞。过度的窗口减小导致了传输超时的发生。因此为了提高一次拥塞中丢弃多个报文情形下TCP的性能,必须使TCP终端减少盲目削减发送窗口的行为。
- New Reno:基于Reno算法的改进
NewReno TCP在Reno TCP的基础上对快速恢复算法进行修改,只有一个数据包丢失的情况下,其机制和Reno是一样的;当同时有多个包丢失时就显示出了它的优势。
Reno快速恢复算法中发送方收到一个新的ACK就退出快速恢复状态,New Reno算法中只有当所有报文都被应答后才退出快速恢复状态。
NewReno TCP添加了恢复应答判断功能,以增强TCP终端通过ACK报文信息分析报文传输状况的能力。
使TCP终端可以把一次拥塞丢失多个报文的情形与多次拥塞的情形区分开来,进而在每一次拥塞发生后拥塞窗口仅减半一次,从而提高了TCP的顽健性和吞吐量。
两个概念:部分应答(PACK)、恢复应答(RACK)
记TCP发送端恢复阶段中接收到的ACK报文(非冗余ACK)为ACKx,记在接收到ACKx时TCP终端已发出的序列号(SN)最大的报文是PKTy,如果ACKx不是PKTy的应答报文,则称报文ACKx为部分应答(Partial ACK,简称PACK);若ACKx恰好是PKTy的应答报文则称报文ACKx为恢复应答(Recovery ACK,简称RACK)。
举例来理解:
如果4、5、6号包丢了,现在只重传4,只收到了4的ACK,后面的5、6没有确认,这就是部分应答Partial ACK。如果收到了6的ACK,则是恢复应答Recovery ACK。
TCP发送端接收到恢复应答表明:经过重传,TCP终端发送的所有报文都已经被接收端正确接收,网络已经从拥塞中恢复。
NewReno发送端在收到第一个Partial ACK时,并不会立即结束Fast-recovery,而会持续地重送Partial ACK之后的数据包,直到将所有遗失的数据包重送后才结束Fast-recovery。收到一个Partial ACK时,重传定时器就复位。这使得NewReno的发送端在网络有大量数据包遗失时不需等待Timeout就能更正此错误,减少大量数据包遗失对传输效果造成的影响。
NewReno大约每一个RTT时间可重传一个丢失的数据包,如果一个发送窗口有M个数据包丢失,TCP NewReno的快速恢复阶段将持续M个RTT。
- 改进的快速恢复算法具体步骤:
- 重新定义恢复阶段
- 进入恢复阶段后,发送端重传被认定为丢失的报文,设置慢启动阈值(ssthresh)和拥塞窗口大小(cwnd)。ssthresh = cwnd/2,cwnd = ssthresh + 3MSS。
- 收到一个重复ACK,cwnd=cwnd+MSS。
- 当收到PACK(部分应答)时,发送端重传PACK所确认报文的下一个报文,如果拥塞窗口允许,继续发送新的数据包。
- 当收到RACK(确认应答)时,发送端认为拥塞中所有被丢弃的报文都已经被重传,拥塞结束,设置cwnd=ssthresh并退出快速恢复状态。
快速恢复是基于数据包守恒的原则,即同一时刻能在网络中传输的数据包是恒定的,只有当旧数据包离开网络后,才能发送新数据包进入网络。一个重复ACK不仅意味着有一个包丢失了,还表示有发送的数据包离开了网络,已经在接收区的缓冲区中,不再占用网络资源,于是将拥塞窗口加一个数据包大小。
三、SACK算法
- Reno和NewReno算法仍存在的问题?
虽然NewReno可以解决大量数据包遗失的问题,但是NewReno在每个RTT时间只能一个数据包遗失的错误。为了更有效地处理大量数据包遗失的问题,另一个解决方法就是让传送端知道哪些已经被接收端收到,但用此方法必须同时修改传送端和接收端的传送机制。
缺乏SACK算法时发送端只能选择两种恢复策略:
- 每一个RTT时间内至多重传一个丢弃的包 (Reno和New Reno)
- 重传所有包,其中包括可能已经正确发送的包。 (Tahoe)
TCP SACK在TCP Reno基础上增加了:
- 选择确认(Selective Acknowledgements,SACK)
- 选择重传(Selective Retransmission)
当一个窗口内有多个数据包丢失时:
- 接收端:在ACK中报告其接收到的不连续的报文,使发送方准确地知道哪些数据包被接收方正确接收。
- 发送端:使用选择重传机制,可以在一个窗口中一次重传所有从一个窗口中丢失的数据包。
减少了时延,提高了网络吞吐量,使更快地从拥塞状态恢复。
SACK中加入了一个SACK选项(TCP option field),允许接收端在返回Duplicate ACK时,将已经收到的数据区段(连续收到的数据范围)返回给发送端,数据区段与数据区段之间的间隔就是接收端没有收到的数据。发送端就知道哪些数据包已经收到,哪些该重传,因此SACK的发送端可以在一个RTT时间内重传多个数据包。
整个TCP选项长度不超过40字节,实际最多不超过4组边界值。
通过一个wireshark示例来说明接收端的SACK行为:
上图中ACK确认序列号为12421,SACK的块左边界值为13801,SACK的块右边界值为15181。明确了这三个参数的数值,我们基本上就可以计算出被丢弃的数据报的序列号和长度了。通过上图所示的带有SACK的数据报文,我们可以知道被丢弃的数据报文的TCP序列号为12422,其数据长度为13801-12421=1380B。
改进的快速恢复算法:
pipe:TCP发送端发出的未被确认的数据报文数的估计值,网络中正在传输的分组数估计值;(决定了什么时候重传)
scoreboard:发送端保存,记录从SACK选项中得知的未被确认的分组。(指出了哪些分组需要重传)
1、进入快速恢复阶段后,只有当pipe<cwnd时,发送端才发送新数据包或重传丢失数据包。
2、发送端每次新发送或重传一个数据包后,pipe=pipe+1;
发送端每收到一个重复的包含SACK选项的ACK包后(新的分组被接到),pipe=pipe-1;
3、当发送端可以发送数据包时,重传scoreboard中指示的最后的数据包,如果计分板为空,则发送新的数据包;
4、当发送端收到PACK,pipe=pipe-2。因为PACK表示两个数据包离开了pipe,一个是丢失的数据包,一个是重传的数据包;
5、当发送端收到RACK后退出快速重传阶段。
四、基于仿真的TCP拥塞控制算法性能分析
仿真分为两组:
第一组对服务器进行访问的用户数为10,第二组用户数是90。
仿真结果如图。当用户较少。即网络拥塞情况不明显时,四种TCP实现的性能差别不大。
当网络用户增多导致网络出现严重的拥塞时,SACK和NewReno 显示了更优越的性能。
当网络拥塞不严重时,Reno,NewReno,SACK TCP都略优于Tahoe TCP;
当网络出现比较严重的拥塞,导致TCP的一个拥塞窗口丢失多个数据包时,
Reno TCP可能会进入超时等待阶段,性能甚至差于Tahoe TCP,
NewReno TCP可以较快地从拥塞中恢复,
SACK TCP恢复速度更快,对拥塞的处理更合理。
—————————————————————————————————————————
【参考文献】:(还有一些参考博客没有列出,如有侵权可以联系博主)
吴文红,李向丽.TCP拥塞控制机制定量性能分析.计算机工程与应用.2008,44(18)
孙伟,温涛,冯自勤,郭权.基于TCP NewReno的稳态吞吐量分析模型.计算机研究与发展.2010
陈琳,双雪芹.TCP网络拥塞控制算法比较研究.长江大学学报.2010,3
许豫飞,TCP拥塞控制算法集齐性能评估.北京邮电大学.2005,3
刘拥民,年晓红.对SACK拥塞控制算法的研究.信息技术.2003,9
焦程波,窦睿彧,兰巨龙.无线网络中选择性重传机制性能分析与改进.计算机应用研究.2007.3
James F.Kurose,Keith W.Ross,Computer Networking A Top-Down Approach Sixth Edition.机械工业出版社
TCP拥塞控制算法之NewReno和SACK的更多相关文章
- 网络拥塞控制(三) TCP拥塞控制算法
为了防止网络的拥塞现象,TCP提出了一系列的拥塞控制机制.最初由V. Jacobson在1988年的论文中提出的TCP的拥塞控制由“慢启动(Slow start)”和“拥塞避免(Congestion ...
- TCP拥塞控制算法纵横谈-Illinois和YeAH
周五晚上.终于下了雨.所以也终于能够乱七八糟多写点松散的东西了... 方法论问题. 这个题目太大以至于内容和题目的关联看起来有失偏颇.只是也无所谓,既然被人以为"没有方法论"而歧视 ...
- Linux TCP拥塞控制算法原理解析
这里只是简单梳理TCP各版本的控制原理,对于基本的变量定义,可以参考以下链接: TCP基本拥塞控制http://blog.csdn.net/sicofield/article/details/9708 ...
- TCP拥塞控制算法 优缺点 适用环境 性能分析
[摘要]对多种TCP拥塞控制算法进行简要说明,指出它们的优缺点.以及它们的适用环境. [关键字]TCP拥塞控制算法 优点 缺点 适用环境公平性 公平性 公平性是在发生拥塞时各源端(或同一源端 ...
- 让人非常easy误解的TCP拥塞控制算法
正文 非常多人会觉得一个好的TCP拥塞控制算法会让连接加速,这样的观点是错误的.恰恰相反,全部的拥塞控制算法都是为了TCP能够在贪婪的时候悬崖勒马,大多数时候.拥塞控制是减少了数据发送的速度. 我在本 ...
- 浅谈TCP拥塞控制算法
TCP通过维护一个拥塞窗口来进行拥塞控制,拥塞控制的原则是,只要网络中没有出现拥塞,拥塞窗口的值就可以再增大一些,以便把更多的数据包发送出去,但只要网络出现拥塞,拥塞窗口的值就应该减小一些,以减少注入 ...
- TCP拥塞控制算法
转自浅谈TCP拥塞控制算法 本篇文章介绍了几种经典的TCP拥塞控制算法,包括算法原理及各自适用场景. 回顾上篇文章:浅谈 redis 延迟 前言 TCP 通过维护一个拥塞窗口来进行拥塞控制,拥塞控制的 ...
- 【转载】TCP拥塞控制算法 优缺点 适用环境 性能分析
[摘要]对多种TCP拥塞控制算法进行简要说明,指出它们的优缺点.以及它们的适用环境. [关键字]TCP拥塞控制算法 优点 缺点 适用环境公平性 公平性 公平性是在发生拥塞时各源端(或同一源端 ...
- TCP拥塞控制算法内核实现剖析(十)
内核版本:3.2.12 主要源文件:linux-3.2.12/ net/ ipv4/ tcp_veno.c 主要内容:Veno的原理和实现 Author:zhangskd @ csdn blog 概要 ...
随机推荐
- babel tsc webpack
我要用啥?js的话:babel编译+webpack模块打包ts的话:tsc编译成js+babel编译+webpack模块打包浏览器情况:如果您的浏览器支持es6所有语法那么就可以只用webpack来处 ...
- django类视图as_view()方法解析
使用视图函数时,django完成URL解析之后,会直接把request对象以及URL解析器捕获的参数(比如re_path中正则表达捕获的位置参数或关键字参数)丢给视图函数,但是在类视图中,这些参数不能 ...
- java 随机生成4位随机数
java 随机生成4位的随机数测试类 @org.junit.Testpublic void testRandom(){ String msg="您的注册码为%s,谢谢注册!"; S ...
- Java8新特性 - Optional容器类
Optional 类(java.util.Optional) 是一个容器类,代表一个值存在或不存在,原来用null 表示一个值不存在,现在Optional 可以更好的表达这个概念.并且可以避免空指针异 ...
- SQL Server2008存储过程中函数的用法(举例)
USE 数据库 GO SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGO CREATE function 函数名称 (@EmpID nvarcha ...
- ef core2.2 mysql迁移问题
前段时间,遇到的是ef core mysql迁移的时候,bool类型会自动yingsheweishort的问题,需要手动更正一下今天测试的时候,遇到了MySQL数据表修改后迁移的问题. 问题详情如下 ...
- CSS3或CSS+JS实现改变滚动条样式(兼容所有浏览器)
/*定义滚动条高宽及背景 高宽分别对应横竖滚动条的尺寸*/ ::-webkit-scrollbar { width: 16px; /*滚动条宽度*/ height: 16px; /*滚动条高度*/ } ...
- 七年开发经验详解JVM的GC 算法
概述 GC 是 JVM 自带的功能,它能够自动回收对象,清理内存,这是 Java 语言的一大优势,但是GC绝不仅伴随着Java,相反,GC历史比Java更悠久.关于GC,我认为有四个问题需要解决: 为 ...
- 七年开发小结MyBatis 在 Spring 环境下的事务管理
MyBatis的设计思想很简单,可以看做是对JDBC的一次封装,并提供强大的动态SQL映射功能.但是由于它本身也有一些缓存.事务管理等功能,所以实际使用中还是会碰到一些问题——另外,最近接触了JFin ...
- Android面试题 描述一下android的系统架构
android系统架构从下往上为linux内核层.运行库.应用程序框架层和应用程序层. Linux Kernel:负责硬件的驱动程序.网络.电源.系统安全以及内存管理等功能. Libraries和an ...