「TCP 重要机制」滑动窗口 & 粘包问题 & 异常情况处理

🎇个人主页：Ice_Sugar_7
🎇所属专栏：计网
🎇欢迎点赞收藏加关注哦！

🍉滑动窗口

网络原理提到的滑动窗口和算法中提到的那个本质是类似的

前面提到的确认应答、超时重传等机制其实都是为了确保可靠传输，不过为了可靠，传输效率也会相应降低，即单位时间内能传输的数据量变少了
滑动窗口就是为了在确保可靠传输的基础上，减少传输效率的损失（止损）
来看一下具体是怎么一回事
之前是发一个数据，然后等待 ACK，然后再发下一条数据。现在是先发一个数据，不等 ACK，直接继续发下一个，等到发了一定数据之后，再停下来等一波 ACK

不过如果出现丢包，那滑动窗口还滑得起来吗？

1. 如果是数据包到了，但是 ACK 丢了

在上图的情况下，报文是序号小的先到，不过也有可能是序号大的先到主机 A，比如 2001 比 1001 先到，此时效果和 1001 丢包一样，主机 A 会认为 1-1001 和 1001-2000 都已经到达 B 了，然后滑动窗口会往后滑动两个格子

2. 数据包丢了
   在这种情况下，那就要重传了

上面这种重传的效率是非常高的，因为这里是有针对的重传，哪个丢了就重传哪个，已经收到的数据是不会重发的，整体效率没有额外损失，这种重传称为快速重传
可以认为接收方的接收缓冲区里面的数据是按照顺序排好的，在上图的例子中，1-7000 中有 6 个数据包被接收方收到，在接收缓冲区里按序号从小到大排序（类似排队），从前往后捋一下就知道缺了 1001 这个数据包，所以通过确认序号索要它

确认应答、超时重传、滑动窗口、快速重传的联系：
滑动窗口中也有确认应答，只不过调整了等待策略，一次性发送大量数据后统一等待 ACK 报文，如果发的数据很少，此时滑动窗口滑不起来，就成了确认应答
如果当前按照滑动窗口的模式传输数据，那就会按照快速重传保证可靠性，此时判定丢包的标准就是看是否有连续多个 ACK 索要同一个数据
如果传输的数据比较少，并且传输速度比较慢，那就不按滑动窗口传输，按照超时重传保证可靠性，判定丢包的标准就是 ACK 过了超时时间还没到达

---

🍌流量控制

滑动窗口越大，就会有更多的数据共用同一块等待时间，效率也就更高
不过窗口的大小不能无限扩大，因为要考虑到接收方的处理速度，如果发得太快了，对端处理不过来，接收缓冲区如果满了，就会出现丢包
（接收方处理数据，指的是是在应用程序的代码中调用 read 从缓冲区读数据）
所以需要让发送方的发送速度和接收方的处理速度保持一致，其实就是通过接收方的反馈来影响发送方的速度（类似生物学里面的负反馈调节），这就称为流量控制

---

🍌拥塞控制

流量控制是站在接收方的角度来控制发送方的速率。拥塞控制则是从中间路径来控制的，见下图：

针对这个问题，拥塞控制控制的核心思路就是把中间经过的所有设备视为一个整体，通过实验的方式找到一个比较合适的传输速率
如果按照某个窗口大小发送数据之后出现丢包，就视为中间路径存在堵塞，减小窗口大小；若没出现丢包，就视为不存在拥堵，增大窗口大小
按照上面的策略就可以让发送速率动态变化

接下来我们来了解一下具体是如何把窗口大小试出来

1. 慢启动：因为一开始不知道网络拥堵情况，所以采用比较小的窗口试探一下，此时传输数据的速率比较小
2. 如果上面传输的数据没出现丢包，那说明网络还是畅通的，于是按照指数增长来扩大窗口大小，指数级别的增长可以使窗口快速扩大，保证传输效率。不过为了防止增长过快导致网络拥堵，引入了一个阈值，当拥塞窗口达到阈值之后就会变成线性增长
3. 在线性增长阶段下积累一段时间后，也可能传输速度太快导致丢包，一旦丢包，就会把拥塞窗口重置为较小的值，这个值在不同的 TCP 版本中是不一样的

