流量控制:数据的传送与接收过程当中很可能出现收方来不及接收的情况,这时就需要对发方进行控制,以免数据丢失.流量控制用于防止在端口阻塞的情况下丢帧,这种方法是当发送或接收缓冲区开始溢出时通过将阻塞信号发送回源地址实现的.流量控制可以有效的防止由于网络中瞬间的大量数据对网络带来的冲击,保证用户网络高效而稳定的运行. 1.通信双方主机上都分别有一个“发送窗口”和一个“接受窗口”2.TCP连接阶段,双方协商窗口尺寸3.发送方根据协商的结果,发送符合窗口尺寸的数据字节流,并等待对方的确认,等待确认机制4.

前面我们演示分析了100+个wireshark TCP实例,拥塞控制部分也介绍常见的拥塞处理场景以及4种拥塞撤销机制,但是我们一直使用的都是reno拥塞控制算法.实际上拥塞控制发展到今天已经有了各种各样的拥塞控制算法,而且普遍认为单纯基于丢包的reno拥塞控制算法已经不适应当前internet网络了,最近谷歌又折腾出了一个BBR拥塞控制算法,对比国内,还没有一个在TCP领域有突出贡献的公司,谷歌在TCP领域真是甩了其他公司好几条街.闲言少叙吧,拥塞控制关注的Scalability.RTT fai

一.拥塞控制的相关算法 早期的TCP协议只有基于窗口的流控(flow control)机制而没有拥塞控制机制,因而易导致网络拥塞.1988年Jacobson针对TCP在网络拥塞控制方面的不足,提出了"慢启动(Slow Start)"和"拥塞避免(Congestion Avoidance)"算法.1990年Jacobson又做了两个修正.在这二十来年的发展过程中,与拥塞控制相关的有四个比较重要的版本:TCP Tahoe.TCP Reno.TCP NewReno和TCP

为了更好地对传输层进行拥塞控制,因特网建议标准定义了以下四种算法:慢启动.拥塞避免.快重传和快恢复. 1 接收窗口rwnd与拥塞窗口cwnd 发送方在确定发送报文段的速率时,既要根据接收方的接收能力,又要从全局考虑不要使网络发生拥塞.因为,TCP协议要求发送方维护以下两个窗口: (1)接收窗口rwnd:接收方向发送方告知的当前还能接收的数据容量,一般所说的窗口大小即rwnd: (2)拥塞窗口cwnd:发送方根据自己估算的网络拥塞程序而设置的窗口值,反映了网络的当前容量. 发送窗口的上限应当取接收

  1. 流量控制 - Flow Control 序言:数据的传送与接收过程当中很可能出现收方来不及接收的情况,这时就需要对发方进行控制以免数据丢失.利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制.TCP的窗口单位是字节,不是报文段,发送方的发送窗口不能超过接收方给出的接收窗口的数值. 说明:使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止.B向A发送的三个报文段都设置了ACK=1.   考虑一种特殊的情况,接收方若没有缓存足够使用,就会发送零窗口大小的报文,此时

1.拥塞窗口 发送方窗口的大小不仅取决于接收方,而.而且还取决于网络拥塞的情况. 发送方有2种信息:接收方通告的窗口大小和拥塞窗口的大小,实际的窗口大小事这两者中的最小者. 实际窗口大小 = min(rwnd,cwnd) rwnd:接收窗口大小. cwnd:拥塞窗口大小. 2.拥塞策略 TCP处理拥塞的一般策略基于3个阶段:慢速启动,拥塞避免和拥塞检测. 2.1.慢速启动:指数增长 TCP拥塞控制所使用的一种算法称为慢性启动(slow start),这种算法是基于这样的想法,它在开始时设置拥塞窗

TCP 的流量控制与拥塞控制可以说是一体的.流量控制是通过滑动窗口实现的,拥塞避免主要包含以下2个内容: (1)慢开始,拥塞避免 (2)快重传,快恢复 1.流量控制——滑动窗口 TCP采用大小可变的滑动窗口进行流量控制,窗口大小的单位是字节. 发送窗口在连接建立时由双方商定.但在通信的过程中,接收端可根据自己的资源情况,随时动态地调整对方的发送窗口上限值(可增大或减小). 为什么要设置窗口? 我们可以把窗口理解为缓冲区(但是有些窗口和缓冲区又不太一样). 如果没有这些“窗口”,那么TCP没发送一

