可靠数据传输原理

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

相关推荐
KKKlucifer4 小时前
拨开接口黑盒迷雾:运营商第三方合作接口安全审计与准入管控落地实践
网络·人工智能·安全
青瓦梦滋5 小时前
传输层UDP/TCP协议
linux·网络·c++·网络协议·tcp/ip·udp
江畔柳前堤5 小时前
LLM 训练核心机制深度解析:Warmup、Cosine Decay 与 Perplexity 的完整知识体系
网络·人工智能·深度学习·算法·机器学习·语音识别
小绫网络安全5 小时前
【每日一讲】学习网络安全的一些注意事项
网络·安全·web安全
星恒讯工业路由器7 小时前
5G LAN + Wi-Fi 6融合组网:工业路由器如何为柔性产线“剪掉辫子”
网络·5g·工业路由器·工业物联网·5g la·柔性产线·5g工业路由
SamChan908 小时前
PDF翻译API的JWT签名鉴权与速率限制设计:安全实战指南
网络·安全·pdf
xiaoxiangsiyan8 小时前
HCIA 网络技术基础核心模块详解
运维·网络·网络协议·tcp/ip·运维开发·网络基础
AGCSDNl9 小时前
葛姓的来源
网络
漫路在线11 小时前
无境红日靶场五 wp
网络·安全·web安全
Sylvia33.11 小时前
从轮询到推送:足球数据API架构演进与火星数据技术拆解
java·服务器·网络·python·websocket·架构