在本篇文章中我们将逐步了解开发发送方和接收方的可靠数据传输协议的过程,它们逐渐复杂,最后会得到一个无错、可靠的数据传输协议。在这个过程中仅考虑单向数据传输但控制信息双向流动。
我们用有限状态机(FSM)来标识发送方和接收方。如下图所示:

实线箭头指示了协议从一个状态变迁到另一个状态。在对应的一个箭头上,有个类似分数样子的数据。横线上方表示导致状态转换的事件,横线下方是状态转换时执行的动作。接下来本文所有的图都按此理解。

一、Rdt1.0:完全可靠信道上的可靠数据传输

首先考虑最简单的情况,即在完全可靠的信道上,没有bit错误、没有分组丢失。
这时发送方与接收方的有限状态机定义如下图:

其中,发送方发送数据到下层信道,接收方从下层信道接收数据。发送方和接收方有各自的FSM,并且都只有一个状态,都是从一个状态返回到自身。
发送端通过rdt_send(data)事件接收来自较高层的数据,经过make_pkt(data)事件把上层的数据转换成下层可以识别的数据段,然后把data数据通过udt_send(packet)发到下层IP层。
接收方通过rdt_rcv(paclet)函数从IP层接收数据,收到信息包之后继续等待来自下层的调用,这个过程的事件主要是将数据段转换成数据,交给应用层。
对于rdt1.0总结一句话就是假设信道没有出错,只是做两个动作,一个是交付,一个是上传。

二、Rdt2.0:具有bit错误的信道

1、确认和否认机制

假设rdt2.0具有bit错误的信道,因为这个过程下层信道可能让传输分组中的bit受损。校验和将检测到bit错误。
那么当检测到错误以后如何从错误中恢复呢?这里我们采用了确认和否认的机制。
(1)确认(ACK):接收方明确告诉发送方,分组接收正确。
(2)否认(NAK):接收方明确告诉发送方,分组接收出错。
发送方在收到NAK后重发这个分组。

2、rdt新机制

在rdt2.0的新机制,即在rdt1.0中没有的主要有如下:
(1)差错检测:接收方检测到何时出现了比特差错。需要有额外的比特,这些比特被汇集在rdt2.0数据分组的分组检验和字段中。
(2)接收方反馈:接收方提供明确的反馈信息给发送方,如ACK和NAK。
(3)接收方收到有差错的分组时,发送方将重传该分组报文。

3、rdt2.0FSM规范


注意:如果对一个事件没有动作,或没有就事件发送而采取了一个动作,将在横线上方或下方使用符号A表示。
在这个过程中发送方首先等待来自上层的调用,做两个事情,第一个是rdt_send(data)接收上层数据。snkpkt与1.0相比加了一个校验和,可以检测到是否发送错误,之后udp_send(snkpkt)将分组发送出去。之后发送方等待来自接收方的ACK或NAK分组。如果收到一个ACK分组,则发送方知道最近发送的分组已经被正确接收,此时协议返回到等待来自上层调用的状态;如果收到一个NAK分组,则该协议会重传最后一个分组并等待接收方为响应重传分组而回送的ACK或NAK分组。
rdt2.0中接收方的FSM同样只有一个状态,当分组到达时,接收方根据接收到的分组是否受损要么回答一个ACK,要么回答一个NAK。
(1)当没有错误时整个发送方与接收方操作如图所示:

(2)当出现错误场景时发送方与接收方的操作如下图所示:

rdt2.0错误场景其实就是一个停等协议,什么是停等协议呢?就是发送方发送一个报文,然后等到接收方的响应,响应类型有ACK和NAK两种,如果是ACK则为正常数据交付,如果是NAK要进行重传。
处理受损ACK和NAK时会发生如下三种情况:
(1)发送方并不知道接收方发生了什么。例如当我们说话时接收方回答的"请重复一遍",发送方会问“你说什么?”。
(2)增加足够的检验和比特,使发送方不仅可以差错检测,还可以回复差错。对于会产生差错但不丢失分组的信道,这就可以直接解决问题。
(3)发送方收到含糊不清的ACK或NAK分组。

4、rdt2.0致命缺陷

我们考虑当ACK/NAK混淆了会发生什么?这时就会发生上面提到的发送方并不知道接收方发生了什么,使得不能正确重发数据,可能会导致数据重复。
解决方法:发送方给每个分组加一个序号,在ACK/NAK混淆时发送方重发当前分组,之后接收方会丢弃重复的分组但并不向上传递。

三、Rdt2.1:处理混乱的ACK/NAK

1、发送方处理混乱的ACK/NAK

FSM描述如下图:

