要約

  • TCP Keep-Alive はアイドル状態の相手に、保持しているシーケンス状態から応答するよう求めるもので、アプリケーションの健全性を判定するものではない。
  • ACK だけのセグメントは確実には配送されないため、1 回の無応答だけで接続の異常を判断することはできない。

長い時間、受信セグメントがなく、新しいデータも未確認データも送る必要がないとき、TCP 接続は静かなままでいられる。その沈黙は、健全なアプリケーションに送信するものがないだけかもしれないし、経路や相手が到達不能になった状態を隠しているかもしれない。Keep-Alive はこの境界で、既存のシーケンス状態についてもう一度観測するために使われる。

この仕組みは再送の代わりではない。送信済みデータが未確認のままなら、TCP にはすでに再送と User Timeout があり、配送を続けられるかを判断する。Keep-Alive が始まるのは、それ以外の点で接続がアイドルになってからである。

RFC 1122 が示すプローブは、通常 SND.NXT-1 のシーケンス番号を使う。これは新しいデータで次に使う位置の直前である。相手が TCP 状態を保持していれば、その状態をもとに応答できる。プローブはデータを含めないことが推奨されるが、データなしの形式を正しく扱えない実装との互換性のため、1 オクテットの形式を用意できる。どちらもアプリケーションのメッセージではなく、トランスポート層の制御交換である。

Keep-Alive の実装は任意である。実装する場合、アプリケーションは接続ごとに有効化・無効化できなければならず、既定では無効でなければならない。送信済みで確認待ちのデータがなく、設定した間隔内にデータまたは ACK が届かなかった場合に限り、プローブを送れる。間隔は設定可能で、規格で定める既定値は少なくとも 2 時間である。

RFC 9293 は RFC 1122 の重要な制約を維持している。ACK だけのセグメントは TCP によって確実には配送されない。相手がプローブを受けて期待された ACK を作っても、その ACK が途中で失われることがある。したがって、特定の 1 回のプローブへの無応答だけで接続の異常を証明することはできない。この仕組みは、普遍的な生存確認サービスになったわけでもない。

参考資料