TCP协议中的几个机制

Bertha 。 2024-03-02 10:28 2阅读 0赞

## TCP协议四 ##

--------------------

TCP协议一: [TCP协议之特点和首部格式][TCP]  
TCP协议二: [TCP协议之可靠传输][TCP 1]  
TCP协议三: [TCP的三次握手和四次挥手][TCP 2]

--------------------

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

*  TCP协议四
 *  1.滑动窗口
 *  2.流量控制
 *  3.拥塞控制
 *  4.延时应答
 *  5.捎带应答
 *  6.面向字节流
 *  7.异常情况

--------------------

## 1.滑动窗口 ##

确认应答，超时重传，连接管理都是给TCP的可靠性提供的支持，引入了可靠性，那就牺牲了传输效率，**可靠性和效率是冲突的**，因此UDP虽然没有可靠性，但是传输效率要比TCP高，TCP竭尽可能的提高传输效率运输(本质上补救措施)，**滑动窗口本质上就是降低了确认应答，等待ack消耗的时间。**

> 等待ack消耗的时间:在进行IO操作的时候，其实时间成本主要是两个部分1.等 2.数据传输(数据拷贝)，但是大多数情况下，IO花的时间成本都是在等待，

> 比如:下一部电影，当开始下载的时候，计算机会向服务器发送请求，并开始将数据从服务器复制到你的计算机中，但是文件比较大，因此需要一定时间才能完成数据传输和ACK确认，因此程序必须等待所有数据完成后才能继续执行其他任务，从而导致程序暂时停滞，直到文件下载完成为止。

对于基本确认应答就是如此，每次都是发送一个数据后，等待ack到达后，再发送下一个数据

![在这里插入图片描述][88870fb1bb674ecc968735b74d87b00e.png]  
**而滑动窗口的本质是批量发送一组数据，使用一份时间来等待一组数据的多个ack，从而提高效率**，并且**将不需要等待，就能直接发送数据的最大的量称为"窗口大小"**

当批量发送了数据(窗口大小)后，发送方就要等待ack，这时候就要讨论，什么时候发送后续数据，**不同于基本确认应答，发送方不需要等待所有ack都到达，才继续往下发，而是到达一个ack，就往下发送一条数据，从而保证了此处等待的ack条数一致。**

这里的滑动窗口就相当于，同时有八个人找我聊天，但是我一次只能回四个人，我是一次性聊完四个人再聊剩下的人，再去聊剩下四个?显然不是，当我四个人回完一个之后，就可以开启下一个人，每次都保持同时在聊四个人，**每次聊完一个人，就立即开启下一个，窗口大小始终不变**，**但是聊的人变了，形象的称为滑动**

> 比如下图，等待的ack条数始终为4条

![在这里插入图片描述][e91b980c9d214f90b0d10403478adc5a.png]  
在基本确认应答中，出现了丢包的情况，在滑动窗口也会出现丢包情况，主要分为两种情况:

**1.ack丢失**

对于ack丢失，解决方案:不用处理，首先我们要明白**确认序号的意义:表示从该序号的所有数据均到达，是一种包含关系**

> 例如下图中虽然1001的ack丢失，但是2001的ack已经包含了1001这个ack

![在这里插入图片描述][b73df6f518ec4ce696749692a0b97252.png]  
但又出现一个新的问题，那为什么前面还要有ack，只要发一次就足够证明的前面的数据均已到达，确实如此，在实际情况中，ack并没有全部都在发，可能会少发，但是这个并不影响可靠性，同时节省了系统资源

**2. 数据丢失**

![在这里插入图片描述][0ac57d6043e0427e82cc525ff87ae64f.png]

在上图中，由于1001-2000丢包，接下来2001-3000到达主机B之后，B返回A的ack确认序号不是2001，而是1001，即索要1001开头的数据，而且在接下来1001的确认序号将会被重复不断地返回，**发送端主机如果连续3次收到同一个确认应答，就会将其所对应的数据进行重发，这种机制比之前的超时重传更加高效，因此也被称为高速重发控制**，**可以将其视为超时重传机制在滑动窗口的变形**（在重传的时候，数据会出现乱序的情况，但TCP中有个接收缓冲区，数据会在缓冲区里按照序号重新排队）

