0


计算机网络 | 谈谈TCP的流量控制与拥塞控制

文章目录

一、TCP的流量控制

1、利用滑动窗口实现流量控制【⭐⭐⭐】

对于滑动窗口,在上面也提到过了,在流量控制这一块,就要利用到这个滑动窗口的机制去实现两个主机之间的通信

[流量控制的目的]:

让发送方的发送速率不要太快,要让接收方来得及接收

然后来说一下很重要的例子,要注意理解,与后面的三次握手紧密度非常之大

  • 首先在建立连接的时候B就告诉了A:“我的接收窗口rwnd = 400”。表示主机B的接受窗口最多可以接收400B的大小,然后设置了一个100字节长的报文段,即DATA = 100,数据报文段序号的初始值设置为1,即seq = 1
  • 然后一开始主机A就向B发送了100B的大小,第一个字节序号为1

在这里插入图片描述

  • 然后再发100B,第一个字节序号为为101

在这里插入图片描述

  • 但是在接下来的数据接收中,A主机继续向B主机发送了从[201]开始的数据,但在途中丢失了。此时主机B发现主机A没有再发送数据过来了,因此向它发送过去一个确认报文段
  • 【ACK】是一个确认字段,我们在TCP的首部格式中有说到过,只有当ACK = 1 时ack才有效
  • 【ack】是表示当前主机希望收到的下一个数据的首字节号,即确认字段的值
  • 【rwnd】表示接收窗口,接收方主机B将此窗口设置为300,表示它只能接收300大小的数据字节,而且是从201开始到500的这段范围,也就限定了主机A的发送窗口从400->300

  • 因为前200个字节的数据主机B已经完全接收了,所以主机A将其发送窗口向前滑动200字节⛸,将首字节号设置为201B,窗口大小设置为300B。
  • 但是因为主机A没有接收到主机B从201~300字节的数据的回应,便开始启动这一块的超时计时器

在这里插入图片描述

  • 接下去主机A就向主机B分别发送了301B - 400B以及401B - 500B的数据,此时接收窗口就满了。

在这里插入图片描述

  • 但此时主机A发现前面201~300B的超时计时器时间到了,但是主机B还是没有发来相关的响应,于是重新发送了一次从201开始的这100个数据报文段,这也就是我们在上面讲到过的【超时重传】

  • 然后接下去主机B就发送了一条确认说“前面的500B我已经全部收到,现在我的接受窗口大小变为100,下一次希望收到501B为初始字节的数据”那此时主机A就可以确认主机B已经全部收到了500B之前的所有数据,于是便会将自己的发送窗口后移300个B,到501B的位置

在这里插入图片描述

  • 接下去主机A又发送过来符合的100B数据,于是主机B的接受窗口就满了。此时主机B就发送回一个确认报文说“前面的600B我已经全部收到,现在把你的发送窗口变为0,不要再发送数据了”

**从上面就可以看出主机B实现了三次流量控制,第一次将主机A的发送窗口大小从

400->300

,第二次从

300->100

,第三次就是从

100->0

,通过【rwnd】这个接收窗口的控制,就使得主机A的发送窗口呈现出一个动态变化的趋势,也就是我们前面在讲到窗口值是在动态变化的**

2、如何破解【死锁】局面❓

  • 但是主机A要何时才能继续向主机B发送数据呢❓也就是当主机B重新发出一个新的窗口值为止。B主机会在它的接收缓存中腾出一些地方,把缓存当中的数据[主机A发送过来的600B]上交给了应用层后,它的接收缓存中就又可以有一些存储空间了
  • 于是这个时候主机B就又会向主机A发送一个rwnd = 400的报文段,告诉它你现在可以将自己的发送窗口设置为400,并且开始发送数据了。但是这个报文段呢若是在传输的过程中丢失了(〃>目<),主机A就收不到,此时主机B一直在等待主机A发送新的数据过来,主机A呢也等待主机B发送一个报文段过来告诉自己可以发数据了,于是它们就开始了一段漫长的等待.<{=....
  • 以上这个局面叫做【死锁】,是双方在数据传输过程中很可能会出现的一个现象

在这里插入图片描述

那要怎么去解决这个局面呢?

  • TCP为每一个连接都设有一个【持续计时器】,当连接的一方收到对方的零窗口通知后,就会启动这个计时器。也就是当前的主机A,接下去呢它会发送一个【探测报文段】,这个报文段中会有1B的数据,发送过去之后若是接收方给出的窗口值依旧是0,那么主机A就会重新设置持续计时器。
  • 在这个时候呢主机B可能已经收到了应用层的通告,可以继续接收数据了;如果不是零,那么死锁的僵局就可以打破了。

  • 从上述流量控制就可以看出TCP真的是非常的严谨,很好得控制了每一次数据的传输o((>ω< ))o

二、TCP的拥塞控制

1、拥塞控制的一般原理

首先来看看什么叫做【拥塞】

【拥塞】:在某段时间内,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏 👉

∑对资源的需求 > 可用资源

① 解决网络拥塞的误区

很多人就认为解决网络拥塞的问题只需要增加一些资源即可

  1. 把节点缓存的存储空间扩大❌
  2. 把链路更换为更高速率的链路 ❌
  3. 把节点处理机的运算速度提高 ❌
  • 其实对于上面的这几种做法,都是不可行的,网络拥塞并没有想象中的那么简单,可能你单纯地解决了某个表现的问题,但是会引发出一些其他层次的问题。 - 例如说丢弃一些路由器分组时,这一分组的源点就会重传这一分组,但是这又会间接导致更多的分组流入网络和被网络中的路由器丢弃
  • 那其实我们可以看到,若只是采用一些简单的做法,在许多情况下,非但不能解决网络的拥塞问题,而且还可能使网络的性能更坏,所以我们要采取更加有效的方法

② 拥塞控制与流量控制的关系【重点理解✔】

在上一模块,我们讲到了流量控制,现在又说到了拥塞控制,那你可能会想它们之间会不会存在着什么关系呢?一起来看看🐎

在这里插入图片描述

  • 对于【拥塞控制】而言, 其实就是要防止过多的数据注入到网络,使得网络中的路由器或链路不至于过载,而且它是一个全局性的过程,会接收到不同主机、路由器所发送过来的数据,那么这个中心的交换节点就会同时被使用,从而到导致繁忙进而造成拥塞,可是呢接收方在这么繁忙的情况下又很难去知道、去查询是哪个主机出了问题
  • 对于【流量控制】而言,要做的就是抑制发送端发送数据的速率,以使接收端来得及接收。它是一个点对点通信量的控制,是个端到端的问题

可能在看了上面的叙述后依旧有点模糊,没关系,我通过一个生活中的小场景来叙述一下

  • 其实对于它们二者可以看作为一个水龙头通过管道向水桶放水。对图a来说,它只有一个很小的桶,因为来不及接收从水管中注入的水,因此就告知水龙头那边的人【将水龙头拧得小一些,以此来减缓放水的速率】,这种两端之间的通信就叫做流量控制
  • 相反,对图b来说,它拥有一个很大的桶,完全可以接得下从水管中流过来的水,但是呢水管中间可能因为一些内部的各种污垢造成了拥塞,然后可以看到水管的上方已经积蓄了很多的水,因此就需要和管水龙头一方的人说【将水龙头拧得小一些,以此来减少流入水管内部的水量】,这种内部的缓解就相当于是拥塞控制

在这里插入图片描述
👉对于同样的请求,都是将水龙头拧得小一些,但是目的却不一样。对照它们的原理之后,若是读者能明白,那也就懂了它们之间的区别

2、TCP的拥塞控制方法

了解了拥塞控制的一半原理,接下去我们来聊聊TCP面对这样的拥塞状况是如何应付的

为了集中讨论拥塞控制,假定:

  1. 数据是单方向传送的,对方只传送确认报文
  2. 接收方总是有足够大的缓存空间,因为发送窗口的大小由网络的拥塞程度来决定

① 接收窗口【rwnd】与拥塞窗口【cwnd】

  • 在流量控制中,我们提到了rwnd接收窗口,是由接收方维护的。表示接收方示意发送方自己可以接受的数据大小,以此来控制发送方发送数据的大小,
  • 在拥塞控制中我们再来聊聊一种窗口叫做cwnd拥塞窗口,它呢是由发送方维护的。它的大小取决于网络的拥塞程度,并且是动态变化着的。因为上面我们假定接收方的接收窗口足够大,因为发送方只需要考虑拥塞窗口的大小即可

【发送方控制拥塞窗口的原则】:

  1. 只要网络没有出现拥塞,拥塞窗口就可以增大一些,将更多的数据发送出去,以此来提高网络利用率
  2. 当网络出现拥塞或可能要出现拥塞时,就把拥塞窗口减小一点,减少注入到网络的分组数,以便缓解网络出现的拥塞

发送方如何知道网络出现了堵塞?

  • 没有按时收到对方的确认报文,超时重传计时器启动,便判断出网络出现了拥塞

来总结一下这两个窗口
👉【接受窗口 rwnd】:由接收方维护,会根据接收缓存设置的值,并告知给发送方,反映接收方容量

👉【拥塞窗口 cwnd】:由发送方维护,会根据自己估算的网络拥塞程度而设置的窗口值,反映网络当前容量

② 慢开始和拥塞避免算法

接下去我们来介绍一下拥塞控制中的算法,首先是

慢开始和拥塞避免算法

这两种,它们是配合使用的

📚 【慢开始算法原理】:由小到大逐渐将数据字节注入到网络中,即逐渐增加拥塞窗口的数值

  • 接着你要知道一个东西叫做最大报文段SMSS,因为慢开始规定,每收到一个新的报文段后,可以把拥塞窗口增加最多一个SMSS的值。然后通过下面这个例子来介绍一下慢开始算法

在这里插入图片描述

  • 从上图可以看出,对于发送方它首先设置【cwnd = 1】,发送出第一个报文段,然后接收方确认了这个报文段再发送回一个确认报文段,这一点我们在前面TCP流量控制中也有说到过,这么一趟来回就叫做一个轮次,也可以叫做往返时延RTT
  • 经过了一个往返时延后,发送方便扩大拥塞窗口,令【cwnd = 2】,连续发出了两个报文段,然后接收方那个接收到之后就进行了返回确认,这是第二轮的RTT
  • 那发送方收到这两个确认报文段之后,便继续扩大自己的拥塞窗口,令【cwnd = 4】,一样,接收方接收到之后又会返回确认,这是第三轮的RTT
  • 依此类推。。。发送方若是试探到本网络的拥塞状况良好,就会不断地增加自己的拥塞窗口,尽快地将数据发送出去。这种慢开始的策略可以使得网络拥塞的概率减小

从上可以知道拥塞窗口在慢开始算法下会不断地增大,但是若是太大也不好,也会造成过多的数据涌入导致网络拥塞,因此便有了

[慢开始门限ssthresh]

这么一个状态变量,它的用法如下👇

  1. 当【cwnd < ssthresh】时,使用上述的慢开始算法
  2. 当【cwnd > ssthresh】时,停止使用慢开始算法而改用拥塞避免算法
  3. 当【cwnd = ssthresh】时,即可使用慢开始算法,也可使用拥塞避免算法

📚 【拥塞避免算法原理】:让拥塞窗口cwnd按线性规律缓慢增长,每个轮次RTT只加1

  • 然后我们便可以通过下面这张曲线图来看出TCP的拥塞窗口cwnd是如何变化的在这里插入图片描述

这一块可以听一听王道这个小姐姐讲的,还是蛮不错的👍

5.3.5 TCP拥塞控制

③ 快重传和快恢复算法

然后再来简单介绍一下

快重传和快恢复

这两个算法

📚 【快重传算法原理】:让发送方尽早知道发生了个别报文段丢失的情况,若发送发一连收到三个重复确认,便会立即重传接收方需要的报文段

  • 对于这三次报文的重复确认,就是我们前面介绍过的冗余ack

在这里插入图片描述
📚 【快恢复算法原理】:当发送端收到连续三个重复的确认时,不执行慢开始算法,而是执行快恢复算法算法

  • 对于慢开始算法而言,会使拥塞窗口降到1后再使用拥塞避免算法慢慢升回到调整后的慢开始门限值
  • 对于快恢复算法而言,不会使拥塞窗口降到最小值1,而是降到门限值ssthresh / 2的位置,然后再次执行拥塞避免算法,使拥塞窗口缓慢地线性增大

以下是【TCP拥塞控制】的整个流程图,可以再对照回顾一下

在这里插入图片描述

三、总结与提炼

来总结一下本文所学习的内容

  • 首先我们谈到了有关TCP的流量控制,在双方进行数据收发过程中,为了防止发送方发送的数据接收方无法接受或者是过载难以接受,于是便使用到了【滑动窗口】的机制去进行了一个收与发的限制,通过发送方和接收方不断地来回响应,以此让我们看出TCP协议的严谨性
  • 接着我们又谈到了有关TCP的阻塞控制。首先清楚了它与流量控制之间的区别,以及它们之间的联系,为了方便大家理解,我用到了水桶接水的案例对它们做了区分。最后我们又细细地谈了谈有关TCP如何去实现一个阻塞控制,清楚了两个窗口,分别是【rwnd】接受窗口和【cwnd】拥塞窗口,也见识了TCP在进行阻塞控制时使用到的【慢开始和拥塞避免算法】、【 快重传和快恢复算法】,湖不过只是浅浅地提了一下,没有非常深入,有兴趣的小伙伴可以再去多了解一些里面的细节

2023年2月20日随记✍


本文转载自: https://blog.csdn.net/Fire_Cloud_1/article/details/129129118
版权归原作者 烽起黎明 所有, 如有侵权,请联系我们删除。

“计算机网络 | 谈谈TCP的流量控制与拥塞控制”的评论:

还没有评论