可靠：不错，不丢，不乱
##### 只考虑单向数据传输，但控制信息双向流动
利用有限状态机（finite state machine）刻画传输协议
-
rdt1.0
可靠信道，可靠数据传输：
底层信道完全可靠
发送方和接收方的FSM独立
-
rdt2.0
产生位错误的信道（假定分组不丢失，不乱序）
底层信道可能翻转分组中的位
利用和UDP一样的检验和机制检测位错误
如何从错误中恢复？
-
确认机制：(Acknowledgements )ACK。 接收方显示地告知发送方分组已正确接受。
-
NAK：接收方显示地告诉发送方分组有错误。
-
发送方收到NAK后，重传分组。
—>基于这种重传机制的rdt协议称为ARQ（Automatic Repeat reQuest
)协议
- 停等协议
Rdt2.0引入的新机制：差错检测，接收方反馈控制信息：Ack/Nak，重传
-
-
rdt2.1
rdt2.0的缺陷：ack/nak发生错误或被破坏
如果ack/nak坏掉，发送方重传
重传又会导致产生重复分组
如何解决重复分组？--->序列号机制：发送方给每个分组增加序列号，接收方丢弃掉重复分组
-
rdt2.2
无nak消息协议，不需要两种确认信息（ACK+NAK）
实现：接受方通过ack告知最后一个被正确接收的分组，在ack消息中显式的加入被确认分组的序列号 发送方在收到重复ack之后，采取与收到nak消息相同的动作，重传当前分组
-
rdt3.0
信道既可能发生错误，也可能丢失分组
检验和+序列号+ack+重传 已经不够用--->发送方等待合理的时间：如果没有收到ack，重传，如果分组或者ack只是延迟了而不是丢了，重传因为序列号机制会处理。所以加上定时器功能即可。
-
流水线
rdt3.0可以正确工作，但性能很差---> 原因：停等操作
网络协议限制了物理资源的使用
采用流水线机制：允许发送方在收到ack之前连续的发送多个分组
更大的序列号范围，发生方和接收方需要更大的存储空间以缓存分组
-->实现：滑动窗口协议
-
滑动窗口协议
窗口：允许使用的序列号范围
窗口尺寸N：最多有N个等待确认的信息
滑动窗口，随着协议的运行，窗口在序列号空间内向前滑动
GBN和SR
-
GBN（回退N步）协议
采用累计确认机制
ACK(N):确认到序列号N（包括N）的分组均已被正确接收
可能收到重复ACK
为分组设置计时器
超时事件：重传序列大于等于N，还未收到ACK的所有分组
会有乱序到达的分组：
直接丢失--接收方没有缓存
重新确认序列号最大的，按序到达的分组
-
SR（选择重传协议）
GBN缺陷：重传N及N以后未确认的分组
接收方对每个分组单独进行确认，设置缓存，缓存乱序到达的分组
发送方只重传那些没收到ack的分组，对每个分组都设置定时器
网友评论