可靠数据传输原理 一(rdt3.0)

Http Socket 2018-05-30

在Rdt2.0及2.x时代,假定的是信道只有一种不可靠特征,也就是只发生位bit的错误,不会丢失分组等错误,现在假设更实际一些。

如果信道极可能发生错误,也可能丢失分组,怎么办?

  • “校验和+序列号+ACK+重传”够用吗?

例子假如说现在发送方发了一个分组给接收方,而接受方没有收到,则接收方一直等着,发送方也一直等着接收方发来确认消息。

这时候这些机制就不够用了,怎么处理分组丢失呢?

解决办法:

设置一个等待的合理的时间。过了时间就重传。

  • 如果没有收到ACK,重传。
  • 如果分组或者ACK知识延迟,而不是丢了。
    重传会产生重复,序列号机制能够处理
    接收方需要在ACK中显式告知所确认的分组
  • 需要定时器。

状态图

下面是正常情况:


发送方发了pkt0,接收方收到后,发ack0。然后发送方收到了ack0,则继续发pkt1,接收方正常接收后,发ack1.发送方收到后,再发pkt0...

下面是丢包的情况下:


当发pkt1的时候,发送失败后,timeout后,触发再次发送pkt1。

如果丢失了ack怎么办?


ack1没有发给发送方,则过了timeout的时间后发送方会重新发送pkt1,这时候其实接收方接到了两次pkt1,删除掉重复的,然后再发一次ack1(ack永远是最后一个收到的分组)给发送方

如果定时器设置过短呢?

在发送方没有接受到ack的时候,又重传的情况

网络延迟是不确定的,timeout的值不好设定。

Rdt3.0功能正确的,性能怎么样?


Rdt3.0性能是由于这样的停等操作引起的效率非常低。


过了半个rtt,第一个bit到达接收方,再过L/R的时间,该分组的最后一个bit到达接收方,然后发ack(ack很小可以认为一次性发过去),再花半个RTT的时间,到达发送方。所以发送一个分组的总时间为t=RTT+L/R.
所以利用率就是


本文由 方方無 创作,采用 知识共享署名 3.0,可自由转载、引用,但需署名作者且注明文章出处。

还不快抢沙发

添加新评论

shijiebei 365bet manbetx 188bet xinshui caipiao 95zz tongbaoyule beplay 88bifa 18luck betway bwin hg0088 aomenjinshayulecheng ca88 shenbotaiyangcheng vwin w88 weide