我是靠谱客的博主 安静月亮,最近开发中收集的这篇文章主要介绍TCP流量控制和拥塞控制一,流量控制二,拥塞控制,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

文章目录

  • 一,流量控制
    • 1.什么是流量控制?
    • 2.实现
      • 滑动窗口机制
      • 死锁现象
        • 解决方法
      • TCP报文段发送时机
      • Nagle算法
      • 接收方糊涂窗口综合征
  • 二,拥塞控制
    • 1.什么是拥塞?
    • 2.什么是拥塞控制?
    • 3.检测网络拥塞的指标
    • 4.TCP拥塞控制算法
      • 控制拥塞窗口原则
      • 拥塞判断
      • 拥塞窗口控制算法
        • 1.慢开始
        • 2.拥塞避免算法
        • 3.快重传
        • 4.快恢复
      • TCP拥塞控制流程图
      • 主动队列管理(AQM)
        • 1.什么是主动队列管理
        • 2.随机早期检测 RED

一,流量控制

1.什么是流量控制?

流量控制就是让发送方发送的速率不要太快,要让接收方来得及接收

2.实现

滑动窗口机制

在这里插入图片描述

死锁现象

B向A发送零窗口的报文段不久后,B的接收缓存有了些存储空间,这时,B向A发送400字节大小的窗口报文段,但是这个报文段发生了丢失,B一直在等待A发送过来的数据,A也一直在等待B的窗口大小报文段,双方僵持,类似java中的死锁,这就是TCP中的死锁现象

解决方法

  • 接收方只要接收到发送方的零窗口通知,就启动持续计时器

  • 如果持续计时器的时间到了,原接收方就发送一个零窗口的探测报文

  • 原发送方接收到这个探测报文段后给出当前窗口的大小

  • 若当前窗口的大小 = 0,原发送方就重新设置持续计时器

  • 若当前窗口的大小 != 0,死锁将打破,双方不再僵持

TCP报文段发送时机

  • 只要TCP缓存中存放的数据达到TCP最大报文段长度时,就组成一个报文发送出去

  • 由发送发应用进程指定要求发送报文段

  • 发送方的一个计时器期限到了,就把当前已有的缓存数据放入一个报文段(不能超过TCP最大报文段长度)中发送出去

Nagle算法

TCP的传输效率是一个很重要的问题

算法思路:

  • 若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存,则发送方就把第一个数据字节先发送出去,把后面到达的数据字节都缓存起来。

  • 当发送方收到对第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个报文段发送出去,同时继续对随后到达的数据进行缓存。

  • 只有在收到对前一个报文段的确认后才继续发送下一个报文段。

  • 当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时,就立即发送一个报文段。

在这里插入图片描述

接收方糊涂窗口综合征

当接收方的 TCP 缓冲区已满,接收方会向发送方发送窗口大小为 0 的报文。
若此时接收方的应用进程以交互方式每次只读取一个字节,于是接收方又发送窗口大小为一个字节的更新报文,发送方应邀发送一个字节的数据(发送的 IP 数据报是 41 字节长),于是接收窗口又满了,如此循环往复。

解决:

让接收方等待一段时间,使得或者接收缓存已有足够空间容纳一个最长的报文段,或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一,接收方就发出确认报文,并向发送方通知当前的窗口大小。

二,拥塞控制

1.什么是拥塞?

在某段时间,若对网络中某资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种现象称为拥塞 。
若网络中有许多资源同时产生拥塞,网络的性能就要明显变坏,整个网络的吞吐量将随输入负荷的增大而下降。

2.什么是拥塞控制?

拥塞控制就是防止过多的数据注入到网络中,使网络中的路由器或链路不致过载。

拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。

拥塞控制是一个全局性的过程,涉及到所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素。

3.检测网络拥塞的指标

  • 由于缺少缓存空间而被丢弃的分组的百分数;
  • 平均队列长度;
  • 超时重传的分组数;
  • 平均分组时延;
  • 分组时延的标准差,等等。

这些指标的上升标志着拥塞增加

4.TCP拥塞控制算法

  • 慢开始

  • 拥塞避免

  • 快重传

  • 快恢复

控制拥塞窗口原则

  • 只要网络没有出现拥塞,拥塞窗口就可以再增大一些,以便把更多的分组发送出去,这样就可以提高网络的利用率。

  • 但只要网络出现拥塞或有可能出现拥塞,就必须把拥塞窗口减小一些,以减少注入到网络中的分组数,以便缓解网络出现的拥塞

