脱 TCP ！ HTTP/3 時代の到来｜研修コースに参加してみた
今回参加したコースは 脱 TCP ！ HTTP/3 時代の到来です。
インターネットで毎日使っている HTTP の最新版 HTTP/3 が 2022 年 6 月に正式に勧告されました。
コースタイトルにある TCP は新人研修で何度も勉強したものですね。
「 TCP は UDP に比べて遅いが信頼できる、 UDP は TCP に比べて速いが信頼しにくい」
「こういう特徴になる理由は TCP が 3 ウェイ・ハンドシェイクを使っているから」
この “常識” が HTTP/3 では変わります。 なぜ、変える必要があったのか、このコースで丁寧に解説いただきました。
では、どのような内容だったのか、レポートします！
もくじ
コース情報
| 想定している受講者 |
|
|---|---|
| 受講目標 |
|
講師紹介
このコースで登壇されたのはインフラ系ではお馴染みの 新谷 泰英さん です。
どうすれば技術を身につけられるか、理解できるか、研究しつづけるインフラ系の人気トレーナー
HTTP/3 登場の背景
HTTP/1.1 の課題
HTTP/2 や HTTP/3 が登場した理由は、それまでの HTTP/1.1 に大きな課題があったからです。
まずは、遅いことです。
- Web コンテンツの発展・拡充
- 元は一つの HTML ファイルに書かれた文字が中心
- 今では、たくさんの画像、音、映像、動的コンテンツなどがある
- それにより相対的に通信速度が低下している
- 通信速度は増えているが、それ以上にデータ量が増えている
そういえば、昔ながらの構成になっている俳優の阿部 寛さんのホームページは軽量ですぐ開くことで有名ですね。
- HTTP/1.1 は 1997 年から十数年にわたって使われてきた
- 遅いのはわかっても、基幹技術すぎて変えられない
- Google が HTTP の新しい技術として SPDY を提唱
- SPDY が正式採用されたのが HTTP/2 （ 2015 年）
ただし、 HTTP の部分を新しくしても、 TCP の遅さが残りました。
- セッション確立には 3 ウェイ・ハンドシェイクが必要
- 1 ページの中に入っているファイルの数だけセッション確立が必要
- 3 パケット × 200 ファイル = 600 パケット
- 電話でたとえると、一言ずつ話してはかけ直すようなもの
- 1 ページの中に入っているファイルの数だけセッション確立が必要
- TCP では輻輳制御のためにスロースタート方式を採用している
- 最初は速度が遅く、段階的に速度を向上させる（ウィンドウサイズを拡大する）
- 回線速度を上げても、初速は上がらない
- ほかで工夫しても根本的にスピードが上がらない
- 接続するたびに上記 2 つが行われるため、セッションが切れると速度低下が避けられない
たしかに 1 ページが 100 以上のファイルから成っていれば、セッションを確立する時間がばかにならないですね。
また、 HTTP の課題として、安全ではないこともあります。
- 暗号通信が必須ではない
- SSL/TLS による HTTPS の普及率も長らく上がらなかった
- HTTPS は、暗号化技術によって安全な通信が可能だが、速度低下と、処理負担が発生する（後述）
- 暗号化と復号のために電子証明書が必要
- お金がかかる
HTTP/2 の登場と課題
続いて登場したのが HTTP/2 です。 これはまだまだ使用されていますね。
- HTTP 1.1 の遅さを緩和
- 単一の TCP セッションによる通信
- 一つの TCP セッションで複数の ストリームという論理的な接続（リクエストとレスポンスに相当）を使う
- セッション確立やスロースタートによる速度低下を回避
- 多重化ストリームとリクエストの優先度管理
- 複数のリクエストを同時に行うパイプライン処理と、そのリクエストの優先度管理が可能
- HTTP ヘッダの圧縮
- リクエストとレスポンスのヘッダを圧縮して通信データ量を削減
- サーバからのプッシュ通信機能
- バイナリヘッダ
- バイナリ形式に変更して処理を効率化
- 単一の TCP セッションによる通信
- HTTP/2 の課題
- 接続時や再接続時のオーバーヘッド
- TCP のコネクション確立など
- HoL（ Head of Line ）ブロッキング
- 先行するパケットにエラーがあると、その再送が完了するまで後続のパケットが送れないため、通信速度が低下する問題
- HTTPS が標準だったが、仕様上は HTTPS が必須ではない
- SSL/TLS は、速度の問題もある
- ネゴシエーションの遅さ
- 1 コネクションごとにネゴシエーションを繰り返すと遅さが積み重なる
- 接続時や再接続時のオーバーヘッド
引き続き、 TCP が遅いという課題が残りました。
HTTP/3 の概要
QUIC
こうした TCP や SSL/TLS の問題から、 TCP を置き換えるものとして Google が提唱したのが QUIC です。 そして HTTP/2 に加えて QUIC を採用したのが HTTP/3 です。 QUIC には TLS も含まれているため、 HTTP/3 では TLS が必須になっています。
SPDY といい QUIC といい、 Google が新しい仕様を作っていますね。 Google はデファクトともいえるさまざまなサービスを運営しているうえ、 Web ブラウザとして Chrome が大きなシェアを持っているので、こういうことができるわけですね。
QUIC の特徴は次のとおりです。
- TCP ではなく UDP上で動作
- TCP は信頼性が高いが複雑、 UDP は単純で高速と言われる
- TCP の信頼性（再送制御など）と UDP の高速性を両立
- 2021 年 5 月に RFC として規格化
QUIC がネゴシエーションをどのように行っているのか調べてみると、 HTTP/2 は TCP と TLS がそれぞれネゴシエーションしていたのを、 QUIC では TLS を内部に入れ、 TLS でネゴシエーションするように変更したのでした（以降は新しいコネクション ID というもので接続を確立）。
HTTP/3 の登場
そこで HTTP/3 が登場します。 HTTP/3 では、 TCP のかわりに QUIC を使うことで HTTP/2 の課題の解決を図っています。
ちなみに、現在 HTTP/3 が使われているのは 25 % 程度だそうです。
HTTP/3 では、 HTTP + TCP の以下のような課題を解決しています。
- HoL ブロッキング問題を解消
- 接続確立や再接続を高速化
- ほとんどの通信を暗号通信で保護
- 多重化による通信処理の並列化
- 通信回線の変更時（ Wi-Fi から 4G など）にも通信を継続
- コネクション ID を用いてセッションを識別する
- 通信中に経路が変化しても通信を継続可能
一方で、デメリットや考慮事項には次のようなものがあります。
- サーバとクライアントの両方で CPU の負荷が上がる
- TLS のためにサーバ証明書などが必要
- ファイアウォールや IDS/IPS などのセキュリティの再構築が必要
- なお、 HTTP/3 では UDP/443 を使う
- 常に高速化されるとは限らない
なお、 HTTP/3 で速くなりやすいところと、それほどでもないところとがあります。
- SNS などには向いている
- 単純なコンテンツはあまり変わらない
- ほぼ文字、画像が少ない、など
阿部 寛さんのホームページは HTTP/3 になっても引き続き、めっちゃ高速という訳ですね。
まとめ
このコースでは HTTP/3 の登場背景と特徴を、メリットデメリット含めて解説いただきました。 新人研修や基本情報技術者試験などで定番で覚えてきた TCP の「 3 ウェイ・ハンドシェイク」がいよいよ変わります。 ちなみに、これもよく出てくる用語 TCP/IP も UDP/QUIC/IP のように変わるのでしょうか … ？
それはさておき HTTP/3 の対応にあたっては HTML ページなどのコンテンツについては対応が必要ないものの、プロトコルが変わってしまうので、ネットワークやセキュリティは対応作業が必要ですし、設定内容も学ぶ必要があります。
また Web サーバについても代表的な Apache と nginx の 2 つを軽く調べたところ、まだ HTTP/3 には完全に対応できていませんでした。
Apache の対応 64462 – [Feature Request] Support for HTTP/3
nginx の対応 Introducing a Technology Preview of NGINX Support for QUIC and HTTP/3 – NGINX
こういった移行・対応作業が見えてきたところで、また具体的な変更ポイントを学びたいところですね。 まずはそれまでにこのコースで事前知識を仕入れましょう！
label SEカレッジを詳しく知りたいという方はこちらから !!
IT専門の定額制研修 月額28,000円 ～/ 1社 で IT研修 制度を導入できます。
年間 670 コースをほぼ毎日開催中!!
SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。