QUIC(頭字語ではありません)は独特な存在ですが、インターネットに長年存在する多くの問題を解決し、TCP、TLS、SCTP、IPSec、HTTP/2がもたらす価値の大部分を取り込んだ新しいトランスポートプロトコルと考えるのが最も適切です。また、TCP/TLSではなくUDP/QUIC上で動作するように設計された、HTTP/3という新しいバージョンのHTTPがあります。
Googleは早くも2014年に、QUIC上で動作するHTTPの初期バージョンを自社のブラウザとWebサーバーに導入しました。IETFによる標準化プロセスは2016年に始まりました。その後、数多くの改良とデータ収集を経て、2021年初頭に最初のRFC群として結実する見込みです。F5を含む複数の大手インターネット企業は、QUICを使用する製品をすでに出荷しているか、自社のインフラストラクチャにQUICを導入しています。2020年10月時点で、Facebookのトラフィックの75%がHTTP/3およびQUIC経由でした。
こうした早期導入と、IETFにおけるQUIC上の新規格策定への熱意は、QUICがインターネット上の最先端アプリケーションを支える重要な基盤となり、主流になる可能性もあることを示しています。
技術概要—なぜQUICなのか?

図1から、QUICがどのような機能を果たすのかを把握できます。しかし、この機能分解だけでは、業界の早期導入企業がQUICへの移行を進めている理由は明らかになりません。
- 低レイテンシ。Webのようなデータ転送では、TCPで1回、TLSで少なくとも1回、HTTPのリクエスト/レスポンスで1回という3層のハンドシェイクによるレイテンシが大部分を占めます。TCP/TLSの最近の進歩により、原理上はこれを1往復に集約できますが、実際にはほとんど機能しません。QUICでは、これを1往復、最大でも2往復に削減します。
- ストリーム。HTTP/2と同様に、QUICはアプリケーションに複数のバイトストリームを提供し、同じ接続で配信される概念的に異なるデータの独立性を高めます。これをトランスポート層で実現することで、独立性はさらに向上します。ストリームは動画ストリーミング配信のニーズに自然に適合し、大手インターネットコンテンツプロバイダーはQUICによるストリーミング配信の実現に向けて着実に進んでいます。
- パケット損失への対応を改善 QUICは、その設計により、パケット損失を検出して回復するTCPの能力を向上させます。さらに、単一の順序どおりのバイトストリームではなく多重化されたストリームを提供するため、あるオブジェクトを含むパケットが失われても、別のオブジェクトの配信が遅延するとは限りません。
- マルチホーミング。MPTCPやSCTPと同様に、QUIC接続では各エンドポイントに複数のIPアドレスを関連付けることができます。これらのプロトコルとは異なり、QUICは、認識されないプロトコル番号やTCPヘッダーオプションを破棄するインターネット環境でも通過できる可能性が高くなります。
- セキュリティとプライバシー QUICは、トランスポート層より上位の層ではなく、トランスポート層で暗号化を適用します。UDPペイロード全体が認証されるため、中間者による透過的な変更が防止され、トランスポート情報のほぼすべてが暗号化されます。この影響については、それだけで1本のホワイトペーパーになるほどです。要するに、これによりプライバシー特性が大幅に向上し、TCPに存在する攻撃対象領域が事実上ほぼ解消されます。IPSecとは異なり、QUICは現在、Webスケールで稼働しています。さらに、次のような効果もあります。
- 拡張性。TCPは、設計者が拡張用の領域を限られた範囲しか確保しなかったことに加え、ミドルボックスが従来のTCPの動作を強制するため、変更が困難です。QUICは、明示的なバージョン管理と、ミドルボックスから内部を見えなくする仕組みを組み合わせることで、トランスポート層のさらなる革新を可能にします。これにより、将来のユースケースに対応できるようになり、最終的にはTCPと比べて大容量データ転送の処理能力が向上します。
一部のアプリケーションがQUICに移行しない可能性がある理由は、惰性以外に2つあります。
- 複雑さ:単一のバイトストリームのみを必要とし、暗号化を重視しないアプリケーションでは、これらの機能に伴う追加の処理負荷は必要ありません。
- ミドルボックス:無視できない割合のインターネット経路では、UDPが許可されていません。HTTP/3は、こうした経路でTCPにフォールバックするよう設計されています。しかし最終的には、主要なWebサイト(Google、Facebookなど)へのパフォーマンス上の影響により、原因となるデバイスは廃れていく可能性があります。ただし、監視を望む国家がその使用を義務付ける場合は除きます。
インターネットを席巻している
Google Chrome、Google App Clients、Facebookアプリは、すでにHTTP/3に対応しています。Safari、Edge、FirefoxにもHTTP/3が実装されていますが、現時点ではデフォルトで無効になっています。
サーバー側では、Google、Microsoft、Facebook、Apple、Cloudflare、LiteSpeed、F5 BIG-IP、NGINX、Fastly、Akamaiによる実装や導入がすでに提供されているか、提供間近です。最近、欧州の大手ISPは、パケットの20%がQUICだったと報告しました。2021年2月時点では、Webサイトの5%がHTTP/3を使用していましたが、RFCの公開後はこの割合が増加すると予想されます。
さらに、標準化団体では、QUICをHTTP以外のユースケースにも拡大するための取り組みが数多く進められています。IETFの標準化草案では、QUIC上でのDNS、WebSockets、SIP、およびTCPとUDPの両方のトンネルが提案されています。QUICは登場がやや遅く、5Gアーキテクチャに全面的に組み込まれるには間に合いませんでしたが、サービスプロバイダーがQUICに高い関心を寄せており、QUICが適用可能であることは明らかです。最後に、HTTP/2とHTTP/3の上位APIは非常によく似ているため、HTTP/2上で動作するプロトコルやアプリケーションは、TCPの代わりにHTTP/3とQUIC上で動作するよう容易に移植できます。
脅威と機会
QUICとHTTP/3は、さまざまな市場に影響を与えるでしょう。高パフォーマンスのWebサイトやアプリケーションには、エコシステムが十分に成熟した段階でHTTP/3とQUICへ移行する大きな動機があります。また、HTTP/3のサポートに対するお客さまの需要は、HTTP/2の導入と同程度のペースで高まると予想しています。
セキュリティ製品は、QUICが主流となるインターネットにおいて、根本的な見直しが必要です。TLSセッションキーにアクセスできなければ、パケット検査ははるかに困難になります。通常、このアクセスにはドメインの秘密鍵が必要です。そのため、単機能デバイスを複数組み合わせるよりも、アプリケーションレベルのプロキシと統合されたセキュリティソリューションの価値が高まります。
さらに、従来のDDoS防御も見直しが必要です。パケットの識別と検査が難しくなっただけでなく、TCP SYN Cookieは、中間者による偽装が容易ではない「Retryパケット」に置き換えられています。サーバーがRetryパケットの生成と検証をオフロードできるように連携する標準的な方法はありますが、やはり開発作業が必要です。
従来のレイヤー4ロードバランシングでは、アドレスやポートが変更されたフローを同一のフローとして関連付け、同じサーバーにルーティングできないため、QUICのアドレス移行が機能しなくなります。この問題についても、連携して解決するための標準仕様はありますが、対応には投資が必要です。
IETFの「MASQUEワーキンググループ」は、QUIC上で汎用的にトラフィックをトンネリングする技術の策定に取り組んでおり、これは次世代VPN方式の基盤となる可能性があります。QUICは、任意のフローを多重化するうえで、TCP上のTLSよりもはるかに優れた特性を備えています。また、これらのトンネルでは、IPSecトンネルをWebスケールの暗号技術で置き換えることで、一部のサービスプロバイダーのユースケースを改善できるほか、クライアントの明示的な同意を得たうえで、モバイル回線の種類に応じてQUIC接続を最適化する手段も提供できます。
QUICには、新たなネットワーク測定・分析ツールが必要になります。TCPの遅延や損失を測定できたシステムでは、これらのシグナルを利用できませんが、ネットワークに対する明示的な遅延シグナルがあり、今後ほかのシグナルも登場する可能性があります。暗号化によって隠されるトランスポート情報が増えるため、パケットキャプチャの有用性は低下します。ただし、多くのQUIC実装が準拠する策定中の標準ログ形式があり、これを活用する分析ツールの開発が進められています。
F5は動向を注視しています
F5のスタッフは長年にわたり、IETFにおける標準化の取り組みを注視し、お客さまに役立つと考えられる分野で貢献してきました。BIG-IPは当初からQUICおよびHTTP/3のドラフトリリースに対応しており、TMOS v15.1.0.1以降では一般公開リリースにも対応しています。NGINXでは、HTTP/3アルファリリースを提供しており、近日中にメインラインへ統合する予定です。
F5は今後もこの分野の動向を注視し、これらのプロトコルがもたらす新たな機能を取り入れた、革新的で魅力ある製品を開発していきます。
まとめ
QUICは業界から幅広い支持を得ており、インターネットを通じてビジネス価値を提供する多くのアプリケーションの基盤となる可能性があります。インターネット経由でアプリケーションを提供する組織は、これらのプロトコルがもたらす新たな脅威と機会を踏まえ、運用をどのように変えるべきか検討を始める必要があります。
著者について
関連するブログ記事

SOAS 2025:足並みの乱れが凡庸さを招く
AI導入における方針の不一致は、非効率を招きます。セキュリティ、自動化、導入の各戦略を整合させ、AIの可能性を最大限に引き出す方法をご紹介します。

WebAssemblyが重要な理由
WebAssembly(Wasm)は、あらゆるプラットフォームで高性能なアプリケーションを実現する、ポータブルで高速かつセキュアなバイナリ命令セットです。
インフラストラクチャは依然として格好の攻撃経路
クラウドコンピューティングでは、APIやドラッグ&ドロップ式の設定ツールを活用し、ネットワークやインフラストラクチャを敬遠する人がそれらを直接扱わずに済むようにすることで、インフラストラクチャへの対応を不要にすることが長年追求されてきました。しかし、インフラストラクチャを無視することも、攻撃の主要な標的であるという事実を見過ごすこともできません。
堅牢なデータアーキテクチャがもたらす戦略的メリット
適切に構築されたデータアーキテクチャがもたらす効果は、業務プロセスの改善にとどまりません。戦略的な業務効率の向上、より深いビジネスインサイトの獲得、隣接するビジネス機会への展開にもつながり、これらすべてをより俊敏に実行できるようになります。
デジタルワークフローにおける不正検知には、データだけでは不十分
2019年には、業界全体でクレジットカード詐欺の試みが約25万件確認されました。これは約2分に1件の割合です。今日、不正を検知するには、デジタルワークフロー上のできるだけ多くのポイントから収集したデータを相互に関連付け、手作業によるデータ処理をはるかに上回る速度で分析する能力が求められます。