流量控制和拥塞控制会分别产生一个窗口大小，此时实际窗口大小是取二者中的较小值

---

🍌延时应答

这个机制也是基于滑动窗口，旨在进一步提高效率
结合滑动窗口及流量控制机制，再通过延时应答 ACK 的方式，就可以在允许的范围内，让反馈的窗口尽可能大一点
具体就是：接收方收到数据之后不会立即返回 ACK，而是等一下再返回，在等待的时间里，接收方就可以消费收到的数据，这样就可以让缓冲区的可用空间大一点，相应地，告诉发送方接下来要设置的窗口大小，就会比没有延时应答的时候大
延时应答的策略，就是每收到几个数据再返回 ACK，而不是收一个就立即返回一个 ACK（这样可以减少 ACK 传输的数量，可以节省开销）。当然也不是只看收到的数据包的个数，还和时间有关，如果达到了延时时间收到的数据包个数还没够的话，也会返回 ACK

---

🍌捎带应答

基于延时应答，引入捎带应答，可以再提升传输效率
捎带应答就是尽可能把可以合并的数据包合并在一起

---

🍉粘包问题

面向字节流在使 TCP 实现灵活的读取时，也带来了粘包问题
TCP 传输的数据到达接收方后，接收方要使用 socket api 读取出来，读取的结果就是应用层数据包，因为 read 的基本单位是字节，所以可能会导致无法区分出当前数据从哪到哪是一个完整的应用数据包
举个例子：

解决问题的关键在于明确包与包之间的边界

1. 使用特殊符号作为分隔符，这样，见到分隔符就知道一个包结束了，注意要确保这个分隔符不会出现在正式的数据中
2. 指定包的长度。比如在包开始的位置加上一个特殊的空间表示整个数据包的长度

粘包问题不是 TCP 特有的，只要是面向字节流的协议，都有这种问题。与之对应的 UDP 就不会有这种问题，因为 UDP 传输的基本单位是 UDP 数据报，在 UDP 这一层就已经分开了，只要约定好每个 UDP 数据报只承载一个应用层数据包，就无需额外的方法来区分了

---

🍉异常情况

🍌一方进程崩溃

进程无论是正常结束，还是出异常崩溃，因为 TCP 连接的生命周期是可以比进程更长一些的，因此即使进程正常结束或者寄了，只要 TCP 连接还在，就仍然可以进行四次挥手
其实这样看来，进程异常崩溃和正常结束时的四次挥手没啥区别，不过进程如果不在了，那就是通过系统中持有的连接信息完成后续的挥手过程

🍌一方按照正常流程关机

一个主机进行关机操作时会先强制终止所有进程，终止进程自然就会触发四次挥手
不过由于系统快关闭了，所以四次挥手不一定可以挥完，这里要分情况讨论

1. 挥手进行得够快，那就可以顺利挥完，此时本端和对端都能正确删掉保存的连接信息
2. 挥得不快，虽然来不及挥完，但还是能够把第一个 FIN 发给对端，这样就已经告诉对端，这边要结束了。对端收到 FIN 后会进入释放连接的流程，返回 ACK 和 FIN。当然这里发 FIN 后就收不到 ACK 了，按照规则，收不到 ACK 就会重传，在重传几次之后还没收到 ACK 就会单方面释放连接信息

🍌一方突然断电（突然关机）

一般情况下主机断电就是直接关机了，在这种情况下肯定是来不及发 FIN，此时双方可能正在传输数据
如果是接收方断电，那就不会有 ACK 报文了（都断电了，肯定不可能发给发送方），当发送方发现没 ACK，就会重传，重传几次之后发现还是没有，那此时 TCP 就会尝试复位连接，复位相当于清除原来 TCP 中各种临时数据，重新开始
如果发送方断电了，接收方本来在阻塞等待发送方的消息，不过一直等不到，此时接收方就会去区分到底是发送方挂了还是说只是暂时不发而已，于是它会触发心跳包来确认对方的存活状态，若对端没心跳，此时本端就会尝试复位并单方面释放连接

心跳包也是不携带应用层数据的特殊数据包，在接收方一直未收到消息时，会由接收方周期性发给对端，如果没有心跳，那就视为对端挂了