2019年09月30日 08時00分ネットサービス

ウェブを支えるHTTP通信はどのように進化しているのか

HTTPはハイパーテキスト・トランスファー・プロトコルの略称で、ウェブサイトを閲覧する際のサーバーとの通信にて使用されています。CloudflareがHTTPの新バージョン「HTTP/3」に対応するにあたり、これまでのHTTP通信の問題点がHTTP/3でどのように解決されているのかをブログにまとめています。

HTTP/3: the past, the present, and the future
https://blog.cloudflare.com/http3-the-past-present-and-future/

1990年末に世界初のウェブページが登場し、その翌年の1991年にHTTPの初めての仕様書が書かれました。これはHTTP/0.9と呼ばれており、単にサーバーから特定のドキュメントをダウンロードするだけの簡易なものとなっていました。

1996年にはアップロードに対応するなど大きく機能をアップデートしたHTTP/1.0が策定され、これが今日のHTTP通信の原型となっています。このHTTP/1.0では、全てのリクエストにおいてそれぞれ新しいTCP接続を作成する仕様になっていたため、ハンドシェイクによる遅延が問題になりました。下図はTLSとTCPを用いたHTTP通信の様子ですが、最下部のHTTP通信を行う前にTCPとTLSのハンドシェイクを行う必要があることがわかります。

この問題を解決するため、HTTP/1.0の半年後には修正を加えたHTTP/1.1が策定されています。このHTTP/1.1では「キープアライブ」が導入され、複数のリクエストを一つの接続で処理できるようになりました。HTTP/1.1は非常に長い間ウェブの通信を支えてきており、2015年に次のバージョンであるHTTP/2が正式に仕様となりましたが、HTTP/2が策定された後でもHTTP/1.1で通信をしているサイトは少なくありません。

HTTP/1.1はその登場以降、約20年以上利用されてきているわけですが、その間にウェブサイトも大きく進化しており、画像、JavaScript、CSSなどそれぞれのサイトを表示するのに必要なリソースもHTTP/1.1の登場当時と比較すると大幅に増加しました。そのため、ブラウザがウェブサイトを素早く表示するためにより多くの接続を同時に行う必要が出てきましたが、HTTP/1.1では一度に行えるリクエストは一つのみ。複数のリクエストを行いたい場合は前のリクエストが完了するのを順番待ちする必要があるという制限があったため、同時接続を行うためには複数のHTTP/1.1接続を行うほかありませんでした。HTTP/1.1はキープアライブの導入により、1回の接続で複数のリソースをダウンロードできるのが特徴でしたが、複数のHTTP/1.1接続を行うというのはそれぞれの接続においてハンドシェイクを行うということであり、元のHTTP/1.0の状態に戻ってしまいました。

2015年にHTTP/2が登場し、一つの接続で複数のリソースを同時にダウンロードすることが可能になりました。

HTTP/2の登場により、一つのTCP接続を効率的に利用することが可能になったわけですが、今度はこの通信がTCP上で行われていることが問題になってきます。TCPはデータ全体を正しい順序で送信するためのプロトコルであり、TCPパケットの一部がネットワーク上で失われると、そのパケットが再送されるまで後続のパケットをブロックしてしまいます。別のリソースへのリクエストを一つのTCP接続にまとめている都合上、何かのリソースへのリクエストでパケットロスが発生した場合、同じTCP接続を利用している別のリソースへのリクエストも中断されてしまいます。

そこでHTTP/3では新たに「QUIC」というプロトコルが開発され、TCPの代わりに用いられることになりました。理論的には、QUICはTCPやUDPに並んでトランスポートプロトコルとして作成するのが収まりが良いのですが、新たなトランスポートプロトコルを普及させるには現在のネットワーク機器を全て一新するほどの労力や時間がかかってしまうため、QUICはUDPを利用して実装されています。

QUICは複数のリクエストをブロックさせずに流せるだけでなく、通信開始時のハンドシェイクも短縮されています。これまではTCPとTLSのハンドシェイクを別個に行っていましたが、QUICを利用すると接続の認証と暗号化をまとめて行うことができ、サーバーとの通信回数を減らすことができます。