引言

上一篇讲述了停止等待协议的工作流程，在最后提到了ARQ自动请求重传机制。接下来，我们就接着上一篇的篇幅，讲一下ARQ这个机制

还是这个图来镇楼 

ARQ是什么？ 

发送端对出错的数据帧进行重传是自动进行的，因而这种差错控制体制常简称为ARQ(Automatic Repeat reQuest)，直译是自动重传请求，但意思是自动请求重传。 

自动请求重传自然是发生在接收端，如果N（S）或者data数据不正确，就会请求重传数据。这个ARQ包含很多类型。

为什么要用ARQ？

    传统的TCP传输，我们先是把一串串字节流分组后经过缓存转发，然后等待确认后在发送下一个分组。因此需要完成通信的时间是：一组数据发送完的时间（Td）+数据传输的时间（RTT）+等待ACK返回的时间（Ta）,每一次这么传输虽然简单又安全，但是效率真差啊！每次都还要确认后再发送数据，中途停留时间太长。

为此，我们改进了ARQ，通过连续ARQ解决这个问题！

连续ARQ

    它的特点是发送方可以连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。由于信道上一直有数据不间断的发送，因此他的利用率很高。

    发送方发送数据后，不必停下来等待接收端的应答，可以继续发送数据；如果发送过程中收到对方同意发送的应答，则可以继续发送；如果某一个数据的确认超时则该数据开始的后续数据全部重发。这种也叫go-back-to-on协议。

    也就是先发大量数据，不等待回复，这时压力给到了接收端，接收端疯狂的处理报文后返回ACKn，一旦接收端发现某一段数据有问题了，那么从这个数据之后发来的所有数据都会丢掉，并要求发送端重发这段数据。接收端得知后，停止后续发送，从副本中找到需要重新发送的数据再次发送。当然，每一次回复的ACKn都会让发送端删除该段和该段以前的数据缓存。

这个就是连续ARQ示意图，发送频率的效率明显更快。 

 

后续

了解了停止等待协议后，也通过连续ARQ处理了错误数据和未接受到数据的发送问题。如今还有一个问题摆在面前——如何保证数据流量大小的控制呢？