网站建设广告管理,品牌建设整体体系包括什么,模板网站优化,建站宝盒源码计算机网络#xff1a;数据链路层 - 可靠传输协议 可靠传输概念停止-等待协议 SW回退N帧协议 GBN选择重传协议 SR 可靠传输概念
如下所示#xff0c;帧在传输过程中受到干扰#xff0c;产生了误码。接收方的数据链路层#xff0c;通过真伪中的真检验序列 FCS 字段的值数据链路层 - 可靠传输协议 可靠传输概念停止-等待协议 SW回退N帧协议 GBN选择重传协议 SR 可靠传输概念
如下所示帧在传输过程中受到干扰产生了误码。接收方的数据链路层通过真伪中的真检验序列 FCS 字段的值也就是检错码可以检测出帧中出现了比特差错。那么接下来该如何处理呢 这取决于数据链路层向其上层提供的服务类型
如果提供的是不可靠传输服务则仅仅丢弃有误码的帧其他什么也不做。如果提供的是可靠传输服务那就还要想办法实现发送端发送什么接收端就收到什么
一般情况下有线链路的雾码率比较低为了减小开销并不要求数据链路层向上提供可靠传输服务即使出现了物码可靠传输的问题由其上层处理。
然而对于无线链路由于其容易受到干扰雾码率比较高因此要求数据链路层必须向上层提供可靠传输服务。
最后要注意的是可靠传输服务并不仅局限于数据链路层其他各层均可选择实现可靠传输服务。
接下来本博客将讲解三种可靠传输协议这三种可靠传输实现机制的基本原理并不仅限于数据链路层可以应用到计算机网络体系结构的各层协议中。 停止-等待协议 SW
如图所示收发双方基于互联网进行通信纵坐标为时间发送方给接收方发送数据分组 接收方收到后对其进行差错检测若没有误码则接受该数据分组并给发送方发送确认。分组简称为ACK发送方收到对所发送数据分组的确认分组后才能发送下一个数据分组。
假设这个数据分组在传输过程中出现了误码接收方收到后对其进行差错检测发现了误码则丢弃该数据分组并给发送方发送否认分组简称为NAK 发送方收到对所发送数据分组的否认NAK分组后就知道了之前自己所发送的数据分组出现了差错而被接收方拒绝于是立刻重传该数据分组。因此发送方每发送完一个数据分组后并不能立刻将该数据分组从缓存中删除只有在收到针对该数据分组的确认分组后才能将其从缓存中删除。 发送方每发送完一个数据分组后就停止发送下一个数据分组等待来自接收方的确认分组或否认分组。 若收到确认分组则可继续发送下一个数据分组若收到否认分组则重发之前发送的那个数据分组。 这样就实现了发送方发送什么接收方最终都能收到什么也就是所谓的可靠传输。
但实际情况远比我们想象的要复杂来看这种情况发送方给接收方发送数据分组然而该数据分组在传输过程中丢失了。 需要说明的是对于数据链路层点对点信道而言不太容易出现这种情况但对于多个网络通过多个路由器互联的复杂互联网环境而言这种情况是会经常出现的。
对于这种情况接收方既然收不到数据分组那么也就不会无缘无故的发送确认或否认分组。如果不采取其他措施发送方就会一直处于等待接收方确认或否认分组的状态。为了解决该问题可以在发送方发送完一个数据分组时启动一个超时计时器。若到了超时计时器所设置的重传时间而发送方仍收不到接收方的确认或否认分组则重传原来的数据分组这就叫做超时重传。一般可将重传时间选为略大于从发送方到接收方的平均往返时间。
如图所示发送方超时重传之前所发送的数据分组 接收方正确接收重传的数据分组后给发送方发送确认分组。发送方收到确认分组后发送下一个数据分组。接收方正确接收该数据分组后给发送方发送确认分组。到目前为止貌似基于停止等待使用确认或否人分组再加上超时重传的手段就可以实现可靠传输了。
再来看这种情况既然发送方发送的数据分组可能丢失那么接收方发送的确认或否认分组就也有可能丢失。例如发送方发送了一个数据分组接收方正确接收该数据分组后给发送方发送确认分组但该确认分组在传输过程中丢失了。这必然会造成发送方对之前所发送数据分组的超时重传 假设这个重传的数据分组也正确到达了接收方那么现在问题来了接收方如何判断该数据分组是否是一个重复的分组呢
为了避免分组重复这种传输错误必须给每个数据分组带上序号。对于停止等待协议由于每发送一个数据分组就进行停止等待只要保证每发送一个新的数据分组其序号与上次发送的数据分组的序号不同就可以了。因此用一个比特来编号就够了记序号 0 和 1。
这样根据数据分组的序号接收方就可以判断出该数据分组是否是重复的。接收方丢弃重复的数据分组并给发送方发送针对该数据分组的确认分组以免发送方对该数据分组的再次超时重传。 第一次接受方接收到了DATA0然后往回传递ACK表示接收到了该分组。发送方没有受到ACK触发超时重传。当接收方第二次接收到DATA0就知道这和上一次是同一个分组把它丢弃再重传一次ACK。当发送方收到ACK就发送和上一次编号不一样的分组DATA1接收方收到DATA1发现和上一次不一样于是正常接收该分组。
我们通过确认分组丢失的情况引出了给数据分组编号的问题请大家思考一下既然数据分组需要编号那么确认分组是否也需要编号呢
来看这种情况 发送方发送 0 号数据分组接收方正确接收后给发送方发送确认分组由于某些原因该确认分组迟到了这必然会导致发送方对 0 号数据分组的超时重传。 在重传的 0 号数据分组的传输过程中发送方收到了迟到的确认分组于是发送 1 号数据分组。接收方收到重传的 0 号数据分组后发现这是一个重复的数据分组将其丢弃并针对该数据分组给发送方发送确认分组以免发送方再次超时重传该数据分组。现在问题来了我们可以非常清楚的看到这是一个对 0 号数据分组的重复确认但是发送方又如何知道这个ACK是 0 号数据的而不是 1 号数据的呢
如果不采取其他措施的话发送方会误认为这是对 1 号数据分组的确认。如果对确认分组也进行编号就可以使发送方避免这种误判。如图所示 该确认分组的序号为0发送方通过确认分组的序号知道这是一个重复的确认分组忽略即可。这个过程叫做确认迟到。
我们用给确认分组编号的方法解决了确认迟到所导致的重复确认的问题。需要说明的是对于数据链路层的点对点信道往返时间比较固定不会出现确认迟到的情况。因此如果只在数据链路层实现停止等待协议可以不用给确认分组编号。
接下来我们对停止等待协议的一些注意事项进行一下小结
接收端检测到数据分组有误码时将其丢弃并等待发送方的超时重传。为了让接收方能够判断所收到的数据分组是否是重复的需要给数据分组编号。由于停止等待协议的停等特性只需一个比特编号就够了。记序号 0 和一。为了让发送方能够判断所收到的确认分组是否是重复的需要给确认分组编号。数据链路层一般不会出现确认分组迟到的情况因此在数据链路层实现停止-等待协议可以不用给确认分组编号。
接下来我们来看看停止等待协议的信道利用率发送方发送完一个数据分组后就停止发送并等待接收方对该数据分组的确认。当收到确认分组后可以发送下一个数据分组 T D T_{D} TD发送方发送数据分组所耗费的发送时延RTT收发双方之间的往返时间 T A T_{A} TA 接收方发送确认分组所耗费的发送时延
途中忽略了接收方对数据分组的处理时延以及发送方对确认分组的处理时延。
总时间为 T D T_{D} TD RTT T A T_{A} TA因此信道的利用率 U 可以用下式来计算 信道利用率 U T D T D R T T T A \text { 信道利用率 } U\frac{T_{D}}{T_{D}R T TT_{A}} 信道利用率 UTDRTTTATD T A T_{A} TA一般都远小于 T D T_{D} TD可以忽略当 RTT 远大于 T D T_{D} TD时信道利用率会非常低。为了克服停止等待协议信道利用率很低的缺点就产生了另外两种协议即后退N帧协议 GBN 和 选择重传协议。 回退N帧协议 GBN
我们刚介绍了停止等待协议发送方每发送完一个数据分组就要停止发送并等待接收方的确认分组。当收到接收方的确认分组后才能发送下一个数据分组如此反复进行。可以看出发送方每发送完一个数据分组就至少要等待一个收发双方之间的往返时间。当往返时间较大时例如卫星链路。停止等待协议的信道利用率很低。若出现超时重传则信道利用率更低。如图所示如果发送方在收到接收方的确认分组之前可以连续发送多个数据分组则可大大提高信道利用率 回退N帧协议该协议在以上传输的基础上利用发送窗口来限制发送方可连续发送分组的个数。我们来举例说明假设采用 3 个比特给分组编序号因此序号的取值范围是 0- 7。如图所示
这是收发双方各自的分组序号。当序号增加到7下一个序号又从 0 开始。
发送方要维持一个发送窗口序号落在发送窗口内的数据分组可被连续发送而不必等收到接收方的相应确认分组后再发送 发送窗口的尺寸记为 W T W_{T} WT 。对于本例其取值范围是[0, 7]。本例取 W T W_{T} WT 的值为5。如果 W T W_{T} WT 的值取为 1则是停止等待协议。如果 W T W_{T} WT 的值超过取值范围的上限则会造成严重的错误我们之后会举例详细说明。
序号落在发送窗口内的数据分组可以连续发送而序号落在发送窗口外的数据分组不允许发送。
接收窗口的尺寸记为 W R W_{R} WR 对于回退N帧协议其取值只能为 1这一点与停止等待协议是相同的。如图所示 序号落在接收窗口内的这个数据分组允许接收而序号落在接收窗口外的数据分组不允许接收。
我们首先来看最简单的情况也就是无差错的情况发送方将序号落在发送窗口内的 0- 4 号数据分组依次连续发送出去 他们经过互联网的传输正确到达了接收方也就是没有出现乱序和误码。接收方按序接收他们每接收一个数据接收窗口就向前滑动一个位置并给发送方发送接收分组的确认分组 发送方每接收一个确认分组发送窗口就向前滑动一个位置这样就有新的序号落入了发送窗口。发送方可以将收到确认的数据分组从缓存中删除了 接下来我们来看累积确认的概念。使用回退N帧协议的接收方可以采用累积确认的方式也就是说接收方不一定要对收到的数据分组逐个发送确认而是可以在收到几个数据分组后对按序到达的最后一个数据分组发送确认ACKn 表示序号为 n 及以前的所有数据分组都已正确接收了。
我们来举例说明累计确认
发送方将序号落在发送窗口内的 0- 4 号数据分组依次连续发送出去。他们经过互联网的传输正确到达了接收方按序接收。
当接收完 0 号和 1 号数据分组后给发送方发送了一个累计确认ACK 1。当接收完 2- 4 号数据分组后又给发送方发送了一个累计确认ACK4。假设ACK 1在传输过程中丢失了而 ACK 4正确到达了发送方 发送方接收ACK 4后就知道了序号为 4 及之前的数据分组已被接收方正确接收了于是将发送窗口向前滑动 5 个位置。这样就有新的序号落入了发送窗口。从本例可以看出使用累计确认的其中一个优点就是即使确认分组丢失发送方也可能不必重传。例如本例中aACK 1丢失了但并没有造成 1 号数据分组的超时重传。使用累计确认还有其他好处例如可以减小接收方的开销减少对网络资源的占用等。
接下来我们来看出现差错的情况发送方将序号落在发送窗口内的这 5 个数据[5,6,7,0,1]分组依次连续发送出去。他们经过互联网的传输到达了接收方假设他们在传输过程中受到了干扰其中 5 号数据分组出现了误码 接收方通过数据分组中的检错码发现了错误于是丢弃该数据分组。而后续到达的这四个数据分组的序号与接收窗口中的序号不匹配接收方同样也不能接受他们将他们丢弃 然后对之前按序接收的最后一个数据分组进行确认也就是发送ACK4每丢弃一个数据分组就发送一个ACK4 这四个ACK4经过互联网的传输到达了发送方。发送方之前就接收过ACK4当收到这些重复的ACK4 时就知道了之前所发送的数据分组出现了差错于是可以不等超时计时器超时就立刻开始重传至于收到几个重复确认就立刻重传由具体实现来决定。
在本例中尽管序号为 6701 的数据分组之前已经正确的到达接收方但由于 5 号数据分组误码不被接受他们也受到牵连而不被接受发送方还要重传这些数据分组这就是所谓的 go back N也就是回退N帧。可见当通信线路质量不好时回退N帧协议的信道利用率并不比停止等待协议高。
为了减少开销接收方不一定每收到一个按序到达且无误码的数据分组就给发送方发回一个确认分组而是可以在连续收到好几个按序到达且无误码的数据分组后才针对最后一个数据分组发送确认分组这称为累积确认。 选择重传协议 SR
刚刚我们介绍了回退N帧协议。回退N帧协议的接收窗口尺寸 W T W_{T} WT 能等于一因此接收方只能按序接收正确到达的数据分组。一个数据分组的误码就会导致其后续多个数据分组不能被接收方按序接收而丢弃尽管他们没有误码。这必然会造成发送方对这些数据分组的超时重传显然这是对通信资源的极大浪费。
为了进一步提高性能可设法只重传出现误码的数据分组。因此接收窗口的尺寸 W R W_{R} WR不应再等于一而应大于一以便接收方先收下失序到达但无误码并且序号落在接收窗口内的那些数据分组等到所缺分组收齐后再一并送交上层。这就是本节课所要介绍的选择重传协议。
需要注意的是选择重传协议为了使发送方仅重传出现差错的数据分组接收方不能再采用累积确认而需要对每个正确接收到的数据分组进行逐一确认。
下面我们来举例说明选择重传协议的工作原理。假设采用 3 个比特给分组编序号因此序号的取值范围是 0- 7。如图所示 发送窗口的尺寸 W T W_{T} WT的取值范围是[1,7]本例取 W T W_{T} WT的值为4。序号落在发送窗口内的这 4 个数据分组可以连续发送。而序号落在发送窗口外的数据分组不允许发送接收窗口的尺寸 W R W_{R} WR的取值一般情况下可与发送窗口的尺寸 W T W_{T} WT的取值相同在本例中其值为4。序号落在接收窗口内的这 4 个数据分组允许接收而序号落在接收窗口外的数据分组不允许接收。
发送方将序号落在发送窗口内的这四个数据分组依次连续发送出去。他们经过互联网的传输陆续到达接收方但其中的 2 号数据分组丢失了 只要序号落入接收窗口内且无误码的数据分组接收方都会接收 先接受0 号和 1 号数据分组并发送 0 号和 1 号确认分组接收窗口向前滑动两个位置 这样就有 4 和 5 这两个新的序号落入接收窗口。接收方接收 3 号数据分组并发送 3 号确认分组 但接收窗口不能向前滑动因为 3 号数据分组是未按需到达的数据分组。
发送方每按序收到一个确认分组发送窗口就向前滑动一个位置。发送方接收 0 号和 1 号确认分组发送窗口向前滑动两个位置这样就有 4 和 5 这两个新的序号落入发送窗口发送方将序号落入发送窗口的 4 号和 5 号数据分组发送出去 发送方接收 3 号确认分组但发送窗口不能向前滑动因为这是一个未按序到达的确认分组。发送方还未收到 3 之前的 2 号确认分组。不过需要记录 3 号数据分组已收到确认这样该数据分组就不会超时重发 4 号和 5 号数据分组到达接收方接收他们并发送 4 号和 5 号确认分组但接收窗口不能向前滑动因为他们是未按序到达的数据分组接收方还未收到他们之前的 2 号数据分组 假设在 4 号和 5 号确认分组的传输过程中发送方针对 2 号数据分组的重传计时器超时了发送方重传 2 号数据分组 4 号和 5 号确认分组陆续到达发送方接收他们但发送窗口不能向前滑动因为他们是未按序到达的确认分组发送方还未收到他们之前的 2 号确认分组不过需要记录 4 号和 5 号数据。分组已收到确认这样他们就不会超时重发 发送方之前重传的 2 号数据。分组到达接收方接收方接收该数据分组并发送 2 号确认。分组接受窗口现在可以向前滑动四个位置这样就有 6701 这四个新的序号落入接收窗口 2 号确认分组经过互联网的传输到达发送方接收该确认分组发送窗口现在可以向前滑动四个位置这样就有 6701 这四个新的序号落入发送窗口。发送方现在就可以继续将这四个序号的数据分组依次发送出去了 可见选择重传协议是对回退N帧协议的优化将接收窗口扩大哪怕数据不是按照顺序发送的也可以接收。这样就可以避免对一些已经正常传递的数据的重发提升效率。
