408计算机网络笔记——3.4流量控制与可靠传输机制

3.4 流量控制与可靠传输机制

流量控制方法
停止-等待协议:每发送完一个帧就停止发送,等待对方的确认,在收到确认后再发送下一个帧

为什么要有停止-等待协议?
除了比特差错,信道还会出现丢包问题。(丢包:物理线路故障,设备故障,病毒攻击,路由信息错误等原因导致数据包丢失)同时也是为了实现流量控制。

研究停止-等待协议的前提?
虽然现在常用全双工通信方式,但为了方便做题,仅考虑一方发送数据,一方接接收数据的情况;因为是在考虑可靠传输原理,所以不讨论数据在哪一个层次上传输;“停止-等待”就是每发送完一个分组就停止发送等待确认,在收到确认后再发送下一个分组。

停止-等待协议无差错情况
在这里插入图片描述
停止-等待协议有差错情况
1.数据帧丢失或检测到帧出错
RTT:往返传播时延
重传的就是刚刚那个没有收到确认的帧
在这里插入图片描述
注意:

  1. 发完一个帧后必须保留它的副本,这样就可以解决数据丢失的问题
  2. 数据帧与确认帧必须编号:如果连续出现了相同编号的数据帧,发送端发生了重传;如果出现连续相同编号的确认帧,就说明接收方收到了相同重复的确认帧,编号就可以解决帧的丢失与重复等问题

2.ACK丢失(确认帧丢失)
在这里插入图片描述
3.ACK迟到
在这里插入图片描述
对于迟到了的ACK0,发送方直接丢弃

停止-等待协议的性能分析:
简单,但是信道利用率太低
在这里插入图片描述
TD:发送时延
RTT:往返时延
TA:确认时延
确认帧只含控制信息,不含数据,所以比特数比数据帧要少一些,线条宽度反映发送时延
信道利用率U=T_D/(T_D+RTT+T_A )
信道利用率是指发送方在一个发送周期内,有效地发送数据所需要的时间占整个发送周期的比率
U=(L/C)/T
T是发送周期(从开始发送数据到收到第一个确认帧为止),T内发送L比特数据,C是发送方数据传输率

信道吞吐率=信道利用率*发送方的发送速率
在这里插入图片描述
RTT=30×2ms,TA=TD=L/C=L/4,L的单位为bit

滑动窗口协议:收到一个确认,接受窗口前进1格,发送窗口也前进1格
发送窗口:在发送端维持一段连续的可以发送的信号
接收窗口: 在接收端维持一段连续的可以接收的信号

在这里插入图片描述在链路层的发送窗口与接受窗口大小都是固定的

可靠传输:发送端发送什么数据,接收端就接受什么数据
流量控制:控制发送速率,使接收方有足够的缓冲空间来接收每一个帧
滑动窗口就是在解决流量控制

3.4.3选择重传协议(SR)
GBN协议的弊端
累积确认:批量重传
可不可以只重传出错的帧?
解决办法:设置单个确认窗口,同时加大接收窗口,设置接收缓存,缓存乱序到达的帧

SR接收方要做的事情:
来者不拒(窗口内的帧)
SR接收方将确认一个正确接收的帧而不管其是否按序。失序的帧将被缓存,并返回给发送方一个该帧的确认帧(收谁确认谁),直到所有帧(即序号更小的帧)皆被收到为止,这时才可以将一批帧按序交付给上层,然后向前移动滑动窗口

在这里插入图片描述
等到2号帧的确认帧到达,发送端窗口就可以继续向前移动了

在这里插入图片描述
WT是发送窗口,WR是接收窗口,n是用多少个比特来编帧的序号,此处有0,1,2,3这4个编号,n=2。
2019 王道考研 计算机网络_哔哩哔哩_bilibili 22:06(该例题对应位置)

GBN协议(后退N帧协议)
在这里插入图片描述
在GBN协议中,发送窗口可以有多个,接收窗口只有一个,而在SR协议中,接收窗口可以有多个;停止等待协议的发送窗口和接收窗口个数都是1

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值