内容根据哈工大计算机网络课程总结整理
先介绍一下有穷自动状态机，后面会大量使用它来刻画协议
状态机.png
一个圆圈表示一个状态，一个带箭头的线表示一个状态转换过程，箭头线旁边有一根横线补充描述。横向上方是造成状态转换的事件，下方是转换过程中执行哪些操作。
下面会以一种渐进的方式从头考虑如何实现可靠数据传输。
rdt1.0 （reliable data transfer，可靠传输协议1.0版本）
假设信道本身是完全可靠的，那一个可靠的传输协议就几乎什么也不用做：发送方等待上层协议调用，根据数据制作报文段，发送数据，接收方接收数据就完了。这就是一个没有检错机制的udp，就实现了一个分用/复用。
下面通信双方的状态机：
rdt1.0，信道完全可靠
rdt2.0 假设信道只会发生位错误，0变1或1变0
一个朴素的想法就是接收方检测错误，发现错了就让发送方重传。（也可以让接收方自己检测错误或纠正错，不过这需要纠错码，实现起来较为复杂）
因此引入了三个机制：
差错检测机制（udp的检验和）确认机制（ACK/NAK）重传机制
发送方发送一个segment，然后等接收方确认。接收方根据检错码判断，正确就回复ACK，否则NAK。发送方收到ACK再发下一个segment，收到NAK，则重发此segment。这种 “发送-等待确认” 的协议被称为 停-等协议。
rdt2.0
rdt2.1 考虑ACK/NAK消息本身也可能坏掉的情况
-
为ACK/NAK消息增加检错码，如果坏掉就重发segment
如果接收方收到一个segment了，但是回复给发送方的ack消息坏掉，于是发送方又重发了一遍，再次收到就造成重复。所以应该再为segment增加一个序列号。 -
为segment分配序列号，因为是停-等协议，所以两个序列号就够了
rdt2.1 发送方
rdt2.1 接收方
注意左下角的case，当前期望收到segment0，但是对方发来的是1，说明上一个segment1的ack消息坏掉了，对方重发。因此依然回复ack，不然对方一直重发。
左下角的case
rdt2.2 考虑ACK/NAK模式
其实没必要使用两种确认消息，只需要在确认无误后回复ack，并在消息中告知发送方ack的segment的序列号即可
只保留ACK
rdt2.2
rdt3.0 假设信道还要发生丢包
丢包后接收方就不会发ack，甚至ack消息也可能丢掉，因此发送方可能一直等下去。
-
超时机制
超时未收到ack，直接重传segment
rdt3.0 发送方
接收方还和rdt2.2一样
至此就实现了不可靠信道上的可靠数据传输，保证了不错、不乱、不丢。但是性能是个问题。
停-等协议性能问题
传输时延是指分组的第一个bit离开结点到最后一个bit离开结点的时长。只和分组大小和链路带宽有关。
传播时延是一个bit从a结点到b结点的时长，只和链路长度、信号在介质中传播速度有关。
RTT是round trip time，指一个来回，也急是两个传播时延。
低效的原因
停等协议中，大量时间在“等”
为了解决这个问题，引入了流水线机制，一次性发送一系列segment，然后再等待确认。
滑动窗口协议（实现了流水线机制）
假设一次最多能发送10个segment，发完后等待这10个segment的ack。假如依次收到4、2、1、3的ack，此时前4个分组就完成并确认成功发送了，于是将窗口向右移动4。
滑动窗口
上图中蓝色的已经成功发送的segment，黄色是发送了尚未收到ack的，蓝色是还可以使用的序列号。
GBN协议
GBN
ack改成累计确认，ack(n) n以及n以前的分组全部确认。
发送方一次性发送多个分组，只为第一个分组设置一个计时器，如果超时，则重发从第一个起的所有分组，如果1到第i个分组的全部ack，就将窗口右滑，重新为当前窗口内的第一个分组设置计时器。
接收方如果收到分组，发送目前能够累计确认的ack。如果收到乱序到达的分组，直接扔掉。
image.png
image.png
SR协议 （Selective Repeat）
gbn的不足之处：
1是一旦重传是将n之后的所有分组重传，2是乱序到达的分组被扔掉。sr在这些方面进行了改进。
SR的改进
另外因为接收方要缓存分组，不再是gbn那种“我期待某分组”的工作模式，因此接收方也设置了一个窗口。
1667401274722.png
1667401362806.png
image.png
image.png
网友评论