可靠数据传输原理

1.可靠数据传输介绍

2.可靠传输rdt1.0

完全可靠信道的可靠数据传输

理想模型:rdt1.0(完全可靠信道) 假设我们使用的是"特快专递"服务,该服务承诺100%包裹送达,且不会出现包裹破损或丢失的情况。 这相当于网络通信中的"完全可靠信道"。 协议特点: 单向传输:数据仅从发送方流向接收方 无差错处理:无需考虑数据损坏或丢失 无反馈机制:接收方无需向发送方发送确认信息

尽管rdt1.0模型简单有效,但其适用范围受限于特定条件(理想化的完全可靠信道): 现实约束:现实中不存在绝对可靠的快递服务,可能遭遇极端天气导致延误,如同实际网络中存在丢包、延迟、数据错误等问题 模型缺陷:无法处理包裹丢失情况,缺乏容错能力。而且我们是假设接收方能即时处理所有数据,并无针对流量的探讨。其次,此模型不支持双向数据交互。

3.可靠传输rdt2.0

经具有比特差错信道的可靠数据传输

Rdt 2.0中引入的新机制

1.差错检测,接收方进行差错检测。一般我们采用CRC-32等标准算法验证数据完整性。

2.确认机制,接收方给发送方反馈控制消息: ACK/NAK---只需要1比特,1表示ACK,0表示NAK。 肯定确认(ACK):接收方确认收到无误的数据。 否定确认(NAK):接收方要求重传错误数据。

3.重传,发送方根据收到的反馈,决定是否重传。

本质上就是 停止等待机制,就是发送方必须收到确认后才能发送下一个数据分组。

他的优点有:实现简单(适合小型系统),保证数据顺序(如同快递公司按下单顺序派送),适用于高延迟网络(如卫星通信)。 当然局限性也很明显,信道利用率低(如同快递员空驶等待签收)。不适应高带宽场景(类似双十一期间快递积压)且无法应对ACK/NAK丢失。

4.可靠传输rdt2.1

经具有比特差错信道的可靠数据传输(确认分组错误)

rdt2.1在rdt2.0的基础上,引入了数据分组序号字段,解决了ACK/NAK分组受损导致的重传歧义问题。 增加了分组序号,并且发送方和接收方FSM的状态数都是之前的二倍,这是因为协议状态此时必须反映出目前正发送的分组或者接收方希望接收的分组的序号是0还是1。

5.可靠传输rdt2.2

去除了NAK确认,通过带序号的ACK实现确认功能

rdt2.2去除了NAK确认,通过带序号的ACK实现确认功能。 无NAK的协议 功能同rdt2.1,但只使用ACK(ack要编号) 接收方对最后正确接收的分组发ACK,以替代NAK。 接收方要在NAK后面加上最后收到的正确分组的编号。

发送方收到的确认重复---重传

收到的确认有问题---也重传

6.可靠传输rdt3.0

rdt3.0在rdt2.2的基础上引入了超时重传机制(解决数据包丢失)

7.自动重传请求ARQ

相关推荐
DianSan_ERP17 小时前
电商API接口全链路监控:构建坚不可摧的线上运维防线
大数据·运维·网络·人工智能·git·servlet
呉師傅18 小时前
火狐浏览器报错配置文件缺失如何解决#操作技巧#
运维·网络·windows·电脑
2501_9462055220 小时前
晶圆机器人双臂怎么选型?适配2-12寸晶圆的末端效应器有哪些?
服务器·网络·机器人
linux kernel20 小时前
第七部分:高级IO
服务器·网络
数字护盾(和中)20 小时前
BAS+ATT&CK:企业主动防御的黄金组合
服务器·网络·数据库
~远在太平洋~20 小时前
Debian系统如何删除多余的kernel
linux·网络·debian
unfeeling_1 天前
Keepalived实验
linux·服务器·网络
坐吃山猪1 天前
OpenClaw04_Gateway常见问题
网络·gateway·openclaw
上海云盾商务经理杨杨1 天前
2025年重大网络安全事件回顾与趋势分析
网络·安全·web安全
kylezhao20191 天前
C# 的开闭原则(OCP)在工控上位机开发中的具体应用
网络·c#·开闭原则