rdt滑动窗口协议Java实现_可靠传输数据概述之RDT到滑动窗口协议的发展

主要思想是有限状态机。

RDT1.0

RDT1.0是模拟信道可靠的情况下。

RDT1.0存在的问题：

信道完全可靠是理论的模型

RDT2.0

RDT2.0是模拟信道不可靠的情况下(数据位翻转，但不丢失分组)，解决信息发送接收的问题，加入checksum校验位。

发送方在发送完成后会进入一个等待确认的状态，当收到接收方返回的消息为ACK时才会让上层进入下一次调用，否则会重新发送消息。

接收方在接收到信息后会对消息进行校验，当信息校验成功后，会发送ACK，否则发送NAK。

RDT2.0存在的问题：

RDT2.0存在的问题是，ACK和NAK也会出现因为信道不可靠而出现数据丢失的问题，那么接受方就无法正确识别ACK和NAK。当发送方第一次发送的数据就已经被接收方接收，而接受方发送的ACK由于信道丢失了数据，发送方会重新发送一份数据，导致数据重叠。

RDT2.1

RDT2.1是对RDT2.0的改进，目的是为了解决RDT2.0存在的问题。

2.1加入的措施：

对发送者和接收者都加入一个序列号(0,1)。由于采用的是“停-等”协议，这个序列号只需要2个。

当发送者发送数据时会携带上当前的序列号，如0。那么在发送者发送后和2.0一样会进入确认状态。

发送者在接收到数据后，会对数据的序列号进行检查，是否与当前自己所期望的序列号一致。

RDT2.1的问题：

如果我们仔细看，NAK是多余的。可以由ACK+序列号来替代NAK。

RDT2.2

RDT2.2是对RDT2.1的简单改进，NAK被去除，而是接受者在发送ACK时携带上序列号，如果是正确接收则添加当前序列号，否则添加另一个序列号。

RDT2.2中存在的问题：

RDT2.0,2.1以及2.2都是建立在信道不可靠但不丢失分组的模拟环境下，但实际上在数据传输的过程中，有可能出现分组丢失的情况，这样，无论是发送方还是接收方都将永远处于等待的状态，这是RDT2.2所不能解决的情况。

RDT3.0

RDT3.0为了解决RDT2.2中存在的问题，引入了定时器。

定时器会在发送分组时启动，当在设定的时间内仍然没有接收到ACK信息，则会认为该分组在传输的过程中丢失了，(有可能是因为网络延迟，但不影响RDT3.0的正常工作)。

RDT3.0存在的问题：

RDT3.0确保了信道交互的可靠性，也就是说，如果不考虑性能的话，RDT3.0满足了不可靠信道下进行可靠传输数据的需求。

但我们来考虑RDT3.0的性能。假设数据链路传输的速率为1Gbps，分组大小为1KB，15ms端到端的传播延迟。数据实际传输的时间：

\[

T_(ransimit) = \frac LR

\]

t=0.008us，RRT=15ms

发送方发送时间百分比

\[

U_(sender)= \frac {L/R}{RTT+L/R}

\]

U = 0.00027。在1Gbps链路上每30ms才发送一个分组---> 33KB/s。

我们可以看出：网络协议限制了物理资源的利用。

流水线和滑动窗口协议

经过分析我们可以看出，RDT3.0中导致性能低下的主要原因是停等协议，一次发送必须等待一次返回。那能不能先发个10次然后再等10次返回呢？100次？1000次呢？

答案是肯定的，我们允许发送方在收到ACK之前连续发送多个分组。但实现这个需要更大的序列号范围，发送方和/或接收方需要更大的存储空间以缓存分组，这就是流水线的主要思想。

滑动窗口协议是基于流水线思想的实现方法，具体协议实现有两种。

GBN---Global Back N

SR ---- Selective Repeat

GBN的实现，发送方有一个滑动窗口，而接收方只有当前预期收到序列号的一个缓存空间。

接收方只接收当前预期收到的序列号分组，才会返回ACK，其余的都将被丢弃。

所以发送方收到的ACK都是接收方所收到的最大序列号，发送方不得不重发大于该序列号的所有分组。这无疑造成的资源的浪费。

SR的实现，不仅发送方有一个滑动窗口，接收方也有一个滑动窗口，但两个窗口是不同步的，不能知道彼此窗口现在的状态。在接收方增加滑动窗口后就可以接收一定范围内的序列号分组，(虽然需要增加缓存空间，以空间换时间的做法)。发送方只需要重新发送那些超时或者是ACK状态有误的数据分组即可，SR相对于GBN有了极大的优化。

但SR实际上还存在一个问题，但只需在设计时需要满足一个条件:

\[

N_s + N_R <=2^k

\]

Ns和NR分别是发送方和接收方滑动窗口的大小，k是定义的可用序列号数。

原文：https://www.cnblogs.com/Ghostant/p/12248299.html