发送方的FSM是rdt2.0的两倍,这是因为协议状态此时必须反映出目前由发送方正发送的分组或者接收方希望接收的分组的序号是0还是1。在这个过程中发送方首先等待来自上层的调用,通过rdt_send(data)接收上层数据。snkpkt与2.0相比加了一个分组序号,用以标识所发送的分组,之后udp_send(snkpkt)将分组0发送出去。然后发送方等待来自接收方的ACK或NAK回送。如果收到一个ACK分组,则发送方知道最近发送的分组已经被正确接收,此时发送方的分组序号变为1,协议返回到等待来自上层调用的状态;如果收到一个NAK分组,则该协议会重传最后一个分组并等待接收方为响应重传分组而回送的ACK或NAK分组,当接收方收到序号为0的分组时就会知道这是一次重传。

2、接收方处理混乱的ACK/NAK

FSM描述如下图:

接收方首先等待来自下层的调用,现在它希望收到的是一个分组0,当发送方传过来的数据有误时会回送NAK,然后等待发送方发来分组0。当确认数据无误后会将数据传递给上层。此时接收方会期望接收到分组1。

四、Rdt2.2:一个不要NAK的协议

如果不发送NAK,而是对上次正确接收的分组发送一个ACK,我们也能实现与NAK一样的效果。发送方接收到对同一个分组的两个ACK,就知道接收方没有正确接收到跟在被确认两次的分组后面的分组。通俗的来说就是假如发送方先发送分组0,之后发送分组1,这是接收方如果返回来的还是分组0的ACK,发送方接收到两个分组0的ACK,就知道分组1没有被接收方接收到。
rdt2.2同rdt2.1相比功能相同,但是只用ACK不用NAK,接收方此时必须包括一个ACK报文所确认的分组序号,而发送方也必须检查接收到的ACK报文中被确认的分组序号。
发送方、接收方FSM片段如图:

五、Rdt3.0:具有出错和丢失的信道

1、rdt3.0介绍

我们假设下层信道还要丢失报文、数据或者是ACK,校验和、序号、确认、重传虽然有一定的帮助,但是远远不够。
我们采用如下方法:发送者等待“合理的”确认时间。如果在这时间内没有收到ACK就重发该分组。但是如果一个分组经历了特别大的时延,即数据或ACK只是延迟但并没有丢失,发送方也会重传该分组,这就在发送方带接收方的信道中引入了冗余数据分组的可能性。幸运的是rdt2.2中的序号处理已经处理了这个问题。
从发送者的角度来看,重传就好像是”万灵药“一样。发送方并不知道是一个数据分组丢失,还是回送的ACK丢失,还是数据或ACK只是延迟但并没有丢失。以上所有的情况,发送方的动作都是重传。为了实现基于时间的重传机制,需要一个倒计数定时器。倒计数定时器的作用为在一个给定的时间量过期后可以中断发送方。
基于上,发送方要有如下功能:
(1)每次发送一个分组(包括第一次分组和重传分组)时就会启动一个定时器。
(2)采取适当动作响应定时器中断。
(3)终止定时器。
注意:等待的”合理的“时间至少是发送方与接收方之间的一个往返时延加上接收方处理一个分组所需要的时间。
下图为发送方的FSM:

2、rdt3.0操作

基于上图rdt3.0有四种情况,我们用图分别来讲。
(1)无丢包操作

这种情况很好理解,发送方发送分组0,接收方接收0分组并回送ACK0,发送方收到ACK0之后发送分组1,以此类推。
(2)分组丢失

发送方发送分组0,接收方接收0分组并回送ACK0,发送方收到ACK0之后发送分组1,在发送分组1的过程中分组1丢失,发送方等待接收方的回送,等待超时后定时器中断发送方重发分组1,j接收方接收分组1,回送ACK1。

(3)丢失ACK

发送方发送分组0,接收方接受分组0回送ACK0,发送方收到ACK0的回送后发送分组1,接收方接收分组1,但是在回送ACK1时发生丢失,当发送方等待超时后重发分组1,接收方接收分组1,检测冗余,之后回送ACK1。
(4)过早超时

发送方发送分组0,接收方接收分组0并回送ACK0,之后发送方接收ACK0发送分组1,接受方接收分组1并回送ACK1A(为了区别下面的ACK1我们后面分别加个A和B),这时因为过早超时,还没有等到ACK1回送过去就中断定时器重传分组1,接收方收到分组1后进行冗余检测在回送ACK1B,在这同时发送方接收到了最开始接收方回送的ACK1A,然后发送分组0。之后发送方就什么也不做了。

3、rdt3.0性能

rdt3.0能工作但是性能很差,网络协议限制了物质资源的使用!

