免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: jiufei19

TCP协议中Window Scale Option问题【完全解决】 [复制链接]

论坛徽章:
0
发表于 2010-01-19 11:11 |显示全部楼层

回复 #10 jiufei19 的帖子

> 那么当接收方的右边界rcv.wup+rcv.wnd - snd.una > 2**31后,为啥接收方会丢掉重发的
> 数据?或者换句话讲,即便不大于2**31,重发的数据因为之前已经被收到了,
> 只是ACK尚未到达发送方,因此发送方若重发的话,这样就不丢掉了吗?

是同样都丢掉了,但是情况稍微有些不同。按照2**31的规定,如果receiver收到超过2**31的包的话,就因为too old而直接丢掉了。而如果在2**31的范围内的话,就需要处理duplicate包的情况,即需要告诉sender它收到了duplicate的数据包。


> 另外接收窗口右边界的位置是受接收方应用进程的控制,所以,假设在发生out-of-phase后,
> 接收方应用若读取了部分数据,那么其右边界可能超过了2**31的位置,难道这个情况不可能
> 吗?

这当然是有可能的,但是我们只是在讨论一种极端的情况,以推出max window的大小,没必要深究更detail的情况。

论坛徽章:
1
IT运维版块每日发帖之星
日期:2015-11-17 06:20:00
发表于 2010-01-19 13:14 |显示全部楼层

回复 #10 jiufei19 的帖子

另外,我还有一个不解就是,为啥不能出现下面的这个方式呢,即窗口大小为2G,这样就恰好应证了我之前的那个2**31的分析了:

snd.una     
snd.nxt     snd.una + snd.wnd
  +---------------------+
  |  Sender                  |
  +---------------------+
                            2**31                          2**32
  +---------------------+-----------------------+
                               +-----------------------+
                                |          Receiver          |
                               +-----------------------+
                           rcv.wup      rcv.wup+rcv.wnd
                           rcv.nxt

[ 本帖最后由 jiufei19 于 2010-1-19 13:42 编辑 ]

论坛徽章:
1
IT运维版块每日发帖之星
日期:2015-11-17 06:20:00
发表于 2010-01-19 13:41 |显示全部楼层
仔细阅读了eexplorer的解释和说明,以及我再次阅读那几个rfc文档,我忽然想到了这样一个似乎“完善”的说明:

1、根据我最前面的分析,已经知道了|snd.una - rcv.wup+rcv.wnd|<=2**31是合理的,即发送窗口最左边的数据序号和接收窗口的最大可接收数据序号只要相差在2**31,即半个32bit序号空间大小,那么old和new数据就肯定不会混淆(这是肯定的,因为一半的使用率完全限制了回绕造成的冲突)。不过要注意这里的不会混淆的代价是网络速率虽然可能较高了,但不是很高,也即在不采用PAWS的算法下,该tcp的吞吐量不是很受影响,换句话讲,如果网络速度非常高,则限制为32bit一半的序号空间的做法,虽然可以避免回绕带来的混淆问题,但是却会造成严重的吞吐量下降,此时必须引入PAWS算法来避免序号的快速回绕



2、在满足1的序号条件下,则发送和接收的最大out-of-phase情况只能是如下情况,此时实际发送和接收窗口只能是2**31的一半,即2**30

snd.una     
snd.nxt     snd.una + snd.wnd
  +----------+
  |  Sender   |
  +----------+
                               2**31                          2**32
  +----------------------+-----------------------+
                 + ----------+
                 |  Receiver   |
                 +- ---------+
        rcv.wup      rcv.wup+rcv.wnd
        rcv.nxt

[ 本帖最后由 jiufei19 于 2010-1-19 13:44 编辑 ]

论坛徽章:
0
发表于 2010-01-19 13:44 |显示全部楼层
原帖由 jiufei19 于 2010-1-19 13:14 发表
另外,我还有一个不解就是,为啥不能出现下面的这个方式呢,即窗口大小为2G,这样就恰好应证了我之前的那个2**31的分析了:

