一、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、拥塞控制的一般原理
首先来看看什么叫做【拥塞】
【拥塞】:在某段时间内,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏 👉∑对资源的需求 > 可用资源
① 解决网络拥塞的误区
很多人就认为解决网络拥塞的问题只需要增加一些资源即可
- 把节点缓存的存储空间扩大❌
- 把链路更换为更高速率的链路 ❌
- 把节点处理机的运算速度提高 ❌
- 其实对于上面的这几种做法,都是不可行的,网络拥塞并没有想象中的那么简单,可能你单纯地解决了某个表现的问题,但是会引发出一些其他层次的问题。
- 例如说
丢弃一些路由器分组
时,这一分组的源点就会重传这一分组,但是这又会间接导致更多的分组流入网络和被网络中的路由器丢弃
- 例如说
- 那其实我们可以看到,若只是采用一些简单的做法,在许多情况下,非但不能解决网络的拥塞问题,而且还可能使网络的性能更坏,所以我们要采取更加有效的方法
② 拥塞控制与流量控制的关系【重点理解✔】
在上一模块,我们讲到了流量控制,现在又说到了拥塞控制,那你可能会想它们之间会不会存在着什么关系呢?一起来看看🐎
-
对于【拥塞控制】而言, 其实就是要
防止过多的数据注入到网络
,使得网络中的路由器或链路不至于过载,而且它是一个全局性
的过程,会接收到不同主机、路由器所发送过来的数据,那么这个中心的交换节点就会同时被使用,从而到导致繁忙进而造成拥塞,可是呢接收方在这么繁忙的情况下又很难去知道、去查询是哪个主机出了问题 -
对于【流量控制】而言,要做的就是
抑制发送端发送数据的速率
,以使接收端来得及接收。它是一个点对点通信量的控制,是个端到端
的问题
可能在看了上面的叙述后依旧有点模糊,没关系,我通过一个生活中的小场景来叙述一下
- 其实对于它们二者可以看作为一个水龙头通过管道向水桶放水。对图a来说,它只有一个很小的桶,因为来不及接收从水管中注入的水,因此就告知水龙头那边的人【将水龙头拧得小一些,以此来减缓放水的速率】,这种两端之间的通信就叫做
流量控制
- 相反,对图b来说,它拥有一个很大的桶,完全可以接得下从水管中流过来的水,但是呢水管中间可能因为一些内部的各种污垢造成了拥塞,然后可以看到水管的上方已经积蓄了很多的水,因此就需要和管水龙头一方的人说【将水龙头拧得小一些,以此来减少流入水管内部的水量】,这种内部的缓解就相当于是
拥塞控制
👉对于同样的请求,都是将水龙头拧得小一些,但是目的却不一样。对照它们的原理之后,若是读者能明白,那也就懂了它们之间的区别
2、TCP的拥塞控制方法
了解了拥塞控制的一半原理,接下去我们来聊聊TCP面对这样的拥塞状况是如何应付的
为了集中讨论拥塞控制,假定:
- 数据是单方向传送的,对方只传送确认报文
- 接收方总是有足够大的缓存空间,因为
发送窗口的大小由网络的拥塞程度
来决定
① 接收窗口【rwnd】与拥塞窗口【cwnd】
- 在流量控制中,我们提到了
rwnd
接收窗口,是由接收方
维护的。表示接收方示意发送方自己可以接受的数据大小,以此来控制发送方发送数据的大小, - 在拥塞控制中我们再来聊聊一种窗口叫做
cwnd
拥塞窗口,它呢是由发送方
维护的。它的大小取决于网络的拥塞程度,并且是动态变化着的。因为上面我们假定接收方的接收窗口足够大,因为发送方只需要考虑拥塞窗口的大小即可
【发送方控制拥塞窗口的原则】:
- 只要网络没有出现拥塞,拥塞窗口就可以
增大一些
,将更多的数据发送出去,以此来提高网络利用率 - 当网络出现拥塞或可能要出现拥塞时,就把拥塞窗口
减小一点
,减少注入到网络的分组数,以便缓解网络出现的拥塞
发送方如何知道网络出现了堵塞?
- 没有按时收到对方的确认报文,超时重传计时器启动,便判断出网络出现了拥塞
来总结一下这两个窗口
👉【接受窗口 rwnd】:由接收方维护,会根据接收缓存设置的值,并告知给发送方,反映接收方容量
👉【拥塞窗口 cwnd】:由发送方维护,会根据自己估算的网络拥塞程度而设置的窗口值,反映网络当前容量
② 慢开始和拥塞避免算法
接下去我们来介绍一下拥塞控制中的算法,首先是
慢开始和拥塞避免算法
这两种,它们是配合使用的
📚 【慢开始算法原理】:由小到大逐渐将数据字节注入到网络中,即逐渐增加拥塞窗口的数值
- 接着你要知道一个东西叫做
最大报文段SMSS
,因为慢开始规定,每收到一个新的报文段后,可以把拥塞窗口增加最多一个SMSS的值。然后通过下面这个例子来介绍一下慢开始算法
- 从上图可以看出,对于发送方它首先设置【cwnd = 1】,发送出第一个报文段,然后接收方确认了这个报文段再发送回一个确认报文段,这一点我们在前面
TCP流量控制
中也有说到过,这么一趟来回就叫做一个轮次,也可以叫做往返时延RTT
- 经过了一个往返时延后,发送方便扩大拥塞窗口,令【cwnd = 2】,连续发出了两个报文段,然后接收方那个接收到之后就进行了返回确认,这是
第二轮的RTT
- 那发送方收到这两个确认报文段之后,便继续扩大自己的拥塞窗口,令【cwnd = 4】,一样,接收方接收到之后又会返回确认,这是
第三轮的RTT
- 依此类推。。。发送方若是
试探
到本网络的拥塞状况良好,就会不断地增加自己的拥塞窗口,尽快地将数据发送出去。这种慢开始的策略可以使得网络拥塞的概率减小↓
从上可以知道拥塞窗口在慢开始算法下会不断地增大,但是若是太大也不好,也会造成过多的数据涌入导致网络拥塞,因此便有了[慢开始门限ssthresh]
这么一个状态变量,它的用法如下👇
- 当【cwnd < ssthresh】时,使用上述的慢开始算法
- 当【cwnd > ssthresh】时,停止使用慢开始算法而改用
拥塞避免
算法 - 当【cwnd = ssthresh】时,即可使用
慢开始算法
,也可使用拥塞避免
算法
📚 【拥塞避免算法原理】:让拥塞窗口cwnd按线性规律缓慢增长,每个轮次RTT只加1
- 然后我们便可以通过下面这张曲线图来看出TCP的拥塞窗口cwnd是如何变化的
这一块可以听一听王道这个小姐姐讲的,还是蛮不错的👍
5.3.5 TCP拥塞控制
③ 快重传和快恢复算法
然后再来简单介绍一下
快重传和快恢复
这两个算法
📚 【快重传算法原理】:让发送方尽早知道发生了个别报文段丢失的情况,若发送发一连收到三个重复确认,便会立即重传接收方需要的报文段
- 对于这三次报文的重复确认,就是我们前面介绍过的
冗余ack
📚 【快恢复算法原理】:当发送端收到连续三个重复的确认时,不执行慢开始算法,而是执行快恢复算法算法
- 对于
慢开始算法
而言,会使拥塞窗口降到1后再使用拥塞避免算法慢慢升回到调整后的慢开始门限值 - 对于
快恢复算法
而言,不会使拥塞窗口降到最小值1,而是降到门限值ssthresh / 2
的位置,然后再次执行拥塞避免算法,使拥塞窗口缓慢地线性增大
以下是【TCP拥塞控制】的整个流程图,可以再对照回顾一下
三、总结与提炼
来总结一下本文所学习的内容文章来源:https://www.toymoban.com/news/detail-779550.html
- 首先我们谈到了有关
TCP的流量控制
,在双方进行数据收发过程中,为了防止发送方发送的数据接收方无法接受或者是过载难以接受,于是便使用到了【滑动窗口】的机制去进行了一个收与发的限制,通过发送方和接收方不断地来回响应,以此让我们看出TCP协议的严谨性 - 接着我们又谈到了有关
TCP的阻塞控制
。首先清楚了它与流量控制之间的区别,以及它们之间的联系,为了方便大家理解,我用到了水桶接水的案例对它们做了区分。最后我们又细细地谈了谈有关TCP如何去实现一个阻塞控制,清楚了两个窗口,分别是【rwnd】接受窗口和【cwnd】拥塞窗口,也见识了TCP在进行阻塞控制时使用到的【慢开始和拥塞避免算法】、【 快重传和快恢复算法】,湖不过只是浅浅地提了一下,没有非常深入,有兴趣的小伙伴可以再去多了解一些里面的细节
2023年2月20日随记✍文章来源地址https://www.toymoban.com/news/detail-779550.html
到了这里,关于计算机网络 | 谈谈TCP的流量控制与拥塞控制的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!