こんにちは！ネットワークの世界へようこそ。
日々何気なく使っているインターネットですが、私たちがブラウザにURLを入力してページが表示されるまで、実は裏側でめちゃくちゃドラマチックな「お辞儀の応酬（ハンドシェイク）」が行われているのをご存知でしょうか？
今回は、その通信の常識を根底から覆した、次世代プロトコルHTTP/3の秘密兵器「0-RTT（ゼロ・アールティーティー）ハンドシェイク」の世界へ皆さんをご案内します。
難しい専門用語や小難しいパケットの構造はいったん脇に置いて、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！
—
1. そもそも「RTT」ってなに？ ネットの往復書簡
「0-RTT」の「RTT」とは、「Round Trip Time（ラウンド・トリップ・タイム）」の略です。日本語に訳すと「往復遅延時間」。
パケット（データのかたまり）が、あなたのパソコンからサーバーまで行って、また手元に戻ってくるまでの「旅の時間」のことですね。
郵便配達で例えてみましょう
あなたが遠く離れた友人に手紙を出すとします。
1. 行き（1往復目）： あなたが手紙を投函し、友人のもとに届く。
2. 帰り（2往復目）： 友人が返事を書き、あなたの手元に届く。
これが「1-RTT」の世界です。手紙が往復するのに、どうしても時間がかかりますよね。インターネットの世界でも、サーバーと通信を始める前には「こんにちは、暗号化の準備をしましょうね」「はい、よろしくお願いします」という挨拶（ハンドシェイク）を何往復も交わしていました。
これまで主流だったHTTP/1.1やHTTP/2（TCPというプロトコル）では、この挨拶だけでどうしても数回の往復（数RTT）が必要でした。これが、ページが表示されるまでの「モタつき」の原因だったのです。
—
2. 待たせない！HTTP/3と0-RTTの魔法
ここで登場するのが、UDPをベースにした次世代の通信規格HTTP/3（QUICプロトコル）です。
QUICは、初回こそ少し挨拶を交わしますが、一度つながったサーバーのことは忘れません。次にそのサーバーへアクセスするとき、驚きの技を使います。それが「0-RTTハンドシェイク」です。
「前回の合言葉」で、いきなり本題を叫ぶ
0-RTTの仕組みは、おなじみの常連カフェを想像すると非常にわかりやすいです。
- 初回（通常）：
「初めて来たのですが、会員証を作ってください」「はい、こちらが会員証と合言葉です」といったやり取り（数往復）が必要です。
- 2回目以降（0-RTT）：
あなたはカフェの扉を開けるなり、レジに向かって「前回と同じやつを！」と叫びながら、同時に代金をカウンターに置きます。店員さんは合言葉をパッと確認して、すぐコーヒーを作り始めます。
なんと、「挨拶の往復を一切待たずに、最初からデータ（リクエスト）を送りつける」のが0-RTTの正体です。往復時間（RTT）が「ゼロ」のままデータが届くので、体感速度が爆発的に速くなります。
—
3. 圧倒的な速さの裏に潜む「影」：リプレイ攻撃の脅威
「じゃあ、いつでも0-RTTを使えば最高じゃん！」と思いますよね。エンジニアの世界はそんなに甘くありません。ここに、セキュリティ上の大きなジレンマが潜んでいます。
先ほどのカフェの例を少し物騒にしてみましょう。
もし、あなたが悪意ある人に「前回と同じやつを！」と言っている音声をこっそり録音され、あなたがカフェに入っていないタイミングで、その音声を何度も何度もスピーカーで再生されたらどうなるでしょう？
店員さんは勘違いして、何杯もコーヒーを作り、あなたの財布から勝手にお金が引き落とされてしまいますよね。
これがネットワークの世界で言う「リプレイ攻撃（再送攻撃）」です。
0-RTTで送られるデータ（例えば「私の銀行口座から1万円振り込んで！」というリクエスト）が誰かに盗聴され、全く同じデータが何度も悪意を持ってサーバーに送りつけられた場合、サーバーはそれが正当なものか、偽物のコピーなのかを最初は判別できません。
そのため、サーバー側やアプリケーション側で以下のような防衛策をしっかり設計・実装しておく必要があります。
- 「1回限りの使い捨て」にするデータだけを0-RTTで送る
（検索窓で文字を検索する、ホームページのトップ画像を取得するなど、何度実行されても安全な「読み取り専用（冪等：べきとうな）」の処理に限定する）
- 書き込みや決済などの重要な処理には使わない
—
4. 実務で触れるNginxでの設定イメージ
インフラエンジニアやWeb開発者が、実際にHTTP/3やQUIC、そして0-RTTを意識する場面として、Webサーバーの設定ファイルがあります。
例えば、モダンなWebサーバーであるNginxでQUICを有効にする際の設定例を覗いてみましょう。（※環境やバージョンによってディレクティブは異なります）
HTTP/3 (QUIC) を有効化するバーチャルホストの設定例
server {
listen 443 ssl;
listen 443 quic reuseport; # UDPポート443番でQUICの待ち受けを開始
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
# TLS 1.3の有効化（QUICの暗号化基盤にはTLS 1.3が必須です）
ssl_protocols TLSv1.3;
# 【重要】0-RTT（早期データ送信）を許可する設定
# これにより、クライアントが持っている前回のセッション情報を使って
# 最初のパケットからアプリケーションデータを処理できるようになります。
ssl_early_data on;
location / {
# 0-RTTで送られてきたリクエストに対するバックエンド側の処理
# ※リプレイ攻撃のリスクがあるため、決済やPOSTリクエスト等の扱いは
# アプリケーション側で厳重にチェックする必要があります。
try_files $uri $uri/ =404;
}
}
このように、設定ファイルの一行(`ssl_early_data on;`)で、あの爆速の0-RTTハンドシェイクが有効になります。しかし、その裏で「リプレイ攻撃対策をどう担保するか」というアーキテクチャの検討が、インフラとアプリの両面で求められるのです。
—
まとめ：一歩ずつ、次世代のネットワークへ
今回は、HTTP/3とQUICの花形機能である「0-RTTハンドシェイク」について紐解いてみました。
- RTT（往復遅延時間）：データが往復する時間のこと。
- 0-RTT：過去の接続情報を使い、挨拶の往復をスキップしていきなりデータを送る技術。
- トレードオフ：圧倒的に速くなる一方で、「リプレイ攻撃（データのコピー攻撃）」への対策が必要不可欠になる。
ネットワークの技術は、ただ「速くする」だけでなく、「どうやって安全性を担保するか」というセキュリティとの戦いの歴史でもあります。
最初は難しく感じるかもしれませんが、こうして身近な例えに置き換えてみると、パケットたちがサーバーとやり取りしている姿が少しイメージしやすくなったのではないでしょうか？
一歩ずつ、確実に知識をアップデートして、次世代のネットワークマスターを目指していきましょう！
コメント