要約

  • TCP keepaliveは、静かな相手がトランスポート層で応答するかを問うだけで、アプリの健全性までは証明しない。
  • 接続の沈黙には複数の原因があるため、この機能は任意、設定可能、既定無効のまま残された。
  • 一度の無応答は死亡の証拠にならず、中間装置の記憶、ユーザータイムアウト、電力も共通周期を不可能にする。

何も送らなければ、再送するものもない

RFC 793 のTCPは、送信されたものに対して明快である。バイトはシーケンス空間に置かれ、確認応答が前進を示し、欠落すれば再送される。最後には配送に成功するか、リセットを受けるか、設定された断念条件へ達する。

ところがアイドル接続には、その観測材料がない。新しいバイトはACKを待っておらず、未確認バイトのタイマーも動かない。両端が健全で話す必要がない場合も、片方がクラッシュした場合も、経路やファイアウォール状態やアドレス変換が失われた場合も、手元のTCPには同じ静けさとして現れ得る。

これは信頼性の破綻ではない。配送を試していない以上、配送の成否から世界を知ることはできないという境界である。

次のバイトの一歩手前から問う

RFC 1122 は1989年、keepaliveを議論の残る任意機能として記録した。典型的なプローブは SEG.SEQ = SND.NXT-1、つまり次に送れる新しいバイトの直前を使う。

この少し不自然な位置には意味がある。新規のアプリケーションデータとして進むのではなく、接続状態を持つ相手のTCPから「次にここを待っている」というACKを引き出す。通常はデータを持たず、ストリームを進めない。一バイトの「ごみ」を付ける方式は、当時の誤った実装との相互運用のためだけに設定可能とされた。

ACKが答える問いは狭い。いま、ある遠隔TCPが往復可能な経路越しにこのセグメントを処理した。それだけである。相手のプロセスが仕事を進めていること、認証が有効なこと、データベースへ届くこと、次の業務要求に答えられることまでは示さない。

「任意」は安全設計だった

RFC 1122は、すべてのTCPにkeepalive実装を義務づけなかった。実装する場合も、アプリケーションが接続ごとに有効・無効を選べなければならず、既定値は無効。アイドル時間は設定可能で、既定は少なくとも二時間とされた。

端末セッション、経路制御の隣接、データベース・プール、眠るセンサーでは、誤切断、検出遅延、余分な通信、状態保持の費用が違う。トランスポート層は「バイトが来ない」ことしか知らず、どの費用を優先すべきか推測できない。

二時間は7,200秒後に相手が死ぬという自然法則ではない。アプリケーションが別の方針を選ばない限り、勝手な探りをまれにするための保守的な境界だった。統合された現行仕様 RFC 9293 もこの配置を保つ。長い運用史は、任意の探りを生命の自動判定へ変えなかった。

一度の無応答が証明にならない理由

データを伴わないACKは、独立したデータのように確実な再送対象ではない。プローブが落ちることも、そのACKが落ちることも、混雑で遅れることもある。このためRFC 1122とRFC 9293は、どれか一度の無応答だけで接続を死んだと扱うことを明確に禁じる。

切断は観測ではなく行為である。ローカルTCPが状態を捨てれば、アプリケーションは取引を断念し、ロックを解き、代替を選出し、別接続を作るかもしれない。一瞬のパケット損失から出た判断が、損失より長く残る結果を生む。

複数回の探りと閾値は故障の確からしさを高める。それでも意味するのは、「証拠がこれだけ欠けたなら、不確実性を維持する費用が閉じる費用を上回る」というローカルなリスク選択である。不在は目撃証言にはならない。

ユーザータイムアウトは別の時計

TCPにはもともと、送ったデータが確認されない場合のユーザータイムアウトがある。RFC 5482 は後にタイムアウト希望を伝えるオプションを定義した。その問いは「送信済みデータをいつまで未確認のまま許すか」であり、「暇な相手がいつから話していないか」ではない。

時計を区別しなければ方針が衝突する。RFC 5482は、keepaliveが一時的な断絶を乗り越えられた接続まで中止し得ると指摘し、同仕様の下で併用するならkeepaliveタイマーを採用済みユーザータイムアウトより長くするよう求める。送信データ、アイドル時の問い、閉鎖判断は近いが同じ証拠ではない。

経路の途中にも消える記憶ができた

端点が接続状態を持つという構図に、NATやステートフルな中間装置は別の期限付き台帳を加えた。両ホストが接続を正しく保持していても、中間装置が次のパケットに必要な対応表を消すことがある。

RFC 5382 は二時間の既定値を互換性の境界にした。確立済み接続の端点活動を判別できないNATは、二時間四分より前にマッピングを捨ててはならない。余分な四分は飛行中のパケットを考慮する。

これは端点の期待を守る規則で、NATへ接続の所有権を与えるものではない。実機が常に守る保証もない。より短い寿命に遭遇した運用者は、しばしば探りを増やす。マッピングは残っても、アプリケーションの会話ではなく私有装置の忘却を防ぐために通信する「中間装置税」である。

電池が逆向きの費用を見せた

常時給電のサーバーなら小さなパケットは安く見える。省電力機器では送信のたびに無線を起こし、高消費の活動時間を延ばすことがある。RFC 9006 は、長いTCP既定値では一部中間装置の状態を保てず、短いkeepaliveでは電池を減らすという対立を示す。

万能の秒数はない。アプリケーションは再接続の遅れを許せるか知り、運用者は経路上の状態寿命を測り、端末は電力予算を持つ。三者を合わせれば、そもそも接続を保たず、仕事が来た時だけ作り直すのが合理的な場合もある。

カーネルの鼓動と業務の鼓動

Keepaliveを心拍と呼ぶと、聞こえる範囲を誤解しやすい。サービス・プロセスがデッドロックしてもカーネルはACKできる。プロキシはTCPへ返答できても上流が壊れているかもしれない。健康なアプリケーションが意図的に休止している場合もある。

アプリケーション層の心拍は、要求を解釈し、状態を読み、有効な応答を作れるかという強い問いを出せる。費用も高く、将来の全作業を保証するわけでもない。二つを重ねるなら、それぞれが検出する故障を先に定義すべきだ。

またkeepaliveはゼロウィンドウ・プローブではない。後者は受信側が明示したゼロ容量から窓を再開した通知の喪失を防ぐ。前者は、ほかに通信のない接続を問う。似た小包が守る契約は別物である。

沈黙には推定無罪が残った

長く残った設計判断は SND.NXT-1 の技巧そのものではなく、沈黙を既定で有罪にしないことだった。

ACKを受ければ、最近TCPが応答できたという証拠になる。アプリケーションの健全性ではない。ACKがなければ不確実である。死亡の証明ではない。連続する欠落が切断を正当化するのは、アプリケーションが自分のリスク予算を選んだからだ。

Keepaliveが任意であり続けるのは、誤判断の結果を負う端点が決定権を持つべきだからである。TCPは問い方を提供したが、なぜ答えがないかを知る権威までは主張しなかった。

出典と証拠の限界

RFC 793 は当初の接続とユーザータイムアウト、RFC 1122 は1989年のkeepalive契約、RFC 5382 はNATの時間要件、RFC 5482 はユーザータイムアウトとの分離、RFC 9006 は電力との交換条件、RFC 9293 は統合された現行規則を示す。個別OSの既定値、すべての中間装置の寿命、各アプリケーションの健全性までは証明しない。