可靠传输的工作原理
我们知道，TCP发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠的传输。因此，TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。理想的传输条件有以下两个特点：
（1）传输信道不产生差错。
（2）不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。
在这样的理想传输条件下，不需要釆取任何措施就能够实现可靠传输。
然而实际的网络都不具备以上两个理想条件。但我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。
下面从最简单的停止等待协议讲起。
停止等待协议
全双工通信的双方既是发送方也是接收方。下面为了讨论问题的方便，我们仅考虑A发送数据而B接收数据并发送确认。因此A叫做发送方，而B叫做接收方。因为这里是讨论可靠传输的原理，因此把传送的数据单元都称为分组，而并不考虑数据是在哪一个层次上传送的。“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
1.无差错情况
停止等待协议可用下图来说明。下图是最简单的无差错情况。A发送分组M1，发完就暂停发送，等待B的确认。B收到了M1就向A发送确认。A在收到了对M1的确认后，就再发送下一个分组M2。同样，在收到B对M2的确认后，再发送M3。
无差错情况
在计算机网络发展初期，通信链路不太可靠，因此在链路层传送数据时都要采用可靠的通信协议。其中最简单的协议就是这种“停止等待协议”。在运输层并不使用这种协议，这里只是为了引出可靠传输的问题才从最简单的概念讲起。在运输层使用的可靠传输协议要复杂得多。
2.出现差错
下图是分组在传输过程中出现差错的情况。B接收M1时检测出了差错，就丢弃M1，其他什么也不做（不通知A收到有差错的分组）。也可能是M1在传输过程中丢失了，这时B当然什么都不知道。在这两种情况下，B都不会发送任何信息。可靠传输协议是这样设计的：A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。要实现超时重传，就要在每发送完一个分组设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。其实在上一个图中，A为每一个已发送的分组都设置了一个超时计时器。但A只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器。为简单起见，这些细节在图中都省略了。
超时重传
这里应注意以下三点。
第一，A在发送完一个分组后，必须暂时保留已发送的分组的副本（为发生超时重传时使用）。只有在收到相应的确认后才能清除暂时保留的分组副本。
第二，分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认第三。超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。
上图中的一段虚线表示如果M1正确到达B同时A也正确收到确认的过程。可见重传时间应设定为比平均往返时间更长一些。显然，如果重传时间设定得很长，那么通信的效率就会很低。但如果重传时间设定得太短，以致产生不必要的重传，浪费了网络资源。然而在运输层重传时间的准确设定是非常复杂的，这是因为已发送出的分组到底会经过哪些网络，以及这些网络将会产生多大的时延（这取决于这些网络当时的拥塞情况），这些都是不确定因素。
3.确认丢失和确认迟到
下图说明的是另一种情况。B所发送的对M1的确认丢失了。A在设定的超时重传时间内没有收到确认，但并无法知道是自己发送的分组出错、丢失，或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M1。现在应注意B的动作。假定B又收到了重传的分组M1。这时应采取两个行动。
第一，丢弃这个重复的分组M1，不向上层交付。
第二，向A发送确认。不能认为已经发送过确认就不再发送，因为A之所以重传M1就表示A没有收到对M1的确认。
确认丢失
下图也是一种可能出现的情况。传输过程中没有出现差错，但B对分组M1的确认迟到了。A会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。B仍然会收到重复的M1，并且同样要丢弃重复的M1，并重传确认分组。
通常A最终总是可以收到对所有发出的分组的确认。如果A不断重传分组但总是收不到确认，就说明通信线路太差，不能进行通信。
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
像上述的这种可靠传输协议常称为自动重传请求ARQ（ Automatic Repeat reQuest。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。
确认迟到
4.信道利用率
停止等待协议的优点是简单，但缺点是信道利用率太低。因为每次只能发送一个分组，等到接收方确认收到之后，才会发送下一个。
停止等待协议的信道利用率太低
为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是釆用流水线传输
。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然，这种传输方式可以获得很高的信道利用率。
流水线传输可提高信道利用率
当使用流水线传输时，就要使用下面的连续ARQ协议和滑动窗口协议。
连续ARQ协议
滑动窗口协议比较复杂，是TCP协议的精髓所在。这里先给出连续ARQ协议最基本的概念，但不涉及到许多细节问题。下图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。
连续ARQ协议的工作原理
连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。图（b）表示发送方收到了对第1个分组的确认，于是把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，那么现在就可以发送窗口内的第6个分组了。
接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。
累积确认有优点也有缺点。
优点是：容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。
例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go- back-N（回退N），表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面的影响。
TCP可靠传输的实现
以字节为单位的滑动窗口
为了讲述可靠传输原理的方便，我们假定数据传输只在一个方向进行。
TCP的滑动窗口是以字节为单位的。
现假定A收到了B发来的确认报文段，其中窗口是20（字节），而确认号是31（这表明B期望收到的下一个序号是31，而序号30为止的数据已经收到了）。根据这两个数据，A就构造出自己的发送窗口，其位置如图所示。
根据B给出的窗口值，A构造出自己的发送窗口
我们先讨论发送方A的发送窗口。
发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时，使用发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。但接收方必须来得及处理这些收到的数据。
发送窗口后沿的后面部分表示已发送且已收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。
发送窗口的位置由窗口前沿和后沿的位置共同确定。发送窗口后沿的变化情况有两种可能，即不动（没有收到新的确认）和前移（收到了新的确认）。发送窗口后沿不可能向后移动，因为不能撤销掉已收到的确认。
发送窗口前沿通常是不断冋前移动，但也有可能不动。这对应于两种情况：一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。
发送窗口前沿也有可能向后收缩。这发生在对方通知的窗口缩小了。但TCP的标准强烈不赞成这样做。因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现在又要收缩窗口，不让发送这些数据，这样就会产生一些错误。
现在假定A发送了序号为3141的数据。这时，发送窗口位置并未改变（图5-16），但发送窗口内靠后面有11个字节（灰色小方框表示）表示已发送但未收到确认。而发送窗口内靠前面的9个字节（4250）是允许发送但尚未发送的。
网友评论