6

ネットワークが (クライアントのサイトで) 輻輳しているときに、TCP ウィンドウ サイズ 0 のヘッダーを送信することが観察されたアプリケーション サーバーがあります。

利用可能なスループットに合わせて TCP ウィンドウ サイズを公称 64K から小さく調整する役割を担っているのが Indy なのか、それとも基盤となる Windows レイヤーなのかを知りたいと考えています。
そして、それが 0 になったときに対処することができます (何も送信されず、ユーザーは待機します => ダメです)。

したがって、Indy コードへの情報、リンク、ポインタは大歓迎です...

免責事項: 私はネットワークの専門家ではありません。平均的な私にとって理解しやすい答えにしてください;-)
注: Windows Server 2003 SP2 上の Indy9/D2007 です。

詳細:
TCP ゼロ ウィンドウのケースは、DB サーバーと通信する中間層で発生します。
これは、エンド ユーザーがクライアント アプリケーションの速度低下を訴えるのと同時に発生します (それが原因でネットワーク調査が開始されました)。
ボトルネックの原因となっている 2 つの主要なネットワークの問題が特定されました。
ネットワークの輻輳が発生したときに TCP ゼロ ウィンドウが発生しましたが、それが原因である場合とそうでない場合があります。
それがいつ発生するかを知りたいので、コードで何か (少なくともログ記録) を行う方法を用意します。

核となる問題は、ウィンドウ サイズを 0 に設定するのは誰で、どこで行うのかということです。
その状態がいつ発生するかを知るために (Indy で?) どこにフックしますか?

4

3 に答える 3

7

TCP ヘッダーのウィンドウ サイズは通常、使用可能なバッファ スペースのサイズを反映するように TCP スタック ソフトウェアによって設定されます。サーバーがゼロに設定されたウィンドウでパケットを送信している場合、サーバー上で実行されているアプリケーションがデータを読み取るよりも速くクライアントがデータを送信しており、TCP 接続に関連付けられているバッファーがいっぱいになっている可能性があります。

クライアントがデータをサーバーが読み取るよりも速く送信する場合、これは TCP プロトコルの完全に正常な動作です。サーバーがゼロ以外のウィンドウ サイズを送信するまで、クライアントはデータの送信を控える必要があります (とにかく破棄されるため、意味がありません)。

これは、クライアントとサーバー間の深刻な問題を反映している場合とそうでない場合がありますが、この状態が続く場合は、サーバー上で実行されているアプリケーションが受信したデータの読み取りを停止したことを意味している可能性があります (読み取りを開始すると、TCP のバッファー スペースが解放され、 TCP スタックは、ゼロ以外の新しいウィンドウ サイズを送信します)。

于 2010-06-08T20:55:51.377 に答える
2

ウィンドウサイズがゼロのTCPヘッダーは、レシーバーのバッファーがいっぱいであることを示します。これは、リーダーよりも高速なライターの通常の状態です。

あなたの説明を読んで、これが予想外であるかどうかは明らかではありません。プロトコルアナライザを開いた理由は何ですか？

于 2010-06-08T20:33:49.313 に答える
2

あなたもあなたの問題の解決策に興味があるかもしれないので：

サーバー側 (0 ウィンドウ サイズ メッセージを送信する側) で実行されているものをある程度制御できる場合: SO_RCVBUF で setsockopt() を使用して、ソケットの受信バッファーのサイズを大幅に増やすことを検討しましたか?

Indy では、setsockopt() は TIdSocketHandle のメソッドです。ソケットに関連付けられているすべての TIdSocketHandle オブジェクトに適用する必要があります。Indy 9 では、これらは TIdTCPServer のプロパティ Bindings を介して配置されます。

最初に SO_RCVBUF で getsockopt() を使用して、OS がデフォルトのバッファー サイズとして提供するものを確認することをお勧めします。次に、これを大幅に増やします。試行を重ねることで、毎回サイズを 2 倍にすることができます。また、setsockopt() の後で getsockopt() 呼び出しを再実行して、setsockopt が実際に実行されたことを確認することもできます。通常、ソケットの実装によってバッファ サイズに設定される上限があります。この場合、通常、その上限値を引き上げる OS 依存の方法があります。しかし、これらはかなり極端なケースであり、これが必要になる可能性はあまりありません。

オーバーフローする側のソースコードを制御できない場合は、そこで実行されているソフトウェアがそのバッファサイズを変更するためのパラメータを公開しているかどうかを確認してください。

幸運を！

于 2010-06-10T07:10:07.660 に答える