下载文档原格式
TCP系列54—拥塞控制—17、AQM及ECN⼀、概述ECN的相关内容是在RFC3168中定义的，这⾥我简单描述⼀下RFC3168涉及的主要内容。
1、AQM和RED⽬前TCP中多数的拥塞控制算法都是通过缓慢增加拥塞窗⼝直到检测到丢包来进⾏慢启动的，这就会导致数据包在路由器缓存队列堆积，当路由器没有复杂的调度和缓存管理策略的时候，路由器⼀般简单的按照先进先出(FIFO)⽅式处理数据包，并在缓存队列满的时候就会丢弃新数据包(drop tail)，这种FIFO/drop tail的路由器称为passive路由器，会导致多个TCP流同时检测到丢包，削减拥塞窗⼝，并进⾏对应的数据包重传流程。
⽽active的路由器则会有相对⾼级的调度和队列缓存策略，这种路由器⽤来管理缓存队列的⽅法就称为AQM(active queue management)机制。
路由器的AQM机制则会在路由器队列满之前探测到拥塞，并提供⼀个拥塞指⽰。
AQM可以使⽤丢包或者本⽂后⾯要介绍的IP头中的Congestion Experienced (CE) codepoint来指⽰拥塞，这样就削减了丢包重传的影响，降低了⽹络延迟。
之所以把CE 指⽰放到IP头中是因为多数路由器对IP头的处理效率要⾼于对IP选项的处理效率。
Random Early Detection (RED)则是AQM机制中⽤来探测拥塞和控制拥塞标记的⼀种⽅法。
RED中有两个门限⼀个是minthresh，另外⼀个是maxthresh，当平均队列长度⼩于minthresh的时候，这个数据包总是会被接收处理，当平均队列长度超过maxthresh的时候，这个数据包总是会被⽤来指⽰拥塞(可能通过丢包或者设置CE来指⽰拥塞)，当平均队列长度位于⼆者之间的时候，则会有⼀定的概率这个数据包被⽤来指⽰拥塞。
RED算法是很多⽤在路由器和交换机中类似变种的基础，例如思科的WRED。
2、ECNECN(Explicit Congestion Notification)则是在AQM机制的基础上，路由器显式指⽰TCP发⽣拥塞的的⼀种机制，中⽂⼀般称呼为显式拥塞通告或者显式拥塞通知。
tcpip拥塞控制、重传、丢包、优化弱⽹环境是丢包率较⾼的特殊场景，TCP 在类似场景中的表现很差，当 RTT 为 30ms 时，⼀旦丢包率达到了 2%，TCP 的吞吐量就会下降89.9%[3]，从下⾯的表中我们可以看出丢包对 TCP 的吞吐量极其显著的影响：概念理解4种计时器1.重传计时器：Retransmission Timer A发报⽂时创建计时器，计时器到期内收到回报⽂ACK，就撤销计时器2.持久计时器：Persistent Timer B告诉A，接收窗⼝填满了（0窗⼝通报），告诉A停⽌发送，进⼊等待，直到B发送报⽂告诉A已有“⾮零窗⼝”，但此时若这个报⽂丢失，B⾃⼰不知道，等着A发数据过来，双⽅都进⼊等待死锁，解决这个问题要在A端创建持久计时器，当收到B发送过来的0窗⼝通报报⽂后，计时器启动，计时器过期后，A发⼀个探测报⽂给B，询问是否有⾮0窗⼝，如果超时还没ack恢复则发探查报⽂，如果超时前收到到ack回复依然是0窗⼝，则将计时器复位并且翻倍时间值（1，2，4，8最⼤60s），如此循环，直到收到B的重开窗⼝确认包。
3.保活计时器：Keeplive Timer 长连接中A发送数据给B，发送⼏个数据包之后，A出故障了，B等待2⼩时后发10个探测报⽂段（每个75分钟发⼀次），如果没有响应就终⽌连接4.时间等待计时器：Timer_Wait Timer time_wati状态下发出的给被关闭端ack报⽂后等待时间(30~120s),⼀般设置⼀个msl（最长报⽂寿命）是60s包重传的原因tcp可靠性通过序列号和ack确认包保障，当tcp发送包之后，将这个包的副本数据段放到重传队列上启动重传计时器1、如果对⽅反馈ack，则销毁数据段和计时器2、如果对⽅没有反馈ack，则在计时器到期后发起重传快速重传：A向B发送4个tcp报⽂段（n1,n2,n3,n4）,B只收到（n1,n2,n4）,其中n3丢失（也许只是延时到达），B发现失序⽴即⽣成重复ACK包（重复确认n3）,且发送三次给A，A重传该数据包超时重传：定时器超时之后，重传包，计时器的时间为“⼤于平均往返延迟”伪超时和重传：过早的判断了超时时间，导致发送⽅触发重传，RTT（连接往返时间）增长超过RTO（重传超时时间）包失序：ip层的包没有按顺序传输，严重失序时，接收⽅误以为包丢失，通知发送端重传，需要设置合理的重传阀值解决包重复：重传包含⼀个数据包，以及两个副本，多次重复会导致B收到过多重复包，从⽽B⽣成重复的ack，容易触发伪快速重传，使⽤sack 避免sack：当出现包失序、⽹络丢包导致的接收⽅数据序队列出现空洞，sack选项可以提供确认信息（描述乱序、空洞），帮助A⽅有效的重传。
TCP系列39—拥塞控制—2、拥塞相关算法及基础知识⼀、拥塞控制的相关算法早期的TCP协议只有基于窗⼝的流控（flow control）机制⽽没有拥塞控制机制，因⽽易导致⽹络拥塞。
1988年Jacobson针对TCP在⽹络拥塞控制⽅⾯的不⾜，提出了“慢启动(Slow Start)”和“拥塞避免(Congestion Avoidance)”算法。
1990年Jacobson⼜做了两个修正。
在这⼆⼗来年的发展过程中，与拥塞控制相关的有四个⽐较重要的版本：TCP Tahoe、TCP Reno、TCP NewReno和TCP SACK。
TCP Tahoe是早期的TCP版本，它包括了3个最基本的算法－“慢启动”、“拥塞避免”和“快速重传(Fast Retransmit)”，但是在Tahoe版本中对于超时重传和快速重传的处理相同，⼀旦发⽣重传就会开始慢启动过程。
TCP Reno则在TCP Tahoe基础上增加了“快速恢复(Fast Recovery)”算法，针对快速重传作出特殊处理，避免了⽹络拥塞不严重时采⽤“慢启动”算法⽽造成过度减⼩发送窗⼝尺⼨的现象。
TCP NewReno对TCP Reno中的“快速恢复”算法进⾏了修正，它考虑了⼀个发送窗⼝内多个数据包丢失的情况。
在Reno版中，发送端收到⼀个新的ack number后就退出“快速恢复” 阶段，⽽在NewReno版中，只有当所有的数据包都被确认后才退出“快速恢复”阶段。
TCP SACK关注的也是⼀个窗⼝内多个数据包丢失的情况，它避免了之前版本的TCP重传⼀个窗⼝内所有数据包的情况，包括那些已经被接收端正确接收的数据包，⽽只是重传那些被丢弃的数据包。
传统的TCP拥塞控制算法主要就由慢启动、拥塞避免、快速重传、快速恢复这4个基础算法组成，这四个基础算法在RFC5681规范中进⾏了描述。
后续我们将会分别对这些拥塞控制相关的算法做介绍，在介绍这些拥塞控制的相关算法之前我们先介绍⼀下拥塞控制中的数据包守恒原则和linux中拥塞控制的背景知识，以⽅便后⾯进⾏更进⼀步的介绍。
