こんにちは！日々のインフラ運用やWeb開発、本当にお疲れ様です。技術メディア主筆の私です。
私たちが何気なくブラウザにURLを打ち込み、Enterキーを押した瞬間、画面の向こう側では目にも留まらぬスピードでデータが行き交っています。最近のWebは「より速く！」を合言葉に進化を続けており、その最先端を走るのがHTTP/3です。
HTTP/3の最大の魅力といえば、何と言っても「0-RTT（ゼロ・アールティーティー）ハンドシェイク」。これまでの通信の常識を覆し、初めて繋ぐ相手であっても「挨拶なしでいきなり本題（データ）を送りつける」という超スピード技を実現しています。
でも、ちょっと待ってください。「挨拶なしでいきなり荷物を送る」って、現実世界で考えたらちょっと怖くないですか？
今回は、この0-RTTが抱える「再送攻撃（リプレイアタック）」というセキュリティの罠と、それを防ぐための仕組みについて、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！
—
1. そもそも「0-RTT」ってなに？ 郵便配達に例えてみよう
これまでの通信（HTTP/1.1やHTTP/2、そして従来のTLS）が、お互いに「はじめまして」「よろしくお願いします」と何度も確認（ハンドシェイク）してから本題に入っていたのに対し、HTTP/3はその手間を極限まで削ぎ落としました。
これを郵便配達に例えてみましょう。
- 従来の通信（1-RTT以上）：
あなたが差出人で、友人に手紙を出したいとします。まず「今から手紙送ってもいい？」とハガキを出し、友人が「いいよ」と返事をくれて初めて、本命の手紙を送ることができます。これだと、やり取りに時間がかかりますよね。
- 0-RTTハンドシェイク：
「去年のやり取りで、お互いの住所もルールも分かっているよね？」という状態です。あなたは「前回と同じルールね！」と自分の中で納得し、確認の返事を待たずに、いきなり本命の手紙をポストに投函してしまう――これが0-RTT（Round Trip Timeが「0」＝往復ゼロ）の世界です。
待ち時間がゼロになるので、体感速度は爆発的に速くなります。モバイル回線でトンネルに入ったり、電波が不安定になったりする現代の私たちにとって、まさに救世主のような技術です。
—
2. スピードの裏に潜む魔物：「再送攻撃（リプレイアタック）」とは？
「挨拶なしでいきなりデータを送れる」ということは、裏を返すと、「悪意ある第三者が、過去のやり取りをそっくりそのままコピーして、もう一度送りつけても、サーバーがそれに気づきにくい」という弱点を生むことになります。
これが再送攻撃（リプレイアタック）です。再び郵便配達の例に戻りましょう。
あなたが通販サイトで「お会計1万円のボタン」を0-RTTでポチッと押したとします。そのとき、あなたの背後で悪意あるハッカー（盗聴者）が、その通信をこっそりスマホで録音（キャプチャ）していました。
ハッカーは、その「1万円払う」というデータを、全く同じ形でサーバーに向けて何千回、何万回と一斉に送りつけました。
もし、サーバーが「お、常連さんからの荷物だな！中身を確認せずに受け取っちゃお！」とすべて処理してしまったらどうなるでしょう？ あなたの口座から、意図せず何十万円ものお金が引き落とされてしまいますよね。これが、0-RTTデータが直面する最大のセキュリティリスクなんです。
—
3. サーバー側の防御策：どうやって「偽物のコピー」を見破るのか？
「じゃあ、0-RTTなんて危なくて使えないじゃないか！」と思われるかもしれませんが、そこは世界中の頭脳が詰まったネットワーク規格です。ちゃんと強固な盾が用意されています。
サーバー側では、以下のような戦略でこの再送攻撃をブロックします。
1. 「安全なデータ」と「危険なデータ」の線引き（べき等性の利用）
サーバーは、何度同じデータが送られてきても結果が同じになる操作（例：ページの閲覧データを取得する`GET`リクエストなど）は、0-RTTでの受け入れを許可します。しかし、お金を支払ったり、パスワードを変更したりするような、何回も実行されては困る操作（`POST`や`PUT`などの状態を変えるリクエスト）については、0-RTTでの受け入れを厳しく制限、あるいは拒否します。
2. 一度きりの「切符（ワンタイムチケット）」の乱用防止
サーバーは、過去に通信したことがあるクライアントに対して「次回使える特殊な切符（セッションチケット）」を渡しています。0-RTT通信を行うには、この切符を提示する必要があるのですが、サーバー側で「この切符でデータを受け取るのは、世界中で一度きり！」という厳しい管理（アンチ・リプレイ・キャッシュなど）を行っています。同じ切符を使った2回目のデータが届いた瞬間、サーバーは「お前、さっきも来たな！」とそれをゴミ箱にポイっと捨てるのです。
—
4. 実装上の制約と現場のエンジニアが知っておくべきこと
では、実際にHTTP/3（QUICプロトコル）をサーバー（NginxやCloudflare、自作のGoアプリケーションなど）で構築・運用する際、私たちはどんなことに気をつけなければならないのでしょうか？
設定のイメージを少し覗いてみましょう。
NginxやQUIC対応サーバーの設定イメージ（擬似コード）
http {
# HTTP/3を有効化
quic_retry on;
# 【重要】0-RTTの許可設定
# 安全性が確認できない環境では、むやみに0-RTTを全許可しないのが鉄則
ssl_early_data on;
server {
listen 443 ssl http3 reuseport;
# 動的なリクエスト（POST等）に対する保護
# 0-RTTで送られてきた危険なメソッドを安全なハンドシェイクにフォールバックさせる
# （アプリケーション側での「べき等性（Idempotency）」の担保が必須）
}
}
実務の現場では、次のような「実装上の制約」に直面します。
- サーバーが複数台ある場合（負荷分散環境）の罠：
最近のWebサイトは、ロードバランサーの裏側に数台〜数十台のWebサーバー（コンテナ）が並んでいますよね。もし、Aサーバーが発行した「切符」を、悪意あるユーザーが別のBサーバーに送りつけた場合、サーバー間で「この切符はもう使われたよ！」という情報をリアルタイムで共有（同期）していないと、再送攻撃をすり抜けてしまうリスクがあります。
- アプリケーション側の設計：
インフラ側だけで完全に防ぐのは難しいため、アプリケーションのコード側でも「リクエストID（UUIDなど）」を一つひとつデータベースでチェックし、「同じIDのリクエストは2回処理しない（デデュプリケーション：重複排除）」という実装を必ずセットで行う必要があります。
—
おわりに：スピードと安全性のバランスをデザインする
HTTP/3の0-RTTハンドシェイクは、Webを劇的に速くする魔法の杖のようですが、その裏側では「スピード＝確認の省略＝リスクの増加」というトレードオフが存在しています。
インフラやネットワークに触れ始めたばかりの頃は、「とにかく速い設定にしたい！」と思いがちですが、私たちが守るべきなのは「ユーザーの大切なデータと信頼」です。
「どこまでを0-RTTでサクサク通し、どこから先を慎重にチェックするか」――この絶妙なバランスをデザインしてこそ、一流のネットワークエンジニアと言えます。
今回の記事が、皆さんの日々の学習や、現場でのトラブルシューティング、そして安全なWebアーキテクチャ設計の小さなヒントになれば幸いです。それでは、また次回の技術の深掘りでお会いしましょう！
コメント