TCP协议中Window Scale Option问题【完全解决】

jiufei19

大家好，我在继续研读Stevens的“TCPIP协议详解卷1”中，又遇到了关于window scale option的一个问题，望大家不吝赐教，下面是问题描述。


在24.4 Window Scale Option中有如下文字：
We saw an example of this option in Figure 18.20. The 1-byte shift count is between 0 (no scaling performed) and 14. This maximum value of 14 is a window of 1,073,725,440 bytes (65535 × 2^14).

这里我没有懂的是为啥scale的最大范围是左移14位，即2^14次幂，这个14是如何得到的？

我查阅了下rfc1323，其中有针对这个14的计算来由，但是不幸的是，该rfc中和14有关的地方我仍然没有明白，所以非常郁闷，请大家帮帮我，下面是rfc1323中有关的内容：

2.3  Using the Window Scale Option
        ...
      TCP determines if a data segment is "old" or "new" by testing
      whether its sequence number is within 2**31 bytes of the left edge
      of the window, and if it is not, discarding the data as "old".  To
      insure that new data is never mistakenly considered old and vice-
      versa, the left edge of the sender's window has to be at most
      2**31 away from the right edge of the receiver's window.

这里rfc1323在推导14这个数时，有上面一段话，其中说明了一个数据分段的序号如果距滑动窗口左边沿2**31次幂之内，则都不是old数据，这里我不明白这个31是如何得到的

[ 本帖最后由 jiufei19 于 2010-1-20 11:56 编辑 ]

jiufei19

我把rfc1323中如何计算出14为最大伸缩因子的文字列出，请大家帮忙看看
--------------------------------------------------------------------------------------

      TCP determines if a data segment is "old" or "new" by testing
      whether its sequence number is within 2**31 bytes of the left edge
      of the window, and if it is not, discarding the data as "old".  To
      insure that new data is never mistakenly considered old and vice-
      versa, the left edge of the sender's window has to be at most
      2**31 away from the right edge of the receiver's window.
      Similarly with the sender's right edge and receiver's left edge.
      Since the right and left edges of either the sender's or
      receiver's window differ by the window size, and since the sender
      and receiver windows can be out of phase by at most the window
      size, the above constraints imply that 2 * the max window size
      must be less than 2**31, or

           max window < 2**30

      Since the max window is 2**S (where S is the scaling shift count)
      times at most 2**16 - 1 (the maximum unscaled window), the maximum
      window is guaranteed to be < 2**30 if S <= 14.  Thus, the shift
      count must be limited to 14 (which allows windows of 2**30 = 1
      Gbyte).  If a Window Scale option is received with a shift.cnt
      value exceeding 14, the TCP should log the error but use 14
      instead of the specified value.

可以看出2**31次幂的结果是最关键的地方，这个明白了，后面的就说得通了，我就是看不懂这个地方，我的疑问是既然tcp的序号空间范围是32bit，超过后会回绕序号，那么2**31次幂的意思就是将该范围划分为相等的2部分，即2**32/2=2**31，为啥是这样呢？

另外，我对原文中所提到的“old”和“new”的含义不是很明白其准确含义？

[ 本帖最后由 jiufei19 于 2010-1-16 11:01 编辑 ]

jiufei19

另外一篇和此问题相关的文字也列出，请大家帮忙看看
--------------------------------------------------------------------------------------

      Even though a 32-bit space is now allowed for the actual window size, the maximum data size is not 4 GB (2**32 ), but rather 1 GB (2**30 ). This is done so that a TCP receiver can uniquely identify an incoming data segment as a new segment. There is no possibility of old and new segments with the same sequence number arriving out of turn and confusing the receiver, as sequence numbers themselves are in the 32-bit space.

为啥这样只利用原来的4G范围的四分之一，即1G，就能保证接收方不会混淆老数据和新数据？

（1） 什么是所谓的新数据，什么是所谓的老数据？
（2） 难道二分之一不行？

[ 本帖最后由 jiufei19 于 2010-1-16 10:59 编辑 ]

hritian

tcp的最大序号是多少？

jiufei19

最大序号是 2**32-1 呀

jiufei19

经过我反复理解，认为这里的old和new是指32bit序号发生回绕后新分段的序号和旧分段的序号相同，于是导致接收方混淆，不过仍然不能理解为啥在2**31次以内就不会造成混淆的原因

jiufei19

自己顶下，这2天我又反复阅读了rfc1072等文档，那几个rfc似乎给出了如下示意图，我对此只是模模糊糊理解，但是详细分析，又觉得不甚了了

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-18 10:40 编辑 ]

jiufei19

我自己尝试下先解决2**31次幂的那个问题，如有错误，请大家拍砖

1、序号空间大小是2**32，而所有和窗口大小有关的值都应满足2的整数次幂，所以窗口大小只能是2**32，2**31，2**30，...，所以现在我们要分析的就是2**32不能被用来表示最大可以使用的窗口值