TCP的流量控制      所谓的流量控制就是让发送方的发送速率不要太快,让接收方来得及接受.利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制.TCP的窗口单位是字节,不是报文段,发送方的发送窗口不能超过接收方给出的接收窗口的数值.      如图所示,说明了利用可变窗口大小进行流量控制.设主机A向主机B发送数据.双方确定的窗口值是400.再设每一个报文段为100字节长,序号的初始值为seq=1,图中的箭头上面大写ACK,表示首部中的却认为为ACK,小写ack表示确认字段的值.

拥塞: 拥塞发生的主要原因在于网络能够提供的资源不足以满足用户的需求,这些资源包括缓存空间.链路带宽容量和中间节点的处理能力.由于互联网的设计机制导致其缺乏"接纳控制"能力,因此在网络资源不足时不能限制用户数量,而只能靠降低服务质量来继续为用户服务,也就是"尽力而为"的服务. 拥塞其实是一个动态问题,我们没有办法用一个静态方案去解决,从这个意义上来说,拥塞是不可避免的. 重传机制: 重发定时器 (1) 每一次一个包含数据的包被发送(包括重发),如果该定时器没有运行则

流量控制: 流量控制是为了控制发送方发送速率,保证接收方来得接收. 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率.将窗口字段设置为 0,则发送方不能发送数据. 拥塞控制: 如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高.因此当出现拥塞时,应当控制发送方的速率.这一点和流量控制很像,但是出发点不同.流量控制是为了让接收方来得及接受,而拥塞控制是为了降低整个网络的拥塞程度. TCP主要通过四种算法来进行拥塞控制:慢开始.拥塞避免

一.概述 ECN的相关内容是在RFC3168中定义的,这里我简单描述一下RFC3168涉及的主要内容. 1.AQM和RED 目前TCP中多数的拥塞控制算法都是通过缓慢增加拥塞窗口直到检测到丢包来进行慢启动的,这就会导致数据包在路由器缓存队列堆积,当路由器没有复杂的调度和缓存管理策略的时候,路由器一般简单的按照先进先出(FIFO)方式处理数据包,并在缓存队列满的时候就会丢弃新数据包(drop tail),这种FIFO/drop tail的路由器称为passive路由器,会导致多个TCP流同时检测到

一.概述 这里主要简单分析一个丢包重传并恢复的场景,通过不同的设置让这个相同的场景分别触发RACK重传和前向重传,通过对比说明以下问题: Forward Retransmit可以产生只有重传标记的数据包,也可以产生同时具有重传标记和SACK标记的数据包,注意这里说的这些数据包是没有Lost标记的,这是前向重传与之前介绍的快速重传及其变种的差异,进而会对in_flight的统计产生影响. Recovery状态,FACK会利用一个dup ACK来前向标记丢失的数据包. RACK可以利用重传在时间域来

一.概述 这里的重点是介绍TLP.ER与拥塞控制并不是介绍TLP和ER本身,因此TLP和ER的详细内容请翻前文. 在TLP与拥塞控制的交互中有几个点需要注意 1.TLP触发的重传后,TCP仍然处于Open状态,TLP重传也不会更新lost_out等状态变量,TLP重传发出的是探测报文并不是因为当前确定丢包而重传. 2.TLP与ER/FACK是相互组合的,TLP触发的FACK重传与之前介绍的FACK下快速恢复一致.TLP和ER的耦合更深一些,TLP只能触发延迟ER,而ER定时器超时,延迟ER重传将

