标签：发送 窗口 协议 确认 计算机网络 3.4 发送窗口 接收 408
3.4 流量控制与可靠传输机制
流量控制方法
停止-等待协议：每发送完一个帧就停止发送，等待对方的确认，在收到确认后再发送下一个帧
为什么要有停止-等待协议？
除了比特差错，信道还会出现丢包问题。（丢包：物理线路故障，设备故障，病毒攻击，路由信息错误等原因导致数据包丢失）同时也是为了实现流量控制。
研究停止-等待协议的前提？
虽然现在常用全双工通信方式，但为了方便做题，仅考虑一方发送数据，一方接接收数据的情况；因为是在考虑可靠传输原理，所以不讨论数据在哪一个层次上传输；“停止-等待”就是每发送完一个分组就停止发送等待确认，在收到确认后再发送下一个分组。
停止-等待协议无差错情况
停止-等待协议有差错情况
1.数据帧丢失或检测到帧出错
RTT：往返传播时延
重传的就是刚刚那个没有收到确认的帧
注意：
- 发完一个帧后必须保留它的副本，这样就可以解决数据丢失的问题
- 数据帧与确认帧必须编号：如果连续出现了相同编号的数据帧，发送端发生了重传；如果出现连续相同编号的确认帧，就说明接收方收到了相同重复的确认帧，编号就可以解决帧的丢失与重复等问题
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
标签：发送,窗口,协议,确认,计算机网络,3.4,发送窗口,接收,408 来源： https://blog.csdn.net/m0_50734673/article/details/117932798
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。