共计 1798 个字符，预计需要花费 5 分钟才能阅读完成。
文章内容概览
进行期待协定
假如当初将计算机分为发送方和接管方，之前的文章中有说到 TCP 是 全双工通道 的协定，也就是同一时刻计算机能够当做发送方，也能够当做接管方。下边是发送方计算机和接管方计算机的时间轴，进行期待协定的工作原理如下：
- 发送方生成 TCP 数据（音讯 1），而后将其发送进来，通过一段时间之后，达到接管方
- 接管方在接管到之后，再发送一个确认的音讯，示意发送方发送的音讯，它收到了
- 接管方将确认音讯发送给发送方，一段时间后，发送方接管到确认音讯。这样发送方就晓得接管方接管到了它的音讯
- 发送方生成音讯 2，而后将其发送给接管方，发送之后，发送方就会期待接管方的确认音讯，当收到接管方的确认音讯之后，它才会生成下一条要发送的音讯
这个过程就是进行期待协定的过程，首先会发现，当发送方发送一个音讯之后，它会进行生成新的音讯，它会期待接管方发送确认音讯，发送方接管到确认音讯之后，才会生成新的音讯。这整个过程就是 进行 — 期待 — 进行 — 期待 …（接管方也是一样，当没有音讯进来的时候，它也会处于期待）
当然，上边其实探讨的是很现实的状况，因为网络环境是十分复杂的，数据在传输的过程中，可能会呈现失落，上边都没有思考，所以上边探讨的就是 无差错的状况
如果音讯传输过程中有过错，进行期待协定是如何解决的？
情景 1：发送方将数据发送进来之后，产生了失落
假如发送方将数据发送进来之后，产生了失落。也就是接管方并没有接管到音讯。咱们晓得，当发送方将音讯发送进来之后，就会期待接管方发送确认音讯，发送方期待一段时间之后发现接管方并没有发送确认音讯。对方是不是没有接管到音讯？因而，发送方在期待一段时间之后，发现并没有接管到确认音讯，就会从新发送音讯，这个就属于 超时重传
超时重传是保障进行期待协定能够进行牢靠传输的一个办法
情景 2：确认音讯在传输过程中产生失落
假如接管方在接管到音讯之后，发送的确认音讯在传输过程中失落了。此时，发送方在期待一段时间之后还是没有收到确认音讯，因而，发送方会进行超时重传，以保障发送的音讯肯定被接管方接管到
情景 3：确认音讯很久才达到发送方
假如接管方发送的确认音讯经验了很久才达到发送方，此时也会产生超时重传，因为确认音讯到的太晚，发送方会认为接管方没有收到音讯
要实现超时重传，必定是须要一个定时器，这个定时器被称为：超时定时器
每发送一个音讯，都须要设置一个定时器（用来计算一个音讯什么时候过期了）。TCP 中有四个定时器，超时定时器是其中一个，后边的文章会提到其它的三个定时器
总结
- 进行期待协定是最简略的牢靠传输协定（只有音讯没正确达到，就会进行超时重传）
- 进行期待协定对 信道的利用效率 不高（从上边的图中也能够看进去，发送每发送一个音讯，都须要期待确认音讯回来，只有确认音讯没有正确的达到，发送方就会始终期待，这对这个连贯来说是十分低效的）
间断 ARQ 协定
间断 ARQ 协定是在进行期待协定的根底上进行革新的
ARQ（Automatic Repeat reQuest：主动重传申请）
既然单个发送和确认效率低，可不可以批量发送和确认？
正是因为这个思考，就产生了 ARQ 协定。例如：假如有编号为 1~12 的报文须要发送，这里可能就不是发送一个报文就期待一个确认音讯了，而可能是间断的发送六个报文。假如发送了前六个报文之后，收到了编号为 1 和 2 的确认音讯，此时会将窗口向前挪动两个地位。接着就会发送编号为 7 和 8 的报文，等接管到其它报文的确认音讯之后，再将窗口持续向后挪动。这里的批量发送的报文大小，就被称为 窗口 ，能够向前滑动的窗口，就被称为 滑动窗口
意思就是，只有是滑动窗口中的数据，都能够进行发送，只有发送进来的数据确认号达到了，就能够将窗口往前推动。其实，如果每一个报文都须要确认的话，确认音讯的开销也是挺大的，因而，对滑动窗口来说，它并不需要对每一个报文都进行确认，而是采纳 累计确认 的办法
假如同时发送了编号为 1~6 的这六个报文，在某一个时刻，发送方接管到了编号为 5 的这个报文的确认音讯。如果是采纳累计确认的办法，5 的这个确认音讯就示意说，1~5 的确认音讯，发送方都曾经收到了，因而就会将窗口向后挪动 5 个地位，此时就能够发送 7~11 这五个报文了，这就属于累计确认。意思就是说，只有收到了某一个报文的确认音讯，就示意说这个音讯之前的所有音讯都曾经收到了确认音讯。通过累计确认，就能够大大减少确认报文的数量，以此来晋升网络的效率
