RFC1323のTcpWindowSize

[unknown]

XPにおける、RFC1323のTcpWindowSizeに関する質問です。

サーバーA、クライアントBでTcpWindowSizeの設定値が違った場合、ホストＡ、Bの
TCP ウィンドウ サイズはどう設定されるのでしょうか。
B->AのSYNでOptionが 0x3,0x3,0x0 A->BのSYN,ACKでOptionが0x3,0x3,0x4
だった場合、AからBへsendする時のTCP ウィンドウ サイズが1,048,560 バイト
、BからAへsendするときのTCP ウィンドウ サイズが65535 以下、と考えて
よろしいのでしょうか？それとも、この逆ですか？

[unknown]

ボコノン教徒です

Post by unknown
B->AのSYNでOptionが 0x3,0x3,0x0 A->BのSYN,ACKでOptionが0x3,0x3,0x4
だった場合、AからBへsendする時のTCP ウィンドウ サイズが1,048,560 バイト
、BからAへsendするときのTCP ウィンドウ サイズが65535 以下、と考えて
よろしいのでしょうか？それとも、この逆ですか？

ACKの遅延状況から見て、後者（逆）っぽいですねえ。
MS独自の仕様なのか、それとも標準の仕様なのか。
RFC１３２３をじっくり読むしかないらしい。
RFCには「This option is an offer, not a promise」とあるのだが、
この offer がリクエストなのか、それとも宣言なのか。

この辺の詳しい解説やポインタをご存知の方がいたら、教えてください。

[unknown]

Post by unknown
ACKの遅延状況から見て、後者（逆）っぽいですねえ。

これ、勘違い。ローカルな環境でテストしても分からんらしい。

[individual]

逆

[unknown]

逆

レス、どうもありがとうございました。

「Windows 2000 および Windows Server 2003 の TCP 機能について」
http://support.microsoft.com/default.aspx?scid=kb;ja;224829
を見ると、「受信ウィンドウ サイズを特定の値に設定」という言い方を
しているので、これだと確かに「逆」ですね。

直にハブにつながった2台のXP間で、RFC1323の設定が効いているかを、
確かめる、いい方法はないでしょうか。
今は、自前のファイル転送アプリのパケットをWinPCap＋Analyzerでキャプチャ
しているんですが、この転送アプリ内でSO_RCVBUFの設定とかをやっているの
がまずいんでしょかねえ。

[individual]

Post by unknown
直にハブにつながった2台のXP間で、RFC1323の設定が効いているかを、
確かめる、いい方法はないでしょうか。

受信確認パケットが確認できなくても、
とりあえず送信してしまう（まぁ受信側がそう望んだのだから）サイズが
ウィンドウサイズなわけですから、
ウィンドウサイズのスケール効果は、
一般に距離的問題で転送帯域に対して遅延が大きい場合に効くわけで、
直にハブにつながった2台のXP間だと、受信側の受信応答パケットを
フィルタするなどしてブロックする必要があるでしょう。
XPには標準でその手のツールはないので自分で作るなりするか、
まぁ比較的簡単にすますならLinuxとかのパケットフィルタを
間に挟んで、受信確認パケットをブロックすれば、確かめられるでしょう。

Post by unknown
今は、自前のファイル転送アプリのパケットをWinPCap＋Analyzerでキャプチャ
しているんですが、この転送アプリ内でSO_RCVBUFの設定とかをやっているの
がまずいんでしょかねえ。

何が問題なのかわかりませんが、
SO_RCVBUFで指定するのは、プログラムが本当に処理を行うための
実際の受信バッファサイズでクリティカルに影響するわけですが、
ウィンドウサイズは距離的影響のある相手との
ネットワーク帯域の効率的利用
（送信側における受信確認のための待ち時間を減らす）
効果なので、これらは直接影響はしないと思いますけど。

[unknown]

ボコノン教徒です。

