QUICの「信頼」を捨てる勇気：Unreliable DeliveryがWebのリアルタイム性を変える
ネットワークエンジニアの諸君、今日もパケットの海を泳いでいるかな。
TCPが支配してきた過去30年、我々は「再送」という名の神に祈りを捧げてきた。「パケットが届かなければ再送せよ、順序が違えば並べ替えよ」。この絶対的な信頼が、実は現代の低遅延アプリケーションの足枷になっていることに気づいているだろうか。
HTTP/3の心臓部であるQUICプロトコルは、これまでの「すべてを正しく届ける」という呪縛を解き放とうとしている。それが今回解説する「Unreliable Delivery（非信頼配送）」だ。
—
なぜ、いま「あえて届かない」通信が必要なのか
Web API設計において、リアルタイム性（レイテンシ）を追求する際、TCPのヘッド・オブ・ライン・ブロッキング（HoLB）は避けられない壁だ。1つのパケットが欠落しただけで、後続のすべてのデータがバッファで止まる。
しかし、考えてみてほしい。音声通話やライブストリーミング、あるいはゲームの現在地データ。これらは「100ms前の古いデータ」を再送して律儀に表示するよりも、「今、この瞬間の新しいデータ」を優先する方が遥かに重要だ。
QUICのUnreliable Deliveryは、この「捨ててもいいデータ」を明示的に扱うためのメカニズムだ。
Datagramフレーム：再送不要なデータの運び屋
QUICには、再送制御を行わない「DATAGRAMフレーム」という仕様がRFC 9221で定義されている。
通常、QUICのストリームデータは信頼性を保証するが、DATAGRAMフレームは「ベストエフォート」だ。送信したパケットが途中でロストすれば、それで終わり。再送も、順序の保証もしない。
通信フローの概念図
[Client] [Server]
| |
|— DATAGRAM (ID: 1, Data) ->| <-- ロストしても気にしない
|--- DATAGRAM (ID: 2, Data) ->| <-- これは届く
| |
|--- DATAGRAM (ID: 3, Data) X | <-- ロストした！(再送は発生しない)
|--- DATAGRAM (ID: 4, Data) ->| <-- 次のパケットが即座に処理される
この挙動を実装するためには、アプリケーション層で「順序番号（Sequence Number）」をデータペイロードに含める必要がある。ネットワーク層は「届いたものをそのまま渡すだけ」に徹するため、欠落検知と「どのデータが最新か」の判定は、諸君らエンジニアのコードに委ねられるのだ。
---
実装の勘所：QUIC Datagramをどう扱うか
実際にこの機能を試す場合、現状のFetch APIなどはまだブラウザ実装が限定的であるため、quic-go等のライブラリを用いたサーバーサイド実装が現実的だ。
以下は、Go言語による`quic-go`を用いたDATAGRAM送受信の概念コードだ。
// サーバーサイドでのDatagram受信例
for {
// データグラムを受信する。エラーが発生しても接続は切れない
data, err := conn.ReceiveMessage(ctx)
if err != nil {
log.Printf(“受信エラー: %v”, err)
break
}
// アプリケーション層で順序番号をチェック
// 0, 1, 2, 4 と届いた場合、3が欠落していることをここで判定する
processPacket(data)
}
// クライアントからの送信例
err := conn.SendMessage([]byte(“最新のセンサーデータ”))
if err != nil {
// 送信失敗時も再送ロジックは実装しない
log.Printf(“送信失敗: %v”, err)
}
デバッグ時の注意点
実務でのデバッグにおいて、Wiresharkでパケットを追う際は以下の点に注目してほしい。
1. `QUIC Datagram`フレームの確認: フィルタに `quic.frame_type == 0x30` を指定する。
2. ACKの有無: 通常のSTREAMフレームと異なり、DATAGRAMフレームにはACKが返ってこない（もしくは受信確認としての意味を持たない）。これが正常な挙動であることを忘れないように。
3. MTUサイズ: DatagramはIPフラグメンテーションを起こすと途端にパケットロス率が跳ね上がる。Path MTU Discovery (PMTUD) の結果を正しく反映し、バースト送信時にはパケットサイズを制御することが肝要だ。
—
シニアからの提言：設計の哲学
Unreliable Deliveryを採用する際に最も重要なのは、「どの情報を捨てていいか」というビジネスロジックの定義だ。
例えば、チャットアプリの「入力中…」というインジケーターは、たとえ途中でパケットが消えても、次のパケットが届けばそれで最新状態に更新される。これはDATAGRAMで送るべき適正なデータだ。一方で、ユーザーの決済ステータスなどは、何があっても再送を担保する信頼性の高いストリームに乗せるべきだ。
ネットワークは魔法ではない。プロトコルに「何をさせないか」を指示することこそが、次世代のインフラエンジニアに求められるスキルである。
さあ、TCPの「過保護な愛」から脱却し、現代の高速なネットワークにふさわしい、タフで無駄のない通信設計を始めてみようではないか。何か詰まったら、いつでもコンソールを開いてパケットを確認してくれ。答えは常に、流れているデータの先にある。
コメント