博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
TCP可靠传输的实现
阅读量:7294 次
发布时间:2019-06-30

本文共 926 字,大约阅读时间需要 3 分钟。

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

转载于:https://www.cnblogs.com/wxgblogs/p/5612066.html

你可能感兴趣的文章
软件测试2019:第五次作业—— 安全测试(含安全测试工具实验)
查看>>
SSM框架搭建总结(2)
查看>>
Python学习(19)正则表达式
查看>>
PHP中空字符串、0、null、empty和false之间的关系
查看>>
【深度学习篇】---CNN和RNN结合与对比,实例讲解
查看>>
201771010126 王燕《面向对象程序设计(Java)》第十二周学习总结
查看>>
XAML实例教程系列 - 资源(Resources)
查看>>
LWIP互联网资料汇总
查看>>
外贸术语
查看>>
网络传输流量控制策略小结
查看>>
上传大文件
查看>>
Mybatis面试集合(转)
查看>>
分布式系统的完整介绍(一)
查看>>
考点1
查看>>
Asp.net 程序连接orcle如果在安装 32 位 Oracle 客户端组件的情况下以 64 位模式运行,...
查看>>
自己写的模板引擎,模板生成静态页面
查看>>
Android 数据库管理— — —更新数据
查看>>
014_捆绑包与显示模式
查看>>
python : logging模块format类
查看>>
[LeetCode] Two Sum
查看>>