构造可靠数据传输协议相关推荐

  1. 可靠数据传输原理1(构造可靠数据传输协议)

    TCP向调用它的因特网应用所提供的服务模型(服务抽象) 数据可以通过一条可靠的信道进行传输.借助于可靠的信道,传输比特就不会受到损坏或丢失,而且所有数据都是按其发送顺序进行交付. 可靠传输协议 实现服 ...

  2. 流水线可靠数据传输协议

    在构造可靠传输协议那一篇我们知道rdt3.0的利用率是非常低的,为了解决利用率问题我们用流水线技术解决. 流水线:发送方允许发送多个"在路上的",还没有确认的报文. 流水线技术对可 ...

  3. 基于C语言的可靠数据传输协议的设计与实现

    资源下载地址:https://download.csdn.net/download/sheziqiong/86799219 资源下载地址:https://download.csdn.net/downl ...

  4. UDT协议-基于UDP的可靠数据传输协议

    1.   介绍 随着网络带宽时延产品(BDP)的增加,通常的TCP协议开始变的低效.这是因为它的AIMD(additive increase multiplicative decrease)算法彻底减 ...

  5. 计网必会:UDP差错检测,检验和、可靠数据传输原理

    文章目录 [前言] UDP套接字 无连接运输 UDP 的优势 UDP的差错检测 可靠数据传输 可靠传输的方式总结 构造可靠数据传输协议 可靠信道 具有比特差错的信道 三种可能 [前言] 之前一节我们介 ...

  6. 我tcp可是铁齿金不换,诚实可靠小郎君——谈谈可靠数据传输服务

    附 rdt_send()函数:上层可以调用数据传输协议的发送方.其中 rdt 为 reliable data transmission. 它将要发送的数据交付给位于接收方的上层. rdt_rev() ...

  7. 可靠数据传输基本原理

    可靠数据传输是指:数据可以通过一条可靠信道来传输.传输的数据不会受到损失或者丢失,而且所有数据都是按照其发送顺序进行交付. 我们都知道IP层是不可靠传输的,而TCP是可靠传输的,但是TCP是传输层的协 ...

  8. 计算机网络(14)——可靠数据传输原理

    文章目录 可靠数据传输原理 构造可靠数据传输协议 经完全可靠信道的可靠数据传输:rdt 1.0 经具有比特错误信道的可靠数据传输:rdt 2.0 经具有比特错误信道的可靠数据传输:rdt 2.1 经具 ...

  9. 计算机网络自顶向下方法 第三章 运输层 3.4 可靠数据传输原理

    计算机网络自顶向下方法总结3.4可靠数据传输原理 目录 3.4 可靠数据传输原理 3.4.1 构造可带数据传输协议 3.4.2 流水线可靠数据传输协议 3.4.3 回退N步 3.4.4 选择重传 3. ...

最新文章

  1. JAVA     面向对象
  2. PyTorch、TensorFlow最新版本对比,2021年了你选谁?
  3. Day 4:PredictionIO——如何创建一个博客推荐器
  4. Python 将两层列表展开平铺成一层
  5. apache日志记录格式LogFormat参数说明
  6. EMR StarRocks 极速数据湖分析原理解析
  7. C和指针 第十六章 标准函数库 本地跳转setjmp.h
  8. ntko web firefox跨浏览器插件_Web浏览器如何使用进程和线程
  9. 5-IP地址、端口、DNS服务器
  10. PMP项目管理—项目风险管理(7)
  11. 笔记本电脑无线网络连接不上怎么办
  12. eureka的自我保护机制?
  13. Variable used in lambda expression should be final or effectively final
  14. 资产监测技术中关于USIM卡座在PCB layut设计中注意事项浅谈
  15. 圣邦微电子2023校招笔试
  16. 如何搭建一个简单的个人网站
  17. canopen pdo通信c语言,CANopen通信之PDO通信
  18. (点击||敲击)发出声音特效「HTML+CSS+JavaScript」项目总结
  19. 1.项目介绍——毕业设计之论坛项目
  20. 关于 字号、PX像素、PT点数、em、CM厘米、MM毫米之间的换算

热门文章

  1. 杭州/北京内推 | 阿里达摩院自然语言智能生物医学团队招聘研究型实习生
  2. 强烈推荐十大NLP主流经典项目:预训练BERT、知识图谱、智能问答、机器翻译、文本自动生成等...
  3. 加速DeiT-S 60%+吞吐量!腾讯优图提出高性能Transformer加速方法
  4. 推荐系统的构建:从经典到深度学习方法
  5. 细粒度情感分析任务(ABSA)的最新进展
  6. poj3126 Prime Path BFS
  7. windows 下 logstash 安装启动
  8. oracle protocol=beq 不可用,学习笔记:Oracle数据库坏块 深入研究obj$坏块导致exp/expdp不能执行原因...
  9. Java实现返回的数据为树形结构
  10. Little Sub and Game