TCP協(xié)議中Window Scale Option問題【完全解決】

jiufei19

大家好，我在繼續(xù)研讀Stevens的“TCPIP協(xié)議詳解卷1”中，又遇到了關(guān)于window scale option的一個(gè)問題，望大家不吝賜教，下面是問題描述。


在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次冪，這個(gè)14是如何得到的？

我查閱了下rfc1323，其中有針對(duì)這個(gè)14的計(jì)算來由，但是不幸的是，該rfc中和14有關(guān)的地方我仍然沒有明白，所以非常郁悶，請(qǐng)大家?guī)蛶臀�，下面是rfc1323中有關(guān)的內(nèi)容：

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在推導(dǎo)14這個(gè)數(shù)時(shí)，有上面一段話，其中說明了一個(gè)數(shù)據(jù)分段的序號(hào)如果距滑動(dòng)窗口左邊沿2**31次冪之內(nèi)，則都不是old數(shù)據(jù)，這里我不明白這個(gè)31是如何得到的

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

jiufei19

我把rfc1323中如何計(jì)算出14為最大伸縮因子的文字列出，請(qǐng)大家?guī)兔�看�?br /> --------------------------------------------------------------------------------------

      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次冪的結(jié)果是最關(guān)鍵的地方，這個(gè)明白了，后面的就說得通了，我就是看不懂這個(gè)地方，我的疑問是既然tcp的序號(hào)空間范圍是32bit，超過后會(huì)回繞序號(hào)，那么2**31次冪的意思就是將該范圍劃分為相等的2部分，即2**32/2=2**31，為啥是這樣呢？

另外，我對(duì)原文中所提到的“old”和“new”的含義不是很明白其準(zhǔn)確含義？

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

jiufei19

另外一篇和此問題相關(guān)的文字也列出，請(qǐng)大家?guī)兔�看�?br /> --------------------------------------------------------------------------------------

      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，就能保證接收方不會(huì)混淆老數(shù)據(jù)和新數(shù)據(jù)？

（1） 什么是所謂的新數(shù)據(jù)，什么是所謂的老數(shù)據(jù)？
（2） 難道二分之一不行？

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

hritian

tcp的最大序號(hào)是多少？

jiufei19

最大序號(hào)是 2**32-1 呀

jiufei19

經(jīng)過我反復(fù)理解，認(rèn)為這里的old和new是指32bit序號(hào)發(fā)生回繞后新分段的序號(hào)和舊分段的序號(hào)相同，于是導(dǎo)致接收方混淆，不過仍然不能理解為啥在2**31次以內(nèi)就不會(huì)造成混淆的原因

jiufei19

自己頂下，這2天我又反復(fù)閱讀了rfc1072等文檔，那幾個(gè)rfc似乎給出了如下示意圖，我對(duì)此只是模模糊糊理解，但是詳細(xì)分析，又覺得不甚了了

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次冪的那個(gè)問題，如有錯(cuò)誤，請(qǐng)大家拍磚

1、序號(hào)空間大小是2**32，而所有和窗口大小有關(guān)的值都應(yīng)滿足2的整數(shù)次冪，所以窗口大小只能是2**32，2**31，2**30，...，所以現(xiàn)在我們要分析的就是2**32不能被用來表示最大可以使用的窗口值

2、在建立連接的TCP收發(fā)雙方初始時(shí)刻，這個(gè)時(shí)刻是snd.una和rcv.wup + rcv.wnd之間相差最大的時(shí)候，于是我們有如下關(guān)系：
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

根據(jù)TCP滑動(dòng)窗口的概念，其表示發(fā)送方在未收到接收方的確認(rèn)前，所能發(fā)送的最大數(shù)據(jù)，那么根據(jù)上圖我們可以看出如果這個(gè)最大數(shù)據(jù)為2**32的話，即表示一個(gè)窗口就可以填滿整個(gè)序號(hào)空間的值，那么此時(shí)當(dāng)發(fā)送方收到確認(rèn)后，序號(hào)回繞就立刻發(fā)生了，因此就會(huì)造成之前窗口中部分被延遲分段的序號(hào)和新窗口中的序號(hào)發(fā)生重疊，顯然，由于此時(shí)TCP還沒有引入timestamps的選項(xiàng)，所以這種情況導(dǎo)致接收方產(chǎn)生混亂。

