提示:文章写完后
- 前言
- 一、可靠数据传输原理
- 二、Rdt协议
- 1.Rdt 1.0(可靠信道)
- 2.Rdt 2.0(ARQ重传)
- 3.Rdt 2.1(序列号)
- 4.Rdt 2.2(无NAK)
- 5.Rdt 3.0(定时器)
- 总结
提示:以下是本篇文章正文内容
一、可靠数据传输原理可靠指数据在传输过程中不错,不丢,不乱
运输层要为应用层提供一种服务:数据可以通过一条可靠的信道进行传输,在该信道中传输的数据不会受到损坏或者丢失, 实现这种服务的是可靠数据传输协议
要实现这种服务并不简单,因为无法保证在运输层下的各层可以实现可靠传输,可靠数据传输协议的实现方式要在运输层下的各层都不可靠的前提下进行
可靠数据传输协议: 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)刻画传输协议 在不同的事件下产生不同的状态,对应着不同的响应动作
前提条件: (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控制信息
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号数据包
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时间段比较长,使得利用率十分的低
最近更新
- 深拷贝和浅拷贝的区别(重点)
- 【Vue】走进Vue框架世界
- 【云服务器】项目部署—搭建网站—vue电商后台管理系统
- 【React介绍】 一文带你深入React
- 【React】React组件实例的三大属性之state,props,refs(你学废了吗)
- 【脚手架VueCLI】从零开始,创建一个VUE项目
- 【React】深入理解React组件生命周期----图文详解(含代码)
- 【React】DOM的Diffing算法是什么?以及DOM中key的作用----经典面试题
- 【React】1_使用React脚手架创建项目步骤--------详解(含项目结构说明)
- 【React】2_如何使用react脚手架写一个简单的页面?