1 什么叫可靠

  数据在传输过程中,不错,不丢,不乱。

 

2 信道是不可靠的

  可靠数据传输对应用 层、传输层、链路层都很重要。

  如下图,数据在信道中传输是不可靠的。

  信道的不可靠特性决定了可靠数据传输协 议(rdt)的复杂性

 

3 可靠传输协议的基本架构

 

4 可靠传输协议设计

  渐进地设计可靠数据传输协议的发送方和接收方,一步一步的完善可靠传输协议的设计。只考虑单向数据传输,控制信息可以双向流动。

  利用状态机(Finite State Machine, FSM)刻画传输协议

 

4.1 简单版本1.0

  假设底层信道完全可靠,不会发生错误,不会丢弃分组

  

  在这种前提下,设计就非常简单了

  发送方:

    状态wait for call from above:等待上层应用发送数据过来,此时可接收上层数据

    当上层应用发送数据过来,通过信道发送到接收方(此时不接收上层应用数据),发送完成,回到wait for call from above状态

  接收方:

    状态wait for call from above:等待发送方发送数据过来

    当发送方发送数据过来,接收数据,接收完成,回到wait for call from above状态

 

4.2 进一步版本2.0

  假设底层信道不可靠,但是只会翻转分组中的位,也就是0变1,1变0

  要保证可靠,就需要增加一些东西:

    校验和(用来检测位错误)

    确认机制:接收方校验无误,给发送方返回ACK,有误,给接收方返回NAK

    重发机制:发送方收到NAK,重新发送

     

  停等协议:发送方发送数据,要等待接收方的应答,根据应答再进行下一个行动。保证数据一个一个有序的发送。

  发送方:

    状态wait for call from above:等待上层应用发送数据过来,此时可接收上层数据

    当上层应用发送数据过来,通过信道发送到接收方(此时不接收上层应用数据),此时状态变为 wait for ack or nak(等待接收方的应答)

  接收方:

    状态-wait for call from above:等待发送方发送数据过来

    当发送方发送数据过来,接收数据,接收完成,检查数据

      无误:接收方返回ACK,变为wait for call from above状态,发送方收到ACK,此次数据传输成功,变为wait for call from above状态

      有误:接收方返回NAK,变为wait for call from above状态,发送方收到NAK,此次数据传输失败,重新传输数据

 

4.3 再进一步3.0

  在2.0版本,还存在问题,如果ACK/NAK这个应答发生错误或者被破坏了,发送方就不知道数据到底发送成功还是失败了。

  方案:如果ACK/NAK坏掉,发送方重传。

  这样又会存在数据重复问题,接收方正确回到数据,返回ACK,ACK被破坏了,发送方重发,接收方接收,这样一份数据收了两份,重复了。

  方案:发送方给每个数据增加一个序列号,接收方丢弃重复数据是。由于采用的停等模式,所以只需要0和1两个数据作为序列号就足够了。

  发送方应对ACK/NAK破坏

  

   接收方应对ACK/NAK破坏

 

 

4.4 进一步优化4.0

  3.0应答采用的ACK和NAK,可以去掉NAK,使用ACK配合序号来应答。

  发送方发送序号为0的数据,接收方应答ACK+0表示成功,应答ACK+1表示失败
  同理,发送方发送序号为1的数据,接收方应答ACK+1表示成功,应答ACK+0表示失败

 

4.5 继续完善5.0

   在4.0,只是信道只会发生位变错误,实际上信道既可能发生错误,也可能丢失数据。

  那么校验和 + 序列号 + ACK + 重传就不够用了

  方案:发送方加一个等待超时机制,加一个定时器。发送方等待“合理”时间,超过这个时间,如果没收到ACK,重传。如果分组或ACK只是延迟而不是丢了,重传会产生重复,序列号机制能够处理重复的问题

  

 

 

4.6 性能提升6.0

4.6.1 缺点

 5.0能够正确工作,但性能很差。

  

 

 

 

4.6.2 流水线机制

  不采用停等机制,而是流水线机制。也就是发送方发送一个数据,不需要等待接收方的应答,就发送下一个数据。这样,效率就会高很多,提高资源利用率。

 

