放心网站推广优化咨询,灵犀科技网站建设,有专业做网站的,图文网站模板可靠数据传输原理 可靠数据传输依靠数据在一条可靠信道上进行传输。
TCP也正是依靠可靠信道进行传数据#xff0c;从而数据不会被丢失。
而实现这种可靠数据传输服务是可靠数据传输协议的责任
构造可靠数据传输协议
1.经完全可靠信道的可靠数据传输#xff1a;rdt1.0
在…可靠数据传输原理 可靠数据传输依靠数据在一条可靠信道上进行传输。
TCP也正是依靠可靠信道进行传数据从而数据不会被丢失。
而实现这种可靠数据传输服务是可靠数据传输协议的责任
构造可靠数据传输协议
1.经完全可靠信道的可靠数据传输rdt1.0
在协议rdt1.0下底层信道是完全可靠的。 上图是rdt1.0发送方和接收方的有限状态机的定义。
经具有比特差错信道的可靠数据传输rdt2.0
rdt2.0的底层信道是不可靠的在该信道下分组中的比特可能会受损。
考虑一下你自己是怎样通过电话口述一条长报文的。在通常情况下报文接收者在 听到、理解并
记下每句话后可能会说“0K” 。如果报文接收者听到一句含糊不清的话时, 他可能要求你重复那句容
易误解的话。这种口述报文协议使用了肯定确认(OK”)与否定确认(请重复一遍)。这些 控制报文使
得接收方可以让发送方知道哪些内容被正确接收哪些内容接收有误并因此需 要重复。在计算机
网络环境中基于这样重传机制的可靠数据传输协议称为自动重传请求 (Automatic Repeat
reQuest, ARQ)协议。
ARQ协议还需要另外三种协议功能来处理比特差错的情况。
1.差错检测。需要一种机制以使接收方检测到何时出现了比特差错。
2.接收方反馈。因为发送方和接收方通常在不同端系统上执行可能相隔数千英里发送方要了解接收方的情况此时分组是否被正确接收的唯一途径就是让接收方提供明确的反馈信息给发送方。
3.重传。接收方收到有差错的分组时发送方将重传该分组文。 在rdt2.0下发送方有两个状态。
最左边的状态发送端协议正等待来自上层传下来的数据。
最右边的状态发送端协议等待接收一个ACK/NAK分组。
如果接受到ACK代表分组已经被正确接收此时关闭该状态重新变为最左边的状态对于这种行为我们也称之为“停等”。
而接收方仍然只有一种状态并且只会回答ACK/NAK(正确/错误)这取决于分组是否受损。
尽管如此rdt2.0仍然存在很大问题因为ACK或者NAK在返回的时候也有可能受损
下面考虑处理ACK和NAK时受损的三种可能性
1.接收方可能并不能理解会大方的ACK和NACK是什么意思显然这不可能
2.增加足够多的检验和比特使发送方不仅可以检测差错还可恢复差错。
对于会产生差错但不丢失分组的信道这就可以直接解决问题。
3.第三种方法是重发分组然而这种方法会向信道中引入亢余分组。
对于这些可能性其实有一个简单方法几乎所有现有的数据传输协议中包括TCP、都采用了这种方法是在数据分组中添加一个新字段让发送方对其数据分组编号即将发送数据分组的序号放在该字段。
于是接收方只需要检查序号即可确定接收到的分组是否一次重传。
下面是rdt2.1的FSM描述是rdt2.0的修订版rdt2.1的发送方和接收方FSM的状态数都是以前的两倍。这是因为协议状态必须反映出目前由发送方正发送的分组或在接收方希望接受的分组序号是0还是1。 以上是rdt2.1发送方 以上是rdt2.1接收方。
经具有比特差错的丢包信道的可靠数据储传输rdt3.0
现在我们界定除了比特受损外底层信道还会丢包。
一个处理这个问题的方法是“重传”。
在发送方发送完一个分组后如果长时间没有接收到ACK则会自动重传。
问题关键在于等待的时间该如何确定
注意到如果一个分组经历了特别大的时延但是没有丢失发送方仍然会重传一个分组这就造成了亢余数据分组的问题幸运的是rdt2.2协议已经能处理亢余分组情况了。
因此为了实现时间的重传机制需要一个倒计数定时器。
在一个给定的时间量过期后可中断发送方。
因此发送方需要做到
1.每次发送一个分组时便启动一个定时器。
2.响应定时器中断。
3.终止定时器。
下图给出了rdt3.0的发送方FSM。 下面是rdt3.0在运行过程中四种协议运作的情况
rdt3.0有时被称为比特交替协议 上图中的括号代表计时器建立时间以及终止时间。
流水线可靠数据传输协议
rdt3.0是一个共功能正确的协议但是rdt3.0作为一个停等协议会严重造成性能浪费
为此一种不以停等方式工作的协议诞生了被称为“流水线”。
流水线协议不以停等方式运行允许发送方发送多个分组而无需等待确认如下图所示 但流水线技术也带来了下面三个影响
1.必须增加序号范围因为每个输送中的分组必须有一个唯一的序号。
2.协议的发送方和接收方两端也许不得不缓存多个分组。发送方最低限度应当能缓冲那些已发送但没有被确认的分组。
3.所需序号范围和对缓冲的要求取决于数据传输协议如果处理丢失、损坏及延时过大的分组。
解决流水线的差错恢复有两种基本方法是
回退N步GBN和选择重传(SR)。
回退N步
允许发送方发送多个分组而不需等待确认但也受限于在流水线中未确认的分组数不能超过某个最大允许数N。
下图是一个发送方看到的GBN协议的序号范围 其中我们将基序号base定义为最早未确认分组的序号将下一个序号nextseqnum定义为
最小未使用的序号即下一个待发分组的序号。
则可以将上面的序号范围分割成四段在[0base-1]段内的序号已经发送在[base
nextseqnum-1]为已发送但是未接收到响应的分组在[nextseqnumbaseN-1]段内的序号是马上
要被立刻发送出的分组大于baseN-1的序号是不能使用。
因此这个序号范围可以被看作是一个长度为N的窗口。
通常随着协议的运行该窗口会向前滑动而N常被称为窗口长度。
GBN协议也被常常称为滑动窗口协议。
该窗口也可以想象为一个队列不断地进出元素未发送的分组序号/已发送且收到回应的分组序号。
下图为GBN的扩展FSM图 除此之外GBN发送方必须响应三种类型的事件
1.上层的调用。当上层调用时发送方检查发送窗口是否已满若未满则产生一个分组并将其发送并更新变量base、nextseqnum。若窗口已满发送方则隐式的告诉上层该窗口已满。
2.收到一个ACK。在GBN协议中对序号为n的分组的确认采取累积确认的方式表明接收方已正确接收到一个窗口容量的分组。
3.超时事件。若出现超时发送方重传所有已发送但还未被确认过的分组。
而接收方的动作也很简单如果一个序号为n的分组被正确的接收到并且按序接收到即上次交付的分组序号为n-1则接收方为分组n发送一个ACK。
其它所有情况下接收方会丢弃该分组。
选择重传
在上面所说的GBN协议潜在地允许发送方用多个分组填充流水线因此避免了停等协议中所提到
的信道利用率的问题。但是GBN本身也有一些情况存在着性能问题尤其是当窗口长度和宽带时
延积都很大时在流水线中会有很多分组处于重传状态。这会导致接收到的数据很断断续续的严
重影响使用感。
而选择重传SR只会选择性的重传它觉得可能出错或出错的位置具体的原理是当发现出错
后接收方会缓存出错序号的所有分组直到该分组之前的正确分组被传送过来这一批分组才会
按照次序被传送给上层。 当我们面对有限序号范围的现实时发送方和接收方窗口间缺乏同步会产生严重的后果。
下面两个例子都代表了接收方无法区别新传来的分组是上一次传输的重传副本还是新一次传来分组的起始。 下面我们来看一个对于该节知识点的一个总回顾图片。
