网站建设ui,百度排行榜,网站后台内容管理系统,常州建设工程交易网可靠性数据传输原理
可靠指数据在传输过程中不错#xff0c;不丢#xff0c;不乱
运输层要为应用层提供一种服务#xff1a;数据可以通过一条可靠的信道进行传输#xff0c;在该信道中传输的数据不会受到损坏或者丢失, 实现这种服务的是可靠数据传输协议。
要实现这种服…可靠性数据传输原理
可靠指数据在传输过程中不错不丢不乱
运输层要为应用层提供一种服务数据可以通过一条可靠的信道进行传输在该信道中传输的数据不会受到损坏或者丢失, 实现这种服务的是可靠数据传输协议。
要实现这种服务并不简单因为无法保证在运输层下的各层可以实现可靠传输可靠数据传输协议的实现方式要在运输层下的各层都不可靠的前提下进行。
可靠数据传输协议
可靠数据传输对应用层、传输层、链路层都很重要信道的不可靠特性决定了可靠数据传输协议(rdt)的复杂性
RDT协议
rdt在应用层传输层和数据链路层都很重要。信道的不可靠特点决定了可靠数据传输协议rdt的复杂性。rdt的下层协议是不可靠的可能是出错的丢失的乱序的rdt应该如何凭借自己的努力来保证可靠性呢在下层提供的服务不可靠的情况下向上层提供可靠的服务。 状态机用来描述某一件事物的状态。
Rdt1.0
我们做出一个假设我们假设信道是可靠的
下层的信道是完全可靠的 没有比特出错没有分组丢失
那么此时就只有一种状态发送方等待接收方的数据发送回来发送方等待接收方的数据发送过去。因为数据是可靠的这样就已经足够了。 Rdt2.0具有比特差错的信道
我们开始假设了一些简单的不可靠的行为了
例如下层的信道可能会出现比特翻转的情况。
这个情况其实很好解决我们使用一个校验和用校验和来检测就可以了。但是事情其实没有这么简单我们引入了校验和之后我的发送方如果知道是否发生了比特翻转呢而且如果发生了比特翻转我们如何从差错中恢复呢
因此我们引入了确认应答机制。
ACK代表肯定确认“OK”NAK代表否定确认“请重复一遍”。
当收到ACK的时候就可以继续发送报文了当收到NAK的时候代表数据损坏了我们需要重新发送基于这样重传机制的可靠数据传输协议称为自动重传请求协议ARQ。
因此Rdt2.0的状态机就会有些复杂了。 rdt2.0的致命缺陷 - rdt2.1
我们的rdt2.0做出的假设是只有发送过去的报文会损坏但是没有考虑到一点有没有可能我ACK/NAK报文也损耗了或者没有发送过去呢
这当然有可能
那我一个报文发送过去了对方不给我任何回应或者给了我一个我看不懂的回应那么我现在应该怎么做呢不重传可能会死锁或者出错。重传可能会出现数据的重复和冗余。 因此我们需要引入新的机制来解决这个问题了
处理重复
发送方在每个分组中加入序号如果ACK/NAK出错发送方重传当前分组接收方丢弃不发给上层重复发呢组 停等阶段发送方发送一个分组然后等待接收方的应答 发送方状态机 接收方状态机 当然这个状态机看看就行了没有必要在这个状态机上面过多的纠缠我们需要的是理清里面的逻辑就可以了。 我们来看一下rdt2.1是如何运行的
rdt2.2无NAK的协议
功能同rdt2.1但只使用ACKack要编号接收方对最后正确接收的分组发ACK以替代NAK 接收方必须显式的包含被正确接收分组的序号 当收到重复的ACK如再次收到ack0时发送方与收到NAK采取相同的动作重传当前分组为后面的一次发送多个数据单位做一个准备 一次能够发送多个每一个的应答都有ACKNACK麻烦使用对前一个数据单位的ACK代替本数据单位的NAK确认信息减少一半协议处理简单
我们把ACK用序号排好当前一个回复报文的ACK表示的是上一次报文的序号也就是序号不对应的话那么我们就认为是失败了NAK。
如图 rdt3.0具有比特差错和分组丢失的信道
新的假设下层信道可能会丢失分组数据或ACK
会死锁机制还不够处理这种状况 校验和序列号ACK重传
方法发送方等待ACK一段合理的时间
发送端超时重传如果到时候没有收到ACK - 重传问题如果分组或ACK只是被延迟了 重传将会导致数据重复但是利用序列号已经可以处理这个问题了接收方必须指名被正确接收的序列号 需要一个倒计时定时器 链路层的timeout时间确定的 传输层timeout时间是适应式的 我们来看一下rdt3.0是怎么运行的 以上就是RDT协议的所有内容关于RDT3.0的性能问题我们会作为滑动窗口协议的引子来讲解。
