Rdt协议(可靠运输协议)

提示:文章写完后


前言


提示:以下是本篇文章正文内容

一、可靠数据传输原理

可靠指数据在传输过程中不错,不丢,不乱

运输层要为应用层提供一种服务:数据可以通过一条可靠的信道进行传输,在该信道中传输的数据不会受到损坏或者丢失, 实现这种服务的是可靠数据传输协议

要实现这种服务并不简单,因为无法保证在运输层下的各层可以实现可靠传输,可靠数据传输协议的实现方式要在运输层下的各层都不可靠的前提下进行

可靠数据传输协议:
1.可靠数据传输对应用层、传输层、链路层都很重要

2.信道的不可靠特性决定了可靠数据传输协议(rdt)的复杂性

在这里插入图片描述
如图,可靠的数据传输协议是建立在运输层底层的不可靠信道上的,
rdt(Reliable data transfer)为可靠数据传输:提供给上层实体的服务抽象是,数据可以通过一条可靠的信道进行传输

udt(unidirectional data transfer))为不可靠传输(单向数据传输): 即数据传输是从发送端到接收端的,但控制信息是双向流动的

可靠数据传输协议基本结构:
在这里插入图片描述
1.rdt_send():被上层应用调用,将数据交给rdt以发送给对方
这里被上层应用调用的单向的,上层应用将数据交给rdt后就不管了

2.udt_send(): 被rdt调用,在不可靠信道上向接收方传输数据
这里是可以双向调用的

3.rdt_rcv(): 当数据包到达接收方信道时被调用

4.deliver_data(): 被rdt调用,向上层应用交付数据

注:单向数据传输,但控制信息双向流动

FSM(状态机):利用状态机(Finite State Machine, FSM)刻画传输协议
在这里插入图片描述
在不同的事件下产生不同的状态,对应着不同的响应动作

二、Rdt协议

1.Rdt 1.0(可靠信道)

前提条件:
(1)底层信道完全可靠条件下:(理想条件,实际不存在)

1.不会发生错误(bit error)
2.不会丢弃分组

(2)发送方和接收方的FSM独立

在这里插入图片描述
发送方:一个状态,等待上层调用,若上层调用,则产生rdt_send,创建packet活动,调用信道上的udt_send(),发送分组,可确定百分百发送,然后回到之前状态,继续等待调用

接收方:一个状态,等待下层调用,当传入一个分组,rdt_rcv接收,extract提取,交付给上层deliver_data

特点:发送方与接收方都只有一个状态

2.Rdt 2.0(ARQ重传)

基于Rdt 1.0的不可行性, Rdt 2.0中引入的新机制:

1.差错检测
2.接收方反馈控制消息: ACK/NAK
3.重传

底层信道可能翻转分组中的位(bit),利用校验和检测位错误

但是,检测道错误如何从错误中恢复:
(1)确认机制(Acknowledgements, ACK): 接收方显式地告知发送方分组已正确接收

(2)NAK:接收方显式地告知发送方分组有错误,发送方收到NAK后,重传分组

基于这种重传机制的rdt协议称为ARQ(Automatic Repeat reQuest)协议

在这里插入图片描述

发送方:若上层调用,则产生rdt_send,创建packet活动并加入校验盒,调用信道上的udt_send(),发送分组。同时进入等待ACK/NAK状态,若为NAK,则重传分组,继续等待ACK/NAK,一直处于该状态,直到传回ACK才进入等待调用状态

接收方:当传入一个分组,rdt_rcv接收并且进行判断,如果没有错误extract提取,交付给上层deliver_data并返回ACK,如果发生错误,则直接返回NAK,并处于等待接收状态

无错误场景:
在这里插入图片描述

有错误场景:
在这里插入图片描述
特点:等待上层调用,等待ACK或NAK控制信息

3.Rdt 2.1(序列号)

Rdt 2.0 缺陷:ACK/NAK消息可能发生错误/被破坏(corrupted)

解决:为ACK/NAK增加校验和,检错并纠错,发送方收到被破坏ACK/NAK时不知道接收方发生了什么,添加额外的控制消息

如果ACK/NAK坏掉,发送方重传,但是不能简单的重传这样会产生重复分组

解决重复分组
引入序列号(Sequence number): 发送方给每个分组增加序列号,并且接收方丢弃重复分组

发送方, 应对ACK/NAK破坏
在这里插入图片描述
发送方:等待上层调用,序列号为0,若上层调用,则产生rdt_send,创建packet活动(此处加入序列号)并加入校验盒,调用信道上的udt_send(),发送分组,同时进入等待ACK/NAK状态,若为NAK,则重传分组,继续等待ACK/NAK,一直处于该状态,若传回ACK,则进入等待调用状态并改变序列号为1

接收方, 应对ACK/NAK破坏
在这里插入图片描述
接收方:当传入一个分组,rdt_rcv接收并且进行判断,如果分组没有错误,并且期望收到分组序列号与当前序列号相同,则extract提取,交付给上层deliver_data并返回ACK;如果发生错误,则直接返回NAK,并处于等待接收状态;若接收分组没错,序列号不匹配,则必须发一个ACK,表示正确接收

