web-dev-qa-db-ja.com

TCP接続で、受信者は送信者が使用するTCPウィンドウサイズを制御できますか？

TCPウィンドウサイズは、送信者がTCP ackを待機する前に送信するデータ量です。受信者はこれを制御する方法を持っていますか（ TCPハンドシェイク）の一部として、または制御できるのは送信者だけですか？

networkingtcptcp-window-scaling
3
jhourback

はい、受信者はTCPウィンドウサイズをすべてTCP通信に沿って、 RFCで述べられているように、ハンドシェイク時だけでなく、 793 ：

フロー制御：

TCPは、受信者が送信者から送信されるデータの量を管理する手段を提供します。これは、正常に受信された最後のセグメントを超えて許容可能なシーケンス番号の範囲を示すすべてのACKで「ウィンドウ」を返すことによって実現されます。 ウィンドウは、送信者がさらに許可を受信する前に送信できるオクテットの許容数を示します。

tcp-window-scaling を追加したため、TCPウィンドウスケーリングは、最大ウィンドウサイズの64kの初期制限を克服するために使用される乗数にすぎません。 。これは、 RFC 7323 で説明されているように、TCP最初のTCPハンドシェイクのオプション）を使用してネゴシエートされます。

ウィンドウスケールオプションは、TCPセッションの基本パラメータをネゴシエートします。したがって、最初のハンドシェイク中にのみ送信されます。さらに、ウィンドウスケールオプションは<SYN,ACK>セグメントは、対応するオプションが最初の<SYN>セグメント。

....

このオプションは最初の<SYN>セグメント（つまり、セグメント
SYNビットがオンで、ACKビットがオフの場合）。ウィンドウスケールオプションの場合
は最初に受け取った<SYN>セグメントの場合、このオプションは
<SYN,ACK>セグメント。セグメントのウィンドウスケールオプション
SYNビットなしでは無視する必要があります。

したがって、この倍率は後で変更できません。さらに説明されています there ：

ウィンドウスケール拡張は、TCPウィンドウの定義を拡張します。
を30ビットにしてから、暗黙のスケール係数を使用してこれを実行します
TCPヘッダーの16ビットウィンドウフィールドの30ビット値（[RFC0793]のSEG.WND）。スケールファクターの指数はTCPで伝達されます
オプション、ウィンドウスケール。このオプションはセグメント（SYNビットがオンになっているセグメント）でのみ送信されるため、接続が開かれると、ウィンドウスケールは各方向に固定されます。

以下は、ワームを繁殖させるために使用されるスキャンを遅らせるために発明された、レシーバーからの極端で異常なウィンドウコントロールの「乱用」の例です。Linuxiptablesの TARPIT アドオンターゲット、ベースLaBreaのtar pit（Jim McClurg、2001 [〜＃〜] pdf [〜＃〜] ）：

TARPIT
ローカルの接続ごとのリソースを使用せずに、着信TCP=接続をキャプチャして保持します。
[...]リスニングサーバーのように再生しますが、ACKまたはRSTを送信することを除いて、データは送信されません。 [...]
--tarpit
このモードは攻撃者との接続を完了しますが、ウィンドウサイズを0に制限するため、攻撃者は長時間待機し続けます。彼は接続の状態を維持し、60〜240秒ごとに続行しようとしていますが、何も保持しないため、非常に軽量です。接続を閉じる試みは無視され、リモート側は接続を12〜24分で強制的にタイムアウトします。このモードがデフォルトです。

5
A.B