网络协议8：【传输层】rdt可靠传输的后续：流水线（Go-back-N与Selective Repeat）
其实这部分还是在“可靠传输”原理内，但是这俩部分涉及的图都太多了再放一起总感觉不舒服
这一部分主要是探讨单个rdt已经可靠传输后，如何提高传输效率的问题
见识rdt3.0的速度吧
请听题： 1 Gbps link, 15 ms delay, 8000 bit packet，将round-trip-time作为传播到那里和返回的时间（简写rtt，即两倍的end-to-end延时)，传输延时是多少？
Dtrans=L/R=8000bits109bits/sec=8msD_{trans}=L/R={8000 bits \over 10^9 bits/sec}=8msDtrans=L/R=109bits/sec8000bits=8ms
看着还挺快的是吧，那求求利用率（utilization），即发送方忙于发送的占总传播时间的百分比
Usender=L/RRTT+L/R=0.008/30.008=0.00027U_{sender}={L/R \over RTT+L/R}= 0.008/30.008=0.00027Usender=RTT+L/RL/R=0.008/30.008=0.00027
笑死，根本没效率，全花在中间这个15ms上了，再算一下甚至发现
当前条件下，传递8000bit（1000KB）的包需要30ms
也就是平均每秒只能走33KB/s
这其实是因为之前提到过的“stop-and-wait operation”——但是，也没办法怪人家，必须要等人家传到了才能开启下一轮
那么，有什么办法改进呢，先进一段例题
小例题
链路利用率的救星——“流水线协议”登场（概述）
流水线pipelining：允许发送方在未得到对方确认（with no ACK as yet） 的情况下一次发送多个packets
必须增加序号的范围：用多个bit表示分组的序号
在发送方/接收方要有缓冲区 （缓解发送/接收速度不匹配的情况）
发送方缓冲：未得到确认，可能需要重传；
接收方缓存：上层用户取用数据的速率≠接收到的数据速率；接收到的数据可能乱序；而且可能需要重新排序后交付（多可靠）
看图，图讲的多好
小例题
两种通用的流水线协议Go-Back-N, selective repeat（具体）
动画辅助理解
怪蠢的Go-back-N
机制
返回N协议的关键是sender能够在收到确认之前发送多个分组,但接收方只能缓存一个符合要求分组并发送确认（cumulative ACK）。
发送方为发送出去的分组保留副本,直到来自接收方确认达到
sender可以一次性发N个packets
receiver只缓存并确认（cumulative ACK）按顺序正确到达的packet
如果有错，不发
sender在第一个packet发送时开始计时
虽然发出去的每个packet都可以有一个计时器,但反正第一个等待确认的分组总是会最先超时的。用这个判断就成了
我还是觉得理解这张就差不多
receiver那边如果跳了，重复发送上一条
来点题目
缺陷
GBN使用流水线技术避免了停等协议中的信道利用率问题
但是GBN中回退N步 明显部分分组是不需要重传的,在窗口长度较大的情况下,GBN代价较大
用选择重传来解决
选择重传Selective repeat
机制
receiver单独确认所有正确接收的packet（不再只对顺序到达的确认）
根据需要缓冲数据包，以便最终按顺序传送到上层
发送方仅重新发送未收到ACK的数据包
每个未确认packet都有一个计时器
窗结构
FSM方式描述
sender
收到来自上层的数据
如果window里的下一个包可用，发送它if next available seq # in window, send pkt
第n个超时了的话
重新发送packet(n), 重启对于它的计时器
收到ACK(n)
标记收到它了
如果它对应的packet是未确认的里编号最小的，右移一位窗口
receiver
收到了packt(n)
不管是否曾收到过，发送ACK(n)
如果顺序乱了，缓存它等前面的搞定
如果正序，发送它到上层，移动接收窗到下一格
重复则忽视
其他情况都无视
给爷看图
怎么还是有问题
当序列太小，重发第一组的可能被认为是第二组的误接收
总之，发送窗口应该小于等于接收窗口（反正多了没用），发送窗口大小和序号大小也应该注意，发送窗应为1/2序号个数
总之，来看看大家的优缺点
GBN的核心就是——简单；相对的SR则是高效。
作者：有氧
链接：https://juejin.cn/post/7030329233314414599