TCP 流量控制和拥塞控制中的重要机制

停止等待协议:
放送方发送一个数据包,要收到接收方对该包的确认后,才发送下一个数据包。
缺点:慢,信道利用率低。

ARQ  Automatic Repeat reQuest
接收方采用累加确认的方式,接收方不必对每一个分组进行缺,只需要对按序到达的最后一个分组发送确认。
缺点:当发送方发送了5个分组,中间第3个丢失,那么接收方只对前两个分组进行确认。发送方只好把后面的3个分组都重传一次。这叫做Go-back-N(回退N)
选择确认 selective ack
接收方对接收到的数据字节流中,若有中间字节块的缺失,只需要重新传输缺失的就可以了,对已经接收到的字节块无需重传。
需要在TCP首部的选项中设置 ”允许SACK” 的选项。
TCP流量控制:
让发送方的发送速率不要太快,要让接收方来得及接收。端到端的问题。
机制:滑动窗口
S--------------->R
当接收方R 的窗口为0时候,S就不能再发送数据了。当R的窗口不为0时候R会发送一个数据给S来表明当前的窗口大小,但是为了防止S收不到R又有窗口的通告,S启动一个持续计时器(persistent timer),只要TCP连接的一方接收到对方的零窗口通告,就启动持续计时器。若持续计时器设置的时间到期,那么发送一个零窗口的探测报文段。

Nagle算法:
此算法在TCP的实现中广泛使用。
若发送应用进程把要发送的数据逐个字节地发送到TCP的发送缓存,则发送方就把第一个数据字节先发出去,把后面到达的数据缓存起来。当发送接收到对第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个报文段发送出去,同时继续对随后到达的数据进行缓存。只有收到对前一个报文段的确认后才继续发送下一个报文段。Nagle算法还规定,当到达的数据已经达到发送窗口的一半或已经达到报文段的最大长度时,就立即发送一个报文。

糊涂窗口综合症:
接收方缓存已经满了,并且一次只从缓存读取一个字节,所以通告给发送方的窗口只有一个字节,那么接收方一次只发送一个字节的数据,但是发送效率低,因为一个字节数据要40个字节协议头部。如果每次发送一个字节的话效率很低,解决方法是:让接收方等待一段时间,再通告自己的窗口大小给接收方。

TCP拥塞控制:
是整个网络的问题(全局性的)。

①慢开始和拥塞避免:
    发送方维持一个叫做拥塞窗口CWND(congestion window)的状态变量。发送方的拥塞窗口等于自己发送窗口。
慢开始:
发送方一开始设置CWND=1,发送一个包,接收到该包确认后,发送方设置CWND=2,发送之后,接收到该包的确认,发送方设置CWND=4 ……以此类推,成倍增长。
千万注意:窗口大小并不时一次性发送数据的大小,发送方可以根据CWND进行连续几次的发数据,这连续发送的数据大小不应该超过CWND。

   为了防止cwnd增长过大引起网络拥塞,还需要设置一个慢启动开始门限 ssthresh 。
当cwnd等于ssthresh 的时候,cwnd并不在是成倍的增长了,而是逐渐加1


当网络拥塞时候(就是发送方没有按时接收到确认),那么就把慢开始门限值设置成当前的CWND的一半,接着将cwnd设置为1,执行慢开始算法。

②快重传和快恢复:
快重传要求接收方收到一个失序报文段后立即发送重复确认(目的是让发送方尽早知道数据段没到达),而不要等到自己发送确认数据时候后捎带。
发送方发送5个报文,第3个缺失,收到第四个报文时候立即发送对第2个的重复确认,接收到第4个、第五个报文时候也发送对第2个的重复确认。只要发送方一连收到3个重复确认就应该重发接收发未收到的报文,而不必等到第3个报文的重传计时器过期才重发。
因此,使用快重传可以提高整个网络的吞吐量。

快恢复与快重传配合使用:
当发送方连续接收到3个重复确认,就执行“乘法减小”算法,把慢开始门限值ssthresh设置为当前CWND的一半,同时,将此时的CWND=新的ssthresh值,接下去并不执行慢开始算法。
因为收到3个重复报文并不时意味着网络出现问题,可能仅仅就是那个包缺失了,所以ssthresh减半后,cwnd在ssthresh的基础上逐渐加1。

原文地址:http://blog.51cto.com/jackor/2088646

