一、Utopian Simplex Protocol（乌托邦）
最简单的协议，假设信道是单工的，无差错的，且接收方有无限的缓冲区。
10年积累的
成都网站建设、网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先
做网站后付款的网站建设流程，更有
汉源免费网站建设让你可以放心的选择与我们合作。
所以发送方就可以一直发
问题：现实情况比这个恶劣的多。
二、Simplex Stop-and-Wait Protocol for an Error-Free Channel（简单停等）
假设：单工信道，无差错，接收方是有限的缓冲区。
发送方发送数据，然后停下来等待接收方的ack，收到ack之后再发数据。这样接收方就可以不发ack来控制发送的速度。
问题：
1、如果信道不是无差错的，那么接收方算了CRC之后发现不对，就会丢弃包，不发ack，这时发送方的timer超时，就会重传。
2、如果数据帧丢了，那么发送方就会收不到ack，timer超时重传。
3、如果ack丢了，那么同样发送方就会收不到ack，timer超时重传。可是这就会有一个问题
发送方重传的是一样的东西，这样接收方就会收到同样的帧，可接收方不知道是同样的帧，这时就需要给数据帧加序号。
可是这样还没完，接收方收到重复的帧后，接受方发现是重复的序号，就丢掉了，不发ack，可发送方不知道啊，发送方觉得是这一帧又没发到，timer到了就又重传。所以这时就需要给ack帧加序号，加上这两个序号，就是第三个协议。
三、Stop-and-Wait ARQ（停等ARQ）
就是用0和1给数据和ack编号，这样就解决了重复数据帧和延迟ack的问题。
四、One-Bit Sliding Window Protocol
窗口大小为1的滑动窗口协议，其实就是停等，只不过这个是双工的，刚才的停等是单工的信道。
工作流程如下：
1、发收双方窗口大小都为1，初始窗口状态都一样，发送方准备发送序号为0的数据，接收方等待接收序号为0的数据，
2、发送方发送数据，把该数据标记为已发送待确认
3、接收方收到数据，crc确认后将数据交给上层，发送ack给发送方，并同时把窗口向右滑动，表示下一个待收的数据序号为1
4、发送方收到ack，将窗口向右滑动，准备发送下一个序号为1的数据，如此反复。
问题：这样对于一些带宽时延积较大的信道，会导致低效，比如卫星信道，数据的发送时延很短，但是传播时延很长，发送方花了很短的时间将数据发送出去，剩下很大一部分时间都在等待数据发给接收方，然后接收方回ack，时间主要都用到这两次传播时延上了，效率很低。
五、Protocol Using Go Back N
还是滑动窗口，这次发送窗口有很多，但是接收窗口还是一个，这个协议采用了累计ack的方法。
1、正常情况
看这个正常情况的例子，发送窗口大小是3，按顺序发0、1、2帧，接收方一开始窗口在0那，收到0号帧之后，由于是累计确认，所以不发ack，把窗口向右滑，等待1号帧，收到1号帧后，滑动窗口，回一个ack1，表示0和1号帧都收到了，发送方收到这个之后，就明白了，就把窗口向右滑动两个。这里有一个问题，那就是累计确认的话，什么时候选择回ack呢，如果收到的帧一直都是对的，迟迟不回，发送方岂不是会超时。
2、丢数据
看这个例子，发送方发送0、1、2，接收方收到0、1后回了ack1，发送方滑动两个窗口，接着发3号帧，可是这时2号帧丢了，接收方收到3号帧后，发现这不是我要的啊，我要的是2号帧，他就丢弃，并且回一个ack1，表示并没有受到2号帧。 这是有一个问题，那就是只有收到帧校验和对的时候，才会回ack，例如这里3号帧如果校验和不对，那就不会回ack1，因为校验和不对时，序号就没有意义了，有可能是错的。然后继续，发送方没有收到ack2和ack3，2、3号帧就会依次超时，并重传。
3、ack丢失
考虑一个极端情况，发送方发送0、1、2号帧，接收方都正确收到并滑动了窗口，并且回了ack，可是ack全丢了，这时接收方窗口在等3号帧，发送方0号帧超时重传，接收方收到后发现不是我要的帧，就会丢掉，回一个我正在等的帧序号的前一个序号，比如这里等的是3号帧，回的ack就是ack2。这时发送方收到ack2后，就知道前三个帧都收到了，就会往右滑三次窗口。
4、窗口大小问题
窗口大小和序号的二进制位数有关，对于n比特位的序号来说，发送窗口和接收窗口的大小的和需要小于等于2的n次方。对于GBN协议来说，接收窗口大小是1，那发送窗口大小就要小于等于2的n次方减一。
如何考虑窗口大小的问题呢，只需要考虑一种极限情况，那就是发送窗口把所有帧全发出去了，接收方的ack全丢了，这时候接收窗口不能和发送窗口有重叠，有重叠就有问题。
看这样一个例子
这里n=2，按照原理，发送窗口大是3，考虑发送和窗口是4的情况，也就是右边这张图，发送方发了0、1、2、3号帧，接收方全部正确收到并回了ack，可是全丢了，这时接收方在等待新的0号帧，可是这时发送方重传了上一次的0号帧，而接收方收到后，会误以为这时新的0号帧，那么就出错了。
5、问题
问题就在于这个go back n，可能发送方发了8个帧，除了第二帧别的都对了，可这样发送方还是得重传2号帧以及他之后的所有帧，这样效率太低了。
六、Selective Repeat（选择重传） ARQ
选择重传其实就是上一个GBN得改进，把接收方窗口扩大了，遵循的窗口大小原则还是一样
Wt是发送窗口大小，Wr是接收窗口大小，第一条的原因和上一个协议一样，第二条的原因是接收窗口的大小大于发送窗口是没有意义的。
这里涉及一个ack timer的问题，接收方收到数据后，会设置一个timer，等待高层的数据，看能不能稍待确认过去，如果timer过了还没有高层的数据，那么就会发送ack。这里这个timer的时间需要考虑，发送方发送数据过来，接收方设置timer，timer超时回ack，这是三段时间，发送方发过来数据的时间加上ack回去的时间是一个RTT，也就是说，RTT加上timer必须要小于发送方超时重传的timer。
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
分享名称：【计算机网络】流量控制协议-创新互联
网站链接：
http://cdkjz.cn/article/edsec.html
