这里是Themberfue

上节我们讲完了TCP协议中保证其可靠性的最重要的三个机制，这节我们将深入更多保证TCP协议可靠性的机制。 

---

滑动窗口 

• 学过算法的小伙伴应该对滑动窗口这个不陌生，没错，滑动窗口这个算法就是出自TCP协议的机制的。没听过也没事，且听我一一道来。
• 通过前面的章节我们知道，TCP保证可靠性传输的一个是确认应答，也就是发送方发送一个报文，接收方收到后会发送给发送方一个确认报文ACK确认其收到了这个报文。但是，发送方发送报文后，不能立即发送下一段，还得先等待接收方对应的确认报文ACK，这样的传输效率是非常慢的，通常表现为包的往返时间越长通信性能就越低，为了解决这一问题，便引入了滑动窗口。

• ✨滑动窗口（Sliding Window）是TCP协议中的一种流量控制机制，用于高效管理数据的发送和接收，确保接收方不会因数据过多而被压垮，同时提升网络传输效率。

• ✨窗口：发送窗口：发送方维护的窗口，用于限制可以发送但未被确认的数据量。接收窗口：接收方维护的窗口，用于告诉发送方它当前可以接收的数据量大小。滑动：窗口的起始和结束位置随着数据的发送、接收和确认不断滑动，动态调整未确认数据和可以发送的数据范围。

• 我不再一个一个传输了，我直接批量传输，将多份数据包直接传输给接收方，等发送到一定量后我再等待一下接收ACK报文，相当于用一份数据包的等待时间换了多组ACK的接收时间。但这样做依然有问题，就是我发送了多份数据包后等待，依然需要等待全部ACK接收后才可继续发送下多份。
• 解决办法就是我收到一份ACK后就直接继续发送下多份数据包。假设我一次性发送4份数据包，也就是(1-4000)，我接受了1001ACK报文后就继续发送4001-8000的数据包就好，但实际并非这样，因为我可能我发送1-100后立刻就受到了1001ACK报文，还没发送1001-2000报文呢；这样没事，根据前面可知此时窗口的大小为4，我收到1001ACK报文后就让窗口向后移动一格就好了，此时窗口就变成了1001-5000。

• 通过图解我们可以清晰的看出来窗口大小的变化。此时你或许又会有疑问了：万一我1001的ACK报文还没收到，2001的ACK的报文就已经收到了，这种情况该怎么处理？很简单，前面我们提到每个数据包都有一个序号，这就体现到序号的好处了，既然你已经收到了2001ACK报文，那么你1001ACK报文就肯定已经收到了，不然你怎么可能给我2001的ACK报文。若先收到2001ACK报文，直接让窗口向后移动两格即可。
• 理论上，窗口越大，批量发的数据就越多，那么我效率就越高，