TCP协议原理二

矫情吗；* 2023-09-27 14:28 12阅读 0赞

![在这里插入图片描述][bbfac66df6c643d09f2e30d673ce5421.gif_pic_center]

#### 文章目录 ####

*  四、滑动窗口
 *  五、流量窗口
 *  六、拥塞控制

## 四、滑动窗口 ##

前面我们学习了 确认应答，超时重传，连接管理，这些机制都为我们TCP的可靠性提供了保证，当然在保证TCP的可靠性的同时，传输效率也受到了一定的影响，我们的TCP也将尽可能的提高传输效率，大家注意这里的提高传输效率，实际上是尽量的降低效率的亏损，无论我们如何提高都不可能比UDP这种不考虑可靠性的效率高，我们要做的是尽量让TCP效率高一些。  
![在这里插入图片描述][74b478fd1c3440679bad10b40d85a892.png]  
对于我们基本的确认应答来言，每次发一个数据后都需要收到一个ack后才发下一个数据。  
![在这里插入图片描述][cc82b598bb61425a821f7f1d972316e4.png]  
滑动窗口的本质就是批量发送一组数据，然后使用一份时间来等待多个ack，这样就可以大大的提高性能。  
窗口大小： 不需要等待，直接可以发送的数据最大的量。  
我们在这里并不是等所有的ack到达后，才继续往下发，而是到一个ack就继续往下发一条，操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉。窗口越大，网络的吞吐率就越高。  
![在这里插入图片描述][83e57f20d6ce42ba9a75540c62366867.png]  
比如这里我们等待的ack是1001-5000，我们收到了2001这个ack，证明2001之前的数据(1001-2000)已经确定了，我们接下来就可以立即再发一条，也就是5001-6000的数据，此时意味着我们等待的ack的范围就是2001-6000了  
**上面的情况都是理想状态，那如果出现了丢包了怎么办?**  
1. ack丢了  
![在这里插入图片描述][50213768ccca4f68ac6a48d37c9fe929.png]  
如果是ack丢了，我们不做任何处理也没事，为什么? 就需要我们弄清楚ack的含义是什么。  
ack代表的是该序号之前的所有数据都确认到达了。  
比如我们这里的1001的ack丢失了，但是我们的2001ack顺利到达了，2001到达的含义就是：2001之前的所有数据都确认到达了(1-1000 和 1001-2000都已到达)，2001这个ack已经覆盖了上一个丢失的1001ack的信息了。

2. 数据丢了  
![在这里插入图片描述][1fd797c9da12441b919efc3e1ae737fb.png]  
我们这里的2001-3000丢包了，接下来3001-4000到达接收方之后，接收方给发送端的ack确认序号仍然是2001，表达的意思就是在索要2001开头的数据，我们可以发下下面的几个ack返回的都是2001，这时候发送端就会发现虽然已经发了许多数据了，但是接收端一直在反复索要2001开头的数据，证明2001-3000是没有收到的需要重传了。  
等我们重传2001-3000的数据之后，由于2001-8000的数据都已经接收到了，于是接下来接收端索要的数据就是8001了。  
**快速重传：** 就是我们上述丢包后重传的情况，也可以理解为超时重传机制在滑动窗口场景的变形。  
有的同学可能会问到，那这样接收端接收的数据不就乱序了吗？  
这个不必担心，因为我们TCP有接收缓冲区，会在缓冲区根据序号进行重新排序。

## 五、流量窗口 ##

简单理解一下，我们流量窗口就是干涉滑动大小的机制。  
随着滑动窗口的变大，我们的传输效率也在变高，但能无限增大吗?

1.  如果无限大，相当于不等ack，那么可靠性能否保证？
2.  窗口太大，会消耗大量的系统资源
3.  接收方的处理能力能否跟得上?

我们接收方的处理能力是我们滑动窗口大小的一个很重要的约束条件，我们流量控制要进行的工作就是根据接收方的处理能力，来协调我们发送方的放松速度。  
衡量接收方的处理能力是一个非常复杂的问题，可以从多个角度去衡量，比如去计算我们接受方的处理速度，但这种方式太麻烦了，于是我们这里有一个更简单的方法，就是**判断接收方缓冲区的剩余大小**。  
![在这里插入图片描述][fd1d99712aed436b99d1977a150d2864.png]  
我们接收方每次接收到数据之后，都需要计算一个水桶剩余的容量，然后将这个值通过ack报文返回给发送方，然后发送方就能根据这个值来决定接下来发送的速率大小(窗口大小)是多少了。  
![在这里插入图片描述][5827fc4da14742a28854d8db27f1cf99.png]  
16位的窗口大小是否意味着窗口大小最大是64kb了?  
并不是，我们的TCP在选项部分引入了一个窗口扩展因子 ，比如当我们窗口大小已经是64kb了但是仍然不够，于是在选项里的扩展因子写了个2，就代表64kb << 2 == 256 kb，这样就可以动态调整窗口大小了。  
![在这里插入图片描述][6dd8873a4afa40b0804a72f8db3f43f7.png]  
由于我们接收端的缓冲区剩余容量是一直动态变化的，所以每次返回的ack的窗口大小也是在不断变化的。

