数据链路层流量控制
流量控制：防止发送端发送和接收端接收速度不匹配造成传输错误
传输层和数据链路层均有流量控制，但是控制手法不一样
传输层：端到端，接收端向发送端发送一个窗口公告。告诉发送端目前我能接收多少
数据链路层：点到点，接收端接收不下的就不回复确认（ack），让发送端自己重传
这里不会造成发送端(发送主机)性能浪费，在传输之前传输层已经限制好了，这里控制是为控制没有传输层的中间节点(交换机)之间的流量
相关 协议
涉及协议较多分批写
停止等待协议（单窗口的滑动窗口协议）
优点：最简单的控制协议
缺点：但是性能较弱,信道利用率低
控制方法：
发送方：发送一个帧
接收方：接收到帧后返回改帧的ack
发送方：接收到ack后发送下一个帧
差错控制：
-
发送帧丢失：发送端发送一个帧后会为该帧启动一个超时计时器，帧丢失后，接收端接收不到自然不会发送ack，发送端等待一个计时器后仍没有收到ack就自动重发
Z4swLV.png -
ack丢失：接收端收到发送端的帧后发送ack 中途丢失，等待一个超时计时器后同帧丢失一样自动重发
Z4sBZT.png -
ack迟到：在超时计时器之后接收到了上一个ack，因为该数据已经重发发送端会直接忽略， 接收端接收到重发数据会重新发送一个ack并丢弃重复数据
Z4sDdU.png
注意：
- 发完一个帧后，必须保留它的副本。优化错误重发性能
- 数据帧和确认帧必须编号。便于差错控制
- 超时计时器设计应比最大RTT更长一些
滑动窗口协议
滑动窗口协议是基于停止等待协议的优化版本
停止等待协议性能是因为需要等待ack之后才能发送下一个帧，在传送的很长时间内信道一直在等待状态
滑动窗口则利用缓冲思想，允许连续发送(未收到ack之前)多个帧，以加强信道利用
窗口：其实就是缓冲帧的一个容器，将处理好的帧发送到缓冲到窗口，可以发送时就可以直接发送，借此优化性能。一个帧对应一个窗口。
后退N帧协议(GBN)
GBN是滑动窗口中的一种，其中 发送窗口 > 1 ,接收窗口=1 因发送错误后需要退回到最后正确连续帧位置开始重发，故而得名。
控制方法：
发送端：在将发送窗口内的数据连续发送
接收端：收到一个之后向接收端发送累计确认的ack
发送端：收到ack后窗口后移发送后面的数据
累计确认：累计确认允许接收端一段时间内发送一次ack而不是每一个帧都需要发送ack。该确认方式确认代表其前面的帧都以正确接收到
eg:发送端发送了编号 0,1,2,3,4,5 的帧，等待一段时间后（超过3的超时计时器）累计收到的ack对应 0,2 帧，则证明已经成功 0,1,2 均已经成功接收，3 传输错误。并且哪怕 4,5两个帧接收成功后也不会返回 4,5 的ack会一直等待从 3 开始重传
差错控制：
发送帧丢失、ack丢失、ack迟到等处理方法基本和停等协议相同，不同的是采用累计确认恢复的方式，当前面的帧出错之后后面帧无论是否发送成功都要重传
优点：信道利用率高（利用窗口有增加发送端占用，并且减少ack回复次数）
缺点：累计确认使得该方法只接收正确顺序的帧，而不接受乱序的帧，错误重传浪费严重
发送窗口大小问题
窗口理论上是越多性能越好，但是窗口不能无限大，n比特编码最大只能2^(n-1)个窗口，否则会造成帧无法区分（本质就是留了一个比特区分两组帧）
选择重传协议(SR)
SR协议可以说是GBN的plus版本，在GBN的基础上改回每一个帧都要确认的机制，解决了累计确认只接收顺序帧的弊端只需要重发错误帧。
其中 发送窗口 > 1 ,接收窗口 > 1 ,接收窗口 > 发送窗口 (建议接 收窗口 = 发送窗口 接收窗口少了溢出多了浪费).
控制方法：
发送端：将窗口内的数据连续发送
接收端：收到一个帧就将该帧缓存到窗口中并回复一个ack
接收端：接收到顺序帧后将数据提交给上层并接收窗口后移（若接收到的帧不是连续的顺序帧时接收窗口不移动）
发送端：接收到顺序帧的ack后发送窗口后移（同理发送窗口接收到的ack不连续也不移动）
差错控制：
发送帧丢失、ack丢失、ack迟到三类处理方式仍然和停等协议相同，不同的是SR向上层提交的是多个连续帧，停等只提交一个帧（不连续的帧要等接收或重传完成后才会提交）
发送窗口大小问题
同GBN一样，发送窗口和接收窗口都不能无限多，且不说缓存容量问题，当两组帧同时发送时会造成无法区分，大小上限仍然是2^(n-1)个窗口（本质就是留了一个比特写组号）
窗口大小这里留一张截图，方便理解
假设窗口大小都为3（图中编号到了3是借4窗口的图，正常应编号到2,但是不妨碍理解）
左边是错误重发，第一组的0帧ack丢失了
右边是正常收发
若是2比特编码，她本身编码只够区分帧本身，而无法区分最后接收的0帧时哪一个组（啥时候应该发来的）
若采用3比特编码就能区分开了
三种协议对比：
停等协议：单线程的傻子，简单不易出错，但是效率极其低下
GBN：假的多线程(接收端太坑啦)，接收端是情种，只等待自己哪一个帧，丢弃了后来的帧
SR：多线程，接收端有收藏癖，等待集齐一套召唤神龙（提交给上层这只神龙……）