> 这里**区别超时重传机制和高速重发控制**，TCP协议中的高速重发控制和超时重传机制都是为了确保数据的可靠传输，但是它们的实现方式不同。**高速重发控制是在发送方收到三个重复的确认报文（ACK）后，立即重传数据，而超时重传机制则是在发送方发送数据后，等待接收方返回确认报文（ACK），如果在指定时间内没有收到接收方的应答，就会重发该数据**

## 2.流量控制 ##

> 流量控制:是一种干预发送的窗口大小的机制

滑动窗口，窗口越大，传输效率就越高(一份时间，等待的ack越多)，但是"月满则亏，水满则溢"，滑动窗口也是这个道理，它不能无限大，当它无限大的时候，就有可能出现以下情况:

> 1.上面所说，确认序号是由包含关系，中间有可能省略发送一些ack，从而节约系统资源，但是当窗口越大时，就有可能导致窗口不等ack去发送数据，从而丧失了可靠性  
> 2.窗口太大，也会损耗大量系统资源  
> 3.发送方发送太快，但接收方可以接受处理的数据量是有限的

**而流量控制，就是根据接收方的处理能力协调发送方的发送速率**，简单而言，就是**让发送方的发送速率不要太快，要让接收方来得及接收**，那要如何衡量接收方的处理能力，直接**计算接收方接收缓冲区的剩余大小**即可

> 举一个例子:可以将接收缓冲区想象成蓄水池

![在这里插入图片描述][76d42dae3c6f42adadc9b3625d29b1d8.png]

> a的部分作为剩余空间的容量就可以作为衡量发送方发送速率的指标，每当A发送给B数据时，B就会计算剩余空间后通过ack报文发送给A，A会根据所传的值决定接下来发送的速率是多少(即窗口大小是多少)

再来说一下窗口大小，窗口大小在报文为ack的时候才会生效，发送方会根据这个数字确定下一轮发送的窗口大小，下图中只有16位窗口大小，是否意味着窗口大小就是64kb（2^16/1024），显然不是的，TCP为了窗口更大，在选项部分引入窗口扩展因子，例如，下图的窗口大小已经是64kb，扩展因子里面标注的为2，意思就是64kb<<2=256kb

![在这里插入图片描述][8aaf2776eb9d49b2805c35298f37505f.png]  
值得注意的是发送方窗口大小不是固定值，也不是配置的，而是随着传输过程的进行，动态调整的，因为接收方接收缓冲区的剩余空间一直在动态变化的，并且当窗口大小为0时，发送方就要暂停发送，暂停发送的等待过程中，会给B定期发送窗口探测报文，这个报文不携带具体的东西，只是为了触发ack查询窗口大小

## 3.拥塞控制 ##

在流量控制中，我们讨论了A的发送速率和B的接收能力，但是没有考虑中间节点，而**拥塞控制描述的是传输过程中中间节点的处理能力**

![在这里插入图片描述][a35d68dcf477402d8b000d638c1305e2.png]

> 从下图中可以看出，第0轮:窗口大小是1，以非常慢的速度发送数据(PS.此处的1不是一字节，而是1单位，至于1单位是多少字节不去细究)，发现传输顺利，无丢包，扩大窗口;第1轮:窗口大小是2，扩大一倍，以此类推…

在初始阶段，由于初始窗口比较小，每一轮都不会丢包，所以每一轮都会扩大窗口一倍(为指数增长)，当增长到达阀值之后，指数增长变为线性增长，但是增长的前提是不丢包，接着持续增长，直到传输过程中出现丢包，说明此时的发送速率已经接近网络的极限，这时将窗口大小骤变成很小的值，再次重复上述过程。

![在这里插入图片描述][2cb8d094a65b41aa9928acacf53f3039.png]  
从上面可以看出**拥塞控制下的窗口大小不是固定数值，而是一直动态变化，并随着时间的推移，逐渐达到一个动态平衡的过程**

简单举例，拥塞控制下的窗口动态变化就相当于两个谈恋爱的人，开始恋爱时，处于热恋时期，感情呈指数增长，当这个时期结束后，感情呈线性增长，当经历吵架分手后，感情迅速下降到低谷，然后和好，再次出现指数增长和线性增长，随着时间推移，感情一直在动态变化，最后处于一个动态平衡状态。

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

