本文主要是介绍TCP可靠传输的工作原理-停止等待连续的ARQ（一），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在网络传输中，我们认为最理想的传输状态就是：
1、传输信道不产生差错。
2、不管发送方以多块的速度发送数据，接收方都能来得及接受以及处理这些数据。
当然，这种只是理想状态，在实际运用中，几乎是不可能的。因此，我们需要采取一些可靠的传输协议。
1、当出现差错时，让发送发重传该差错数据。
2、接受方来不及处理数据时，及时告知发送方适当的降低发送速度。
那么，要做到上述第一点，就需要采用：停止等待协议
一、停止等待协议。
所谓停止等待协议就是没发送完一组数据后，等待对方确认并且收到确认后，再发送下一组数据。
我将它简单的理解为以下过程：发送数据，收到数据，发送确认，收到确认。
那么这样，就分为了以下4种情况。（无差错、出现差错、确认丢失、确认迟到）
1、无差错
所谓无差错，就是数据能够正常发送，正常接收，正常确认，正常收到确认的一个过程。也是最理想，最好的一种状态。
2、出现差错
所谓出现差错，就是数据在发送的过程中部分或全部丢失（如上图左）。
A发送M1并出现差错，B在收到M1时（全部丢失，不会收到）检测出了差错，就丢弃M1，其他什么也不做（不会通知A数据出现了差错，因为有可能全部丢失，B并不知道）。在这两种情况下，B都不会发送任何的信息。那么，怎么办？
A只要超过一段时间仍然没有收到确认，就认为刚才所发送的数据丢失，然后重传前面发送的数据。这就叫做超时重传。当前需要一个计时器来完成。
因此，有如下三点要求：
1>、A在发送完一组数据后，必须暂时保留自己已发送的数据的副本（供超时重传使用）。只有收到确认后，才会删除该副本。
2>、每一组数据和确认数据都必须编号（TCP头部有该字段）。这样才能明确是哪一个发送出去的数据收到了确认，哪一个没有收到。
3>、超时计时器设定的时间应该要长于数据平均往返时间。
3、确认丢失
所谓确认丢失，其实就是确认消息在传输过程丢失。那么，该如何处理？
当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：
1>、丢弃这个重复的M1消息，不向上层交付。
2>、向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。
4、确认迟到
所谓确认迟到，就是B发送的确认消息没有丢失，但是却迟到（过了很长一段时间才到）。那么该如何处理？
A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：
1>、A收到重复的确认后，直接丢弃。
2>、B收到重复的M1后，也直接丢弃重复的M1。
至此，就是停止等待协议中所出现的所有的可能情况。也一一解决。像这种可靠的传输协议通常称为自动重传请求ARQ（Automatic Repeat reQuest）。意思就是，重传的请求是自动进行的，不需要接受方请求发送某一个丢失或出错的消息。
但是，很显然。我们发现，其信道的利用率很低。
那该怎么办？
那就是利用连续ARQ请求协议。
二、连续的ARQ协议
先看一张信道利用率图：
这两张图的差异很明显。使用连续的ARQ协议可以大大的提高信道利用率。
吧后者这张图的工作模式又叫做流水线传输。
其原理如下：
其实现的基础是建立在滑动窗口之上。而滑动窗口乃是TCP的精髓所在（下一篇详解）。
连续ARQ规定，发送方每收到一个确认就将滑动窗口向前（时间增大方向）滑动一格。如上图表示收到一个确认。
接受方采用累积确认的方式：接收方不必每收到一个消息，就发送一个确认。而是在收到几条消息后，对按序到达的最后一条消息发送确认。表示，这个消息之前的所有消息全部收到。
当然，这两个方式都有自己的优缺点：
1、自动重传请求ARQ协议
优点：简单
缺点：信道利用率低
2、连续的ARQ协议
优点：信道利用率高，容易实现，即使确认丢失，也不必重传。
缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。
比如：发送方发送了5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫
Go-Back-N（回退N），表示需要退回来重传已经发送过的N个消息。
这篇关于TCP可靠传输的工作原理-停止等待连续的ARQ（一）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
