一.介绍 当TCP连续大量的发送数据的时候,当出现丢包的时候可以有足够的dup ACK来触发快速重传.但是internet上还有大量的交互式服务,这类服务一般都是由小包组成,而且一次操作中需要传输的数据包一般比较少,比如在线游戏.股票交易等,这一类数据流我们就称呼为thin stream.在一次交互式操作触发一次TCP传输的时候,如果传输的这个数据包发生丢包,很可能后面没有足够的dup ACK来触发快速重传,最终只能依赖RTO超时来进行重传.还有一种受限传输的场景,如果发送窗口受到拥塞控制的限制

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

一.快速重传介绍 按照TCP协议,RTO超时重传是一个非常重要的事件,当RTO超时的时候,TCP会同时通过两种方式非常谨慎的降低发送数据包的速率,一种是基于拥塞控制削减发送窗口的大小,另外一个是通过指数回退增加每次RTO超时的时间(即karn算法的第二部分).所以RTO超时后有可能会导致网络容量的利用不足. 最开始我们介绍tcp重传的时候就介绍过TCP还有另外一种重传方式--快速重传.快速重传是RFC5681定一个的一个过程.快速重传不依赖定时器的超时,而是依靠ACK确认包来进行重传.使用快速重

在TCP/IP中,快速重传和恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包.没有FRR,如果数据包丢失了,TCP将会使用定时器来要求传输暂停.在暂停的这段时间内,没有新的或复制的数据包被发送.有了FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认.如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段.有了FRR,就不会因为重传时要求的暂停被耽误. 当有单独的数据

本文为原创,转载请注明:http://www.cnblogs.com/gistao/ Background 写网络程序的都知道,tcp的窗口控制分为慢启动阶段和拥塞避免阶段,重传机制有快速重传/恢复和超时重传.网上关于快速重传的文章很多,但质量参差不齐,这里对它的设计背景和原理总结下. Concept rtt,即网络往返时间. 慢启动过程,指的是请求窗口的变化过程,是指数级的,这变化可不慢吧,这里说它慢是说窗口每次都要从1开始,需要经过好几个rtt才能达到理想的窗口数. Network traf

当tcp传送一个分组时会设置一个定时器,如果在规定的实际间隔内没有收到ACK分组,那么则重新传输该分组,但是 如果tcp收到三个连续的ACK分组,此时不管是否过超时间隔则重传该分组,具体步骤如下: 1.将慢启动阈值ssthresh设为拥塞窗口(cwnd--可理解为发送数据包大小)的一半 2.对于连续三个重复的ACK报文,cwnd依次加1,重发分组 3.当新的ACK分组再次到来的时候,把拥塞窗口的大小设为慢启动阈值的大小 4.进入拥塞避免算法. 1,2,3个步骤为快速重传机制,为什么快,因为不需要

转载自:TCP慢启动.拥塞避免.快速重传.快速回复 转自:http://blog.csdn.net/itmacar/article/details/12278769 感谢博主的辛勤成果! 为了防止网络的拥塞现象,TCP提出了一系列的拥塞控制机制.最初由V. Jacobson在1988年的论文中提出的TCP的拥塞控制由"慢启动(Slow start)"和"拥塞避免(Congestion avoidance)"组成,后来TCP Reno版本中又针对性的加入了"

不多说,直接上干货! 福利 => 每天都推送 欢迎大家,关注微信扫码并加入我的4个微信公众号:   大数据躺过的坑      Java从入门到架构师      人工智能躺过的坑         Java全栈大联盟        每天都有大量的学习视频资料和精彩技术文章推送... 人生不易,唯有努力.        百家号 :九月哥快讯               快手号:  jiuyuege               什么是拥塞? 当大量的分组进入通信子网,超出了网络的处理能力时,就会引起网络

TCP提供了最可靠的数据传输,它给发送的每个数据包做顺序化(这看起来非常烦琐),然而,如果TCP没有这样烦琐的操作,那么,可能会造成更多的麻烦.如造成数据包的重传.顺序的颠倒甚至造成数据包的丢失. 那么,TCP具体是通过怎样的方式来保证数据的顺序化传输呢? 主机每次发送数据时,TCP就给每个数据包分配一个序列号并且在一个特定的时间内等待接收主机对分配的这个序列号进行确认,如果发送主机在一个特定时间内没有收到接收主机的确认,则发送主机会重传此数据包.接收主机利用序列号对接收的数据进行确认,以便检测

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

一.虚假重传 在一些情况下,TCP可能会在没有数据丢失的情况下初始化一个重传,这种重传就叫做虚假重传(Spurious retransmission).发生虚假重传的原因可能是包传输中重排序.传输中发生包复制.ACK确认包传输中丢失等等.如果由于链路时延变化或者负载变化等因素导致RTT突然变大等原因,TCP的发送端可能还没收到ACK确认包就已经RTO超时而触发重传,这种重传就叫做虚假超时重传(Spurious retransmission timeouts).虚假超时重传会降低网络性能,其主要由