因此，2**32不能作為最大的窗口值，并且由于窗口大小必須是2的整數(shù)次冪，于是我們就知道了上圖中|snd.una - (rcv.wup + rcv.wnd)| <= 2**31，即這個(gè)差的絕對(duì)值最大只能是32bit序號(hào)空間的一半，此時(shí)，發(fā)方最多發(fā)送2**31字節(jié)數(shù)據(jù)，若還沒有收到收發(fā)的ACK，則發(fā)方必須等待，顯然這個(gè)初始狀態(tài)的差值是最大的，并且只有滿足在此2**31范圍內(nèi)，則老數(shù)據(jù)和新數(shù)據(jù)（序號(hào)回繞后）絕對(duì)不會(huì)重疊。以后發(fā)送窗口和接收窗口都會(huì)隨著時(shí)間平移，但保持這個(gè)差值不大于2**31是恒定的

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

eexplorer

原帖由 jiufei19 于 2010-1-18 10:38 發(fā)表
自己頂下，這2天我又反復(fù)閱讀了rfc1072等文檔，那幾個(gè)rfc似乎給出了如下示意圖，我對(duì)此只是模模糊糊理解，但是詳細(xì)分析，又覺得不甚了了

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

查了一下，沒有找到2**31的出處。可能沒有我們想像的那么復(fù)雜，可能就是一個(gè)判斷sequence wrap問題的一個(gè)最loose的規(guī)定(在PAWS出現(xiàn)之前)。在實(shí)際的tcp/ip stack的實(shí)現(xiàn)中，窗口不可能有那么大，所以一般就是判斷收到的segment的sequence有沒有在窗口內(nèi)就可以了。

"the sender and receiver windows can be out of phase by at most the window size"
sender和receiver的窗口有可能out-of-phase，最壞的情況有可能就是sender發(fā)了一窗口的數(shù)據(jù)，receiver都收到了，但是reciever的ack都沒有到達(dá)sender，這樣就出現(xiàn)了rfc1323所說的out-of-phase一個(gè)窗口的情況。receiver想收rcv.wup+rcv.wnd開始的數(shù)據(jù)，而sender可能重發(fā)它窗口的left edge的數(shù)據(jù)。

sender窗口的left edge和receiver窗口的right edge不能超過2**31。否則reciever就會(huì)直接把sender可能重發(fā)的數(shù)據(jù)直接丟掉了。在這種情況下得到了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的答復(fù)，不過我對(duì)你的如下說明的意思還沒有太明白，請(qǐng)明示：

sender窗口的left edge和receiver窗口的right edge不能超過2**31。否則reciever就會(huì)直接把sender可能重發(fā)的數(shù)據(jù)直接丟掉了。在這種情況下得到了max window是2**30。

>> 我們先假定那個(gè)2**31的概念是先驗(yàn)的，不需要推導(dǎo)，根據(jù)本帖子的如下圖示，的確表示收發(fā)雙方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

那么當(dāng)接收方的右邊界rcv.wup+rcv.wnd - snd.una > 2**31后，為啥接收方會(huì)丟掉重發(fā)的數(shù)據(jù)？或者換句話講，即便不大于2**31，重發(fā)的數(shù)據(jù)因?yàn)橹�前已�?jīng)被收到了，只是ACK尚未到達(dá)發(fā)送方，因此發(fā)送方若重發(fā)的話，這樣就不丟掉了嗎？另外接收窗口右邊界的位置是受接收方應(yīng)用進(jìn)程的控制，所以，假設(shè)在發(fā)生out-of-phase后，接收方應(yīng)用若讀取了部分?jǐn)?shù)據(jù)，那么其右邊界可能超過了2**31的位置，難道這個(gè)情況不可能嗎？我感覺我某個(gè)地方對(duì)滑動(dòng)窗口理解有錯(cuò)誤了。這里我感覺正是因?yàn)?**31預(yù)先認(rèn)為是正確的，所以才有上圖中發(fā)送和接收窗口錯(cuò)開的情況，并且因?yàn)槌跏紩r(shí)刻接收方緩存大小是固定的，而且假定一直不發(fā)生改變，于是我們有：

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

這樣，當(dāng)發(fā)送方發(fā)送了這里的2**30字節(jié)，即整個(gè)窗口后，接收方都收到后，并且返回的ACK假定都未到達(dá)發(fā)方，此時(shí)才發(fā)生了上述的out-of-phase情況

PS：
之所以我對(duì)這里2**31，窗口擴(kuò)大因子14等等有疑問是我感覺我對(duì)滑動(dòng)窗口的概念存在不清晰的地方，望不吝賜教哈！

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