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

计算机网络学习9:可靠传输

作者头像
程序员洲洲
发布2024-06-07 09:19:05
680
发布2024-06-07 09:19:05
举报
文章被收录于专栏:项目文章

如果提供不可靠传输,丢弃有误码的帧即可,其他不做。 如果提供可靠传输服务,就需要告诉发送端重发。

可靠传输的实现比较复杂。即如果接收端发送给发送端的通知帧(告诉有收到误码)也出现了误码,那该怎么办呢。

注意,此处将 帧 的称呼 改为了 分组。

停止-等待协议 SW

发送方发送完分组之后,不能立马从缓存中把分组删除,而是要等到ack才能删除。 这样就实现了可靠传输,但是还是会有一些特殊情况。

如果一开始就没发送失败。

也有可能就是接收方 发送的确认分组或者否认分组都没有发送出去。

所以需要对确认分组也需要加一个序号。

对于点对点,可以不用给确认分组进行编号。数据链路层一般不会出现ACK分组迟到的问题。

一般 TA远小于TD,可以 忽略不计。

例如使用卫星电路,会造成利用率很低。

练习题:

退回N帧协议GBN:Go-Back-N

GBN就是在流水线传输的基础上 利用发送窗口来限制发送方可以连续发送分组的个数

WT是 发送窗口的范围,如果WT=1 那么就是停止等待协议SW。

如果超过了上限,就会造成严重的错误。

无差错情况: 将0-4号依次发送出去,没有出现乱序和误码,然后按序接收,然后接收窗口向下滑动。发送方接收一个ack,就向前移动一个位置,这样就可以删除发送过的缓存了。

可以进行进一步的优化,就是累计确认。

在这里插入图片描述
在这里插入图片描述

假设ack1传输丢失了,发送方也会知道ack4之前的也正确接收了。发送窗口往前滑动5个位置。接收方可以将已经接收的数据交付给上层处理了。

优点:确认分组丢失,发送方也可以不必重传。还可以减少网络资源的占用。

缺点:不能及时反映正确接收的信息。

如果发送56701,而接收方第一个5就已经有差错了,不接收,那么后面的也同样不会接受。将他们丢失,并且重新发送一个ack4。每丢弃一个分组,就会发送一个ack4.

当发送方接收到了重复的ack4后,就可以立刻重传了。

如果WT超过范围,(成功接收到的信息没有发到发送方。)就会造成接收方无法辨析是不是接受过。

退回N帧协议在流水线传输的基础上利用发送窗口来限制发送方连续发送数据分组的数量,是一种连续ARQ协议。

在协议的工作过程中发送窗口和接收窗口不断的向前滑动,因此这类协议又称为滑动窗口协议。

由于其特性,当通信线路的质量不好时,信道利用率并不比停止-等待协议高。

选择重传协议-SR:selective request

回顾GBN的优缺点:

  • 选择重传协议为了使得发送方仅仅重传出现差错的分组,接收方不能再采用累积确认!而需要对每个正确接收到数据分组进行逐一确认!

假设采用三个比特来给分组编序号,就是0-7。

发送方接收到了3之后,并不能使发送窗口向前滑动,因为是未按序到达的窗口。

接收方在没收到2号,那么就接收窗口就不会向前滑动的。

如果在上述过程中,发送方的重传计时器超时了,那么就会重传2号,同时发送方也会记录45号已经成功发送了。

这个时候接收窗口重新收到了2,那么就会往前移动4个。 发送窗口接收到了2,也会向前移动4个。

如果超过了窗口的尺寸范围会怎么样呢?

会一样出现接收方无法分辨新旧的数据分组。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2024-06-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

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

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 停止-等待协议 SW
  • 退回N帧协议GBN:Go-Back-N
  • 选择重传协议-SR:selective request
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档