一.RACK概述 RACK(Recent ACKnowledgment)是一种新的基于时间的丢包探测算法,RACK的目的是取代传统的基于dupthresh门限的各种快速重传及其变种.前面介绍的各种基于dup ACK的快速重传算法及其变种通过修改dupthresh门限等手段,有些可以迅速的探测到丢包,有些可以精确的探测丢包,但是没有能同时达到迅速和精确两个目标的算法. RACK基本思想:如果发送端收到的确认包中的SACK选项确认收到了一个数据包,那么在这个数据包之前发送的数据包要么是在传输过程中发

一.概述 forward retransmit相关的内容在RFC6675中有描述,可以参考RFC6675 section 4中NextSeg ()的定义.forward retransmit中文名可以叫做前向重传,我这里简单说一下linux实现上的前向重传 在快速重传(包括快速重传的各种变种)到达Recovery point之前,都会尝试重传标记为lost的数据包,当把标记为lost的数据包重传完毕后,如果同时满足下面几个条件: 1.当前拥塞控制处于Recovery状态,且在尝试重传数据包的时候

一.介绍 Tail Loss Probe (TLP)是同样是一个发送端算法,主要目的是使用快速重传取代RTO超时重传来处理尾包丢失场景.在一些WEB业务中,如果TCP尾包丢失,如果依靠RTO超时进行重传会带来比较大的延迟,进而影响用户体验.如果一个TCP连接没有在一段时间内没有收到ACK报文,TLP会强制传输还没有收到ACK确认的报文里面的最后一个报文或者未发送的新报文(传输的这个报文就叫做loss probe).这里强制传输是指loss probe的发送不受到拥塞控制的限制但是同样收到对方通告

一.介绍 在前面介绍thin stream时候我们介绍过有两种场景下可能不会产生足够的dup ACK来触发快速重传,一种是游戏类响应交互式tcp传输,另外一种是传输受到拥塞控制的限制,只能发送少量TCP报文.针对这种场景提出了一个快速重传的改进算法即早期重传(early retransmit,简称ER).按照RFC5827,ER有两种形式一种是基于字节的,一种是基于包的,基于包的ER精度要高于基于字节的ER,linux实现的是基于TCP包的ER,因此我们这里只介绍基于包的ER. ER是在没有新数

一.介绍 FACK的全称是forward acknowledgement,FACK通过记录SACK块中系列号最大(forward-most)的SACK块来推测丢包信息,在linux中使用fackets_out这个状态变量来记录FACK信息.我们之前介绍SACK重传时候说过在SACK下需要3个dup ACK来触发快速重传(3个为默认值),而SACK下的dup ACK的定义与传统的非SACK下定义又略有不同(详细请参考前面的文章和示例).当使能FACK的时候,实际上我们可以通过一个SACK块信息来推

我们之前介绍SACK选项的时候说过,SACK可以把接收端系列号空间的洞反映给发送端,因此发送端可以更充分的理解接收端的情况,而进行更好的重传恢复过程.这种过程有时候也叫做advanced loss recovery. 一.数据接收端SACK行为 我们通过一个wireshark示例来说明接收端的SACK行为:   如上图,为了方便在info列中查看SACK信息,我把info列中TSopt的信息隐藏了,同时把源地址列和目的地址列一起隐藏了.client依次发送P1(1-6).P2(25-30).P3

1. TCP重传机制 TCP协议是一个可靠的协议.发送方每次发送一个数据包,需要等到ACK确认包再继续发送. 发出去的请求包在规定时间内没有收到ACK,不管是请求包丢失,还是ACK包丢失,还是网络延迟,这里都是需要有个重传机制.重传机制是保障通信链路可靠性的重要方式之一. TCP的重传机制有两种:超时重传和快速重传. - 超时重传 (主动重传) 在请求包发出去的时候,开启一个计时器,当计时器达到时间之后,没有收到ACK,就进行重发操作,直到达到重发上限次数或者收到ACK. - 快速重传 (请求重

TCP的阻塞和重传机制 网络拥堵 现在网络上大部分的网络请求都是以TCP的方式进行传输的了.网络链路是固定的,各种链路情况也是不一样的.网络拥堵一直是TCP协议设计和使用的时候尽力要避免的.比如,从TCP协议的网络包协议设计来看,TCP使用一发一答的ACK的网络包确认方式,而不是使用NAK这种会增加确认包的方式来做确认机制.这个就是在尽力降低网络上的包传递数量,避免网络拥堵. 还有哪些控制网络拥堵的方式呢? 慢启动 当一个连接连接上网络的时候,并不应该一次向网络中就发送大量的数据包,否则的话,如

1.TCP提供的是可靠传输,它通过接收方发送一个确认报文ACK来提供这种可靠性.但是数据报文和确认报文都可能会丢失,所以TCP会给发出的数据报文设置一个时间,如果超时了则进行重传 2.Karn's Algorithm:当发生了一次超时重传之后,我们不能根据发回的对于重传数据的ACK更新RTT和RTO(retransmission timeout 重传时间)的值.因为我们不知道这个ACK是对于第一次传送的数据的确认(可能是第一次发送的数据在网络中有延时或者是它对应的ACK报文有延时)还是对重传数据