4.6.3 滑动窗口协议介绍

  滑动窗口协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认。因此该协议可以加速数据的传输,提高网络吞吐量。
  滑动窗口: 随着协议的运行,窗口在序列号空间内向前滑动    
  两种滑动窗口协议:GBN(Go-Back-N), SR(Selective Repeat)
 
4.6.4 发送方(GBN协议)

  分组头部包含k-bit序列号,所以共有2^k个序列号

  窗口尺寸为N,所以最多能有N个数据分组处于发送未响应的状态

  超时事件:若序号为n的数据分组超时了,重传序号列大于等于n,且还未收到ACK的所有分组

    如,发送方发送1/2/3/4/5/6/7,接收方接收1,返回ack1,接收2,返回ack2,接收3.返回ack3

    接收5,由于5不是按序到达的,直接舍弃,接收4,返回ack4,接收6,舍弃,接收7舍弃 

    发送方收到ack1,ack2,ack3,没有收到ack4,超时触发重发,把4/5/6/7全部重发 

 

4.6.5 接收方(GBN协议)

  按序接收,不是按序到达的直接舍弃。

   

4.7 性能提升7.0

4.7.1 缺点

  6.0能够采用GEB协议能正确工作,相较于5.0效率有所提升。

  但是,为了保证正确有序,接收方会舍弃不是按序到达的数据分组。而发送方一旦某个序号没有正确发送,序号大于等于它的全部需要重发。

  这样效率也损耗了很多。

  为了增加效率,采用SR协议。相较于GBN,它增加了缓存机制,它在接收方也设置了窗口,还设置了缓存。

 

4.7.2 发送方(SR协议)

  分组头部包含k-bit序列号,所以共有2^k个序列号

  窗口尺寸为N,所以最多能有N个数据分组处于发送未响应的状态

  超时事件:若序号为n的数据分组超时了,重传序号列大于等于n,且还未收到ACK的所有分组

 

  如上图:
    N为窗口的大小
    绿色的为已正确发送完成的数据分组序号
    黄色的表示已发送等待应答的数据分组序号
    蓝色的表示窗口空闲的,可发送的数据分组序号
    白色的表示还不能发送的数据分组序号
 
  
 
 

4.7.3 接收方(SR协议)

  ACK机制: 发送拥有最高序列号的、已被正确接收的分组的ACK

  乱序到达的,若有空闲的窗口,缓存起来。无空闲窗口,直接舍弃。

 

  如上图:
    N为窗口的大小(接收方和发送方的窗口大小可以不一致)
    绿色的为已正确接收完成的数据分组序号
    黄色的表示已接收缓存起来的数据分组序号
    蓝色的表示窗口空闲的,可继续接收的分组数据分组序号
    白色的表示还不能接收的数据分组序号
  

 

4.7.4 示例

  发送方窗口大小为4,接收方窗口大小也为4,共有序号为0-5的6个数据分组要发送

 

    1)发送方发送序号为0/1/2/3的数据分组,由于窗口大小是4,不能继续发送,等待应答

  2)接收方收到0,数据分组没有问题,应答ACK0,窗口右移一格

     3)接收方收到1,数据分组没有问题,应答ACK1,窗口右移一格

   4)2丢失了

   5)接收方收到3,数据分组没有问题,不是按序到达,缓存起来,应答ACK1(ACK机制: 发送拥有最高序列号的、已被正确接收的分组的ACK,由于被正确接收的最大的序号是1,所以应答ACK1)

   6)发送方收到ACK0,窗口右移一格,发送数据分组4

   7)发送方收到ACK1,窗口右移一格,发送数据分组5

   6)发送方一致没收到ACK2,超时了,重发2/3/4/5(超时事件:若序号为n的数据分组超时了,重传序号列大于等于n,且还未收到ACK的所有分组)

   7)接收方收到2,数据分组没有问题,应答ACK2,窗口右移一格

   8)由于缓存中已有3,应答ACK3,窗口右移一格

   9)接收方又收到3,舍弃

   10)接收方收到4,数据分组没有问题,应答ACK4,窗口右移一格

   11)接收方收到5,数据分组没有问题,应答ACK5,窗口右移一格

   12)发送方收到ACK3,窗口右移一格

   13)发送方收到ACK4,窗口右移一格

   14)发送方收到ACK5,窗口右移一格

 

 

  

 

原文地址:http://www.cnblogs.com/jthr/p/16864113.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性