文章内容概览
停止等待协议
假设现在将计算机分为发送方和接收方，之前的文章中有说到TCP是全双工通道的协议，也就是同一时刻计算机可以当做发送方，也可以当做接收方。下边是发送方计算机和接收方计算机的时间轴，停止等待协议的工作原理如下：
- 发送方生成TCP数据（消息1），然后将其发送出去，经过一段时间之后，到达接收方
- 接收方在接收到之后，再发送一个确认的消息，表示发送方发送的消息，它收到了
- 接收方将确认消息发送给发送方，一段时间后，发送方接收到确认消息。这样发送方就知道接收方接收到了它的消息
- 发送方生成消息2，然后将其发送给接收方，发送之后，发送方就会等待接收方的确认消息，当收到接收方的确认消息之后，它才会生成下一条要发送的消息
这个过程就是停止等待协议的过程，首先会发现，当发送方发送一个消息之后，它会停止生成新的消息，它会等待接收方发送确认消息，发送方接收到确认消息之后，才会生成新的消息。这整个过程就是停止—等待—停止—等待…（接收方也是一样，当没有消息进来的时候，它也会处于等待）
当然，上边其实讨论的是很理想的情况，因为网络环境是十分复杂的，数据在传输的过程中，可能会出现丢失，上边都没有考虑，所以上边讨论的就是无差错的情况
如果消息传输过程中有差错，停止等待协议是如何处理的？
情景1：发送方将数据发送出去之后，发生了丢失
假设发送方将数据发送出去之后，发生了丢失。也就是接收方并没有接收到消息。我们知道，当发送方将消息发送出去之后，就会等待接收方发送确认消息，发送方等待一段时间之后发现接收方并没有发送确认消息。对方是不是没有接收到消息？因此，发送方在等待一段时间之后，发现并没有接收到确认消息，就会重新发送消息，这个就属于超时重传
超时重传是保证停止等待协议可以进行可靠传输的一个方法
情景2：确认消息在传输过程中发生丢失
假设接收方在接收到消息之后，发送的确认消息在传输过程中丢失了。此时，发送方在等待一段时间之后还是没有收到确认消息，因此，发送方会进行超时重传，以保证发送的消息一定被接收方接收到
情景3：确认消息很久才到达发送方
假设接收方发送的确认消息经历了很久才到达发送方，此时也会发生超时重传，因为确认消息到的太晚，发送方会以为接收方没有收到消息
要实现超时重传，肯定是需要一个定时器，这个定时器被称为：超时定时器
每发送一个消息，都需要设置一个定时器（用来计算一个消息什么时候过期了）。TCP中有四个定时器，超时定时器是其中一个，后边的文章会提到其它的三个定时器
总结
- 停止等待协议是最简单的可靠传输协议（只要消息没正确到达，就会进行超时重传）
- 停止等待协议对信道的利用效率不高（从上边的图中也可以看出来，发送每发送一个消息，都需要等待确认消息回来，只要确认消息没有正确的到达，发送方就会一直等待，这对这个连接来说是非常低效的）
连续ARQ协议
连续ARQ协议是在停止等待协议的基础上进行改造的
ARQ（Automatic Repeat reQuest：自动重传请求）
既然单个发送和确认效率低，可不可以批量发送和确认？
正是因为这个思考，就产生了ARQ协议。例如：假设有编号为1~12的报文需要发送，这里可能就不是发送一个报文就等待一个确认消息了，而可能是连续的发送六个报文。假设发送了前六个报文之后，收到了编号为1和2的确认消息，此时会将窗口向前移动两个位置。接着就会发送编号为7和8的报文，等接收到其它报文的确认消息之后，再将窗口继续向后移动。这里的批量发送的报文大小，就被称为窗口，可以向前滑动的窗口，就被称为滑动窗口
意思就是，只要是滑动窗口中的数据，都可以进行发送，只要发送出去的数据确认号到达了，就可以将窗口往前推动。其实，如果每一个报文都需要确认的话，确认消息的开销也是挺大的，因此，对滑动窗口来说，它并不需要对每一个报文都进行确认，而是采用累计确认的方法
假设同时发送了编号为16的这六个报文，在某一个时刻，发送方接收到了编号为5的这个报文的确认消息。如果是采用累计确认的方法，5的这个确认消息就表示说，15的确认消息，发送方都已经收到了，因此就会将窗口向后移动5个位置，此时就可以发送7~11这五个报文了，这就属于累计确认。意思就是说，只要收到了某一个报文的确认消息，就表示说这个消息之前的所有消息都已经收到了确认消息。通过累计确认，就可以大大减少确认报文的数量，以此来提升网络的效率