文章目录

可靠数据传输原理
- 构造可靠数据传输协议
- - 经完全可靠信道的可靠数据传输：rdt 1.0
  - 经具有比特错误信道的可靠数据传输：rdt 2.0
  - 经具有比特错误信道的可靠数据传输：rdt 2.1
  - 经具有比特错误信道的可靠数据传输：rdt 2.2
  - 经具有比特错误的丢包信道的可靠数据传输：rdt 3.0
  - 流水线技术
  - GBN
  - SR

可靠数据传输原理

可靠指不错、不丢、不乱。可靠数据传输的框架如下图所示，为上层实体提供的服务抽象是：数据可以通过一条可靠的信道进行传输（如图 (a) 所示）；实现这种服务抽象是可靠数据传输协议（reliable data transfer protocol, rdt）的责任，由于可靠数据传输协议的下层协议也许是不可靠的（如图 (b) 所示），因此这是一项困难的任务。

构造可靠数据传输协议

下面我们渐进地设计可靠数据传输协议的发送方和接收方，且仅考虑单向数据传输（unidirectional data transfer）的情况，即数据传输是从发送端到接收端的，但控制信息是双向流动的。

经完全可靠信道的可靠数据传输：rdt 1.0

首先考虑最简单的情况，即底层信道是完全可靠的，我们称该协议为rdt 1.0，该协议本身是简单的，发送方和接收方的有限状态机（Finite-State Machine, FSM）如下图所示：

发送方和接收方的 FSM 都只有一个状态，rdt 的发送端只通过 rdt_send(data) 事件接收来自较高层的数据，产生一个包含该数据的分组（经由 make_pkt(data) 动作），并将分组发送到信道中；在接收端，rdt 通过 rdt_rcv(packet) 事件从底层信道接收一个分组，从分组中取出数据（经由 extract(packet, data) 动作），并将数据上传给较高层（通过 deliver_data(data) 动作）。

实际上，rdt_send(data) 事件是由较高层应用的过程调用产生，rdt_rcv(packet) 事件是由较低层协议的过程调用产生的。

经具有比特错误信道的可靠数据传输：rdt 2.0

假设底层信道仅可能产生位错误，即可能将某比特由 0 翻转为 1，由 1 翻转为 0，仍然假定所有发送的分组（虽然有些比特可能受损）将按其发送的顺序被接收。

考虑一下你自己是怎样通过电话口述一条长消息的：报文接收者在听到、理解并记下每句话后可能会说“OK”；听到一句含糊不清的话时，他可能会说“请重复一遍”。这种方法使用了肯定确认与否请确认，这种控制报文使得接收方可以让发送方知道哪些内容被正确接收，哪些内容接收有误并需要重复。
在计算机网络中，基于这种重传机制的 rdt 协议称为自动重传请求（Automatic Repeat Request, ARQ）协议，它需要三种协议功能来处理存在位错误的情况：

差错检测。可以通过校验和来检测位错误。
接收方反馈。接收方提供明确的反馈信息给发送方，rdt 2.0 协议将从接收方向发送方回送 ACK 与 NAK 分组，接收方通过 ACK 显示地告知发送方分组已正确接收，NAK 则显示地告知发送方分组有错误。
重传。接收方收到有差错的分组时，发送方将重传该分组。

下图说明了 rdt 2.0 的 FSM，该数据传输协议采用了差错检测、肯定确认与否定确认：

rdt 2.0 的发送端有两个状态:

在左边的状态中，发送端正等待来自上层传下来的数据，当上层调用 rdt_send(data) 时，发送方将产生一个包含待发送消息和校验和的分组 sndpkt，然后经由 udt_send(sndpkt) 操作发送该分组;
在右边的状态中，发送方协议等待来自接收方的 ACK 或 NAK 分组，如果收到一个 ACK 分组，则发送方知道最近发送的分组已被正确接收，因此协议返回到等待来自上层的数据的状态；如果收到一个 NAK 分组，该协议重传最后一个分组并等待接收方为响应重传分组而回送的 ACK 或 NAK。

rdt 2.0 的接收端的 FSM 仍然只有一个状态，当分组到达时，接收方要么回答一个 ACK，要么回答一个 NAK，这取决于收到的分组是否受损。

注意到：当发送方处于等待 ACK 或 NAK 的状态时，它不能从上层获得更多的数据，仅当接收到 ACK 并离开该状态时才能再次接收上层的数据，因此，rdt 2.0 这样的协议被称为停等（stop-and-wait）协议。

经具有比特错误信道的可靠数据传输：rdt 2.1

rdt 2.0 存在一个致命的缺陷，即没有考虑 ACK / NAK 分组受损的可能性！解决方法：
（1）可以为 ACK / NAK 增加校验和，检错并纠错，难度较高，且伴随着较高的代价；
（2）当发送方收到含糊不清的 ACK 或 NAK 分组时，只需重传当前数据分组即可。然而，这可能会产生重复分组。重复分组的根本困难在于接收方不知道它上次所发送的 ACK 或 NAK 是否被发送方正确地收到，也就无法事先知道接收到的分组是新的还是一次重传。
解决重复分组问题的一个简单方法（几乎现有的数据传输协议，包括 TCP，都采用了这种方法）是在数据分组中添加序列号（Sequence Number）：发送方给每个分组增加序列号。接收方只需要检查序列号即可确定收到的分组是重传的还是新的分组。

对于停等协议这种简单的情况，1 比特序列号就足够了，因为它可以让接收方知道发送方是否正在重传前一个发送分组或是一个新分组。下图给出了 rdt 2.1 发送方的 FSM，状态数是 rdt 2.0 的两倍，因为协议状态必须反映出发送方所发送的分组或接收方希望接收的分组的序号是 0 还是 1：

当从接收方收到的确认分组受损（虽然此时可能接收方已经正确接收）或为 NAK 时，都需要重传当前分组；
只有当从接收方收到的确认消息没有受损且为 ACK 时，才会等待传输下一个数据分组。

下图给出了 rdt 2.1 接收方 FSM 的状态，需判断分组是否是重复的：

当接收到失序分组时，接收方对所接收的分组发送一个肯定确认。
- 现象产生原因：可能上一个回复的 ACK 分组在传输到发送方的过程中发生错误，发送方又重传了一遍原来序号的分组，这就导致接收方收到重复分组。
- 此时只有回复 ACK，才会使发送方发送下一个序号的分组，即接收方希望接收序号的分组；
- 如果此时回复 NAK 的话，那么就会陷入无限循环当中，发送方一直会发送接收方不希望接收的这个冗余分组；
- 当然置之不理更不可以。
当接收到受损分组时，接收方将发送一个否定确认。

经具有比特错误信道的可靠数据传输：rdt 2.2

其实不需要使用 ACK 和 NAK 两种确认消息，只使用一种确认消息就可以实现 rdt 2.1 的功能，这就是 rdt 2.2：无 NAK 消息协议。

接收方通过 ACK 告知最后一个被正确接收的分组序列号，这就需要在 ACK 确认消息中显示地加入被确认分组的序列号。发送方接收到对同一个分组的两个 ACK（即重复 ACK）后，就知道接收方没有正确接收到跟在被确认两次的分组后面的分组。

rdt 2.2 和 rdt 2.1 的细微变化在于，接收方此时必须包括又一个 ACK 报文所确认的分组序号，接收方此时必须检查接收到的 ACK 报文中被确认的分组序号。

经具有比特错误的丢包信道的可靠数据传输：rdt 3.0

现在假定除了比特受损外，底层信道还会丢包，假定发送方传输一个数据分组，该分组或者接收方返回对该分组的 ACK 发生了丢失，这样发送方都收不到应当到来的接收方的响应。协议现在必须处理另外两个问题：怎样检测丢包以及发生丢包后该做什么。通过使用检验和、序列号、ACK 分组和重传等，我们能够给出第二个问题的答案，为了解决第一个问题，还需要增加一种新的协议机制：发送方等待“合理”时间：

如果没收到 ACK，发送方重传分组。
如果分组或 ACK 只是延迟而不是丢失，那么重传会产生重复分组，但 rdt 2.2 中通过序列号机制已经能够处理重复分组（需要在 ACK 中显示地加入上一个被正确接收的分组序列号）。

发送方不知道是一个数据分组丢失，还是一个 ACK 丢失，或者只是该分组或 ACK 过度延迟，在所有这些情况下，发送方的动作是同样的：重传。为了实现基于时间的重传机制，需要一个倒计数定时器（countdown timer）。下面给出了 rdt 3.0 发送方的 FSM，而接收方的 FSM 与 rdt 2.2 完全相同。

注意 rdt 3.0 发送方与 rdt 2.2 发送方有一个细微的差别，当发送方收到重复 ACK 时，rdt 3.0 什么都不做，直到定时器到时间后才会重传分组，而 rdt 2.2 的发送方收到重复 ACK 时会直接重传分组。
rdt 3.0 仍然是一个停等协议，因为分组序号在 0 和 1 之间交替，因此 rdt 3.0 有时被称为比特交替协议（alternating-bit protocol）。

rdt 3.0 已经是一个功能正确的协议，虽然采用停等协议使得该协议比较简单（只需要两个分组序列号），但性能很差，因为只有等收到了想要的 ACK，才会回到从上层接收数据的状态。如下面的例子中，假设端到端的传播延迟远大于数据分组的传输延迟，那么发送方对链路带宽的利用率是非常低的，即网络协议限制了物理资源的利用。

流水线技术

解决 rdt 3.0 性能问题的一个简单方法是：不使用停等协议，允许发送方在收到 ACK 之前发送多个分组，即采用流水线（pipelining）技术。流水线技术对可靠数据传输协议可带来如下影响：

必须增加序列号范围，因为每个输送中的分组必须有一个唯一的序列号，而且也有许多个在输送中未确认的报文。
协议的发送方和接收方两端也许必须缓存多个分组。发送方最低限度应当能缓冲那些已发送但没有确认的分组，接收方或许也需要缓存那些已正确接收的分组。

所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线的差错恢复有两种基本方法：回退 N 步（Go-Back-N, GBN）和选择重传（Selective Repeat, SR）。

GBN

在 GBN 协议中，允许发送方发送多个分组而不需等待确认，但它也受限于在流水线中未确认的分组不能超过某个最大允许数 N，N 常被称为窗口长度，GBN 协议也常被称为滑动窗口协议。下图显示了发送方看到的 GBN 协议的序号范围，定义基序号（send_base）为最早的未确认分组的序号，将下一个序号（nextseqnum）定义为最小的未使用序号，则可将序号范围分割成 4 段。
（1）在 [0, send_base - 1] 段内的序号对应于已经发送并被确认的分组。
（2）在 [send_base, nextseqnum - 1] 段内对应已经发送但未被确认的分组。
（3）[nextseqnum, base + N - 1] 段内的序号能用于要被发送的分组。
（4）大于等于 base + N 的序号是不能使用的，直到当前流水线中未被确认的分组（特别是序号为 send_base 的分组）已得到确认为止。

在实践中，一个分组的序号在分组首部的一个固定长度的字段中。如果分组序号字段的比特数是 k k k，则序列号的范围是 [ 0 , 2 k − 1 ] [0, 2^k-1] [0,2k−1]，所有涉及序号的运算必须使用模 2 k 2^k 2k 运算（即序号空间可被看作是一个长度为 2 k 2^k 2k 的环）。

GBN 发送方的扩展 FSM 如下所示，它必须响应三种类型的事件：

上层的调用。当上层调用 rdt_send() 时，发送方首先检查发送窗口是否已满，即是否已经有 N 个已发送但未被确认的分组。如果窗口未满，则产生一个分组并将其发送，并相应地更新变量；如果窗口已满，在实际实现中，发送方可能缓存（并不立刻发送）这些数据。
收到一个 ACK。在 GBN 协议中，采用的是累积确认的方式，表明接收方已确认到序列号 n（包含 n）的分组均已经被正确接收，此时窗口滑动。可能收到重复 ACK。
超时事件。发送方仅使用一个计时器，它可以当作是最早的已发送但未被确认的分组所使用的计时器。如果出现超时，发送方重传所有已发送但还未被确认过的分组。如果收到一个 ACK，但是仍有已发送但未被确认的分组，则计时器重新启动；如果没有已发送但未被确认的分组，该定时器被终止。

GBN 接收方的动作也很简单。如果一个序号为 n 的分组被正确接收到并且按序，则接收方为分组 n 发送一个 ACK(n)，表示到序号 n 的分组均已被正确接收。在所有其他情况下，接收方丢弃该分组（接收缓存实现简单），并为最近按序接收的分组重新发送 ACK。因此，虽然发送方必须维护窗口的上下边界以及 nextseqnum 在该窗口中的位置，但是接收方需要维护的唯一信息就是下一个按序接收的分组的序号。其扩展 FSM 如下所示：

SR

在 GBN 协议中，单个分组的差错就能够引起 GBN 重传大量分组。顾名思义，选择重传（SR）协议通过让发送方仅重传那些它怀疑在接收方出错的分组而避免了不必要的重传。此时不仅发送方需要维护一个窗口，接收方也需要维护一个窗口。

发送方只重传那些没收到 ACK 的分组，因此需要为每个分组设置计时器。发送方需要处理的事件：

