届いたことを確かめる — ACKと再送、そして規定と実装のズレ

第22週で接続がつながりました。つながった以上、そこへ流し込んだデータは相手に届く——そう考えたくなりますが、そうはなりません。

ネットワークには、データが失われないことを保証する仕組みがありません。途中のルータが混んでいれば捨てられますし、線の途中で化ければ破棄されます。しかも捨てた側は、誰にも謝りません。落ちたことは黙って起きます。

では送信側は、どうやって「届いた」と知るのでしょうか。

方法はひとつしかありません。相手に言ってもらうことです。 これが**確認応答(ACK)**です。受信側が「ここまで受け取った」と返し、送信側はそれを見て初めて、自分のデータが相手の手元にあると判断します。

逆に言えば、ACKが返ってこないうちは何も分かりません。データが落ちたのか、ACKのほうが落ちたのか、相手が遅れているだけなのか、送信側からは区別がつきません。区別がつかないので、TCPは一律に同じ対応を取ります——もう一度送る。これが再送です。

さて、以上がRFCの規定です。ではLinuxで動いているTCPの最小RTOは何秒でしょうか。

200msです。1秒ではありません。

Linuxカーネルの include/net/tcp.h には、次の定義が置かれています。

#define TCP_RTO_MAX_SEC 120
#define TCP_RTO_MIN     ((unsigned)(HZ / 5))    /* = 200ms */
#define TCP_TIMEOUT_INIT ((unsigned)(1*HZ))     /* RFC6298 2.1 initial RTO value */

3行を規定と突き合わせます。

項目      RFC 6298 の規定           Linux 実装値    評価
初期値    1秒 (§2.1)                1秒             一致
最小値    1秒に切り上げ (§2.4)       200ms           食い違う
最大値    60秒以上 (§2.5)            120秒           規定を満たす

初期値は一致しています。しかもソース中のコメントが RFC6298 2.1 initial RTO value と、参照している節まで明示しています。この実装はRFCを読んで書かれているわけです。

それでも最小値は食い違います。規定は1秒、実装は200ms。5分の1です。

そして、この節の見出しに戻ります。規定を読んだだけでは、目の前のマシンがどう動くかは分かりません。 RFC 6298 を最初から最後まで読んでも、自分のLinuxサーバが200msで再送を始めることは書いてありません。それはカーネルのソースにしか書かれていません。

逆も同じです。TCP_RTO_MIN の値だけを見ても、なぜ200msなのか、それが逸脱なのかどうかは分かりません。規定と実装の両方を見て、初めて事実の全体が見える——これが本レッスンで持ち帰ってほしい姿勢です。

累積ACKには構造的な限界があります。伝えられるのが「ここまでは連続して受け取った」という一点だけだからです。その先で何が届き何が欠けているかは表現できません。

そのため、1つのウィンドウの中で複数のセグメントが失われると厄介なことになります。RFC 2018 の表現を借りると、送信側は「1往復時間あたり単一の失われたパケットについてしか学習できない」のです。2つ落ちていれば、1つ目を直してから次の往復でようやく2つ目が見えます。

これを解くのが SACK (Selective Acknowledgement) です。受信側が「飛び地としてここも持っている」と追加で伝えることで、送信側は RFC 2018 の言う「欠けているデータセグメントだけ」を再送できます。

ただしここに、2つの外せない注意があります。どちらもRFC 2018 の原文に明記されています。

この2点は繋がっています。SACKが助言的だからこそ、確定の役割は累積ACKに残されているのです。「SACKがあれば累積ACKは不要」と考えると、どこまでが確定でどこからが暫定なのかの区別が消えてしまいます。