snd.una     
snd.nxt     snd.una + snd.wnd
  +---------------------+
  |  ...



在这种情况下,如果receiver收到一个seq = 0的数据包,那它就不能区分是新的还是旧的了。可能这就是tcp规定2**31的原因了。。。

论坛徽章:
1
IT运维版块每日发帖之星
日期:2015-11-17 06:20:00
发表于 2010-01-19 13:50 |显示全部楼层

回复 #14 eexplorer 的帖子

eexplorer是否是这个意思:

因为之前一个窗口的seq=0的序号分段虽然已经收到了,导致接收窗口的右边沿到了2**32-1,但是由于此时发送方没有收到应答,于是可能重发了一个seq=0的分段,但是此时即将发送的一个新分段的seq也为0,于是接收方可能将这个新0分段当成了老的

论坛徽章:
0
发表于 2010-01-19 13:58 |显示全部楼层
原帖由 jiufei19 于 2010-1-19 13:50 发表
eexplorer是否是这个意思:

因为之前一个窗口的seq=0的序号分段虽然已经收到了,导致接收窗口的右边沿到了2**32-1,但是由于此时发送方没有收到应答,于是可能重发了一个seq=0的分段,但是此时即将发送的一个 ...


sender重发一个seq = 0的segment,但是receiver不知道这个segment是新的还是旧的,即应该丢掉还是放到自己的receive queue里。

论坛徽章:
1
IT运维版块每日发帖之星
日期:2015-11-17 06:20:00
发表于 2010-01-19 14:05 |显示全部楼层

回复 #16 eexplorer 的帖子

恩,就是这个意思,那么再请eexplorer看看我在13楼做的一个该问题的小结是否合理,谢谢!

论坛徽章:
1
IT运维版块每日发帖之星
日期:2015-11-17 06:20:00
发表于 2010-01-19 14:07 |显示全部楼层

回复 #16 eexplorer 的帖子

恩,就是这个意思,那么再请eexplorer看看我在13楼做的一个该问题的小结是否合理,谢谢!

论坛徽章:
0
发表于 2010-01-19 14:30 |显示全部楼层
原帖由 jiufei19 于 2010-1-19 14:07 发表
恩,就是这个意思,那么再请eexplorer看看我在13楼做的一个该问题的小结是否合理,谢谢!


> 如果网络速度非常高,则限制为32bit一半的序号空间的做法,虽然可以避免回绕带来的混淆问题,但是却会造成严重的吞吐量下降,
> 此时必须引入PAWS算法来避免序号的快速回绕


我始终觉得,引入2**31的限制只是在理论上做了一些限制,用来推导一些别的东西,如max window size的问题。
实际情况下:
1. 不可能有那么大的窗口
2. PAWS应该更常用
所以问题没这么严重。

不过佩服你的学习钻研精神,我也学到了不少东西。

论坛徽章:
1
IT运维版块每日发帖之星
日期:2015-11-17 06:20:00
发表于 2010-01-19 14:54 |显示全部楼层

回复 #19 eexplorer 的帖子

谢谢eexplorer的夸奖哈,我一直比较注意这些细节,也许有点过于?不过这个概念和精确理解滑动窗口的原理是有密切联系的,我一直感到自己对滑动窗口的概念没有精确理解,泛泛讲还觉得自己掌握了,但是一到代码有时就有点糊涂了:(

另外,2**31一定不是随意想出来的数,肯定是在一个条件下得到的,我认为就是按照如下2点:
1、窗口大小是2的整数次幂
2、限制为2**32的一半,理论上肯定序号回绕肯定不会导致混淆问题出现,因为前后序号相差只能最大达到2**31,因此当回绕后,最早前一个窗口的序号已经越过了2**31,所以如果用刚才的例子seq=0,则此时该序号一定是新的数据了。不过这里一定要注意这样来保证序号回绕问题不会产生麻烦的代价就是吞吐量下降了,否则PAWS也没有必要引入

再次感谢eexplorer的热心哈,总是在我需要的时候你给出的解答能让我进一步理解,虽然有时不能完全彻底
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP