可靠数据传输原理

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

相关推荐
虎头金猫1 天前
4K 视频总卡在公网带宽?用 N1 + OpenList 把网盘播放链路重新理顺
运维·服务器·网络·python·容器·beautifulsoup·pandas
wuyk5551 天前
《WiFi 嵌入式物联网开发全套实战》| 第 16 章 ESP32 AP+STA 双模共存原理与工程坑点
网络·stm32·物联网
QYRdata1 天前
年均增速24.2%!机器人数据湖未来六年增长动能强劲
网络·机器人·服务发现
CHENKONG_CK1 天前
破解制鞋打磨痛点:RFID赋能去毛刺工序自动化升级
网络·单片机·嵌入式硬件·网络协议·tcp/ip
chshang19921 天前
工业路由器是什么?浅谈5G工业网络中的IR602
网络·物联网·5g·智能路由器
萧瑟余晖1 天前
Netty 核心组件与 Reactor 模型详解
网络·架构
ITxiaobing20231 天前
IP 定位服务选型指南:从准确率到工程落地的技术考察
linux·服务器·网络
wuyk5551 天前
【Socket 进阶之路】第 9 章 Linux 网络服务量产稳定性优化|心跳保活、TIME_WAIT、SO_LINGER、内存池、断线重连、完整异常防护框架
linux·服务器·开发语言·网络·物联网
z落落1 天前
C#UDP+串口服务端+UDP 客户端(含 CRC16 校验)
网络·网络协议·udp
云运维笔记1 天前
华为设备IP地址配置全攻略
运维·网络·计算机网络·华为