1.第一种解决方法—-停止等待协议
阶段一：没有任何比特差错与分组丢失的安全信道
发送端只管发，接收方直管受，不管任何的数据可靠性。
阶段二：具有比特差错的
1⃣️加入对错（出错）反馈机制ack、nak
ACK 确认字符：(Acknowledge character）
出错的确认NAK 英文缩写: Negative Acknowledgment
不仅发送的数据可能出错，ack与nak也可能会出错
2⃣️通过为发送的packet编号解决ack与nak出错的问题
发送端收到接受端的确认可能有3种情况：1.ack 2.nak 3.乌拉乌拉
如果出现3，则一律重传。因为 接收端不知道发送方是否重传，所以接收方不知道过来的packet是新packet还是老packet，所以要为paccket加上编号（因为停止等待协议一次只有一个packet，所以01两个状态就够用了，接收方能够分辨是哪个编号的分组）
3⃣️：free nak（去除nak），对ack编号，实现与阶段三同样的功能
接收方的ack编号为对上一次成功接受packet时的编号
阶段三：具有比特差错与分组丢失的信道
加入超时重传机制，每发送一个分组，都会启动一个重传计时器，如果重传计时器的时间到了还没有收到接收方发来的对分组的确认，则会重传旧分组。
没有收到接收方传来可能是由于分组丢失，也可能没有丢失只是信道阻塞来的慢了一点，丢失了进行重传，不丢失也重传（接收方可以根据packet的编号去除重复）
方案三已经可以确保packet可以顺利放了，但是效率太低，所以需要加强为流水线协议
2.第二种解决方案—-流水线（pipeline）协议
在讲两种流水线协议前先讲一下滑动窗口协议
0⃣️滑动窗口协议
1⃣️GBN协议（Go Back N）回退N步协议
2⃣️SR协议（select repeat）选择重传协议
具体看ppt
对比GBN协议与SR协议
主要就三个区别：
1⃣️窗口大小
2⃣️重传时是单独重传还是全部重传
3⃣️接收时是累积确认还是单独确认
3.s-w与GBN与SR窗口大小对比
若有收获，就点个赞吧
0 人点赞
