Wireshark でしばしば観測される TCP Window 関連の表示についてまとめてみました。
TCP Window とは
これらの表示に関連する TCP Window とは、TCP のフロー制御の実装のことです。
簡単に言うと、データを受信する立場からすると、『大量データを送り付けられても処理しきれない、とは言っても少量ずつ送られても効率が悪い』という問題をうまく制御して、程よい速さで相手に送らせる方法のことです。
TCP Window の詳細については以下をご参照下さい。
[TCP ZeroWindow] が示す状況
[TCP ZeroWindow] が送信される、というのは、TCP においてデータ受信側が「もう処理しきれないから一度送るのを待って！」と送信側に伝えている状況です。
具体的には、相手に Ack と共に、TCP の "Windowフィールド" を 0 にセットしたパケットが観測されたときに表示されます。
[TCP Window Update] が示す状況
一方、[TCP Window Update] の送信は、「処理できるバッファが出来たから送信を再開して下さいね！」と送信側に伝えている状況です。
具体的には、ZeroWindow と同じ ACK 番号で、TCP の "Windowフィールド" に自身の受信バッファ分の数値をセットしたパケットが観測されたときに表示されます。
なお、通常の TCP のやり取りの中でも Window の Update はしているのですが、特に相手に送る用事が無い (最後に受信したデータに対する Ack も送信済) ときに Update する場合は、この表示がされます。
[TCP Window Full] が示す状況
最後に、[TCP Window Full] ですが、これは送信側が、『受信側の受信バッファの限界まで送り切ったった』という状況です。
これは Wireshark が Window と送信量を計算しており、この状況を把握してわざわざ表示してくれているのです。
Expert Info には "tcp window specified by the receiver is now completely full" と表示されます。
これら3つの表示が多発する状況とは
可能性は 2 つあります。
単に受信側の処理が遅い
1 つは単純に『データ受信側のバッファがオーバーフローし、送信側にデータ送信を止めるように伝え (ZeroWindow)、バッファが出来たらその容量を伝え (Window Update)、またクライアント側が処理し切る前に送信側がバッファ容量の限界まで送りつける』という状態。
つまり、データ受信側の処理能力がネットワーク速度に比べて非常に遅い場合が該当します。
この場合の対策は、データ受信側のスペックを上げるしかありません。
データ受信側が帯域制御している
もう 1 つは、クライアント側が帯域制御のためにわざとそのような状態を作っている可能性です。
これは具体的にはアプリケーションの TCP/IP ソケット API に関する作り方に依るのですが、例えば curl コマンドや wget コマンドで "--limit-rate" オプションを付けた場合や、rsync コマンドで "--bwlimit" を付けた場合等には、クライアントは一定量をダウンロードした後、これらの一連の動作を繰り返して、速度を制御します。
以下は curl コマンドで速度を 100kbps に制限する例です。
# curl --limit-rate 100k http://www.yahoo.co.jp
この例ではあくまでコマンドのオプションで明示的に実行しているので分かり易いですが、アプリケーションによってはこのあたりは明示的でない可能性もありますので、頻発するようであればアプリ開発ベンダへ問い合わせする必要があります。
【厳選 3 冊】パケットキャプチャを学ぶための本
パケットキャプチャ関連でお奨めの本を 3 冊紹介します。どれも私のサイトからの購入率が高いものです。
現場での利用方法や具体的なトラブルシュート方法など、現場で活用できる技が豊富に記載されています。サンプルのキャプチャファイルを実際に見ながら学べるので初心者にも分かり易く学べます。
無線を見える化し、セキュリティやトラブルシュートを行うためのノウハウが豊富に記載されています。無線LANのエンジニアなら必携です。
あなたが成長の日々を歩めますように。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント