40
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

HTTP/3とQUICについてざっくり解説

Last updated at Posted at 2021-12-18

この記事は、Ateam Finergy Inc. Advent Calendar 2021 19日目の記事です :christmas_tree:

本日は、ナビナビ証券 の開発に携わっている @kazenomachi が担当します。

はじめに

これまでインターネットではTCP(Transmission Control Protocol)という通信プロトコルが標準的に用いられてきましたが、
今年の5月、IETF(Internet Engineering Task Force)によって新たにQUICというプロトコルがRFC9000として承認されました。

QUICがこれからのインターネットにどのような影響を及ぼすのでしょうか?

本記事では、QUICHTTP/3について、できるだけ簡単に、掻い摘んで解説してみようと思います。

これまでのインターネット

WebブラウザとWebサーバーとの間の通信では、HTTPというプロトコルが用いられています。

HTTPは、最初にHTTP/1.1が1997年にRFC 2068として標準化されました。

HTTP/1.1は、テキスト形式でデータのやりとりを行います。
ひとつのリクエストが完了するまで、次のリクエストを送信することができないという仕組みのため、Webコンテンツが発展し大規模になるにつれて、非効率な通信方法であることが問題となってきました。
(これをHead-of-Line-Blocking問題といいます)

その後、時代に合わせて改良が進み、HTTP/2が2015年にRFC 7540として標準化されました。

HTTP/2では、テキスト形式ではなくバイナリ形式でデータのやりとりを行うようになりました。
従来のHTTP/1.1を踏襲しつつ、HPACKというヘッダ圧縮技術やストリーム技術が導入され、データの転送量を減らすことが可能となりました。

HTTP/1.1で問題となっていたHead-of-Line-Blocking問題に対しては、ストリームの多重化を行うことで、1つのコネクション上で複数のリクエストを送ることが可能となりました。
しかし、複数のリクエストを単一のTCPコネクションで処理するため、もしもパケットロスが生じた場合、そのパケットの再送を待つ間、コネクションが停止することとなります。
パケットロス率が上昇すると、それだけパフォーマンスが低下することとなります。

HTTP/2ではHTTP(アプリケーション層)におけるHead-of-Line-Blocking問題は解消しましたが、TCP(トランスポート層)におけるHead-of-Line-Blocking問題は残っているという状態でした。
この問題を解消するために、新たにQUICというプロトコルが開発されました。

QUIC

QUICとは、2013年にGoogleが発表し、2021年5月にIETFでRFC9000として承認されたトランスポート層のプロトコルで、UDPをベースに開発されました。

HTTP/2までで使われていたTCPではなく、UDPがベースとなっています。
UDPは、パケットを受信する順序に決まりがないため、パケットロスが発生しても問題なく他のパケット処理を行うことができ、TCPで発生していたHead-of-Line-Blocking問題は発生しません。
しかし、TCPと違い、3wayハンドシェイクによる応答の確認やパケットロス時の再送処理等を行わない通信方法のため、信頼性が低いことが問題となります。
(TCPは確実に届くけど時間がかかる宅配便で、UDPは玄関の前に置き配していくけどたまに誤配や紛失があるようなものだとイメージすると理解しやすいかと思います)

この信頼性の低さを補うための機能が独自に実装されたものが、QUICとなります。

QUICでは、暗号化通信を必須とし、TLSハンドシェイクを行います。
また、TLS1.3を使用することで、TLS1.2よりも通信が1往復少なく、より効率化されています。
パケットロス時の処理や輻輳制御も独自に実装され、効率よく信頼性の高い通信を行うことができるのが特徴です。

HTTP/3

ここまで長くなりましたが、QUICを使用してWeb通信を行うためのアプリケーション層のプロトコルが、HTTP/3になります!

QUICを使用することにより、Head-of-Line-Blocking問題を解消し、より高速なWeb通信を実現するのがHTTP/3です。

QUICは今年5月にIETFで標準化されましたが、HTTP/3についてはまだDraftの段階で、QUIC Working Groupで議論が進められています。
ですが、Google等ではすでにHTTP/3が段階的に採用されています。

Chromeの最新バージョンの開発者ツールでネットワークタブを開くと、プロトコルの項目に「h3」と記載されるものがHTTP/3を使った通信となっています。
YouTube等を開いて確認してみると、意外と身近なところでHTTP/3が使われていることを実感できると思います。
スクリーンショット 2021-12-16 12.08.12.png

HTTP/3の普及は徐々に広がっており、W3Techsの調査によると2021/12/16現在ではおよそ**23.9%**のWebサイトがHTTP/3に対応しているようです。

スクリーンショット 2021-12-16 12.17.23.png
引用: HTTP/2 vs. HTTP/3 usage statistics, December 2021

CloudflareFastly等のCDNでも、HTTP/3に対応しています。
Cloudflareでは、「ネットワーク」の設定画面で有効にするだけでクライアントからエッジまでの接続を簡単にHTTP/3化することができます。
スクリーンショット 2021-12-16 11.33.21.png

CloudflareのQUICの実装については、OSSとして公開されています。(Rustで実装されています!)
curlやNginxで動かしてみることができるので、ぜひ試してみてください。

まとめ

QUICとHTTP/3について、長くなりましたができるだけ掻い摘んで解説してみました。
通信の効率化において様々な工夫がされており、Webの高速化が期待できます。
HTTP/3についてはまだDraftですが、標準化されればより一層普及が進んでいくと思うので、取り残されないように今後も最新情報を追っていきたいと思います。

最後までお読みいただき、ありがとうございました :santa: :christmas_tree: :stars:

参考文献など

40
15
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
40
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?