2、在建立连接的TCP收发双方初始时刻，这个时刻是snd.una和rcv.wup + rcv.wnd之间相差最大的时候，于是我们有如下关系：
snd.una           
snd.nxt               snd.una + snd.wnd
  +---------------------+
  |     Sender                |
  +---------------------+
     
  +---------------------+----------------------+
  0                            2**31-1                  2**32-1
   
  +---------------------+
  |    Receiver               |
  +---------------------+
rcv.wup      rcv.wup+rcv.wnd
rcv.nxt

根据TCP滑动窗口的概念，其表示发送方在未收到接收方的确认前，所能发送的最大数据，那么根据上图我们可以看出如果这个最大数据为2**32的话，即表示一个窗口就可以填满整个序号空间的值，那么此时当发送方收到确认后，序号回绕就立刻发生了，因此就会造成之前窗口中部分被延迟分段的序号和新窗口中的序号发生重叠，显然，由于此时TCP还没有引入timestamps的选项，所以这种情况导致接收方产生混乱。

因此，2**32不能作为最大的窗口值，并且由于窗口大小必须是2的整数次幂，于是我们就知道了上图中|snd.una - (rcv.wup + rcv.wnd)| <= 2**31，即这个差的绝对值最大只能是32bit序号空间的一半，此时，发方最多发送2**31字节数据，若还没有收到收发的ACK，则发方必须等待，显然这个初始状态的差值是最大的，并且只有满足在此2**31范围内，则老数据和新数据（序号回绕后）绝对不会重叠。以后发送窗口和接收窗口都会随着时间平移，但保持这个差值不大于2**31是恒定的

[ 本帖最后由 jiufei19 于 2010-1-18 14:12 编辑 ]

eexplorer

原帖由 jiufei19 于 2010-1-18 10:38 发表
自己顶下，这2天我又反复阅读了rfc1072等文档，那几个rfc似乎给出了如下示意图，我对此只是模模糊糊理解，但是详细分析，又觉得不甚了了

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

查了一下，没有找到2**31的出处。可能没有我们想像的那么复杂，可能就是一个判断sequence wrap问题的一个最loose的规定(在PAWS出现之前)。在实际的tcp/ip stack的实现中，窗口不可能有那么大，所以一般就是判断收到的segment的sequence有没有在窗口内就可以了。

"the sender and receiver windows can be out of phase by at most the window size"
sender和receiver的窗口有可能out-of-phase，最坏的情况有可能就是sender发了一窗口的数据，receiver都收到了，但是reciever的ack都没有到达sender，这样就出现了rfc1323所说的out-of-phase一个窗口的情况。receiver想收rcv.wup+rcv.wnd开始的数据，而sender可能重发它窗口的left edge的数据。

sender窗口的left edge和receiver窗口的right edge不能超过2**31。否则reciever就会直接把sender可能重发的数据直接丢掉了。在这种情况下得到了max window是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

感谢eexplorer的答复，不过我对你的如下说明的意思还没有太明白，请明示：

sender窗口的left edge和receiver窗口的right edge不能超过2**31。否则reciever就会直接把sender可能重发的数据直接丢掉了。在这种情况下得到了max window是2**30。

>> 我们先假定那个2**31的概念是先验的，不需要推导，根据本帖子的如下图示，的确表示收发双方out-of-phase的情况
snd.una     
snd.nxt     snd.una + snd.wnd
  +----------+
  |  Sender    |
  +----------+          2**31                          2**32
  +---------------------+-----------------------+
                +-----------+
                | Receiver    |
                +-----------+
           rcv.wup      rcv.wup+rcv.wnd
           rcv.nxt

那么当接收方的右边界rcv.wup+rcv.wnd - snd.una > 2**31后，为啥接收方会丢掉重发的数据？或者换句话讲，即便不大于2**31，重发的数据因为之前已经被收到了，只是ACK尚未到达发送方，因此发送方若重发的话，这样就不丢掉了吗？另外接收窗口右边界的位置是受接收方应用进程的控制，所以，假设在发生out-of-phase后，接收方应用若读取了部分数据，那么其右边界可能超过了2**31的位置，难道这个情况不可能吗？我感觉我某个地方对滑动窗口理解有错误了。这里我感觉正是因为2**31预先认为是正确的，所以才有上图中发送和接收窗口错开的情况，并且因为初始时刻接收方缓存大小是固定的，而且假定一直不发生改变，于是我们有：

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

这样，当发送方发送了这里的2**30字节，即整个窗口后，接收方都收到后，并且返回的ACK假定都未到达发方，此时才发生了上述的out-of-phase情况

PS：
之所以我对这里2**31，窗口扩大因子14等等有疑问是我感觉我对滑动窗口的概念存在不清晰的地方，望不吝赐教哈！

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