前前言：看过本节的朋友应该都知道本节长度长的吓人，但其实内容含量和之前的差不多，老师在本节课举的例子和解释比较多，所以大家坚持看完是一定可以理解透彻的。本节课大部分是在提出问题和解决问题，先明确出现的问题是什么再去看 RDT 是如何解决它的会很有帮助；在 RDT 之后又引入了流水线协议去解决 RDT 利用效率问题，这部分同样需要先搞清楚提出了什么问题。
前言：学习视频：中科大郑烇、杨坚全套《计算机网络（自顶向下方法 第7版，James F.Kurose，Keith W.Ross）》课程
该视频是B站非常著名的计网学习视频，但相信很多朋友和我一样在听完前面的部分发现信息量过大，有太多无法理解的地方，在我第一次点开的时候也有相同的感受，但经过了一段时间项目的学习，对计网有了更多的了解，所以我准备在这次学习的时候做一些记录并且加入一些我的理解，希望能够帮助到大家。
往期笔记可以看专栏中的内容😊😊😊
文章目录
- [3.4 可靠数据传输的原理](#3.4 可靠数据传输的原理)
- [3.4.1 实现 RDT 通信需要解决哪些问题？](#3.4.1 实现 RDT 通信需要解决哪些问题？)
- [3.4.2 RDT 1.0 - 可靠信道上传输数据](#3.4.2 RDT 1.0 - 可靠信道上传输数据)
- [3.4.3 RDT 2.0 - 在具有比特差错的信道传输数据](#3.4.3 RDT 2.0 - 在具有比特差错的信道传输数据)
- [3.4.3.1 RDT 2.1](#3.4.3.1 RDT 2.1)
- [3.4.3.2 RDT 2.2 - NAK FREE](#3.4.3.2 RDT 2.2 - NAK FREE)
- [3.4.4 RDT 3.0 - 在具有比特差错和分组丢失的信道上传输](#3.4.4 RDT 3.0 - 在具有比特差错和分组丢失的信道上传输)
- [3.4.5 流水线协议](#3.4.5 流水线协议)
- [3.4.5.1 案例](#3.4.5.1 案例)
- [3.4.5.2 滑动窗口](#3.4.5.2 滑动窗口)
- [3.4.6 GBN 协议](#3.4.6 GBN 协议)
- [3.4.7 SR 协议](#3.4.7 SR 协议)
3.4 可靠数据传输的原理
💡 RDT（Reliable Data Transfer，可靠数据传输）是一种通信协议，旨在通过各种技术手段确保数据在通信网络中可靠地传输。RDT的实现方式可以基于不同的传输层协议，如TCP或UDP。
3.4.1 实现 RDT 通信需要解决哪些问题？
如果说是在传输层来实现可靠数据传输的话需要从上层收取数据，将其进行封装然后交给下层，但如果下层是 unreliable 的话，就需要通过本层实现来解决下层不可靠的问题。
整个可靠数据传输需要解决如下的问题：
- 完整性（Integrity）：数据在传输过程中没有被篡改或损坏。接收方能够准确地接收到发送方发送的数据。
- 顺序性（Ordering）：数据包按照发送的顺序被接收方接收。即使在传输过程中发生了拥塞或丢包，接收方也能够按照正确的顺序重组数据。
- 可靠性（Reliability）：数据包能够在不丢失的情况下被接收方接收到。如果数据包丢失或损坏，可靠的传输机制会重新发送数据，直到接收方正确地接收到为止。
- 及时性（Timeliness）：数据包能够在合理的时间内被接收方接收到，避免过长的延迟或等待时间。
但如果网络层实现了其中的一部分，那传输层只需要解决 剩余的部分 即可。
所以采用一种渐进的方式来讲述 RDT 的实现，先假设一个可靠的传输信道，再逐步减少其能实现的功能，同时逐步是通过上层的协议来解决这些问题。
💡 使用有限状态机（FSM）来描述发送方和接收方
- 是一种抽象的计算模型，用于描述系统在不同状态之间的转换以及状态转换所触发的行为。有限状态机由一组状态、一组输入和一组状态转换规则组成。
- 使用圆来表示一种状态，使用连线来表示从一个状态到另一个状态的变迁，连线上的标注：分子表示引起状态变迁的事件，分母表示状态变迁的时候要进行的动作。
3.4.2 RDT 1.0 - 可靠信道上传输数据
💡 此时下层的信道是完全可靠的
- 没有比特出错
- 没有分组丢失
此时的传输层就不需要做任何的操作，只需要接收上层的数据并且封装，接着将数据交给网络层即可。
此时发送方和接收方的 FSM：
💡 看懂这个图需要记住上面说的分子和分母的含义
- 发送方等待上层的数据，上层使用
rdt_send(data)发送数据- 此时发送方将数据封装并且调用下层的
udt_send()来进行发送- 接收方同理，接收到数据然后解封装向上层传递
3.4.3 RDT 2.0 - 在具有比特差错的信道传输数据
💡 此时下层的信道就稍微不可靠一点了，会使得发送的分组中的比特翻转过来。
此时发送方和接收方就需要通过一定的手段来找出数据中是否存在问题和解决了。
比如使用 校验和 的方式：
-
校验和是一种简单的错误检测方法，通常用于确认数据在传输过程中是否发生了错误。
-
它通过对数据中的每个字节进行加和运算得到一个校验值，并将该校验值附加到数据中 一起传输。
-
接收端 在接收到数据后也计算校验和，然后与发送端附加的校验和进行比较，如果两者相等，则说明数据在传输过程中没有发生错误；如果不相等，则说明数据可能已经损坏，需要进行重传。
-
校验和虽然能够检测一部分错误，但并 不是完美的错误检测方法，因为存在一些情况下校验和并不能准确地检测出错误。
💡 这篇博客里有关于 UDP 校验和形成的描述，感兴趣的朋友可以去看看：中科大计网学习记录笔记（十四）：多路复用与解复用 | 无连接传输：UDP
此时校验如果出错，那解决方法就只能是通过 重传 ，所以需要 将检测结果反馈给发送端 来决定是否重传，当数据没有错误的时候向发送端发送 确认（ACK） ，反之发送 否定确认（NAK）
- 发送方需要等待接收方的确认消息才能决定是否重传分组或者继续发送其他分组
- 发送端接收到
NAK的时候就重传分组
此时发送方就有了等待上层交付数据和等待接收方返回数据两种状态
3.4.3.1 RDT 2.1
💡 RDT 2.0 存在一个致命的缺陷：既然发送的数据可能损坏，那发送的 ACK 或者 NAK 是否也有可能损坏呢？
此时就需要一种解决方法：
发送方接收到一个无法理解的消息，这个消息有两种可能：ACK 或者 NAK，NAK 直接重传就可以了，但是得有一种方法能让接收方重传这个 ACK。
- 此时就采用和 NAK 同样的处理方式，直接重新发送上次的分组过去。
- 此时如果接收方发送的是
NAK那就直接结束了，但如果发送方发送的是ACK但是接收到了相同的分组，也就知道是发送的ACK在传输中出现了问题，直接重发ACK即可。 - 为了让接收方和发送方都能认识分组，所以采用编号的方式，快速的判断是否是重传。
3.4.3.2 RDT 2.2 - NAK FREE
💡 发送数据不一定一次就只发送一条数据，但如果发送多条数据的其中一条出错，仍然使用单调的
NAK解释的话，就无法知道要重发哪一条。
- 停等协议（Stop-and-Wait）
- 流水线协议（Pipelining Protocol）
同时上面又引入了编号，那就有了一种新的确认错误的方式：发送的编号和返回的编号是否相同，比如说发送的是数据 0 但是接收方传输过来的是 ACK(1) 这时候同样可以达到标识错误。
这种改动其实对单个数据发送没有太大影响，而对后续改编成连续数据的发送则有很大的帮助。
3.4.4 RDT 3.0 - 在具有比特差错和分组丢失的信道上传输
💡 此时下层的信道可能会丢失分组，比如数据会丢失，或者 ACK 也可能会丢失
这样就带来了一些问题：发送方不知道接收方接收到了没有，因为发送的数据和发送方的 ACK 都有可能会丢失。
此时的解决方式就是采用超时重传机制：发送方等待 ACK 一段时间，如果没有收到就说明出现了问题，此时直接重传：
- 如果此时是数据丢失的情况，重传后双方同步
- 如果是 ACK 丢失的情况，接收方接收到了重复的数据，同样发送 ACK 回去，此时也能同步
👉 这个超时重传的时间设定要合理，当时间设置的过长会导致错误处理不及时，过低则会导致使用效率的降低：
- 当 ACK 还没来得及过来的时候发送方就重发了信息，此时接收方收到了重发，再次发送一个 ACK 过去，这样就会导致每次发送都是两次甚至多次的发送：
3.4.5 流水线协议
💡 此时通过 RDT 协议已经解决了网络层可能出现的所有问题，但是发送一条后等待确认再发送下一条的特质使得其对信道的利用效率极低。
3.4.5.1 案例
💡 使用发送速率为 1 Gbps 的链路进行通信，端到端的传播延时为 15 ms，一个分组的大小为 1kB，评判一下数据传输的效率。
传输延时为 8 / 10^9^ = 8 us
总延时：15ms ✖ 2 + 8us
此时的利用率也就是总延时除以发送延时，达到了 0.00027，也就是说只有 0.027% 的时间在发送数据，其他时间都在等待 ACK。
这样的效率显然是不尽如人意的，所以在等待的时间中可以通过再次发送其他数据来增大利用率。
3.4.5.2 滑动窗口
💡 在学习具体的流水线协议之前要先了解滑动窗口，这是实现该协议的一种机制。
比如说此时有五个分组等待发送
肯定无法直接将这五个分组全部打出去，因为接收方的接受能力是有限的，而且下方的网络层提供的是不可靠的传输，需要对错误的信息进行重传等操作。
所以需要设置一个固定大小的 缓冲区，将每次只处理缓冲区域内的数据，等到缓冲区域中的一部分数据处理完成，通过移动缓冲区，又可以处理新的数据。
假设缓冲区的大小为 3，就将这三个数据全部打出
此时进入等待，等到数据 0 的 ACK 收到的时候，就可以移动窗口了
这样逐次进行操作，直到处理完所有需要发送的分组。
以上就是滑动窗口的基本思想，同样的，在接收方也可以顺序的去接收一个分组或同时可接收多个分组，对于这两种情况发送方又有不同的策略。
3.4.6 GBN 协议
💡 GBN（Go-Back-N）：当接收方一次只能接收一个分组的时候就需要使用该协议。
此时发送方只能接收分组 0，当接收到分组 0 的时候，将可接受的内容后移一位来接收 1，同时向发送方发送 ASK。
发送方接收到 ASK 之后可以移动窗口继续发送其他分组。
这是最好的情况，比如说此时通信处于如下的情况：
接收方等待接收分组 2，但是如果出现了某些情况导致分组 2 没有到达，而是分组 3 和 分组 4 到达，那这时候接收方就会 拒收 这些分组。
那这样之后，分组 2 包括其以后的分组都没有收到，必须通知发送方来重传；最好的方式就是给分组设置定时器，如果发送的分组没有收到 ASK 的话，就进行重传的操作。
所以当接收方收到分组 3 的时候，会返回 分组 1 的 ASK，那自然分组 2 之后的所有分组在分组定时器到期后就会进行重传操作，解决了分组丢失的问题。
所以当分组 2 丢失了之后就需要跳回到数个位置之前去重传，所以称之为 Go Back N。
但显然因为一个分组的丢失去重传多个分组是可以优化的，可以让 接收方同时可以接收多个分组 来实现，这也就是接下来要说的 SR 协议。
3.4.7 SR 协议
💡 SR（Selective Repeat）：即选择重传协议，通过让接收方接收多个分组，可以实现选择性的重传分组，而不需要重传 N 个分组。
此时比如说接收到了分组 2，就将分组 2 先保留下来，同时发送 ASK2 给发送方，发送方此时给分组 2 一个标识，然后只需要发送其他的未接受到 ASK 的分组即可。
这个重发操作同样是通过 定时器 来实现。
对比一下：
- 当出错率低的时候使用 GBN，因为即使是 Go Back N 带来的损失依旧很小，没必要去使用复杂的 SR 协议。
- 当链路容量很大的时候建议使用 SR，因为容量大代表同时可发送的内容较多，为了充分利用就会同时发送很多的分组，此时如果出现错误，代价会比较大。
平衡这两点考虑就可以选择出适合的协议方式。