可靠信道传输2.0 2.1 3.0
转载自:https://blog.csdn.net/springtostring/article/details/80379841
计算机网络的设计基本方案是复杂化,多功能化应用层,运输层的协议设计,从而使得网络层,链路层,物理层变得相对简单,网络搭建的物质条件变得简单。由于网络层较为简单,采用了无连接的协议,在不可靠信道上传输,导致数据传输是不可靠的。为了保证数据传输的可靠性,我们选择在运输层采用复杂的rdt(可靠数据传输协议),以完成网络的可靠性。
原理图如下所示:
rdt协议经历了rdt1.0,rdt2.0,rdt2.1,rdt2.2,rdt3.0.一步步完善,使得网络得到很好的安全性稳定性。
rdt1.0是基于理想情况下的协议,假设所有信道都是可靠的,没有比特位的翻转,没有数据包的丢失与超时,所以rdt1.0的传输功能就是 发送方发送数据,接收方接受数据。
rdt2.0在rdt1.0的基础上解决了比特位翻转的问题,这里的比特位防撞发生在运输层下面的不可信信道中数据包中的1可能会变0,0可能会变成1。rdt2.0增加了3种新机制:1.错误检验 2.接收者反馈接受信息(ACK,NAK)3.重传机制。在运输层对应用层的数据进行打包处理时,新增checksum(校验和),从而接收端可以对其数据包进行检验,如果正确,返回ACK,发送者继续发送下一个数据包;如果不正确,返回NAK,发送者重传数据。
但是rdt2.0有着一个致命的缺点,只考虑了发送方到接收方的数据传输,如果反馈信息ACK,NAK传输时发生比特位翻转会出现什么情况?如果ACK发生翻转,那么发送方会再次重复的发送相同的数据包;如果NAK发生翻转,那么发送方会认为数据传输情况很好,但是接收方却已经收到了一个错误的数据包。
由此rdt2.1应运而生,在rdt2.0的基础之上,发送方在打包数据包时添加了0或者1编号,同样ACK,NAK字段上也添加了0,1字段,表示0.1号字段的确认或者否定。发送方就有了2种状态发送0号数据包,1号数据包,接收方也有了2种状态等待0号数据包和等待1号数据包。现在假设情景发送方向接收方发送0号数据包,如果接收方接收到0号数据包,返回ACK,但是ACK出现翻转,接收方处于等待1号数据状态,发送方重复发送0号数据,接收方会拒绝0号数据,避免重复。如果接收方接收到0号数据包出现错误,返回NAK,但是NAK出现翻转,接收方处于等待0号数据状态,发送方继续发送1号数据,接收方会拒绝1号数据,避免错序。
rdt2.2是在rdt2.1上的基础之上做了小小的改善,摒弃了NAK,只需采用ACK。我们在ACK的信息上加上了期望的顺序号,现在假设情景发送方向接收方发送0号数据包,如果接收方接收到0号数据包,返回(ACK,1),发送方接着发送1号数据包。如果接收方接收到0号数据包出现错误,返回(ACK,0),发送方重传0号数据包。
rdt2.2之前的版本都重在处理数据包的比特位翻转情况,却没有考虑到数据包在传输过程中出现的数据包丢失问题,这样数据包丢失会使得网络处于拥塞状态。
rdt3.0在rdt2.2的基础之上处理了数据包丢失的情况,增加了计时器的机制,如果在RTT时间段内,发送方没有接收到反馈信息,那么发送方默认数据包已经丢失了,会自动重传。
rdt3.0性能分析:
rdt3.0 可以工作, 但是性能很差
ex: 1 Gbps 链路, 15 ms 传播延迟, 8000 bit数据报:
U sender: utilization – 发送者忙于发送的时间占比
每30 msec发送 1KB pkt -> 33kB/sec (1 Gbps 链路)
这是一个网络协议严重影响链路资源利用的一个例子!
主要原因是在RTT时间段内,网络处于空闲状态,而RTT时间段比较长,使得利用率十分的低。
在此基础上采用流水线协议来改进rdt3.0
允许发送者发送多个, “在途(in-flight)”, 等待确认的数据报
顺序号的范围必须扩大
Sender /receiver必须使用缓冲区
主要有两类流水线协议: go-Back-N, selective repeat。
大致描述如下:
go-Back-N(回退N重传协议):
1.发送者在流水线中最多有 N 个未确认的数据报。
2.接收者仅发送累计的确认 ,如果中间有数据报缺失,就不予以确认。
3.发送者对最久未确认的数据报进行计时,如果计时器到点, 重传所有未确认的数据报。
4.发送窗口大于1,接受窗口等于1(也就意味着如果某一个报文段出现错误,那么接受窗口会停留再次,之后收到的数据将会被丢弃)
selective repeat(选择重传协议):
1.发送者在流水线中最多有 N 个未确认的数据报。
2.接收者对单个数据报进行确认。
3.发送者对每一个未确认的数据报进行计时,如果计时器到点, 仅重传该个未确认的数据报。
4.发送窗口大于1,接受窗口大于1(意味着可以缓存出错位置之后的报文段),最好是两者相同,
可靠信道传输2.0 2.1 3.0相关推荐
- KCP-快速的可靠网络传输协议
KCP简介 KCP是一个快速可靠的协议,能以比 TCP浪费10%-20%的带宽的代价,换取平均延迟降低 30%-40%,且最大延迟降低三倍的传输效果.纯算法实现,并不负责底层协议(如UDP)的收发,需 ...
- BFT-SMaRt:用Netty做客户端的可靠信道
目录 一.Netty服务端的构建 1. 父类构造函数 ① 查找缓存 ② 相关日志 2. 服务端构造 ① 配置读取 ② 服务端配置 3. 服务端功能 ① 通用接口功能 ② Channel处理器 4. 节 ...
- 数字模拟信号 单双信道传输
一.信号 1.数字信号转模拟信号(调制解调) 2.摸拟信号转数字信号(调制解调) 3.数字信号表示 二.单信道传输 1.串行传输和并行传输 2.同步传输和异步传输 3.基带传输和模拟传输 三.多信道传 ...
- 几种常见的可靠UDP传输协议(包含C#实现)
几种UDP网络库的整理Raknet,UDT,ENet,lidgren-network-gen3 http://blog.csdn.net/u014630768/article/details/3489 ...
- 《计算机网络自顶向下》 Miscellaneous Lab1 Implementing a Reliable Transport Protocol(实现可靠的传输协议(上))
文章目录 前引 Lab1 实现可靠的传输协议 Lab1 文档查阅(友情提供下载链接) 查看c语言参数声明的说明 原模版代码(个人整理格式后) 原模板代码(稍加分析) 交替位协议版本 代码实现 交替位协 ...
- harmonyos基于arm么,华为架构师解读:HarmonyOS低时延高可靠消息传输原理
华为架构师解读:HarmonyOS低时延高可靠消息传输原理 [复制链接] 本文作者:zhangkesi,华为软件架构设计工程师 这是一篇HarmonyOS低时延高可靠消息传输原理的介绍,希望对你有所帮 ...
- 双绞线是计算机网络的一种通信线路吗,计算机网络环境的信道传输技术分析
韩长军 [摘要]计算机网络的产生对人类文明进步树立了新标杆,促进了人们的交流,对于人类社会信息获得的途径以及咨询传播方式等等也产生了极其重大的影响.数据密集程度较高的科学和工程,比如.水文观测.地壳波 ...
- 传输18 Gbps的HDMI 2.0,包括4 K 60 4:4:4参考设计
2017年2月7日--HDBaseT的开发者和HDBaseT联盟的创始人瓦伦斯,宣布了HDBaseT的一种参考设计,它可以传输18 Gbps的HDMI 2.0,包括4 K 60 4:4:4.参考设计利 ...
- RabbitMQ 可靠消息传输实战--云平台技术栈12
导读:之前发布了云平台技术栈(ps:点击可查看),本文主要说一下其中的RabbitMQ! 作者:极客慧 https://my.oschina.net/jikeh/blog/2207127 可能是缓存架 ...
最新文章
- 代表Java未来的ZGC深度剖析,牛逼!
- Vijos P1131 最小公倍数和最大公约数问题【暴力】
- mysql显示bmp图片_BMP格式图像的显示
- 信息系统项目管理师-信息系统进度管理核心知识点思维脑图
- HAProxy + Keepalived + Flume 构建高性能高可用分布式日志系统
- android 代码 截取屏幕,如何以编程方式在Android上截取屏幕截图?
- webpack+vue+vueRouter模块化构建完整项目实例详细步骤-入门篇
- 听说读论文也有trick?这篇文章告诉你深度学习论文阅读最佳姿势
- Bootstrap 弹出提示插件Popover 的选项
- 8.6 edu25 ,577#div2 CF补题(二分 ,dp 与 贪心
- Grep 用法和正则表达式(一)
- c++规定浮点数输出格式
- mysql jdbc 连接池配置
- Tomcat的Document base ……does not exist or is not a readable directory错误
- node 拦截器拦截请求下载电子书以及等待前端渲染操作、浏览器操作
- PMOS和NMOS引脚及封装
- 【C++之GDB调试】GDB调试从入门到精通
- c语言y为奇数的关系表达,设y是int型,请写出y为奇数的关系表达式
- 超级演说家赖斌斌到访时空梭
- 算法竞赛中的JAVA使用笔记
热门文章
- 电力安全工作规程发电厂和变电站电气部分_一招告诉你,何为电力系统
- python语言基础笔记_Python语言 基础知识笔记
- captcha must be filled out_直播行业这些英文单词,不知道你就out了
- getBoundingClientRect使用指南
- Python——配置环境的导出与导入
- Qt多线程-QThread
- python-使用字典使Fibonacci更有效率
- URAL1018 Binary Apple Tree
- Hive-RCFile文件存储格式
- UVa 1605 (构造) Building for UN