可靠数据传输 (RDT) 2.0

可靠数据传输 (RDT) 2.0 协议适用于通过误码通道进行可靠数据传输。这是一个更现实的模型，用于在传输时检查通道中存在的位错误，可能是数据包中的位已损坏。当数据包被传输、传播或缓冲时，此类比特错误会发生在网络的物理组件中。在此，我们将假设所有传输的数据包都按照发送的顺序接收（无论它们是否已损坏）。在这种情况下，我们要求用户发送 ACK（确认，即接收到的数据包正确且未损坏）或 NAK（否定确认，即接收到的数据包已损坏）。

在这个协议中，我们使用Checksum Field来检测错误，校验和是一个值，表示传输消息中的位数。要检查最终用户计算的校验和值与原始校验和值甚至略有不同，这意味着数据包已损坏，允许接收方使用校验和检测数据包中的比特错误所需的机制称为错误检测.

该技术允许接收器检测并可能纠正数据包位错误。在此我们只需要知道这种技术需要额外的比特（除了要传输的原始数据的比特之外）从发送方发送到接收方；这些位将被收集到 RDT 2.0 数据包的数据包校验和字段中。

另一种技术是接收方反馈，因为发送方和接收方在不同的终端系统上执行，发送方了解接收方情况的唯一方法，即是否正确接收到数据包，接收方应提供明确的反馈给寄件人。消息听写场景中的肯定 (ACK) 和否定确认 (NAK) 回复就是这种反馈的示例。零值表示 NAK，值 1 表示 ACK。

发送方：
RDT 2.0 的发送端有两种状态。在一种状态下，发送方协议正在等待数据从上层向下传递到下层。在另一种状态下，发送方协议正在等待来自接收方的 ACK 或 NAK 数据包（反馈）。如果收到一个ACK包，即rdt_rcv(rcvpkt) &&是ACK(rcvpkt)，则发送方知道最近发送的包已经正确接收，因此协议返回等待上层数据的状态。

如果接收到 NAK，则协议重新传输最后一个数据包并等待接收器返回 ACK 或 NAK 以响应重新传输的数据包。需要注意的是，当接收方处于wait-for-ACK-or-NAK状态时，它无法从上层获得更多的数据，只有在发送方收到一个ACK并离开该状态后才会发生这种情况。因此，发送方在确定接收方正确接收到当前数据包之前不会发送新数据，由于协议的这种行为，该协议也称为停止和等待协议。

接收方：
接收者站点有一个单一的状态，一旦数据包到达，接收者回复一个 ACK 或一个 NAK，这取决于接收到的数据包是否被破坏，即使用 rdt_rcv(rcvpkt) &&rupt(rcvpkt) 其中接收到数据包并发现错误或 rdt_rcv(rcvpkt) && not corrupt(rcvpkt) 接收到的数据包是正确的。

RDT 2.0 看起来好像可以工作，但它有一些缺陷。很难理解 ACK/NAK 数据包的位是否实际损坏，如果数据包损坏，协议将如何从 ACK 或 NAK 数据包中的错误中恢复。这里的困难在于，如果 ACK 或 NAK 被破坏，发送方无法知道接收方是否正确接收到最后一条传输数据。