Webサイトの表示速度をさらに高速化!「HTTP/3」とは? | SSLサーバー証明書ならさくらインターネット

Webサイトの表示速度をさらに高速化!「HTTP/3」とは?

2015年にHTTP/2がリリースされ、現在では幅広く利用されていますが、2020年からはHTTP/3のブラウザ実装が進んで徐々に普及することが予想されます。今回は「HTTP/3」についてご紹介します。

Webサイトの表示速度をさらに高速化!「HTTP/3」とは?

そもそもHTTP/2やHTTP/3とは何か?

HTTP/2やHTTP/3とは、例えばあなたが今利用しているパソコンと、本コラムのデータが保存されているサーバーとの通信をやり取りするための「ルール」のようなものです。HTTP/3では、HTTP/2よりも通信効率が上がりWebサイトの表示速度が速くなると言われています。「HTTP/2」について知りたい方は、当コラムの『あなたのサイトを高速化する次世代プロトコル「HTTP/2」とは』をご覧ください。

「SSLコラムなのにどうしてHTTP/3の記事を書いているんだろう?」と思う方もいるかもしれませんが、「HTTP/3」はSSL/TLSの利用が前提となっているため、SSLサーバー証明書(以下、SSL証明書)とは切っても切れない関係なのです。さて、本題に戻りますが「本当にWebサイトの表示が速くなるの?」「どうして速くなるの?」「対応を検討した方がいい?」など、色々な疑問を解消しながら解説していきましょう。

なぜ通信速度が速くなるのか?

通信に利用する「ルール」が違う