Post by individual
XPには標準でその手のツールはないので自分で作るなりするか、
まぁ比較的簡単にすますならLinuxとかのパケットフィルタを
間に挟んで、受信確認パケットをブロックすれば、確かめられるでしょう。

やぱりそうなりますかねえ。
本番でトラぶった時、現場で原因の切り分けがし易いように、事前に確認
しときたいんですよね。
マイクロソフトの場合、実装が標準と違っている可能性がある
（ちょっと偏見ですが）ので、事前の検証が欠かせません。

Post by individual
何が問題なのかわかりませんが、

「Microsoft Windows Server 2003 TCP/IP 実装詳細」
http://www.microsoft.com/japan/technet/prodtechnol/windowsserver2003/technologies/networking/tcpip03.mspx
の「TCP 受信ウィンドウサイズの計算とウィンドウ スケーリング (RFC 1323)」の項を見ると

　Windows Server 2003 では、アドバタイズした TCP 受信ウィンドウの既定サイズは、
　以下の要因に依存します。なお、これらの要因は優先度の高い順に示してあります。
　　1. 接続の SO_RCVBUF WinSock オプション。
　　2.インターフェイス別の TcpWindowSize レジストリ設定値
　　3. グローバル TcpWindowSize レジストリ設定値
　　4. NDIS により報告されたメディアのビット レートに基づく自動判定。

などと書いてあるもんで。Server 2003 とXPの実装がどう違うかは不明ですが。
パケットのSyn,Ackを見た限り、3.のみが影響しているようです。
4.はよーわからん。

[individual]

Post by unknown
本番でトラぶった時、現場で原因の切り分けがし易いように、事前に確認
しときたいんですよね。
マイクロソフトの場合、実装が標準と違っている可能性がある
（ちょっと偏見ですが）ので、事前の検証が欠かせません。

確かに、マイクロソフトの場合は特に…

Post by unknown
　Windows Server 2003 では、アドバタイズした TCP 受信ウィンドウの既定サイズは、
　以下の要因に依存します。なお、これらの要因は優先度の高い順に示してあります。
　　1. 接続の SO_RCVBUF WinSock オプション。
　　2.インターフェイス別の TcpWindowSize レジストリ設定値
　　3. グローバル TcpWindowSize レジストリ設定値
　　4. NDIS により報告されたメディアのビット レートに基づく自動判定。
などと書いてあるもんで。Server 2003 とXPの実装がどう違うかは不明ですが。
パケットのSyn,Ackを見た限り、3.のみが影響しているようです。
4.はよーわからん。

ん？ これらの機能チェック？
仕様指示書にウィンドウサイズ指定があったりするとか？

まぁとりあえず、その手の意味であれば、

Post by unknown
　　1. 接続の SO_RCVBUF WinSock オプション。

これ、手元のネットワーク系レジストリを何もいじっていない
一般的なSP2＋WUHOTFIXのXPでもXP x64バージョンでも機能してますよ。

default SO_RCVBUF Value: 8192
x.2289 > z.80: S win 65535 <mss 1460,nop,nop,sackOK>
set SO_RCVBUF Value: 524288
x.2290 > z.80: S win 65535 <mss 1460,nop,wscale 4,nop,nop,sackOK>
set SO_RCVBUF Value: 131072
x.2292 > z.80: S win 65535 <mss 1460,nop,wscale 2,nop,nop,sackOK>

といった感じに自動設定されてます。

[unknown]

Post by individual
仕様指示書にウィンドウサイズ指定があったりするとか？

衛星を使って映像データを送る、という話もあるので、往復2秒分の
Windowsサイズが必要になります。
また、データ量が多いので、クライアント側で受信バッファを拡張しないと
データの取りこぼしが発生します。

Post by individual
これ、手元のネットワーク系レジストリを何もいじっていない
一般的なSP2＋WUHOTFIXのXPでもXP x64バージョンでも機能してますよ。

これ、こちらでは確認できてません。
クリーンなテストプログラムを作って確認してみます。
色々とアドバイスしていただいて、ありがとうございました。