一、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是如何变化的
  

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

③ 快重传和快恢复算法

然后再来简单介绍一下快重传和快恢复这两个算法

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

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

📚 【快恢复算法原理】：当发送端收到连续三个重复的确认时，不执行慢开始算法，而是执行快恢复算法算法

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

---

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

三、总结与提炼

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

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

---

2023年2月20日随记✍