## 4.延时应答 ##

延时应答是一种提升效率的机制，在滑动窗口的基础上，增添东西，**即在收到数据后，不会立即返回ack，而是等待一定时间后再返回**，可以在等待的时间里，接收方的应用程序会将接收缓冲区的数据进行处理，从而得到更大的剩余空间，可以接收更多数据。

延时应答的本质是在滑动窗口的基础下，ack不再每一条都返回，例如下图中每隔一条返回一个ack  
![在这里插入图片描述][6287342ff6714644af745f1eb2b27752.png]

## 5.捎带应答 ##

捎带应答是一种提高效率的机制，捎带应答是在延时应答的基础上引入的

> 例如下图中，"我看看"和"计组"本身就是不同的时机，但是TCP中存在延时应答，导致在等待  
> ack的过程中，B就给A发送业务数据，就可以业务数据捎带上这个ack一起发送过去，**捎带应答本质上就是增加合并的概率**

![在这里插入图片描述][b621224d75fb4b9d9c256e9d5c1d8656.png]

## 6.面向字节流 ##

TCP中的一个特点是面向字节流，但是同时也引入了一个问题，粘包问题

> 例如：现在要发送一句话:“我喜欢你的钱”，按照正常传输应该是没有问题的，但是TCP是字节流，一次可能读1个字节，也可能读N个字节，这就导致一次读到的数据，有可能是半个应用层数据报，可能是一个，也可能是多个，所以这句话，可能被读成两个，就变成了第一个是:“我喜欢你”,第二个是:“的钱”，从而产生粘包问题

解决方案其实很简单:约定好应用层协议，明确应用层数据报和应用层数据报之间的边界即可，1.约定好分隔符，2.约定好每个包的长度

## 7.异常情况 ##

异常情况即传输中出现了不可抗力的因素

**1.进程崩溃**

进程没了，对应的PCB没了，对应的文件描述符表就释放掉了，但是此时的内核仍然会继续完成四次挥手，仍然是一个正常的断开连接

**2.主机关机(按照正常流程关机)**

主机关机会杀死进程，然后才正式关机，仍然会触发四次挥手

**3.主机掉电/4.网线断开**

假设接收方掉电/掉网，发送方仍在传送数据，发送数据后，等待ack到达，然后始终都等不到ack到达，进行超时重传，也无法接收到ack，仍然无法接收到ack，再进行重置TCP连接(复位报文段RST)，结果重置失败，最后TCP单方面放弃连接；

假设发送方掉电/掉网，接收方在接收数据的时候，发现没有数据传入，接收方会先等待，并且周期性的给发送方发送一个消息即心跳包，用来确认通信双方是否处于正常的工作状态

[TCP]: https://blog.csdn.net/m0_62055442/article/details/130868996
[TCP 1]: https://blog.csdn.net/m0_62055442/article/details/133099050
[TCP 2]: https://blog.csdn.net/m0_62055442/article/details/133152407
[88870fb1bb674ecc968735b74d87b00e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/5b68635b02384ffaa4d60b505e74e3e7.png
[e91b980c9d214f90b0d10403478adc5a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/0644850db887432ca6baa87152c7873f.png
[b73df6f518ec4ce696749692a0b97252.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/7d34376ebbbd4a718f7e6ee7786b80a2.png
[0ac57d6043e0427e82cc525ff87ae64f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/f395b184b331490792bf6f3cb097f533.png
[76d42dae3c6f42adadc9b3625d29b1d8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/fb767563e6a843ef8f8dcfe0009aedcd.png
[8aaf2776eb9d49b2805c35298f37505f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/a9c31c41fc3d473b91256ff5448a722c.png
[a35d68dcf477402d8b000d638c1305e2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/facba422aea64e5e8254cb606b656486.png
[2cb8d094a65b41aa9928acacf53f3039.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/25ca3b49b020418cb9f3e5749c2e0267.png
[6287342ff6714644af745f1eb2b27752.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/d01b2663899e4406b8e3e861b6f429ee.png
[b621224d75fb4b9d9c256e9d5c1d8656.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/52963a3f9b68436cbc649450c04314cf.png