在网络传输中,我们认为最理想的传输状态就是:
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个消息。