メインコンテンツへスキップ

QUICとUDP

🌐はじめに

HTTPはWeb通信の中心を担うプロトコルです。その最新版であるHTTP/3では、なんとTCPではなくUDPを使うという大胆な変更がなされています。

この記事では、「なぜHTTP/3はUDPを使うのか？」という疑問を軸に、QUICという新技術の仕組みや利点を中心に解説していきます。

📚背景：HTTPの進化と限界

🧱HTTP/1.1とTCPの限界

  • HTTP/1.1では1つのTCP接続で1つのリクエストという制限があり、ページ表示が遅かった

  • TCPは信頼性重視で再送制御があり、パケットロスに弱く、復旧に時間がかかる

  • 特にモバイル通信では遅延の原因に

HTTP/1.1時代は、画像やスクリプトの取得のために多数のTCP接続を張る「多重接続」が一般的で、負荷も高かった

🚅HTTP/2での改善と限界

  • TCP上でストリームの多重化が可能に（1接続で複数リクエスト）

  • しかし、1つのパケットが失われると全体のストリームが足止めされる（ヘッド・オブ・ラインブロッキング問題）

🚀QUICとは？

✅概要

QUIC（Quick UDP Internet Connections）は、Googleが開発したUDP上に構築された新しいトランスポートプロトコルです。

✅位置づけ

  • OSIモデルで言えば「TCPの代わり」にあたる

  • HTTP/3はこのQUIC上で動作する

  • つまりHTTP/3 = HTTP/2 + QUIC（UDPベース）

🔍なぜUDPを使うのか？

UDPはコネクションレスで軽量。この特性を活かして、以下のような自前実装の自由度が得られます：

課題 TCPの限界 QUIC（UDPベース）による改善
接続時間 3-wayハンドシェイクで遅延 1-RTTで高速接続（場合によっては0-RTT）
モバイル回線の切替 IP変わるとTCPは再接続 QUICは接続IDによりセッション継続可
パケット損失の影響 他のストリームも止まる 各ストリーム独立（マルチプレクシング）
セキュリティ TLSは別レイヤー QUICはTLS 1.3が組み込み済み

🧩QUICの内部構造：特徴的な仕組み

✅ 1. マルチプレクシング

  • 複数のストリームが独立して並行送信できる

  • パケットロスしても、他のデータには影響しない

✅ 2. 0-RTTハンドシェイク

  • 過去に接続したサーバであれば0-RTTで通信開始可能（キャッシュによる再利用）

  • 初回でも1-RTTでTCPより高速

✅ 3. 接続ID（Connection ID）

  • 通信中にIPアドレスやポートが変わってもセッションを維持できる

  • 特にモバイル端末のWi-Fi↔4G切り替え時に有効

✅ 4. TLS組み込み

  • 暗号化が必須で標準装備

  • TCP + TLSよりセキュリティとパフォーマンスのバランスが良い

🌐HTTP/3の登場：実用化の現状

✅ 状況

  • Google Chrome、Firefox、Safariなど主要ブラウザで対応済

  • Cloudflare、Facebook、YouTube、Googleなどもすでに本番運用

  • Webサーバ（nginx、LiteSpeed）やCDNも対応を進行中

✅ 注意点

  • UDPポート443がファイアウォールでブロックされている環境では使えない可能性がある

  • その場合は従来のHTTP/2やHTTP/1.1にフォールバックされる

🎯QUICの嬉しさまとめ

特性 嬉しさ
ストリームの独立 映像・音声・テキストなど混在でもスムーズ
早い接続 ページ表示が速くなる、特に初回以外
モバイル環境に強い 通信切り替えでも中断なし
組み込みTLS セキュリティと速度の両立
UDP利用 カーネルバイパスや独自最適化が可能

🧠おわりに

HTTP/3は単なる「新しいHTTP」ではなく、インターネット通信の根本を変える革新です。

QUICによって、TCPでは解決できなかったレイテンシ・柔軟性・セキュリティの課題を一気に解消しつつ、UDPの柔らかさを活かした未来型プロトコルへと進化しています。

上に戻る