TCP SACK：選択確認応答で損失区間を絞る
累積ACKの先に届いた範囲をSACKが伝える仕組み、D-SACKの重複受信信号、再送や輻輳制御との役割の違いを説明します。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
TCPの累積確認応答（ACK）は、連続受信したデータの次に期待するバイト位置を示します。欠落の後にデータが届いても、後続のどの範囲が受信済みか累積ACKだけでは分からない場合があります。選択確認応答（SACK）は非連続の受信範囲を知らせ、送信側が到着済みデータを不必要に再送しないよう助けます。SACKは損失回復を補うもので、TCPの再送や輻輳制御を置き換えません。
接続時の交渉と累積ACK
RFC 2018では、SACK受信機能を持つ端点が接続時のSYNでSACK-Permittedオプションを送れます。接続後、受信側はSACKオプションで非連続範囲の境界を報告できます。累積ACK欄の意味は変わりません。ACK番号は連続受信の終端を示し、SACKブロックは欠落のため累積確認が進めない間に届いた範囲を表します。
範囲Aが欠落して後続のBとCが届く例では、累積ACKはAの前に留まり、SACKはBとCを報告できます。送信側はその情報を送信キューと照らして受信済み範囲を記録します。TCPオプション領域は限られ、すべてのブロックを一つのACKに載せられるとは限りません。RFCは新しい変化と一部の過去ブロックの再報告を勧めますが、ACK損失や領域不足で状態把握が遅れることがあります。
送信側の記録で再送候補を分ける
RFC 2018は、送信済みで累積確認されていないセグメントのキューを維持し、SACK範囲に印を付ける実装例を説明します。後で再送を選ぶとき、SACK済み範囲を避け、未確認の範囲を候補に残せます。この管理はSACKスコアボードと呼ばれます。受信側の報告を送信側の履歴に対応させる仕組みで、OSごとの全アルゴリズムを規格が一つに固定するものではありません。
一つのウィンドウで複数のセグメントが失われた場合、累積ACKのみより受信済み範囲と欠落を細かく分けられます。その結果、後続の到着済みデータを再送する必要が減ることがあります。ただし再送時点やfast recoveryは損失検出、輻輳制御、実装に依存します。SACKがどの損失でも一定の復旧時間や性能向上を保証するわけではありません。
D-SACKは重複受信の手掛かり
RFC 2883はDuplicate SACK（D-SACK）拡張を定義します。受信側がすでに受け取った範囲を再び受信すると、最初のSACKブロックで重複を報告できます。送信側は自らの再送記録と照合し、実損失後の再送か、経路での遅延・複製による重複かを考える手掛かりにできます。これは評価の証拠であり完全なネットワーク診断ではありません。
報告を含むACKが失われると送信側には届きません。累積ACKと送信履歴を合わせて解釈する必要があります。RFC 2883は重複セグメントが以前のシーケンス番号空間の周回と関係する可能性にも注意します。重複ブロックだけでパケット複製と断定せず、並べ替えや再送の文脈を確認します。
SACKと輻輳制御の役割を分ける
SACKは受信状態を詳しく知らせるACKオプションです。輻輳制御は送信量と速度を調節し、タイマーや損失検出は回復開始に関わります。そのためキャプチャにSACKが見えても、輻輳ウィンドウ、再送時点、実効速度は判断できません。RFC 2018はSACKを助言的情報とし、受信側が以前報告したデータを後で破棄する可能性も説明します。
専門家の視点でキャプチャを読むときは、SYN交渉、累積ACKの進み方、繰り返しブロック、再送順序、重複報告を分けます。特定実装の診断にはOSと版、輻輳制御モジュール、タイムスタンプ、取得位置も必要です。本稿は二つのIETF文書のオプション仕様と例を説明し、あらゆるTCP接続の性能や安全性を判定しません。