引言
上一篇讲述了停止等待协议的工作流程,在最后提到了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处理了错误数据和未接受到数据的发送问题。如今还有一个问题摆在面前——如何保证数据流量大小的控制呢?