前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >计算机网络-可靠传输的实现机制

计算机网络-可靠传输的实现机制

原创
作者头像
Karos
发布2023-11-16 20:54:50
3520
发布2023-11-16 20:54:50
举报
文章被收录于专栏:MyBlog-Karos

可靠传输的实现机制

停止-等待协议(SW)

参考3.4.1 可靠传输的基本概念哔哩哔哩bilibili

发送方(S)必须等待接收方(R)回应后才能发送下一个请求。

会出现一下几种情况:

  • S发送给R,R接收到,R回复,over
image-20231116204637775
image-20231116204637775
  • S发送给R,R没有接收到,S超时重传,这里会发生两种情况
    • 网络中断,R没有收到,消息丢失,超时重传
    image-20231116204659718
    image-20231116204659718
    • 网络延迟,R收到了,但是这个时候S又发送了一份,那么R就收到了重复数据,那么这种问题如何解决?
    image-20231116205243147
    image-20231116205243147

    S给R发送的请求可以在请求头中新增一个序列号(Seq),如果Seq重复,那么我们R端可以丢弃,并且做出响应,这个时候如果之前网络延迟导致消息迟到的响应也到达了S,那么我们为了能够让S也知道消息重复,所以我们给响应头增加了个(ACK)]

    image-20231116205300388
    image-20231116205300388

回退N帧协议(GBN Go-Back-N)

和停止等待协议类似,不过我们采用分组发送,对于每个分组,我们称之为窗口

在S端,窗口尺寸我们成为W_T,在R端,窗口尺寸成为W_R

如果我们采用n个比特来对分组进行编号,那么W_T的取值为:1 \lt W_T \le {2^n-1},W_R的取值为:W_R = 1

假设我们是3个比特位,W_T=5,如图:

image-20231115204535400
image-20231115204535400

滑动窗口

拿正常(无差错)情况来说,S依次连续发送0-4给R,正确到达R,没有乱序和误码,每接收一个接受窗口就向前滑动一个位置,并给S返回接收分组的确认分组,S每收到一个回复,发送窗口也向前移动一个位置,收到确认数据的分组就可以删除

累积确认

R不一定要对接收到的数据分组逐个发送确认,而是在收到几个数据分组后,对按需到达后的最后一个分组进行确认,ACK_N表示序号为n及以前的所有数据分组都已正确接收了。

优点和产生的问题:

如果分为两组累计,.e.g:

\{0,1\}\ and\ \{2,3,4\}

如果ACK_1丢失了,而ACK_4又返回给了S,那么S就会认为ACK_4以及之前的数据分组都被R正确接受了,滑动窗口前行,旧分组从cache中删除

这里可以说说累计确认的优点之一:即使确认分组丢失,S也可能不必重传,同时减少了R的开销和网络资源占用

但是R不能向S及时反应出R已经正确接受的数据分组信息

如果有差错的情况呢?

比如{5,6,7,0,1},如果5出现了误码,那么丢弃5,而后续代码的序号和接收方窗口的序号不匹配,所以全部丢弃,这个时候依然返回ACK_4,所以S还需要重传,这就是Go-Back-N

可以看到,如果通信线路质量不好,回退N帧信道利用率并不比SW协议高

如果W_T的大小超过了取值上限

如果超限,如果发送超时重传,此时无法分辨新、旧分组

image-20231116152755952
image-20231116152755952

选择重传协议(SR)

  • GBN协议设置接受窗口尺寸W_R只能为1,因此R只能按需接受正确到达的数据分组
  • 一个数据分组的无码,会导致多组数据超时重传,对通信资源产生极大的浪费 那么能否直冲穿出现误码的分组呢? 因此,接收窗口的尺寸W_R不应该等于1,而应该大于1,编译u接收方先收下失序到达但无无码并且序号落在接收窗口内的那些数据分组,等到所缺分组收齐后再一并送交上层。 这就是选择重传协议(SR) 因为SR协议为了使S仅重传出现差错的分组,接收方不能再采用累计确认,而需要对每个争取接受到的数据分组进行逐一确认!
image-20231116164524731
image-20231116164524731

针对分组丢失

image-20231116165250302
image-20231116165250302

在这种情况下,R中0和1已经接收了,所以返回0和1的确认信息,并发送确认分组,R窗口向前滑动两个位置。

image-20231116165427390
image-20231116165427390

R接受3号分组,并确认,但是R窗口不能向前滑动,因未按序到达

此时将\{0,1,3\}的确认分组信息返回给S

image-20231116170034354
image-20231116170034354

S处理完0和1后,窗口滑动

image-20231116170121614
image-20231116170121614

此时将\{4,5\}发送给R,\{0,1\}从cache中删除,R将\{0,1\}交付上层处理

image-20231116170320348
image-20231116170320348

S接受3号确认分组,但是S窗口不能向前滑动,同时记录3号分组已收到确认,避免出现超时重传

image-20231116170438867
image-20231116170438867

\{4,5\}到达R,R发送确认分组,但是R窗口不能滑动

S收到后也不能滑动,但是要记录

如果此时S针对2号数据分组的重传定时器超时了,那么进行重传

image-20231116170714062
image-20231116170714062

2到达后,理所应当

image-20231116171054967
image-20231116171054967
image-20231116175026183
image-20231116175026183

S & R 窗口超限引发的问题

最大值

$$ W_T = W_R = 2^{(3-1)}=4 $$

如果我们设置为5的话呢?

image-20231116203230186
image-20231116203230186

如果在返回确认分组的时候ACK_0丢失,1-4记录为已收到,发动窗口不能移动,等待超时重传

image-20231116203707111
image-20231116203707111

所以这里又发生了问题

所以说这里取值为2^{n-1}是为了避免最后n个出现差错

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 可靠传输的实现机制
  • 停止-等待协议(SW)
  • 回退N帧协议(GBN Go-Back-N)
    • 滑动窗口
      • 累积确认
        • 优点和产生的问题:
    • 选择重传协议(SR)
      • 针对分组丢失
        • S & R 窗口超限引发的问题
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档