时间: 2024-10-11 13:40:33

TCP 流量控制和拥塞控制中的重要机制的相关文章

TCP流量控制和拥塞控制

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

TCP流量控制与拥塞控制

 一.TCP建立连接后,通信双方都同时可以进行数据的传输:在保证可靠性上,采用超时重传和捎带确认机制:在流量控制上,采用滑动窗口协议,协议中规定,窗口内未经确认的分组需要进行重传:在拥塞控制上,采用慢启动算法. (一)拥塞控制: 1. TCP慢启动.拥塞避免.快速重传.快速回复 为了防止网络的拥塞现象,TCP提出了一系列的拥塞控制机制.最初由V. Jacobson在1988年的论文中提出的TCP的拥塞控制由"慢启动(Slow start)"和"拥塞避免(Congestio

TCP 流量控制、拥塞控制

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

TCP的流量控制和拥塞控制

一.首先和UDP作比较谈谈TCP的特点 (1)UDP是数据报协议,每个数据报都有长度,数据报的长度和数据一起发送和接受,各个数据报的发送和接受相互独立,互不影响.而TCP是字节流协议,所有经TCP发送的数据没有记录边界. (2) UDP是无连接.不可靠的协议,而TCP是有连接,可靠协议.TCP的可靠性主要指经TCP发送的数据要么准确无误的发送到了对端,要么发送失败并且以合适的方式通知应用程序,也就是可靠的传输数据和可靠地报告错误,TCP协议每一次发送数据以后先暂时将数据保存在缓存区,直到接收到对

TCP的流量控制与拥塞控制小结

概述 为了提高信道的利用率TCP协议不使用停止等待协议,而是使用连续ARQ协议,意思就是可以连续发出若干个分组然后等待确认,而不是发送一个分组就停止并等待该分组的确认.其中TCP的流量控制与拥塞控制是TCP在数据传输过程俩个重点机制,为TCP有效数据传输立下汗马功劳,这部分也是面试网络协议重点所在,下面从以下俩大方面总结一下 [1]流量控制 [2]拥塞控制 1.流量控制 流量控制:指点对点通信量的控制,是端到端正的问题.流量控制所要做的就是抑制发送端发送数据的速率,以便使接收端来得及接收. 在T

TCP详解(3):重传、流量控制、拥塞控制……

数据传输 在TCP的数据传送状态,很多重要的机制保证了TCP的可靠性和强壮性.它们包括:使用序号,对收到的TCP报文段进行排序以及检测重复的数据:使用校验和来检测报文段的错误:使用确认和计时器来检测和纠正丢包或延时. 在TCP的连接创建状态,两个主机的TCP层间要交换初始序号(ISN:initial sequence number).这些序号用于标识字节流中的数据,并且还是对应用层的数据字节进行记数的整数.通常在每个TCP报文段中都有一对序号和确认号.TCP报文发送者认为自己的字节编号为序号,而

TCP自时钟/拥塞控制/带宽利用之脉络半景解析

0.说明 搬家公司的人很多都穿皮鞋!Why? 这个题目不是很明确,而且这个文章比较长,也算是我的一个阶段性总结,既然是总结,就不必为题目而纠结了.在端午假期的最后来做这个总结也实属不易(假期前两天加班,没有完成预期的计划,低落),记得很早以前写那篇<TCP协议疑难杂症全景解析>的时候跟现在一个心情.翻翻以前的记录,写那个的时候是2011年的7月初,小小才刚刚半个月,如今小小已经马上5岁了,时间过得真快啊,弹指一挥间!!回首过去的五年间,最累的时候是在2011年中到2014年初这两年半的时间,有

TCP流量控制和拥塞避免

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

linux套接字通信之recv中的缓存机制的研究

以前一直有这么一个小小的疑惑,当一个进程注册一个套接字后,如果这个套接字没有被调用recv函数接受数据包,那么这个套接字能接受到数据包吗? 或者这样说,如果我的程序注册了一个套接字去接受数据包,但是每收到一个数据包都需要很长一段时间处理,并且在处理数据包的途中recv函数使没有被调用的,那么如果程序再处理数据包的途中有数据包到来,那我的程序会不会漏过这些数据包(那个包到达的时候程序在处理别的包,而没有调用recv函数)? 答案是不会的.事实上linux中会为每个套接字建立缓存,当属于套接字的包到