一.概述 FRTO虚假超时重传检测我们之前重传章节的文章已经介绍过了,这里不再重复介绍,针对后面的示例在说明两点 1.FRTO只能用于虚假超时重传的探测,不能用于虚假快速重传的探测. 2.延迟ER重传触发的进入Recovery状态时候,并不会立即更新cwnd. 本篇在演示FRTO的同时,还会涉及到ER超时重传.TLP探测.SACK关闭场景下的拥塞撤销,后面或者前面都会有针对这些场景的专门介绍文章. 一.wireshark示例 1.FRTO与ER 我们通过一个示例看一下关闭SACK时候,tcp_s

一.概述 FACK下的重传我们在之前的重传部分已经进行了介绍,这里简单介绍一下随着FACK提出的拥塞控制算法的改进及随后的进一步改进. 从我们之前介绍的RFC2582和RFC5681中可以看到,快速恢复下当探测到丢包的时候,会设置ssthresh = max (FlightSize / 2, 2*MSS). cwnd=ssthresh+3*MSS,随后发送端收到dup ACK的时候进行cwnd的inflate过程,发送端需要收到大约一半的dup ACK后,才能允许发送新数据,这意味着发送端需要等

一.概述 1.SACK下的特殊处理过程 SACK下的拥塞控制处理是linux中拥塞控制的实现依据,再次强调一遍RFC6675的重要性,linux中拥塞控制主体框架的实现是与RFC6675一致的,所以如果要理解linux中拥塞控制的实现,强烈建议看一下RFC6675.我这里给出RFC6675中SACK处理的2个关键点,下面的描述实际上不太严谨,严谨定义请参考RFC6675. 1.SACK下对于dup ACK的定义简单说是指反馈了新的SACK信息,也就是说SACK下ack number不同的ACK报

一.概述 这篇文章介绍一下TCP从Recovery状态恢复到Open状态的时候cwnd的更新.我们在tcp重传部分的文章中曾经介绍过虚假重传的概念,Linux在探测到虚假重传的时候就会执行拥塞撤销操作.所谓的拥塞撤销是指撤销虚假的快速重传或者RTO超时重传对拥塞窗口的影响.有多种方法可能会触发拥塞撤销如前面介绍的DSACK和FRTO以及后面要介绍的Eifel算法以及本文介绍的SACK关闭场景下的拥塞撤销,本文先介绍一种SACK关闭场景下的拥塞撤销.首先在介绍几个新的linux状态变量 undo_

) return;    delta = ssthresh - in_flight;     prr_delivered += newly_acked_sacked; if (delta < 0) {  //注意下面的除法要向下取整 sndcnt = (ssthresh * prr_delivered + prior_cwnd - 1)/prior_cwnd - prr_out } else if (ack number新确认了之前重传的数据且RACK没有标记重传报文丢失) { sndcnt =

一.概述 在RFC2861中,区分了TCP连接数据传输的三种状态   After sending a data segment:       If tcpnow - T_last >= RTO           (The sender has been idle.)           ssthresh =  max(ssthresh, 3*cwnd/4)           For i=1  To (tcpnow - T_last)/RTO               win =  min(

在本篇中我们继续上一篇文章wireshark的示例讲解,上一篇介绍了一个综合示例后,本篇介绍一些简单的示例,在读本篇前建议先把上一篇读完,为了节省篇幅,本篇只针对一些特殊的场景点报文进行讲解,不会像上一篇一样对每个报文都进行讲解并随报文更新相关状态变量的值了. 一.wireshark示例 本篇示例的TCP测试仍然设置初始拥塞窗口为3,并关闭TSO.GSO等功能.同时设置wireshark使其不在info列显示TSopt的信息. ******@Inspiron:~$ sudo ip route a

一.Linux中的慢启动和拥塞避免 Linux中采用了Google论文的建议把IW初始化成了10了.在linux中一般有三种场景会触发慢启动过程 1.连接初始建立发送数据的时候,此时cwnd初始化为10,ssthresh初始化为0x7fffffff,因此会触发慢启动.但是当路由表中有对应的设置的时候,cwnd和ssthresh会被路由表中的设置的值覆盖,有可能连接建立后直接进入拥塞避免阶段. 2.RTO超时进入Loss状态后,此时cwnd初始化为1,ssthresh的值会调用具体拥塞控制算法的回