回答:
基本的なTCP ACKは、「Xまでのすべてのバイトを受信しました」と言います。選択的ACKにより、「バイトXY、およびVZを受信しました」と言うことができます。
そのため、たとえば、ホストから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パケットのシーケンス番号をランダム化するなどのことを行うが、リモートから送信される可能性のあるTCP SACKオプションを「ランダム化しない」ゲートウェイデバイスの問題です終わり。実際のSACK値がこれらのデバイスによって適切な値に変換されない場合、リモートエンドがSACKを使用して選択的ACKの利点を取得しようとすると、パケット損失が発生してもTCPセッションは完了しません。
おそらく、人々がこのソフトウェアに予防的なソフトウェアメンテナンスをより積極的に適用するのであれば、これは問題ではないでしょうが、そうではない傾向があります。
苦い経験から、特定のCisco ASAファイアウォールアプライアンスを使用している場合、tcp_sack = 1が約12 MBを超えるファイルでsftp / rsync / scpなどを介してデータ転送を停止させることが確認できます。
停止するたびに。
2つの異なるデータセンターのホストAとホストBの間で専用の100 mbpsリンクを介して転送していました。どちらもCiscoファイアウォールとスイッチハードウェアとCentOSを使用していました。
これは、バッファサイズを変更することで多少緩和できます。たとえば、sftpバッファを2048に設定しない限り、ホストAからホストBに1 GBファイルをsftpで転送できませんでしたが、ホストBがAからファイルをプルしているかどうかに関係なく
rsyncと送信/受信バッファのチューニングを使用した同じファイルの実験により、AからBにプッシュされた1GBのファイルのうち約70MBを取得することができました。
しかし、最終的な答えはホストAでtcp_sackを無効にすることでした。最初はオンザフライでカーネルでtcp_sack = 0を設定しました-しかし、最終的には/etc/sysctl.confに追加しました