TCP连续ARQ协议和滑动窗口协议

90 阅读 0 评论 60 点赞

我是靠谱客的博主娇气水蜜桃，最近开发中收集的这篇文章主要介绍TCP连续ARQ协议和滑动窗口协议，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

博客转载自：http://blog.csdn.net/guoweimelon/article/details/50879588

TCP协议通过使用连续ARQ协议和滑动窗口协议，来保证数据传输的正确性，从而提供可靠的传输。

一、ARQ协议

ARQ协议，即自动重传请求（Automatic Repeat-reQuest），是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议，拥有错误检测（Error Detection）、正面确认（Positive Acknowledgment）、超时重传（Retransmission after Timeout）和负面确认及重传（Negative Acknowledgment and Retransmission）等机制。

（1）停止等待ARQ协议

要想弄明白为什么TCP要使用连续ARQ协议，首先需要弄清楚停止等待ARQ协议的原理。

TCP 连接是全双工的连接，也就是说在通信的时候，双方既是发送方，也是接收方。下面为了简化问题，只考虑一方发送，一方接受的情况。其中，A作为发送方，B作为接收方。

1.无差错情况

A发送分组M1，发送完就暂停发送，等待B的确认。B收到M1就向A发送确认。A在收到了对M1的确认后，就再发送下一个分组M2。依次下去发送剩余的数据...如下图所示：

2.出现差错

如果A发送的过程中出现差错，B在接收M1时检测出了差错，就丢弃M1，其他什么都不做（也不会通知A收到有差错的分组）。又或者A传送的过程中分组丢失了，以上这两种情况下，B不会发送任何信息。

既然说它是可靠传输协议，那自然有它可靠的方法：如果发生以上的情况，A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，所以它会重传刚刚的发送过的分组，也就是所谓的超时重传。

超时重传的原理也很简单：发送方发送完一个分组后，就会设置一个超时计时器，如果超时计时器到期之前没有收到接收方发来的确认信息，则会重发刚发送过的分组；如果收到确认信息，则撤销该超时计时器。如下图所示：

这里应该注意的是：

①既然发送方发送的分组可能丢失或者有差错，可能需要重传，那么它必须暂时保留已发送的分组副本，只有收到确认后，才清除这个副本。

②分组和确认分组信息都应该有各自的编号，用来标示每一个分组和确认信息。（这样才知道需要发送哪个分组，收到了哪个分组的确认信息）

③超时计时器设置的时间应该略长于分组传送往返时间。

3.确认丢失和确认延迟

没有正常进行通信，除了发送方出现问题外，接收方同时也可能存在问题。

例如，如果A发送了M1分组，到达B，B发送了M1确认信息，但由于网络原因，该确认信息丢失。那么这个时候，A在超时重传时间内，没有收到B的确认信息，而且它并不知道是自己的分组有差错、丢失，还是B发生的确认丢失了。因此，A会在超时重传过后，重传M1分组。

接收方B会采取这两个行动：

①B会丢弃M1分组，不向上层交付。（B之前已经收到过M1分组了）

②向A发送确认（因为A重发了，肯定重传时间内没有收到确认信息）

还有可能是另一种情况，就是B发送了确认，没有丢失，但是延迟了。也就是说，B发送的确认在A超时计时器过期后才到达。这种情况下，A收到确认信息后会丢弃，然后重传刚才的分组，B收到后，丢弃重复的分组，并重传确认信息。

根据上述的确认和重传机制，我们就可以在不可靠的网络上实现可靠的传输。

4.信道利用率

停止等待ARQ协议的优点是简答，但也有很严重的确定，就是信道利用率太低。如下图所示：

信道利用率U = TD / (TD + RTT + TA)

（2）连续ARQ协议

由于停止等待ARQ协议信道利用率太低，所以需要使用连续ARQ协议来进行改善。这个协议会连续发送一组数据包，然后再等待这些数据包的ACK。

发送方采用流水线传输。流水线传输就是发送方可以连续发送多个分组，不必每发完一个分组就停下来等待对方确认。如下图所示：

连续ARQ协议通常是结合滑动窗口协议来使用的，发送方需要维持一个发送窗口，如下图所示：

图（a）是发送方维持的发送窗口，它的意义是：位于发送窗口内的5个分组都可以连续发送出去，而不需要等待对方的确认，这样就提高了信道利用率。

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。例如上面的图（b），当发送方收到第一个分组的确认，就把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，则现在可以发送窗口内的第6个分组。

接收方一般都是采用累积确认的方式。也就是说接收方不必对收到的分组逐个发送确认。而是在收到几个分组后，对按序到达的最后一个分组发送确认。如果收到了这个分组确认信息，则表示到这个分组为止的所有分组都已经正确接收到了。

累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是，不能正确的向发送方反映出接收方已经正确收到的所以分组的信息。比如发送方发送了前5个分组，而中间的第3个分组丢失了，这时候接收方只能对前2个发出确认。而不知道后面3个分组的下落，因此只能把后面的3个分组都重传一次，这种机制叫Go-back-N（回退N），表示需要再退回来重传已发送过的N个分组。

二、滑动窗口协议

滑动窗口协议在在发送方和接收方之间各自维持一个滑动窗口，发送发是发送窗口，接收方是接收窗口，而且这个窗口是随着时间变化可以向前滑动的。它允许发送方发送多个分组而不需等待确认。TCP的滑动窗口是以字节为单位的。

如下图所示，发送窗口中有四个概念：：已发送并收到确认的数据（不在发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之内）、允许发送但尚未发送的数据（位于发送窗口之内）、发送窗口之外的缓冲区内暂时不允许发送的数据。

接收窗口中也有四个概念：已发送确认并交付主机的数据（不在接收窗口和接收缓冲区之内）、未按序收到的数据（位于接收窗口之内）、允许的数据（位于接收窗口之内）、不允许接收的数据（位于发送窗口之内）。

规则：

（1）凡是已经发送过的数据，在未收到确认之前，都必须暂时保留，以便在超时重传时使用。

（2）只有当发送方A收到了接收方的确认报文段时，发送方窗口才可以向前滑动几个序号。

（3）当发送方A发送的数据经过一段时间没有收到确认（由超时计时器控制），就要使用回退N步协议，回到最后接收到确认号的地方，重新发送这部分数据。

此外，TCP利用滑动窗口协议来进行流量控制，如下图所示：