文章内容概览
停止等待协议
假设现在将计算机分为发送方和接收方,之前的文章中有说到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这五个报文了,这就属于累计确认。意思就是说,只要收到了某一个报文的确认消息,就表示说这个消息之前的所有消息都已经收到了确认消息。通过累计确认,就可以大大减少确认报文的数量,以此来提升网络的效率