（一）流量控制与可靠传输机制简介
一、数据链路层的流量控制
较高的发送速度和较低的接受能力的不匹配，会造成传输出错，因此流量控制也是数据链路层的一项重要工作。
注：数据链路层的流量控制是点对点的，而传输层的流量控制是端到端的
数据链路层流量控制手段：接收方收不下就不回复确认
传输层流量控制手段：接收端给发送端一个窗口公告。
二、流量控制的方法简介
（1）停止-等待协议（相当于发送窗口是1的滑动窗口协议）
每发送完一个帧就停止发送，等待对方的确认，在收到确认后再发送下一个帧。
（2）滑动窗口协议
1.后退N帧协议（GBN）
2.选择重传协议（SR）
注：每一个小格都代表一个帧，可发现序号有重复，这是因为帧序号是可以重复利用的。
代表发送了发送窗口的第一个帧。0号帧。
代表在接收了0号帧后，接收方再向发送方发送确认帧，并且接收窗口向右移动
发送方在接收到确认帧后，发送窗口向右移动。
注：如果这时候没有收到确认帧，它会继续将发送窗口的帧发送出去，直到接收到确认帧，才会向右移动一格。
注：
停止等待协议：发送窗口大小=1，接收窗口大小=1
后退N帧协议（GBN）：发送窗口大小>1，接收窗口大小=1
选择重传协议（SR）：发送窗口大小>1，接收窗口大小>1
注：链路层的滑动窗口大小是固定值，在传输层的窗口大小可能改变
（3）可靠传输、滑动窗口、流量控制
可靠传输：发送端发啥，接收端收啥
流量控制：控制发送速率，使接收方有足够的缓冲空间来接收每一个帧
滑动窗口解决：流量控制（收不下就不给确认，想发也发不了） 可靠传输（发送方自动重传）
（二）停止—等待协议
（1）为什么要有停止等待协议
除了比特出差错，底层信道还会出现丢包问题。为了实现流量控制。
注：丢包：物理线路故障、设备故障、病毒攻击、路由信息错误等原因，会导致数据包的丢失。
（2）停止等待协议的前提
虽然现在常用全双工通信方式，但是为了讨论问题的方便，仅考虑一方发送数据（发送方），一方接收数据（接收方）。
因为是在讨论可靠传输的原理，所以并不考虑数据是在哪一个层次上传送的。
停止等待就是每发送完一个分组就停止发送，等待对方确认，再收到确认后在发送下一个分组。
（3）停等协议有几种应用情况
1.无差错情况
2.有差错情况
数据帧丢失或检测到帧出错
注：1.发送完一个帧后，必须保留它的副本。这样如果发生帧丢失，就可以重传。
2.数据帧和确认帧必须编号
ACK（确认帧）丢失
发送方由于没收到确认帧，所以依旧会重传，但是接收方就相当于重复接收了两次。所以接收方会丢弃重复的1帧，重传确认1帧
ACK迟到
发送方对于迟到的确认帧不做处理，直接丢弃
（4）性能分析
方式简单，但是信道利用率太低
（5）信道利用率&信道吞吐率
信道利用率：发送放在一个发送周期内，有效的发送数据所需要的时间占整个发送周期的比率。
引言
停等协议的弊端：发送方每发送一个帧，就处于等待状态，只有当接收到了确认帧才继续发送。发送效率很低，浪费时间和资源。
那么我们可以连续发送三个帧码，这又被称为流水线技术。
注：1.必须增加序号的范围，即连续发送的序号要不同
2.发送方需要缓存多个分组，来为重传做准备。比停止等待的缓存要大一点
针对以上两个解决方案，我们有了后退N帧协议（GBN）和选择重传协议（SR）
（三）后退N帧协议（GBN）
（1）GBN中的滑动窗口机制
发送窗口：发送方维持一组连续的允许发送的序号
接收窗口：接收方维持一组连续的允许就收帧的序号
后退N帧协议的滑动窗口机制是：GBN的发送窗口内的帧可以连续发送，被发送的帧同时会保存副本，防止需要重传情况的发生。当接收方接收到帧后，接收窗口就会向右滑动，同时发送确认帧。发送方在收到确认帧的时候，发送窗口就会向右滑动。
（2）发送方必须响应的三件事
上层（网络层）调用（网络层如果让链路层给他发送数据，链路层应当在GBN协议中做些什么）
上层要发送数据的时候，发送方首先检查发送窗口是否已满，如果未满，则产生一个帧并将其发送，如果窗口已满，发送方只需将数据返回给上层，暗示上层窗口已满。上层等一会再发送。（实际实现中，发送方可以缓存这些数据，窗口不满时再发送帧）
收到一个ACK
GBN协议中，对n号帧的确认采用累计确认的方式。标明接收方已经收到n号帧和它之前的全部帧（也就是说，不需要逐个发确认帧）
超时事件
协议的名字为后退N帧，来源于出现丢失和时延过长帧时发送方的行为。就像在停等协议中一样，定时器将再次用于恢复数据帧或确认帧的丢失。如果出现超时，发送方重传所有已发送但未被确认的帧。
（3）接收方要做的事
正确接收
如果正确收到n号帧，并且按序，那么接收方为n帧发送一个ACK，并将该帧的数据部分交付给上层
接收错误
其余情况都丢弃帧，并为最近按序接收的帧重新发送ACK。接收方无需缓存任何失序帧，只需要维护一个信息：expectedseqnum（下一个按序接收的帧序号）
（4）运行中GBN协议（一个例子）
假设发送窗口尺寸为4
（5）发送窗口的大小上限
Q：窗口的长度可以无限吗？
A:若采用n个比特对帧编号，那么发送窗口的尺寸WT应满足：1≤WT≤2^n-1。因为发送窗口尺寸过大，就会使得接收方无法区别新帧和旧帧。（旧帧全部丢失，要重传的时候全部都要重传，那么没有重复编号的话就会无法分辨新帧和旧帧）
（6）GBN的重点总结（考研）
1.累计确认
2.接收方只按顺序接收帧，不按序无情丢弃
3.确认序列最大的，按序到达的帧
比如接收到124，那么接收方丢弃4，发会序号为2的确认帧
4.发送窗口最大为2^n-1，接收窗口大小为1
（7）GBN的性能分析
优点：因连续发送数据帧而提高了信道利用率
缺点：（累计确认导致的批量重传现象）在重传时必须把原来已经正确传送的数据帧重传，使传送效率降低
引言
那么有没有办法只重传出错的帧呢？
解决办法：设置单个确认，同时加大接收窗口，设置接收缓存，缓存乱序到达的帧
（四）选择重传协议（SR：Selective Repeat）
（1）SR中的滑动窗口机制
SR中的滑动窗口：
设发送窗口和接收窗口的大小都是4.那么此时发送窗口里的帧的类型分为这几种。
与GBN协议不同的是，此时的发送窗口可能不都是发完等待确认或者还能发送的的帧，可能还有发完也确认过了的帧，只不过在它前面的帧还没有被确认，所以滑动窗口还不能被滑动。
同样的，接收方除了等待接收的，还有可能存在已经收到了，但他前面有帧还没有收到，所以接受滑动窗口还不能移动。
（2）发送方必须响应的三件事
上层调用
从上层收到数据后，SR发送方检查下一个可用于该帧的序号，如果序号位于发送窗口内，则发送数据帧。否则就像GBN一样，要么将数据缓存，要么返回给上层之后再传输。
收到一个ACK
如果收到ACK，假如该帧序号在窗口内，则SR发送方将那个被确认的帧标记为已接受。如果该帧序号是窗口的下界（最左边第一个窗口对应的序号），则窗口向前移动到具有最小序号的未确认帧处。如果窗口移动了，并且有序号在窗口内的为发送帧，则发送这些帧。
例：这里，2.4是发送了，有副本，但没有收到确认的帧，3是发送了也受到确认的帧，5是等待发送的帧。
如果此时2受到了确认。那么发送窗口会直接滑到4567，并开始发送窗口中还未发送的帧
超时事件
每一个帧都有一个自己的定时器，一个超时事件发生后只重传一个帧。
（3）接收方要做的事
窗口内的帧来者不拒（在接收窗口的帧）
SR接收方将确认一个正确接收的帧而不管其是否按顺序。失序的帧将被缓存。并返回给发送方一个该帧的确认帧（收谁确认谁），直到所有帧（即序号更小的帧）都被收到为止，这时才可以将一批帧按序交付给上层，然后向前移动滑动窗口。
例：此时5是准备接收的，6是已经确认且发送确认帧的，如果这时候接收到了7号帧，那么会将他缓存起来。等到接收到5号帧的时候再一起按顺序交付给网络层，且移动滑动窗口。
其余情况
如果收到了窗口序号外（小于窗口下界）的帧，就返回一个ACK。其他情况，就忽略该帧。
（4）运行中的SR
（5）窗口大小上限
注：发送窗口最好等于接收窗口（大了会产生溢出现象，小了没有意义），窗口过大会导致可能辨别不出是旧帧还是新帧。
WTmax=WRmax=2^（n-1），n是表示帧号用的比特数
（6）SR重点总结
1.对数据帧逐一确认，收一个确认一个
2.只重传出错的帧
3.接收方有缓存
4.WTmax=WRmax=2^（n-1）
