TCP SACKをオフにするのはいつですか？
私はLinuxのチューニングパラメータを調べており、SACKがオフになっている構成をいくつか見てきました。誰かがこれを説明できますか？
これは、ビジー状態のWebサーバー用に調整することになります。
基本的なTCP ACKは「Xまでのすべてのバイトを受信しました。」と言います。選択的ACKでは、「バイトX-Y、およびV-Zを受信しました」と言うことができます。
したがって、たとえば、ホストから送信されたバイト数が10,000バイトで、送信中に3000〜5000バイトが失われた場合、ACKは「3000まですべてを取得した」と表示します。もう一方の端は、バイト3001〜10000を再度送信する必要があります。 SACKは「私は1000-2999と5001-10000を得た」と言うことができ、ホストは3000-5000を送信するだけです。
これは、高帯域幅で損失の多い（または遅延が大きい）リンクでは優れています。問題は、特定の状況で深刻なパフォーマンスの問題を引き起こす可能性があることです。通常TCP= ACKは、サーバーに子供用手袋との高帯域幅の損失の多い接続を処理させます（500バイトを送信、待機、500バイトを送信、待機など）。SACKは、高パケット数が実際に失われたことが正確にわかるため、遅延が発生します。
ここで悪いことが起こります。攻撃者は、サーバーに大量の再送信キューを長期間保持させ、その全体を何度も何度も処理することができます。これは、CPUを固定し、RAMを消費し、必要以上の帯域幅を消費する可能性があります。簡単に言うと、軽量システムはより強力なサーバーに対してDoSを開始できます。
サーバーが堅牢で、大きなファイルを提供しない場合は、これに対して十分に保護されています。
主にイントラネットやその他の待ち時間の短いユーザーグループにサービスを提供している場合、SACKは何も購入しないため、セキュリティ上の理由でパフォーマンスを失うことなくオフにすることができます。
低帯域幅のリンク（完全に任意の経験則として1Mbps以下と言う）を使用している場合、SACKは接続を飽和させることにより通常の操作で問題を引き起こす可能性があるため、オフにする必要があります。
最終的に、それはあなた次第です。あなたが何を誰に、何を提供しているかを検討し、SACKのパフォーマンスへの影響に対するリスクの程度を比較検討してください。
SACKとその脆弱性の概要 こちら
TCP SACKが無効にされることが多いもう1つの理由は、このオプションを正しく処理できないネットワーク機器が驚くほど大量にあるためです。高速ファイル転送でこれが常に見られます私たちが提供する、TCPを使用する製品です。最も一般的な問題は、内部ネットワークから外部にデバイスを通過するTCPパケットのシーケンス番号をランダム化するようなゲートウェイデバイスの問題ですが、 t「ランダム化解除」TCPリモートエンドから送信される可能性のあるSACKオプション。実際のSACK値がこれらのデバイスによって適切な値に変換されない場合は、TCPリモートエンドがSACKを使用して選択的ACKのメリットを得ようとする場合、パケット損失が発生してもセッションは完了しません。
おそらく、人々がこのギアに予防的なソフトウェアメンテナンスをより積極的に適用するなら、これは問題の少ないものになるでしょうが、彼らはそうしない傾向があります。
苦い経験から、特定のCisco ASAファイアウォールアプライアンスを使用している場合、tcp_sack = 1が原因でsftp/rsync/scpなどのファイル転送が約12mbを超えると停止することが確認できます。
毎回それは行き詰まっているでしょう。
私たちは、CiscoファイアウォールとCentosを備えたスイッチハードウェアの両方を使用して、2つの異なるデータセンターのホストAとホストBの間の専用100 Mbpsリンクで転送していました。
これは、バッファサイズを変更することで多少軽減できます。 sftpバッファを2048に設定しないと、sftpを介して1GBのファイルをホストAからホストBに転送できませんでしたが、ホストBがAからファイルをプルしているかどうかは関係ありませんでした。
Rsyncと送信/受信バッファーのチューニングを使用して同じファイルを実験したところ、AからBにプッシュされた約70MBの1GBファイルを取得できました。
ただし、最終的な答えは、ホストAでtcp_sackを無効にすることでした。最初はカーネルでオンザフライでtcp_sack = 0を設定しましたが、最終的には/etc/sysctl.confに追加しました。