3-4 可靠传输
# 340.3-4 可靠传输
本节课我们介绍可靠传输的基本概念。
# 3.4.1 可靠传输基本概念
通过上节课的学习，我们已经知道使用差错检测技术，例如循环冗余校验 CRC，接收方的数据链路层，就可以检测出帧在传输过程中是否产生了误码，也就是出现比特错误。如下所示，帧在传输过程中受到干扰，产生了误码。接收方的数据链路层通过帧尾中的帧检验序列、FCS 字段的值，也就是检测可以检测出帧中出现了比特差错，那么接下来该如何处理呢？
这取决于数据链路层向其上层提供的服务类型。如果提供的是不可靠传输服务，则仅仅丢弃有误码的帧，其他什么也不做。
如果提供的是可靠传输服务，那就还要想办法实现发送端发送什么，接收端就收到什么。例如接收方可以给发送方发送一个通知帧，告诉他之前发送的帧产生了误码，请重发。发送方收到通知后重发之前产生了误码的帧即可。实际上可靠传输的实现并没有我们想象的这么简单。试想一下，这个通知帧如果也出现了误码，又会怎么样？
本节课我们不会深入讨论实现可靠传输的具体方法，而是介绍可靠传输的基本概念。在后面的课程中，我们会详细介绍三种实现可靠传输的方法。一般情况下有线链路的误码率比较低，为了减小开销，并不要求数据链路层向上提供可靠传输服务，即使出现了误码，可靠传输的问题，由其上层处理。
然而对于无线链路，由于其容易受到干扰，误码率比较高，因此要求数据链路层必须向上层提供可靠传输服务。
需要说明的是比特差错只是传输差错中的一种。从整个计算机网络体系结构来看，传输差错还包括分组丢失，分组失序以及分组重复。请注意，此处我们将帧的称呼改为了分组，这意味着传输差错不仅仅局限于数据链路层的比特差错。
我们来举例说明，主机 H6 给主机 H2 发送的分组，到达了路由器 R5，由于此时 R5 的输入队列快满了，R5 根据自己的分组丢弃策略，将该分组丢弃，这是一种分组丢失的情况。
再来看分组失序的例子，主机 H6 依次给主机 H2 发送了三个分组，但他们并未按照发送顺序依次到达 H2，也就是说最先发送的分组未必最先到达。
再来看分组重复的例子，主机 H6 给主机 H2 发送的分组，由于某些原因在网络中滞留了没有及时到达 H2，这可能造成 H6 对该分组的超时重发，重发的分组到达 H2 一段时间后滞留在网络中的分组又到达了 H2，这就会造成分组重复的传输差错。
分组丢失，分组失序以及分组重复这些传输差错，一般不会出现在数据链路层，而会出现在其上层。因此可靠传输服务并不仅局限于数据链路层，其他各层均可选择实现可靠传输服务。
例如这是 TCP/IP 的 4 层体系结构，如果网络接口层使用的是 802.11 无线局域网，那么其数据链路层要求实现可靠传输，如果网络接口层使用的是以太网，那么其数据链路层不要求实现可靠传输，网际层中的 IP 协议向其上层提供的是无连接不可靠的传输服务。
运输层中的 TCP 协议向其上层提供的是面向连接的可靠传输服务，而 UDP 协议向其上层提供的是无连接不可靠的传输服务，最后需要提醒大家注意，可靠传输的实现比较复杂，开销也就比较大，是否使用可靠传输取决于应用需求。
小结：
# 3.4.2 可靠传输的实现机制 — 停止-等待协议
从本节课开始，我们将用几次课的时间来介绍三种可靠传输的实现机制，它们是停止等待协议 SW，回退 N 帧协议 GBN，选择重传协议 SR。
需要提醒大家注意的是，这三种可靠传输实现机制的基本原理，并不仅限于数据链路层，可以应用到计算机网络体系结构的各层协议中，希望同学们在学习时不要把思维局限在数据链路层，而应放眼于整个网络体系结构。
本节课我们介绍停止等待协议，如图所示，收发双方基于互联网进行通信，而不是局限在一条点对点的数据链路，纵坐标为时间：
- 发送方给接收方发送数据分组，接收方收到后对其进行差错检测
- 若没有误码，则接受该数据分组，并给发送方发送确认分组，简称为 ACK
- 发送方收到对所发送数据分组的确认分组后，才能发送下一个数据分组
- 假设这个数据分组在传输过程中出现了误码，接收方收到后对其进行差错检测，发现了误码，则丢弃该数据分组，并给发送方发送否认分组，简称为 NAK
- 发送方收到对所发送数据分组的否认分组后，就知道了之前自己所发送的数据分组出现了差错，而被接收方拒绝，于是立刻重传该数据分组
- 因此发送方每发送完一个数据分组后，并不能立刻将该数据分组从缓存中删除，只有在收到帧对该数据分组的确认，分组后才能将其从缓存中删除
- 看来每发送完一个数据分组后，就停止发送下一个数据分组，等待来自接收方的确认分组或否认分组。若收到确认分组，则可继续发送下一个数据分组
- 若收到否认分组，则重发之前发送的数据分组，这样就要实现了发送方发送什么，接收方最终都能收到什么，也就是所谓的可靠传输
但实际情况远比我们想象的要复杂。
来看这种情况，发送方给接收方发送数据分组，然而该数据分组在传输过程中丢失了，需要说明的是对于数据链路层点对点信道而言，不太容易出现这种情况，但对于多个网络，通过多个路由器互联的复杂互联网环境而言，这种情况是会经常出现的。
对于这种情况，接收方既然收不到数据分组，那么也就不会无缘无故的发送确认或否认分组。如果不采取其他措施，发送方就会一直处于等待接收方确认或否认分组的状态。为了解决该问题，可以在发送方发送完一个数据分组时，启动一个超时计时器。若到了超时计时器所设置的重传时间，而发送方仍收不到接收方的确认或否认分组，则重传原来的数据分组，这就叫做超时重传。一般可将重穿时间选为略大于从发送方到接收方的平均往返时间。
如图所示发送方超时重传之前所发送的数据分组，接收方正确接收重传的数据分组后，给发送方发送确认分组，发送方收到确认分组后，发送下一个数据分组，接收方正确接收该数据分组后，给发送方发送确认分组，到目前为止，貌似基于停止等待，使用确认或否认分组，再加上超时重传的手段，就可以实现可靠传输了。
但请大家再深入的思考一下，是否还会出现目前这些手段不足以应对实现可靠传输的其他情况？
来看这种情况：既然发送方发送的数据分组可能丢失，那么接收方发送的确认或否认分组就也有可能丢失。例如发送方发送了一个数据分组，接收方正确接收该数据分组后，给发送方发送确认分组，但该确认分组在传输过程中丢失了，这必然会造成发送方对之前所发送数据分组的超时重传，假设重传的数据分组也正确到达了接收方。那么现在问题来了，接收方如何判断该数据分组是否是一个重复的分组？
为了避免分组重复这种传输错误，必须给每个数据分组带上序号。例如该数据分组的序号为 0，对于停止等待协议，由于每发送一个数据分组，就进行停止等待，只要保证每发送一个新的数据分组，其序号与上次发送的数据分组的序号不同就可以了。因此用一个比特来编号就够了。即序号 0 和 1，这样根据数据分组的序号，接收方就可以判断出该数据分组是否是重复的，接收方丢弃重复的数据分组，并给发送方发送帧对该数据分组的确认分组，以免发送方对该数据分组的再次超时重传。
发送方收到帧对 0 号数据分组的确认分组，就可以发送下一个数据分组了，其序号为 1，接收方正确收到 1 号数据分组后，给发送方发送确认分组，我们通过确认分组丢失的情况，引出了给数据分组编号的问题。请大家思考一下，既然数据分组需要编号，那么确认分组是否也需要编号？
来看这种情况，发送方 发送 0 号数据分组，接收方正确接收后，给发送方发送确认分组，由于某些原因，该确认分组迟到了，这必然会导致发送方对 0 号数据分组的超时重传。
在重传的 0 号数据分组的传输过程中，发送方收到了迟到的确认分组，于是发送一号数据分组，接收方收到重传的零号数据分组后，发现这是一个重复的数据分组，将其丢弃，并针对该数据分组给发送方发送确认分组，以免发送方再次超时重传该数据分组。
现在问题来了，我们可以非常清楚的看到，这是一个对 0 号数据分组的重复确认，但是发送方又如何知道呢？如果不采取其他措施的话，发送方会误认为这是对 1 号数据分组的确认，如果对确认分组也进行编号，就可以使发送方避免这种误判。
如图所示该确认分组的序号为 0，发送方通过确认分组的序号，知道这是一个重复的确认分组，忽略即可。接收方正确接受一号数据分组后，给发送方发送帧对该数据分组的确认，分组其序号为一，发送方收到该确认分组后，发送下一个数据分组，序号为 0。
请注意该数据分组与之前序号为 0 的数据分组，不是同一个数据分组，我们用给确认分组编号的方法，解决了确认迟到所导致的重复确认的问题。需要说明的是对于数据链路层的点对点信道，往返时间比较固定，不会出现确认迟到的情况。因此如果只在数据链路层实现停止等待协议，可以不用给确认分组编号。
接下来我们对停止等待协议的一些注意事项，进行一下小结：
- 接收端检测到数据分组有误码时，将其丢弃，并等待发送方的超时重传。但对于误码率较高的点对点链路，为使发送方尽早重传，也可给发送方发送否认分组
- 为了让接收方能够判断所收到的数据分组是否是重复的，需要给数据分组编号，由于停止等待协议的停等特性，只需一个比特编号就够了，即序号 0 和 1
- 为了让发送方能够判断所收到的确认分组是否是重复的，需要给确认分组编号，所用比特数量与数据分组编号所用比特数量一样，数据链路层一般不会出现确认分组迟到的情况，因此在数据链路层实现停止等待协议，可以不用给确认分组编号
- 超时计时器设置的重装时间应仔细选择，一般可将重装时间选为略大于从发送方到接收方的平均往返时间
- 在数据链路层点对点的往返时间比较确定，重传时间比较好设定。然而在运输层，由于端到端往返时间非常不确定，设置合适的重装时间有时并不容易，我们将在第 5 章有关 TCP 协议的课程中详细讨论该问题
接下来我们来看看停止等待协议的信道利用率。如图所示，横坐标为时间。
为了简单起见，假设收发双方之间是一条直通的信道，发送方发送完一个数据分组后，就要停止发送，并等待接收方对该数据分组的确认。当收到确认分组后可以发送下一个数据分组。如此反复进行
这一段时间是发送方发送数据分组所耗费的发送时延 TD，这一段时间是收发双方之间的往返时间 RTT，这一段时间是接收方发送确认分组所耗费的发送时延 TA，途中忽略了接收方对数据分组的处理时延，以及发送方对确认分组的处理时延，这是使用停止等待协议的发送方，从发送一个数据分组开始，到可以发送下一个数据分组为止，所经历的总时间，因为仅仅是在时间 TD 内才用来传送有用的数据，也就是数据分组。因此信道的利用 U 可以用下式来计算：
TA 一般都远小于 TD，可以忽略，当 RTT 远大于 TD 时，信道利用率会非常低。
我们来举例说明，假设信道长度为 2000 公里，数据分组长度为 1500 字节，发送速率为 10 兆比特每秒，忽略 TA，因为 TA 一般都远小于 TD，可以计算出信道利用率约为 5.66%，这是数据分组的发送时延 TD，这是往返时间 RTT。
如果将发送速率提高到 100 兆比特每秒，则可计算出信道利用率仅为 0.6%。这是数据分组的发送时延 TD，这是往返时间 RTT：
可以看出当往返时延 RTT 远大于数据帧发送时延 TD 时，例如使用卫星链路，信道利用率非常低，若出现重传，则对于传送有用的数据信息来说，信道利用率还要降低。为了克服停止等待协议信道利用率很低的缺点，就产生了另外两种协议及后退 N 帧协议 GBN，和选择重穿协议 SRr。
最后我们来做一道有关停止等待协议的练习题。这是计算机专业考研全国统考计算机网络部 分2018 年的题 36，答案是 D。
我们一起来分析该题，根据提议可以画出停止等待协议的示意图，这一段是数据帧的发送时延，这一段是数据帧的最后一比特信号，从主机甲传播到主机乙所耗费的传播实验，也就是信号在两主机之间的单程传播实验。
同理，这一段也是单程传播时延，停止等待协议的信道利用率等于数据帧的发送时延除以数据帧发送时延加端到端往返时延，也就是两倍的单程传播时延，设数据帧长度为 x 个比特，将其与题目所给的相关已知量代入上式可得解得 x 等于 800 比特
像停止等待协议这种通过确认和重传机制实现的可靠传输协议，常称为自动请求重传协议 ARQ，意思是重传的请求是自动进行的，因为不需要接收方显示的请求，发送方重传某个出错的分组。
小结：
# 3.4.3 回退 N 帧协议
在上节课中我们介绍了停止等待协议，如图所示，发送方每发送完一个数据分组，就要停止发送，并等待接收方的确认分组。当收到接收方的确认分组后，才能发送下一个数据分组，如此反复进行。
从图中可以看出，每发送完一个数据分组，至少要等待一个收发双方之间的往返时间。当往返时间较大时，例如卫星链路，停止等待协议的信道利用率很低，若出现超时重传，则信道利用率更低。
如图所示，如果发送方在收到接收方的确认分组之前，可以连续发送多个数据分组，则可大大提高信道利用率。这是一种流水线式的传输。就本例而言，同等条件下，在相同的时间内，使用停止等待协议的发送方，只能发送一个数据分组，而采用流水线传输的发送方可以发送 5 个数据分组。
本节课我们介绍回退 N 帧协议，该协议在流水线传输的基础上，利用发送窗口，来限制发送方可连续发送分组的个数。我们来举例说明，假设采用三个比特给分组编序号，因此序号的取值范围是 0~7，如图所示，这是收发双方各自的分组序号，当序号增加到 7，下一个序号又从 0 开始，发送方要维持一个发送窗口，序号落在发送窗口内的数据分组，可被连续发送，而不必等收到接收方的相应确认分组后再发送。发送窗口的尺寸即为 WT。对于本例其取值范围是大于 1，小于等于 23-1，其中的 3是构成分组序号的比特数量，本例取 WT 的值为 5，如果 WT 的值取为一，则是停止等待协议。如果 WT 的值超过取值范围的上限，则会造成严重的错误，我们之后会举例详细说明。
如图所示序号落在发送窗口内的这 5 个数据分组，可以连续发送，而序号落在发送窗口外的数据分组，不允许发送。
接收窗口的尺寸即为 WR。对于回退 n 帧协议，其取值只能为一，这一点与停止等待协议是相同的。如图所示序号落在接收窗口内的数据分组，允许接收，而序号落在接收窗口外的数据分组不允许接收。
我们首先来看最简单的情况，也就是无差错的情况：
- 发送方将序号落在发送窗口内的 0~4 号数据分组，依次连续发送出去
- 他们经过互联网的传输，正确到达了接收方，也就是没有出现乱序和误码
- 接收方按序接收他们。每接收一个接收窗口就向前滑动一个位置，并给发送方发送帧对所接收分组的确认分组。
- 0~4 号确认分组，经过互联网的传输，正确到达了发送方，每接收一个发送窗口就向前滑动一个位置，这样就有新的序号落入了发送窗口，发送方可以将收到确认的数据分组，从缓存中删除了
- 而接收方可以择机将已接收的数据分组交付上层处理
接下来我们来看累积确认的概念，使用回退 N 帧协议的接收方可以采用累积确认的方式，也就是说接收方不一定要对收到的数据分组逐个发送确认，而是可以在收到几个数据分组后，对按序到达的最后一个数据分组发送确认，ACKn 表示序号为 n 及以前的所有数据分组都已正确接收了。
我们来举例说明累计确认。发送方将序号落在发送窗口内的 0~4 号数据分组，依次连续发送出去，他们经过互联网的传输，正确到达了接收方按序接收他们。当接收完 0 号和 1 号数据分组后，给发送方发送了一个累积确认 ack1，当接收完 2~4 号数据分组后，又给发送方发送了一个累计确认 ACK4，假设 ack1 在传输过程中丢失了，而 ack4 正确到达了发送方，发送方接收 ACK4 后就知道了，序号为 4 及之前的数据分组已被接收方正确接收了，于是将发送窗口向前滑动 5 个位置，这样就有新的序号落入了发送窗口，发送方可以将收到确认的数据分组从缓存中删除了，而接收方可以择机将已接收的数据分组交付上层处理。
从本例可以看出，使用累计确认的其中一个优点，就是即使确认分组丢失，发送方也可能不必重传。例如本例 ACK1 丢失了，但并没有造成一号数据分组的超时重传
使用累计确认还有其他好处。比如可以减小接收方的开销，减少对网络资源的占用等。当然了使用累计确认也有缺点，那就是不能向发送方及时反映出接收方已经正确接收的、数据分组的信息。
接下来我们来看出现差错的情况，发送方将序号落在发送窗口内的这 5 个数据分组，依次连续发送出去，他们经过互联网的传输到达了接收方，假设他们在传输过程中受到了干扰，其中 5 号数据分组出现了误码，接收方通过数据分组中的检错码发现了错误，于是丢弃该数据分组。
而后续到达的这 4 个数据分组的序号与接收窗口中的序号不匹配，接收方同样也不能接受它们，将它们丢弃，并对之前按序接收的最后一个数据分组进行确认，也就是发送 ACK4，每丢弃一个数据分组，就发送一个 ACK4，这 4 个 ACK4 经过互联网的传输到达了接收方，发送方之前就接收过 ACK4，当收到这些重复的 ACK4 时，就知道了之前所发送的数据分组出现了差错，于是可以不等超时计时器超时就立刻开始重传。
至于收到几个重复确认，就立刻重传，由具体实现来决定。在本例中，假设收到这 4 个重复的确认，并不会触发发送方立刻重传。一段时间后，超时计时器出现超时，发送方将发送窗口内已发送过的这些数据分组全部重传。在本例中，尽管序号为 6701 的数据分组，之前已经正确的到达接收方，但由于 5 号数据分组误码不被接受，他们也受到牵连而不被接受。
发送方还要重传这些数据分组，这就是所谓的 Go Back-n 也就是回退 N 帧。可见当通信线路质量不好时，回推 N 帧协议的信道利用率并不比停止等待协议高。
接下来我们来看看，如果发送窗口的尺寸，WT 超过其取值范围的上限会出现什么情况？
对于本例，采用三个比特给分组编序号，wt 的最大值为 23 - 1，也就是 7，我们故意超过该上限将 WT 取值为 8，发送方将序号落在发送窗口内的 0~7 号这 8 个数据分组依次连续发送出去，他们经过互联网的传输，正确到达了接收方，接收方按序正确接收他们号，给发送方发回累计确认 ACK7。
假设 ack7 在传输过程中丢失了，这将导致发送方的超时重传重传的 0~7 号数据分组到达接收方。现在问题来了，接收方根据当前接收窗口内的序号，会对这 8 个数据分组按序接收，但是接收方之前已经接收过这 8 个数据分组了，现在是在重复接收，也就是说接收方无法分辨新旧分组，进而会产生分组重复这种传输差错，因此发送窗口的尺寸不能超过其上限。
接下来我们对回退 n 帧协议的工作原理进行一下小结。发送窗口尺寸 wt 的取值范围是大于 1，小于等于 2 的 n 次-1，其中 n 是构成分组序号的比特数量，若 WT 等于 1 则变回了停止等待协议，若 WT>2 的 n 次-1，则会造成接收方无法分辨新旧数据分组的问题。
接收方的接收窗口尺寸 WR 只能等于 1，因此接收方只能按序接收数据分组，发送方可在未收到接收方确认分组的情况下，将序号落在发送窗口内的多个数据分组全部发送出去，接收方只接受序号落在接收窗口内，且无误码的数据分组，并且将接收窗口向前滑动一个位置。与此同时，给发送方发回相应的确认分组。
为了减少开销，接收方不一定每收到一个按需到达且无误码的数据分组，就给发送方发回一个确认分组，而是可以在连续收到好几个按需到达，且无误码的数据分组后，才针对最后一个数据分组发送确认分组，这要成为累计确认，或者可以在自己有数据分组要发送时，才对之前按序接收，无码的数据分组进行捎带确认。
接收方收到未按需到达的数据分组，除丢弃外，还要对最近按序接收的数据分组进行确认。
发送方只有收到对已发送数据分组的确认时，发送窗口才能向前相应滑动。发送方收到多个重复确认时，可在重传计时器超时前尽早开始重传，由具体实现决定，
发送方发送窗口内，某个已发送的数据分组产生超时重发时，其后续在发送窗口内且已发送的数据分组也必须全部重传，这就是回退 N 帧协议名称的由来。
接下来我们来做一个有关回退 N 帧协议的练习，这是计算机专业考研全国统考计算机网络部分 2009 年的题 35。答案是 C
题目所给发送方只收到 023 号帧的确认，这就表明接收方正确接收了 0~3 号帧，并帧对他们中的每一个发送了确认帧，只不过帧对一号帧的确认帧丢失了，这是题目中的陷阱，但又没有相应的选项，所以迷惑性并不是很大。截止到计时器超时，发送方只收到了帧对 023 号帧的确认，而发送方之前已经发送了 0~7 号帧，因此应该从 4 号帧开始重传，即重传之前已经发送过的 4567 号帧，共计重传 4 个帧。
我们再来画个示意图，以便更容易理解该题。假设这是帧可用的序号，这是发送窗口，发送方将序号落在发送窗口内的 0~7 号数据帧依次发送出去，当收到帧对 0 号数据帧的确认帧 ACK0 时，发送窗口向前移动一个位置。若收到帧对 1 号数据帧的确认帧 ACK1 时发送窗口也会向前移动一个位置，只不过 ACK1 在传输过程中丢失了，当收到帧对 2 号数据帧的确认帧 ACK2，发送窗口向前移动两个位置，将序号 1 和 2全部移出发送窗口。
当收到帧对三号数据帧的确认帧 ACK3，发送窗口向前移动一个位置，之后发送方出现了超时，将发送窗口内已发送但未收到确认 的4567 号数据帧依次重传。
本节课的内容小结如下：
回退 N 帧协议在流水线传输的基础上，利用发送窗口来限制发送方连续发送数据分组的数量，是一种连续 ARQ 协议。
在协议的工作过程中，发送窗口和接收窗口不断向前滑动，因此这类协议要称为滑动窗口协议。
由于回退 N 帧协议的特性，当通信线路质量不好时，其信道利用率并不比停止等待协议高。下节课我们将介绍选择重传协议，他是对回退 N 帧协议的改进。
# 3.4.4 选择重传协议
在上节课中我们介绍了回退 N 帧协议，回退 N 帧协议的接收窗口尺寸 WR 只能等于 1，因此接收方只能按需接收正确到达的数据分组，一个数据分组的误码，就会导致其后续多个数据分组不能被接收方按序接收而丢弃，尽管他们没有误码，这必然会造成发送方对这些数据分组的超时重传，显然这是对通信资源的极大浪费。
为了进一步提高性能，可设法只重传出现误码的数据分组。因此接收窗口的尺寸 w 不应再等于 1，而应大于 1，以便接收方先收下失序到达，但无误码，并且序号落在接受窗口内的那些数据分组，等到所缺分组收齐后，再一并送交上层。这就是本节课所要介绍的选择重传协议。需要注意的是选择重传协议，为了使发送方仅重传出现差错的数据分组，接收方不能再采用累积确认，而需要对每个正确接收到的数据分组进行逐一确认。
下面我们来举例说明，选择重传协议的工作原理。假设采用三个比特给分组编序号，因此序号的取值范围是 0~7，如图所示这是发送方的分组序号，这是接收方的分组序号。
当序号增加到 7 是，下一个序号又从 0 开始，发送窗口的尺寸，WT 的取值范围是大于 1，小于等于 2 的 3 次方-1 次。其中的三是构成分组序号的比特数量，本例取 WT 的值为 4，如图所示序号落在发送窗口内的这 4 个数据分组可以连续发送，而序号落在发送窗口外的数据分组不允许发送。
接收窗口的尺寸 WR 的取值，一般情况下可以发送窗口的尺寸 WT 的取值相同，在本例中其值为 4，如图所示序号落在接收窗口内的这 4 个数据分组允许接收，而序号落在接收窗口外的数据分组不允许接收
发送方将序号落在发送窗口内的这 4 个数据分组，依次连续发送出去，他们经过互联网的传输陆续到达接收方，但其中的 2 号数据分组丢失了，只要序号落入接收窗口内，且无误码的数据分组，接收方都会接收。接收方接收 0 号和 1 号数据分组，并发送 0 号和 1 号确认分组，接收窗口向前滑动两个位置，这样就有 4 和 5 这两个新的序号落入接收窗口，接收方接收 3 号数据分组，并发送 3 号确认分组，但接收窗口不能向前滑动，因为 3 号数据分组是未按需到达的数据分组，这些确认分组经过互联网的传输，陆续到达发送方，每按序收到 1 个确认分组，发送窗口就向前滑动 1 个位置：
发送方接收 0 号和 1 号确认分组，发送窗口向前滑动两个位置，这样就有 4 和 5 这两个新的序号落入发送窗口，发送方将序号落入发送窗口的 4 号和 5 号数据分组发送出去，发送方现在可以将已经收到确认的 0 号和 1 号数据分组从发送缓存中删除了，而接收方可择机将以按需接收的 0 号和 1 号数据分组交付上层处理：
发送方接收三号确认分组，但发送窗口不能向前滑动，因为这是一个未按需到达的确认分组，发送方还未收到他之前的 2 号确认分组，不过需要记录 3 号数据分组已收到确认，这样该数据分组就不会超时重发。4 号和 5 号数据分组到达接收方，接受方接受他们，并发送 4 号和 5 号确认分组，但接收窗口不能向前滑动，因为他们是未按需到达的数据分组，接收方还未收到他们之前的 2 号数据分组。
假设在 4 号和 5 号确认分组的传输过程中，发送方帧对 2 号数据分组的重传计时器超时了，发送方重传 23 号数据分组，4 号和 5 号确认分组陆续到达发送方，发送方接收他们，但发送窗口不能向前滑动，因为他们是未按时到达的确认分组，发送方还未收到他们之前的 2 号确认分组，不过需要记录 4 号和 5 号数据分组已收到确认，这样他们就不会超时重发。
发送方之前重传的二号数据分组到达接收方，接收方接收该数据分组，并发送 2 号确认分组，接受窗口现在可以向前滑动 4 个位置，这样就有 6701 这 4 个新的序号落入接收窗口。
2 号确认分组,经过互联网的传输，到达发送方，发送方接收该确认分组，发送窗口现在可以向前滑动 4 个位置，这样就有 6701 这 4 个新的序号落入发送窗口，发送方现在就可以继续将这 4 个序号的数据分组依次发送出去了。
接下来我们再来讨论一下，选择重传协议的发送窗口和接收窗口的尺寸问题。发送方的发送窗口尺寸 WT 必须满足大于 1 小于等于 2 的 n-1 次，其中 n是构成分组序号的比特数量。若 WT 等于 1 则与停止等待协议相同，若 WT > 2 的 n 减一次，则会造成接收方无法分辨新旧数据分组的问题。
接收方的接收窗口尺寸，WR 必须满足大于一，小于等于 WT 。若 WR 等于 1 则与回退 N 帧协议相同，若 WR 大于 WT，则没有意义。
下面我们就来看看，如果发送窗口和接收窗口的尺寸超过了他们的取值范围，会出现什么样的情况？我们还是采用三个比特给分组编序号，即序号 0~7，发送窗口的尺寸，wt 取最大值，接收窗口的尺寸 WR 也取最大值，也就是 wt 等于 WR=2 的 3-1 次 = 4。假设我们故意将发送窗口尺寸 WT 设置为 5，相应的将接收窗口尺寸 WR 也设置为 5，看看会出现什么情况。
发送方将序号落入发送窗口内的 0~4 号这 5 个数据分组依次发送出去，他们经过互联网的传输，依次到达接收方，接收方接收他们，并发送 0~4 号确认分组，接收窗口向前滑动 5 个位置，这样就有 56701 这 5 个新的序号落入接收窗口：
这些确认分组经过互联网的传输，陆续到达发送方，但其中的 0 号确认分组丢失了，发送方接收 1~4 号确认分组，并记录 1~4 号数据分组已收到确认，发送窗口不能向前移动。
一段时间后，0 号数据分组的重传计时器超时了，发送方重传 0 号数据分组，该数据分组经过互联网的传输到达接收方，其序号 0 落在接收窗口内，接收方会接收它，但是接收方先前已经正确接收过该数据分组了，如果现在还要接收，那就会出现分组重复这种传输差错。也就是说如果发送窗口和接收窗口的尺寸超过了取值范围，就会使接收方无法分辨新旧数据分组，进而出现分组重复这种传输差错。
接下来我们对选择重传协议的工作原理进行一下小结：
- 这是我们刚刚举例说明过的，发送窗口和接收窗口的尺寸问题，就不再赘述了。发送方可在未收到接收方确认分组的情况下，将序号落在发送窗口内的多个数据分组全部发送出去，接收方可接收未按需到达，但没有误码，并且序号落在接收窗口内的数据分组。
- 为了使发送方仅重传出现差错的分组，接收方不能再采用累计确认，而需要对每个正确接收到的数据分组进行逐一确认。
- 接收方只有在按序接收数据分组后，接收窗口才能向前相应滑动。
- 发送方只有按序收到，对已发送数据分组的确认分组时，发送窗口才能向前相应滑动。
- 若收到未按需到达的确认分组，应对其进行记录，以防止其相应数据分组的超时重发，但发送窗口不能向前滑动。
接下来我们来做一个有关选择重传协议的练习。这是计算机专业考研全国统考计算机网络部分 2011 年的题 35：
答案是选项 B，与回退 N 帧协议不同，选择重穿协议，不支持累计确认，接收方每接收一个数据帧，就会发回相应的确认帧，题目所给收到一号帧的确认，而 0 号和 2 号帧依次超时，因此需要重传 0 号和 2 号帧。至于发送方已发送的三号数据帧，题目并未给出它的任何其他线索，因此无需考虑 3 号帧。
我们再来画个示意图，以便更容易理解该题。假设这是帧可用的序号，这是发送窗口，发送方将序号落在发送窗口内的 0~3 号数据帧依次发送出去之后，收到了 1 号帧的确认，而 0 号和 2 号帧的重传计时器超时，因此需要重传的就是 0 号和 2 号这两个帧。
本节课的内容小结如下：
