可靠指分组数据不错、分组到达顺序不乱、分组不丢失。由于物理信道是不可靠的，所以通过可靠数据传输协议（reliable data transfer protocol，简称RDTP）来构建可靠的逻辑信道。
其基本原理图如下：

接下来我们将渐进式的设计可靠传输协议的发送方和接收方，且仅考虑单向数据传输的情况，即数据传输是从发送端到接收端的，但控制信息是双向流动的。
特别注意：整个可靠信道传输协议是不规定如何建立连接，释放连接的，并且这些协议都是抽象协议，不是具体代码实现。

rdt：为reliable data transfer缩写，即可靠数据传输。 udt：为unreliable data transfer缩写，即不可靠数据传输。

1.RDTP_1.0

首先考虑最简单的、最理想的情况：

• 下层信道完全可靠。
• 分组按顺序到达接收端。

发送端有限状态机：

接收端有限状态机：

在最理想的情况下，发送端只需要按顺序发送分组，接收端就一定会按顺序接收到完整的分组。

rcv：为receive简写，即接收。 snd：为send简写，即发送。 pkt：为packet简写，即分组或者数据包。

2.RDTP_2.0

实际情况中，下层信道不可能完全可靠。分组传输过程中，可能出现比特翻转、丢失的情况，导致分组数据损坏。为解决该问题，需要接收端收到分组后向发送端反馈收到的分组是否正确，再由发送端根据反馈决定是否重传分组。
现对RDTP_1.0协议基础做如下修改：

• 下层信道不完全可靠。
  • 数据分组传输过程中可能损坏。
  • 确认分组传输过程中保证完整。
  • 分组保证送达。
• 分组按顺序到达接收端。

RDTP_2.0协议类似通过无线电口述一段长消息，接收者在听到并理解每句话后都会说“确认收到”，没有听清楚则回复“请重复一遍”。这种方式被称为肯定确认和否请确认，可以让发送端知道哪些分组被正确接收，哪些分组出现损坏并需要重传。
基于这种重传机制的可靠传输协议称为自动重传请求（Automatic Repeat Request，缩写ARQ）协议，它需要三种协议功能来处理错误：

• 差错检查：通过校验和来检测位错误（不考虑极小概率的无法校验出错的情况，实际工程也不会考虑）。
• 接收方反馈：接收端通过ACK告知发送方分组已正确接收，通过NAK告诉发送端分组有错误。
• 重传：接收端收到有差错的分组时，发送端将重传该分组。

发送端有限状态机：

当上层调用可靠数据发送服务后，发送端将上层数据打包为分组，并添加校验和，再调用下层不可靠传输服务发送分组（事件1），然后进入等待确认状态。如果收到否请确认则重传该分组，并继续保持等待确认状态（事件2）；如果收到肯定确认，则进入等待上层调用服务状态（事件）。
接收端有限状态机：

如果接收端收到损坏的分组，则反馈否请确认，请求发送端重传该分组（事件1）；如果接收端收到正确的分组，则提取数据交付给应用层（事件2）。
当发送端处于等待ACK或NAK的状态时，它不能从上层获得更多的数据，仅当接收到ACK并离开该状态时，才能再次接收上层的数据。因此，这样的协议被称为停等（stop-and-wait）协议。

ACK：为acknowledgement的简写，表示肯定确认。 NCK：为negative acknowledgement简写，表示否请确认。

3.RDTP_2.1

RDTP_2.0存在一个致命缺点：没有考虑 ACK/NAK 分组受损的情况。
因此在RDTP_2.0协议基础上做如下修改：

• 下层信道不完全可靠。
  • 数据分组传输过程中可能损坏。
  • 确认分组传输过程中可能损坏。
  • 分组保证送达。
• 分组按顺序到达接收端。

解决思路：为ACK/NAK确认分组添加校验和，检错并纠错。但纠错总体性能代价太大，可行但不经济。所以不对确认分组进行纠错，当发送端收到损坏分组或NAK分组时，直接重传当前分组。
但这种方式可能产生重复分组——当接收端收到正确的分组后，向发送端发送ACK分组，但ACK分组在传输过程中变成了损坏分组，导致发送端重传已经被接收端完整收到的分组。此外，当接收端收到重传的分组又后，又会出现无法分辨分组是重传分组还是新分组的问题，需要在发送端在分组中添加序列号，接收端每次接收到分组时就将当前分组序列号与上次收到分组的序列号进行比较，如果序列号相同，则知这是一个重传分组，反之则是一个新分组。
发送端有限状态机：

当上层调用可靠数据发送服务后，发送方将上层数据打包为分组，并在分组中添加一个序列号来告知接收方该分组是重传分组还是新分组（事件1和4）。此后进入等待确认当前分组是否被成功接收的状态。只要收到的确认分组损坏或者为否请确认（事件2和5），就重传当前分组，否则进入等待上层调用传送新分组的状态（事件3和6）。
接收端有限状态机：

事件3和5就是接收端收到无损的、序号正确的分组，但是反馈给发送端的ACK分组在传输过程中损坏，从而导致发送端重传分组的情况。事件2和6就是数据分组在传输过程中损坏，接收端请求发送端重传的情况。事件1和4是接收端在线路状况良好情况下工作的情况。

4.RDTP_2.2

对于RDTP_2.1协议，其实不需要ACK和NAK两种确认消息，只需要在ACK消息中捎带最后一个被接收端完整接收的分组序号即可。当发送端收到两个确认序号相同的ACK时，就知道接收端没有正确接收跟在被重复确认分组后面的分组。
发送端有限状态机：

