zoukankan      html  css  js  c++  java
  • TCP可靠传输的实现

    1.以字节为单位的滑动窗口

      TCP的滑动窗口是以字节为单位的。现假设A收到了B发来的确认报文段,其中窗口是20字节,而确认号是31.根据这两个数据,A就构造出自己的发送窗口。如下图所示。

      发送窗口表示:在没收收到B的确认情况下,A可以连续把窗口内的数据都发送出去。凡是已经发送的数据,在未收到确认之前都必须暂时保留,以便超时重传。发送窗口里面的序号表示允许发送的序号。显然,窗口越大,发送方就可以在收到对方确认之前连续发送更多的数据,因而具有更高的传输效率。但是接受方必须来得及处理这些数据。

      发送窗口后沿表示已经发送且已经收到了确认。这些数据不需要再保留在缓存。发送窗口前沿的前面部分表示不允许发送的数据,因为接收方没有为这部分数据保留临时存放的缓存空间。发送窗口的位置由窗口前沿和后沿的位置共同确认。发送窗口后沿的变化情况有两种可能,即不动(没有收到新的确认)和前移(收到了新的确认)。发送窗口后沿不能向后移动,因为不能撤销已收到的确认。发送窗口前沿通常是不断向前移动,但也有可能不动。发送窗口前沿也有可能向后收缩。这发生在对方通知的窗口缩小了。但TCP的标准强烈不赞成这样。因为很有可能发送方在收到这个通知以前已经发送了窗口中很多的数据,现在又要收缩窗口,不让发送这些数据,这样会产生一些错误。

      如图B的接收窗口大小是20.在接收窗口外面到30号为止的数据是已经发送过确认的,并且已经交付给主机。因此B可以不保留这些数据。接收窗口内的序号(31~50)是允许接收的。如上图B收到了32和33号数据。这些数据没有按序到达,因为对按序接收到的数据中的最高序号给出确认,因此B发送的确认号任然是31(即期望收到的序号),而不能是32或33.

     超时重传时间的选择

      TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。重传时间的选择是TCP最复杂的问题之一。如果把超时重传时间设置太短,就会引起许多报文段不必要的重传,是网络负荷增大。但把超时重传时间设置的太长,则又使网络的空闲时间增大,降低传输效率。

     

     选择确认SACK

  • 相关阅读:
    轻量级javascript库不用写CSS3动画 Move.js
    ajax post 和 get方法详解
    HTML5 localStorage图书阅读器实例
    css3 监听webkitAnimationEnd运动结束 后执行什么
    设计模式四 工厂模式
    设计模式三 原型模式
    设计模式二 单例模式
    设计模式一 6大设计原则
    zookeeper 源码编译
    plantuml 基本语法(转摘)
  • 原文地址:https://www.cnblogs.com/wxgblogs/p/5612066.html
Copyright © 2011-2022 走看看