拥塞判断

  • 重传定时器超时

  • 连续接收三个相同(重复)ACK确认

拥塞窗口控制算法

1.慢开始

算法思路

有小到大的增大拥塞窗口大小

拥塞窗口cwnd每次的增加量 = min (N, SMSS)

其中 N 是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。

传播轮次

使用慢开始算法后,每经过一个传输轮次 (transmission round),拥塞窗口 cwnd 就加倍。

一个传输轮次所经历的时间其实就是往返时间 RTT。

“传输轮次”更加强调:把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个字节的确认。

例如,拥塞窗口 cwnd = 4,这时的往返时间 RTT 就是发送方连续发送 4 个报文段,并收到这 4 个报文段的确认,总共经历的时间。

慢开始门限ssthresh

避免拥塞窗口增大过大引发网络拥塞

  • 当 cwnd < ssthresh 时,使用慢开始算法。
  • 当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。
  • 当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞避免算法。

2.拥塞避免算法

算法思路
使拥塞窗口缓慢的增大,每经过一个往返时间RTT增加+1

慢开始门限重新设置

当使用拥塞避免算法减缓了拥塞窗口增大的速度。但是随着轮次的增大,窗口还是会逐渐增加,从而会导致网络拥塞,这时就需要重新设置慢开始门限值,这个主要针对重发定时器超时的情况

  • 1.新的ssthresh = max{拥塞窗口大小/2,2}

  • 2.重置拥塞窗口大小 = 1

  • 3 .执行慢开始

3.快重传

算法思路

  • 采用快重传FR (Fast Retransmission) 算法可以让发送方尽早知道发生了个别报文段的丢失。

  • 快重传 算法首先要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认,即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。

  • 发送方只要一连收到三个重复确认,就知道接收方确实没有收到报文段,因而应当立即进行重传(即“快重传”),这样就不会出现超时,发送方也不就会误认为出现了网络拥塞。

  • 不难看出,快重传并非取消重传计时器,而是在某些情况下可更早地重传丢失的报文段。

4.快恢复

算法思路

当发送端收到连续三个重复的确认时,由于发送方现在认为网络很可能没有发生拥塞,因此现在不执行慢开始算法,而是执行快恢复算法 FR (Fast Recovery) 算法:

  • (1) 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ;
  • (2) 新拥塞窗口 cwnd = 慢开始门限 ssthresh ;
  • (3) 开始执行拥塞避免算法,使拥塞窗口缓慢地线性增大。

TCP拥塞控制流程图

在这里插入图片描述

主动队列管理(AQM)

1.什么是主动队列管理

所谓“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。这样就太被动了。应当在队列长度达到某个值得警惕的数值时(即当网络拥塞有了某些拥塞征兆时),就主动丢弃到达的分组。

2.随机早期检测 RED

使路由器的队列维持两个参数:队列长度最小门限 THmin 和最大门限 Thmax 。
RED 对每一个到达的分组都先计算平均队列长度 LAV 。
(1) 若平均队列长度小于最小门限 THmin,则将新到达的分组放入队列进行排队。
(2) 若平均队列长度超过最大门限 THmax,则将新到达的分组丢弃。
(3) 若平均队列长度在最小门限 THmin 和最大门限THmax 之间,则按照某一概率 p 将新到达的分组丢弃

在这里插入图片描述

路由器的队列通常都是按照“先进先出”FIFO (First In First Out) 的规则处理到来的分组。
当队列已满时,以后再到达的所有分组(如果能够继续排队,这些分组都将排在队列的尾部)将都被丢弃。这就叫做尾部丢弃策略 (tail-drop policy)。
路由器的尾部丢弃往往会导致一连串分组的丢失,这就使发送方出现超时重传,使 TCP 进入拥塞控制的慢开始状态,结果使 TCP 连接的发送方突然把数据的发送速率降低到很小的数值。

最后

以上就是安静月亮为你收集整理的TCP流量控制和拥塞控制一,流量控制二,拥塞控制的全部内容,希望文章能够帮你解决TCP流量控制和拥塞控制一,流量控制二,拥塞控制所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(62)

评论列表共有 0 条评论

立即
投稿
返回
顶部