昨天我们简单说了这个 HTTP 和 HTTPS 为什么说简单呢？因为就是基础的 HTTP 的协议的讲解以及 HTTPS 的安全性等，这就有读者说，为什么不说点进阶的内容呢。
停止等待协议
我们在了解滑动窗口协议之前，我们要先来了解一下什么是停止等待协议，停止等待协议又是怎么工作的呢？
停止等待协议（stop-and-wait）是最简单但也是最基础的数据链路层协议。很多有关协议的基本概念都可以从这个协议中学习到。
停止等待就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
简而言之就是，发送方发送数据包后，如果没有对方确认，那就一直等待，不再发送下一个数据包，而接受到确认之后，再继续发送数据包。
图片
这也就导致了停止等待协议的缺点尤为的明显，
- 一次只能发送一个数据包效率低下。
这效率的低下都难以想象了，比如如果我们的带宽是100M 而这个停止等待协议每次都只发送一个数据包，这平白的浪费了带宽，别说现在有很多都是千兆以上的带宽了。
因为这个效率问题，导致了停止等待协议并不是很适用，所以就有了其他的协议出现，也就是我们接下来所要说的滑动窗口协议。
滑动窗口协议
那么什么是滑动窗口协议呢？
滑动窗口协议（Sliding Window Protocol），属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认。因此该协议可以加速数据的传输，提高网络吞吐量。
在滑动协议中，发送方要维持一个发送窗口，随着数据的传输，这个窗口就需要不断的向前滑动，这也就与停止等待协议出现了不同，不同在那里呢？
区别就是他允许发送方在停止并且等待确认前，可以发送多个数据包，而不再像停止等待协议一样，每次发送就只是发送一个数据包了。这样的话，发送方也就不需要每发一个数据包就需要停下等待了。这就是他们之间最本质的却区别了。
这个时候就有读者疑问了，这时候到底会发送多少数据包呢？
这个数据包的多少，那就得取决一个参数了，而这个参数则被我们称之为窗口大小。
我们简单模拟一下这个滑动窗口协议下，数据不丢包的情况。
图片
上图中，窗口大小为4，我们的发送方有10个数据包要发送，也就是意味着，我们一次可以发送四个数据包，
图片
当发送发在发送第一个数据包的时候，这和个时候滑动窗口就已经开始运行了吗？确实是的，在我们发送第一个数据包的时候，滑动窗口就开始运行了，也就是说我们在接受到确认之前，可以发送窗口大小为4的量的数据包。
在3号数据包发送完成之后，0-3号的对应的确认消息也反馈给了发送方。
同时窗口开始陆续的向左边滑动，
图片
我们也可以从图中看出，区分了已发送，正在发送和等待发送的部分。
而滑动窗口协议的原理则可以看如下：
滑动窗口协议的主要原理是通过使用序列号来标识每个数据包，并使用确认号来确认接收到的数据包。发送方维护一个发送窗口，其中包含已发送但未收到确认的数据包。接收方维护一个接收窗口，其中包含已接收但未按顺序交付的数据包。
发送方在发送数据包时，将数据包的序列号添加到数据包中，并将其发送给接收方。接收方在接收到数据包后，将确认号添加到确认包中，并将其发送给发送方。发送方在收到确认包后，将发送窗口向前滑动，将已确认的数据包从发送窗口中移除，并继续发送下一个数据包。
如果发送方在一定时间内没有收到确认包，或者接收方在一定时间内没有收到正确的数据包，滑动窗口协议会触发超时重传机制，重新发送未确认或未正确接收的数据包。
滑动窗口协议可以提高数据传输的效率和可靠性，同时充分利用网络带宽。它被广泛应用于各种网络通信中，如TCP协议就是基于滑动窗口协议实现的。
滑动窗口协议需要注意的点
（1）发送方不必发送一个全窗口大小的数据。（2）来自接收方的一个报文段确认数据并把窗口向左边滑动，这是因为窗口的大小是相对于确认序号的。（3）窗口的大小可以减小，但是窗口的左边沿却不能够向右移动。（4）接收方在发送一个ACK前不必等待窗口被填满。
这个向右和向左，取决你理解图时的窗口移动方向，我习惯了从从右往左，你也可以理解为从左往右，理解都是一样的。
所以，你了解滑动窗口协议了么？