在rdt2.0的基础之上,发送方在打包数据包时添加了0或者1编号,同样ACK,NAK字段上也添加了0,1字段,表示0.1号字段的确认或者否定。发送方就有了2种状态发送0号数据包,1号数据包,接收方也有了2种状态等待0号数据包和等待1号数据包。

特点:发送方和接收方都有四个状态,比Rdt 2.0中多了两个序列号状态

4.Rdt 2.2(无NAK)

在Rdt2.1情况下,假设情景发送方向发送0号数据包,如果接收方接收到0号数据包,返回ACK,但是ACK出现翻转,接收方处于等待1号数据状态,发送方重复发送0号数据,接收方会拒绝0号数据,避免重复

如果接收方接收到0号数据包出现错误,返回NAK,但是NAK出现翻转,接收方处于等待0号数据状态,发送方继续发送1号数据,接收方会拒绝1号数据,避免错序

与rdt 2.1功能相同,但是只使用ACK:
接收方通过ACK告知最后一个被正确接收的分组在ACK消息中显式地加入被确认分组的序列号,发送方收到重复ACK之后,采取与收到NAK消息相同的动作重传当前分组

在这里插入图片描述
在ACK的信息上加上了期望的顺序号,假设发送方向接收方发送0号数据包,如果接收方接收到0号数据包,返回(ACK,1),发送方接着发送1号数据包。如果接收方接收到0号数据包出现错误,返回(ACK,0),发送方重传0号数据包

5.Rdt 3.0(定时器)

rdt3.0在rdt2.2的基础之上处理了数据包丢失的情况,增加了计时器的机制,如果在RTT时间段内,发送方没有接收到反馈信息,发送方默认数据包丢失,会自动重传

发送方等待“合理”时间:
如果没收到ACK,重传,但是如果分组或ACK只是延迟而不是丢了,重传会产生重复,序列号机制能够处理,接收方需在ACK中显式告知所确认的分组

需要一个合理的定时器:

1.每次发送一次分组,便启动一个定时器
2.响应定时器的中断
3.终止定时器

发送方
在这里插入图片描述
在Rdt 2.0的基础上增加一个时钟,其它没有任何变化,发送方等待合理的时间,若timeout,没收到ACK,则重传

Rdt 3.0示例
不丢包和丢包
在这里插入图片描述

丢失ACK 和超时
在这里插入图片描述

Rdt 3.0能够正确工作,但性能很差
假设:1Gbps链路,15ms端到端传播延迟,1KB分组
在这里插入图片描述
则发送方利用率:发送方发送时间百分比
在这里插入图片描述
在1Gbps链路上每30毫秒才发送一个分组,速率33KB/sec,网络协议限制了物理资源的利用

传输过程:
在这里插入图片描述
主要原因是在RTT时间段内,网络处于空闲状态,而RTT时间段比较长,使得利用率十分的低


总结

提示:这里对文章进行总结:

Rdt协议引入了校验和,序号,定时器,肯定确认和否定确认,这些机制共同合作下得到了一个有效的可靠数据传输协议,虽然是一个停等协议,在每发送完一个分组就停止发送,等待对方的确认,在收到确认后再发送下一个分组,但为TCP协议的完善建立了基础

  • 8
    点赞
  • 47
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
可靠数据传输协议(Reliable Data Transfer Protocol, RDT)是一种在网络通信中确保数据准确无误地从发送方传递到接收方的机制。它们主要用于实时应用和需要高数据完整性的场景,如电子邮件、文件传输、视频会议等。常见的RDT协议包括TCP(Transmission Control Protocol)和UDP(User Datagram Protocol)在TCP/IP协议栈中的扩展。 **优点:** 1. **数据完整性**:RDT协议提供了错误检测和纠正机制,如校验和或序列号,确保数据在传输过程中不丢失、不重复或损坏。 2. **顺序保证**:接收端能按照发送顺序接收数据,这对于需要按特定顺序处理信息的应用非常重要。 3. **重传机制**:如果数据包丢失,RDT协议通常会自动请求重新发送,提高数据传输的可靠性。 4. **连接管理**:建立连接后进行数据传输,断开连接时清理资源,简化了应用程序的复杂性。 **缺点:** 1. **效率**:为了提供可靠性,RDT协议增加了额外的控制信息和确认机制,可能导致带宽利用率降低和较高的延迟。 2. **开销**:额外的控制信息和确认过程会增加网络流量和处理器负载。 3. **复杂性**:实现复杂,对于简单的应用场景可能会引入不必要的复杂性。 4. **实时性**:虽然尽力而为,但仍然可能受到网络拥塞等因素影响,无法保证实时性,尤其是在网络条件较差时。 **相关问题:** 1. RDT协议如何处理网络丢包? 2. UDP协议是否支持可靠数据传输? 3. TCP和UDP在哪些场景下各有优势?

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Super.Bear

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值