接收端只要收到损坏的分组，或者收到的分组的确认序列号与当前发送出去的序列号不一致，发送端就知道接收端没有完整收到当前发送出去的分组，于是就会重发当前分组（事件2和5）。
接收端有限状态机：

只要接收端收到损坏的分组或者分组序号不符合需求就会重新发送一次确认分组（事件2和4），告知发送端最后一次完整收到的分组序列号。

5.RDTP_3.0

此前的4版协议，信道保证都能保证送达分组，实际上这是不可能的，所以RDTP_3.0对此进行了考虑：

• 下层信道不完全可靠。
  • 数据分组传输过程中可能损坏。
  • 确认分组传输过程中可能损坏。
  • 分组可能无法送达。
• 分组按顺序到达接收端。

这种情况下，如果确认分组在传输过程中丢失，发送端就收不到来自接收端的响应，会一直保存等待响应状态，所以协议必须解决检测丢包问题。
解决思路：发送端发送分组后，在“合理”时间内没有收到接收端响应，则视为丢包，然后重传当前分组。
发送端有限状态机：

RDTP_3.0协议在RDTP_2.2协议的基础上添加了定时器，定时器结束后还没有收到接收端的响应就重传当前分组（事件3和7）。另外，在定时器结束前如果收到了损坏分组或者乱序分组，发送端不会做任何操作（时间2和6），而是等待定时器结束后重发当前分组。在定时器结束前收到完整的分组，接收端就会关闭定时器（事件4和8），进入等待发送下一个分组的状态。
接收端的有限状态机与RDTP_2.2协议一样。

6.滑动窗口协议

虽然RDTP_3.0已经是一个面向实际情况的、功能正确的协议，它解决了如何在不可靠的物理信道上构建一条可靠的逻辑信道的问题，但是没有解决效率通信效率的问题，而对效率影响最大的就是RDTP协议使用了停等协议进行流量控制。
假设端到端的传播时延远大于传输时延，不考虑处理时延和排队时延，那么发送端对信道的利用率就非常低，即网络协议限制了物理资源的利用。如下是停等协议通信过程图：

其信道利用率为：
#card=math&code=%E4%BF%A1%E9%81%93%E5%88%A9%E7%94%A8%E7%8E%87%3D%5Ccfrac%7Bt%7D%7Bt%2BRTT%7D%7B%5Cquad%7D%E5%85%B6%E4%B8%AD%28RTT%7B%5Cgg%7Dt%29&id=LwYcM)
解决停等协议效率的简单方法是：不使用停等模式，而使用流水线模式，如下是流水线模式通信过程图：

其信道利用率为：
#card=math&code=%E4%BF%A1%E9%81%93%E5%88%A9%E7%94%A8%E7%8E%87%3D%5Ccfrac%7Bnt%7D%7Bt%2BRTT%7D%7B%5Cquad%7D%E5%85%B6%E4%B8%AD%28RTT%7B%5Cgg%7Dt%29&id=ZqwMK)
停等模式下流量控制相对简单，但流水线模式下流量控制就变得复杂，需要专门的协议来协调——滑动窗口协议（Sliding-window Protocol），滑动窗口协议主要有两类协议：GBN(Go-Back-N，回退N重传)协议和SR(Selective Repeat，选择重传)协议。
滑动窗口协议中，由于发送端和接收端要同时处理多个分组，为了区分这些分组，分组序号范围必须扩大。同时，如果发送端或接收端还要缓存多个待确认分组，接收端或发送端的缓冲区也需要扩大。至于何时滑动窗口，协议的具体实现决定。

7.GBN协议

在GBN协议当中，允许发送端发送多个分组而不需要等待确认，下图是GBN协议的基本模型：

GBN的接收端窗口大小为1，发送端窗口大小为 ，其中 的大小取决于协议规定的、用于标识序号的比特数。
由于连续发送了多个分组，所以确认分组必须指明对哪一分组进行确认。为了减少开销，GBN协议规定接收端不一定每收到一个正确的分组就必须发回一个确认分组，而可以在连续收到好几个正确的分组后，才对最后一个分组发送确认分组。或者可在自己有关数据要发送时才将对以前正确收到的分组加以捎带确认。这就是说，对某一分组的确认就表明该分组和此前所有的分组均已正确收到。这就是GBN协议的累计确认机制。
不同的GBN协议实现采用的累计确认机制不同，但对确认的结果的处理确实相通的。接收端收到错误分组或断序分组，就会丢弃该分组后面所有的分组，直到再次收到该分组的重传分组，才会接收该分组后面的分组。发送端如果收到损坏的确认分组，会重传上次正确确认之后发送的所有分组。

8.SR协议

GBN协议会因为一个损坏分组而丢弃后面可能正确的分组，如果下层信道质量很差，GBN协议完全又可能退化为停等协议。为进一步提高信道利用率，SR协议只会重传出现差错或计时器超时的分组。下图是SR协议的基本模型：

SR协议接收端和发送端的窗口大小满足 。如果 大于 ，会导致接收窗口溢出；如果 小于 ，接收窗口多出部分无意义；
SR协议的接收端窗口会那些正确的分组，等到窗口内所有分组都正确接收后，再一并交付给应用层，这样才能保证序号的顺序。对于损坏的分组，SR协议会反馈一个带序号的NAK（）分组给发送端。
GBN协议计时器是全局唯一的，而SR协议会为每一个分组开启一个定时器。当某个分组的定时器截止时或者收到对某个分组的 时就会重传该分组，或者收到 时不做处理，而是等待该分组的定时器截止。

参考文章

• 《王道考研系列——2023年计算机网络考研复习指导》——p78~p80