HTTP/3がHTTP/2と比較して決定的に違うのは、TCPを使うHTTP/2と異なり、HTTP/3はUDPを使って通信を行う点です。TCPとUDP、どちらも通信の「ルール」ですが、HTTP/*よりも下位にあるルールであり、簡単に言うと「データの運び方」に関するルールをまとめたものです。

TCPはルールが厳格で信頼性が高く、UDPはより柔軟に仕様を決められるようになっているため、効率を重視した通信が可能になっています。HTTP/3は絶対的な速度向上というより、速度を上げるための工夫を行い、通信をより効率化した「新しいルール」と言えます。

通信を開始するための手続きを効率化

HTTP/2で使われていたTCPは、クライアントとサーバーが通信のやり取りする際に、「3wayハンドシェイク」という挨拶のようなやり取りがありました。Webサイトのデータ取得を開始するまでに3往復のやり取りが必要で、さらにSSL通信を行う場合は「3wayハンドシェイク」の後に「TLSハンドシェイク」という鍵交換のやり取りが続き、それが終わってから実際のデータの通信が始まりました。「TLSハンドシェイク」について詳しくは当コラムの『SSLって何?意味や仕組みをわかりやすく解説! 』をご覧ください。

これらに掛かる時間は、Chromeのデベロッパーツール上で確認することが出来ます。以下のように、それぞれ「Initial connection」「SSL」と表示されます。

TLSハンドシェイクのイメージ図

わかりやすいように応答に時間の掛かる海外のサーバーにアクセスしたため遅くなっていますが、ご覧の通り本当にとても時間が掛かっています。「DNS Lookup」は初回なので仕方ないとしても、「Initial connection」は接続を”開始するため”だけに(実際に必要なデータが1バイトも流れていないにも関わらず)、702ms(ミリセカンド:1ms=1/1000秒)も掛かっています。この余分な部分をオーバーヘッドと呼びます。もちろん、それぞれキャッシュやセッションがあるため、2回目以降もアクセスする度にこれだけのオーバーヘッドが出るわけではありませんが、それでも無視できない長さです。

「なぜハンドシェイクが通信効率を悪化させるのか?」というと、相手の応答が無ければ次に進めない処理であることに起因します。応答に10ms(0.01秒)掛かるサーバーと1000ms(1秒)掛かるサーバーでは、3往復やり取りするのに前者は30ms、後者は3000ms掛かります。「3wayハンドシェイク」と「TLSハンドシェイク」を行うだけで6秒も掛かってしまうわけですね。

UDPは、TCPと異なり「挨拶なし」でいきなりデータのやり取りを開始することが出来ます。この「挨拶」を交わさないUDPでも信頼性の高いやり取りをできるように実現したのが、2013年からGoogleが開発を続けてきたQUIC(クイック)というルールです。以下のようにHTTP/3は上位のルールで、QUICという下位のルール上に成り立っており、それらはUDP上でやり取りされているとイメージしてください。

  • ※実際にはUDPの下層にIPが存在しますが、今回は説明を割愛します。

QUICのルールのイメージ図

QUICは暗号化通信(SSL証明書の利用)を前提としているため、TLSハンドシェイクが発生します。QUICではTLS1.3が利用されており、TLS1.2と比較してTLSハンドシェイクで発生するやり取りが1往復減っているため、その分効率化されています。また、TLS1.3には0-RTT(Zero Round Trip Time)という方式が追加されているため、セッション再開時にTLSハンドシェイク無しでデータ通信を開始することも可能です。

前述の通り、QUICはGoogleによって開発と実装が進められており、すでにGoogleの一部サービスとChromeブラウザ上で展開されています。Googleの発表した論文によると、Googleの通信の30%がQUICで行われており、Google Searchのレイテンシーをデスクトップで8%、スマートフォンで3%削減したと言われています。

The QUIC Transport Protocol: Design and Internet-Scale Deployment

「ハンドシェイク」の処理を可能な限り効率化する(オーバーヘッドを減らす)ことで通信効率を高めているのがHTTP/3(正確にはHTTP/3とQUIC、そしてQUICに含まれるTLS1.3)と言えます。

データの受け取り方を効率化

HTTP/3の通信効率化のもう1つのポイントとして、データの受け取り方が変わった点があります。インターネットの通信は「パケット」と呼ばれる細切れのファイルでやり取りされています。例えば、1GBのファイルをダウンロードするとき、実際には1000バイトぐらいの細切れファイル(パケット)が何個も送信されており、それらを1つずつ受け取っています。

HTTP/2では、サーバーからの「データの送り方」を効率化して、複数ファイルを同時に送信できるようになりました。このため、大量に画像が並べられている(構成ファイルがとても多い)ページの表示において大きな効果がありました。しかしながら、一部パケットに欠落(パケットロス)があった場合、再送されたパケットが到着するまで後続の処理が止まってしまう、という欠点がありました。

HTTP/3では、この欠点がQUICを利用することで解消され、再送中でも並行して他のパケットを処理できるようになりました。この改善はデータの欠落が多い低品質なネットワーク環境を利用している場合などに効果があると考えられます。

HTTP/3を利用する場合の注意

「HTTP/3はUDPを利用する」という説明を見て気づいた方もいるかもしれませんが、ファイアウォールなどでUDPの443番ポートがブロックされている場合、HTTP/3を利用することができません。一般的にWebサイトの通信はTCPの80番ポート(非SSL)とTCPの443番ポート(SSL)が利用されており、これまではこのポートさえ開いていれば支障はありませんでした。

HTTP/3ではUDPの443番ポートを利用するため、クライアント、サーバーともにUDPの443番ポートを開放する必要があります。企業などでセキュリティのために不要なポートを閉じている場合は注意する必要があります。

またHTTP/3は暗号化通信(SSL証明書の利用)を前提としているため、Webサイトも常時SSL化されている必要があります。レンタルサーバーのHTTP/3対応は、HTTP/2の時と同様にレンタルサーバー会社側で対応してくれますが、サイトの常時SSL化は自身で行う必要があるので注意しましょう。

現在(2020年1月)、HTTP/3が利用できるWebサーバーは、大手のものではLiteSpeedの有料版しかありません。NginxやApacheには対応していないことも注意が必要です。レンタルサーバーにおいても、対応しているホスティング事業者は少ないのが現状です。

  • ※LiteSpeedはHTTP/3より前のバージョンのQUICにも対応しているため、そちらを利用できる場合もあります。

HTTP/3のメリットとは?

「HTTP/3」、そして「QUIC」では、これまで説明したように様々な通信の効率化が行われました。これによって、外部リソースのファイルが大量にあってハンドシェイクを何度も行う必要がある場合や、物理的にサーバーまでの距離が遠くて1回1回のリクエストに時間がかかるような場合、そしてネットワーク品質が低くてデータの欠落が多い場合などでも、より効率的にデータを送り合うことができるため、結果的にWebサイトの表示速度を高速化すると見込まれています。

逆に言うと、外部リソースのファイルが少なく、サーバーのレイテンシーも小さく、高品質なネットワーク環境下であれば、効果が薄くなるとも言えます。実際にGoogleの調査によると、ネットワークのレイテンシーが小さい韓国においては、TCPとQUIC(UDP)の差はあまり見られませんでした。一方、レイテンシーが大きいインドにおいては顕著にQUICの効果が出ていました。

また、QUICの仕様で「クライアントのIPアドレスが変わってもセッションを継続できる」という特長があります。例えば、外出先から帰宅した場合など、モバイルデータ通信からWi-Fi通信に切り替わる際に通信が切れてしまう(IPアドレスが変わって通信が切れてしまう)ことがありますが、HTTP/3ではIPアドレスが変わっても通信を継続できるため、「通信が切れない」というメリットもあります。

ただしHTTP/2が出た時もそうでしたが、過度な期待は禁物です。例えば、PHP5.6で運用していたWordPressサイトをPHP7.3に変更したときのように爆発的(200~400%程度)にWebサイトの表示速度を高速化するようなものではありません。ファイルサイズがちょっと大きめの画像を使っているだけで、HTTP/3で稼いだ時間が無駄になることもありえます。Webサイトの表示速度のチューニングにおいては様々なボトルネックが存在し、その”数あるボトルネック”の1つである「通信効率」の部分を改善するのがHTTP/3と言えるでしょう。

さくらのSSLでは、最も厳格な審査により発行されるEV証明書から、即日発行が可能な格安のDV証明書まで、幅広いラインアップでSSL証明書を取り揃えています。もちろん、全てのSSL証明書がHTTP/3で利用できます※。まだWebサイトの常時SSL化をしていない方は、HTTP/3時代に備えて常時SSL化を検討してみてはいかがでしょうか?

  • ※HTTP/3はSSL証明書の仕様には依存しません。

こちらの記事もあわせておすすめ!

当コラムの文中でもご紹介しましたが、HTTP/2について詳しく知りたい場合は『あなたのサイトを高速化する次世代プロトコル「HTTP/2」とは』をご覧ください。

最終更新日:2020.2.3