从上层收到数据。当从上层接收到数据后，检查下一个可用于该分组的序号是否在窗口范围内。
超时。现在窗口内的每个分组都拥有其自己的逻辑定时器，因为超时后只能发送一个分组。
收到 ACK。如果ACK序号在窗口内，则 SR 发送方将那个被确认的分组标记为已接收。如果该分组的序号等于 send_base，则窗口基序号向前移动到具有最小序号的未确认分组处。

接收方对每个分组单独进行确认，需要设置缓存机制，缓存乱序到达的分组。接收方需要处理的事件：

序号在 rcv_base, rcv_base+N-1 内的分组 n 被正确接收。一个带有相应序号的 ACK 被会送给发送方。如果该分组以前没收到过，则缓存该分组。如果该分组的序号等于接收窗口的基序号，则将该分组以及向后缓存的连续序号的分组交付给上层。
序号在 rcv_base-N, rcv_base-1 内的分组 n 被正确接收。在此情况下，必须产生一个该序号的 ACK，即使该分组是接收方以前已确认过的分组（但发送方不知道）。
其他形况则忽略该分组。

序列号空间与窗口大小尺寸需要满足 N S + N R ≤ 2 k N_S+N_R\leq 2^k NS+NR≤2k 的关系，其中 N S N_S NS 表示发送方的窗口尺寸， N R N_R NR 表示接收方的窗口尺寸， k k k 表示分组头部代表序号的比特位数。

计算机网络（14）——可靠数据传输原理相关推荐

计算机网络自顶向下方法第三章运输层 3.4 可靠数据传输原理
计算机网络自顶向下方法总结3.4可靠数据传输原理目录 3.4 可靠数据传输原理 3.4.1 构造可带数据传输协议 3.4.2 流水线可靠数据传输协议 3.4.3 回退N步 3.4.4 选择重传 3. ...
可靠数据传输原理详细图解
可靠数据传输原理概述 rdt1.0 rdt2 rdt2.0 rdt2.1 rdt2.2 rdt3.0 流水线可靠数据传输协议为什么使用流水线流水线对可靠数据传输协议带来的影响流水线协议中恢复差 ...
计算机网络（自顶向下方法）学习记录---3.4 可靠数据传输原理
文章目录前言一.构造可靠传输协议 1.rdt1.0 2.rdt2.0 3.rdt2.1 4.rdt3.0 二.GBN 总结前言在学习3.5节TCP传输之前,我们需要先了解到可靠数据的传输原理, ...
可靠数据传输原理1（构造可靠数据传输协议）
TCP向调用它的因特网应用所提供的服务模型(服务抽象) 数据可以通过一条可靠的信道进行传输.借助于可靠的信道,传输比特就不会受到损坏或丢失,而且所有数据都是按其发送顺序进行交付. 可靠传输协议实现服 ...
计网必会：UDP差错检测，检验和、可靠数据传输原理
文章目录 [前言] UDP套接字无连接运输 UDP 的优势 UDP的差错检测可靠数据传输可靠传输的方式总结构造可靠数据传输协议可靠信道具有比特差错的信道三种可能 [前言] 之前一节我们介 ...
【Sofice小司笔记】5 计算机网络，包含数据传输原理、网络各层协议详细说明、TCP/IP协议栈各常用协议说明、TCP握手挥手、可靠传输、网络加密技术
❓ 在浏览器地址栏输入一个 URL 后回车,背后发生了什么解析 URL 浏览器封装 HTTP 请求报文 DNS 域名解析获取 IP 地址建立 TCP 连接(长链接) 浏览器发送请求负责传输的 I ...
Day6:可靠数据传输的原理
加油!偷博仔今天遇见两首顾城的诗黑夜给了我黑色眼睛我却用它寻找光明 ----<一代人> 1979年4月在你的门前我堆起一个雪人代表笨拙的我把你久等你拿出一颗棒糖一颗甜甜的 ...
[计算机网络] 可靠数据传输 rdt1.0 2.0 2.1 2.2 3.0；GBN；SR
(给爷整吐了还有状态机要背) 可靠数据传输原理可靠数据传输的问题在运输层.链路层及应用层都会出现. 数据通过一条可靠的信道传输即传输的数据不出错,丢失,并按照发送的顺序传送可靠传输实现设计可 ...
[计算机网络] 运输层可靠传输rdt 拥塞控制 TCP连接多路复用
运输层运输层服务运输层协议:为运行在不同主机上的应用进程提供逻辑通信功能(主机直接相连).即端到端传输. 进程之间使用逻辑通信功能彼此发送报文,无需考虑具体物理链路. 运输层协议运行在端系统,不在 ...

计算机网络（14）——可靠数据传输原理