ARQ--自动重传请求与UDP提供可靠交付

自动重传请求(Automatic Repeat-reQuest)是OSI模型中数据链路层的错误纠正方式之一。它通过超时和确认机制在不可靠的服务基础上提供可靠的信息传输。如果发送方在发送数据后一段时间后没接收到确认帧，它通常会进行重发。ARQ可能包括停止等待ARQ协议和连续ARQ协议，错误检测(Error Detection)、正面确认(Positive Acknowledgment)、超时重传(Rechansmission after timeout)、和负面确认及重传(Negative Acknowledgment and Retransimission)。

停等ARQ协议(stop-and-wait ARQ)

停止等待ARQ协议工作原理如下：

     1、发送点对接收点发送数据，等待接收点回复ACK并且开始计时

     2、在等待过程中，发送点停止发送新的数据包

     3、发送方在timeout时间内没接收到接收方的ACK确认帧，重新发送数据

     4、反复以上步骤直到收到接收方的ACK

发送方的timeout时间应该大于传输点数据包发送时间（数据包容量/发送点传输速度）、接收方ACK接收时间（数据量容量/接收方接收速率）、数据在连接上的传输时间、接收点验证数据是否正确的时间之和。实际应用中是这个时间的倍数。

很明显这个协议对通道的利用率很低，因为花费较长的等待时间。

连续ARQ协议(Continuous ARQ)

针对停等的缺点，连续ARQ连续发送一组数据包，然后等待这些数据的ACK。

选择重发（selective Repeat）

    1、发送方连续发送一组数据包，但对每个数据包都设一个计时器

    2、一定时间内(timeout)没收到某个数据包的ACK时，发送方只重发没ACK的数据包，发送方对每个数据包都要进行顺序编号

    3、接收方丢弃从第一个没有收到的数据包开始的所有数据包

    4、发送方收到NACK后，从NACK指定的数据包开始重新发送，假设有10个分组，接收方第5个包没接收到，于是给发送方返回NACK表明第5个包没接收到，并丢弃排序在5后面但已经接收到的包，发送方重新发送从5编号开始的数据包。

纠错

     ARQ协议对错误纠正的方法是：

     1、丢弃已经接收的含有错误的数据包(一般检测CRC校验码)

     2、向发送方要求重新发送数据

优缺点：

ARQ的有点是非常简单。因而被广泛应用与网络分组中。缺点是需要接收方回复ACK确认帧，加重网络负担。

我们知道UDP是不可靠的网络协议，在传输过程中不保存应用程序的副本（应用进程的数据沿协议栈向下传递时通常被复制到某种形式的内核缓冲区中，然而当数据被发送之后，这个副本就被数据链路层丢弃）。那么就引出一个问题，如何保证UDP交付？答：应用程序自己实现网络重发。借助ARQ自动重发协议可以实现UDP的可靠交付。了解TCP的不禁要问，这不过是实现一个自己的TCP，那为什么不直接使用TCP而要使用UDP？这也困扰过我，还好育人帮忙解答，TCP是面向连接的，它发送数据必须connect，TCP需要花一段时间才能知道是否连接成功。此外在局域网还好，在广域网由于不确定的原因随时可能造成已经建立的连接断开，假设在TCP写或者读数据时，网络断开，等你知道断开的时候说不定人家又连接上了，然后又连上，又断开。。。。。。这时候UDP的优越性就体现了，因为UDP不需要建立连接，所以它可以利用网络的间隙将数据发送出去。

只是有一点疑惑，一开始我想的是连续发送一系列编号序号的数据包给接收方，接收方对接收到的数据包回复一个确认帧ACK，在timeout后发送方只发送接收方没接收到的数据包。还是上面的例子，序号为5的数据包没接收到，发送方只重发序号为5的数据包，而不是重新发送自5开始的所有数据包。至于ARQ为什么这么要求暂时不得而知。