1.  接收端一旦发现自己的缓冲区快满了，会将窗口大小设置成一个更小的值通知发送端
2.  发送端发现会随着接收端ack报文中的窗口大小减小而减慢自己的发送速度
3.  如果接收端缓冲区慢了，就会将窗口设置为0，发送方将不再发送数据，会定期发送一个**窗口探测**数据段，使接收端发送一个新的窗口大小给发送端

## 六、拥塞控制 ##

拥塞控制和流量控制共同去决定发送方的窗口大小为多大，我们刚刚学习的流量控制考虑的是接收方的处理能力，而我们拥塞控制考虑的是传输过程中各个结点的处理能力。  
![在这里插入图片描述][8e933a0d64584672bcdd10dda056c580.png]  
我们刚刚只考虑了B的处理能力，越没有考虑这些中间结点的因素，决定A发送速度是有这两者最差的一个决定的，也就是典型的木桶效应。  
我们中间的结点是错综复杂的，不太好衡量，但是大佬们总是有办法，想出了一个实验的方式来  
测试出一个合适的值。  
**拥塞控制：** 本质上就是通过实验的方式，来逐渐找到了一个合适的窗口大小。  
![在这里插入图片描述][4ea12ccf112c49a99a3c62a39522f0c4.png]  
**慢启动：** 我们可以发现0轮时，窗口大小是1(1不是一字节，而是一个单位，具体代表多少不是我们考虑的范围)，以非常慢的速度发送数据，如果发现没有丢包，就扩大窗口。第一轮窗口大小为2，扩大了一倍，初始阶段，由于窗口大小比较小，只要每一轮不丢包窗口都扩大一倍(指数增长)。  
**阈值：** 因为指数方式增长的很快，为了不增长那么快，引入了一个慢启动的阈值，当拥塞窗口超过这个阈值的时间，不再按照指数增长，而是按照线性方式增长。  
在接下来，如果传输过程中一旦出现了丢包，如果是极少量的丢包仅仅触发超时重传，如果大量丢包，我们就认为网络拥堵，到达了发送速率的极限，此时就将窗口大小一次性缩到很小的值，然后重复上述的指数增长和线性增长的过程，因为我们的拥塞窗口不是固定的值，而是一直动态变化的。

**流量控制和拥塞窗口共同决定了发送方实际发送的窗口大小(流量控制和拥塞控制的较小值)**

[bbfac66df6c643d09f2e30d673ce5421.gif_pic_center]: https://img-blog.csdnimg.cn/bbfac66df6c643d09f2e30d673ce5421.gif#pic_center
[74b478fd1c3440679bad10b40d85a892.png]: https://img-blog.csdnimg.cn/74b478fd1c3440679bad10b40d85a892.png
[cc82b598bb61425a821f7f1d972316e4.png]: https://img-blog.csdnimg.cn/cc82b598bb61425a821f7f1d972316e4.png
[83e57f20d6ce42ba9a75540c62366867.png]: https://img-blog.csdnimg.cn/83e57f20d6ce42ba9a75540c62366867.png
[50213768ccca4f68ac6a48d37c9fe929.png]: https://img-blog.csdnimg.cn/50213768ccca4f68ac6a48d37c9fe929.png
[1fd797c9da12441b919efc3e1ae737fb.png]: https://img-blog.csdnimg.cn/1fd797c9da12441b919efc3e1ae737fb.png
[fd1d99712aed436b99d1977a150d2864.png]: https://img-blog.csdnimg.cn/fd1d99712aed436b99d1977a150d2864.png
[5827fc4da14742a28854d8db27f1cf99.png]: https://img-blog.csdnimg.cn/5827fc4da14742a28854d8db27f1cf99.png
[6dd8873a4afa40b0804a72f8db3f43f7.png]: https://img-blog.csdnimg.cn/6dd8873a4afa40b0804a72f8db3f43f7.png
[8e933a0d64584672bcdd10dda056c580.png]: https://img-blog.csdnimg.cn/8e933a0d64584672bcdd10dda056c580.png
[4ea12ccf112c49a99a3c62a39522f0c4.png]: https://img-blog.csdnimg.cn/4ea12ccf112c49a99a3c62a39522f0c4.png