TCP可靠传输的实现
博客专区 > MrYx3en 的博客 > 博客详情
TCP可靠传输的实现
MrYx3en 发表于3年前
TCP可靠传输的实现
  • 发表于 3年前
  • 阅读 36
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 新注册用户 域名抢购1元起>>>   

TCP的滑动窗口是以字节为单位的。为描述可靠传输原理的方便,现假定数据只在一个方向上传输。

假定A收到B发来的确认报文段,其窗口是20,确认号是31(B 期望 收到的下一个序号是31,而序号30为止的数据以及收到了),根据这两个数据,A构造出了自己的发送窗口,如下:


发送方A的  发送窗口表示:在没有收到B的确认的情况下,A可以连续的把窗口内的数据都发送出去。凡是已经发送过的数据,在未收到确认之前都必须暂时保留,以便在超时重传时使用。

        发送窗口里面的序号表示允许发送的序号(31-50);

        发送窗口的后沿的后面部分表示“已发送并收到确认”的数据;发送窗口的前沿的前面部分表示“不允许发送”,因为此时B(接收方)还没有为这部分数据保留临时的缓存空间;发送窗口的大小由前沿和后沿的位置共同决定。前【前移或者不动(收到了确认但是对方通知的窗口变小了)】;后沿 【不动(没有收到新的确认)或前移(收到了新的确认)】                    虽然前沿也有可能会向后收缩,但是TCP标准强烈不赞成这样做

描述一个发送窗口需要三个指针(个人理解:P1指向此时的确认号   P3指向下一个确认号   P2指向已发送但未收到确认的最后一个序号  P3-P2即 允许发送但是尚未发送的称为可用窗口或者有效窗口)

B的接收窗口:

B的接收窗口大小是20。在接受窗口外,到30为止的数据是发送过确认并且已经交付主机使用了,因此B不在保留这些数据,接收窗口内的(31-50)是允许接收的,由于B只能对按序收到的数据给出确认号,所以图中接收到了32、33,但是由于31在传输的图中丢失或者其他原因导致数据没有按序到达,所以B发送的确认号任然是31(期望收到的序号)。

现在假设B收到了序号31的数据,而且已经把序号31 - 33 交付主机了,然后B删除了这些已经确认过的数据,接着把接收窗口向前移了3个序号,同时给A发出确认,其中窗口值仍为20,但确认号是34(期望接收到的序号),表明B已经接收到了到33为止的数据。图中B还接收到了 37 38 40序号的数据,但这些都没有按序到达,所以都只能暂存在接收窗口。            A收到B的确认后,就可以把发送窗口向前滑动3个序号,但是指针P2(P2指向允许发送但未发送的第一个序号)不动,此时A的有效窗口增大了,可以发送的范围  42 - 53.


A在继续发送完数据42 - 53之后,指针P2向前移动与P3重合。发送窗口的序号都用玩了,此时 有效窗口 的大小为零,因此必须停止发送,等待B的确认回复,但是如果A在一段时间内没有收到B的确认回复,由于要保证可靠传输,A只能认为B还没收到这些数据,所以A在经过一段时间之后(由超时计时器控制)就重传这部分数据,重设超时计数器,直到收到B的确认回复为止。如果A收到确认号落在发送窗口内,那么A就可以是发送窗口继续向前滑动,并发送新的数据。


发送发的应用程序把字节流写入TCP的发送缓存,接收方的应用程序从TCP的接受缓存中读取字节流。

缓存空间和序号空间都是循环使用的。

窗口和缓存的关系:

发送缓存暂时存放:

            发送应用程序传送给发送发TCP准备发送的数据;

            TCP已发送出但是尚未收到确认的数据。


接受缓存暂时存放:

        按序到达的但是尚未被应用程序读取的数据;

        未按序到达的数据。

强调内容:

    A的发送窗口并不总是和B的接收窗口一样大小;

    TCP通常对不按序到达的数据先临时存放在接收窗口中,等到字节流中所缺失的字节收到后,在交付给上层应用进程;

    TCP要求接收方必须有累计确认的功能,这样可以减小传输开销。


超时重传时间

    TCP每发送一个报文段,就会对这个报文段设置一个计时器,计时器设置的重传时间到了却还没有收到确认,就要重传该报文段。


选择确认(SACK)

    如果收到的报文段没有差错,只是没有按序,或者中间缺少了一些虚耗的数据,采用选择确认的方法来重传缺少的数据,而不重传已经正确传输的数据。


共有 人打赏支持
粉丝 10
博文 88
码字总数 30598
×
MrYx3en
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: