HTTP/2の正体を探るため、実際にどのようなやり取りをしているのかを確認しながら、その特徴を解説していこう。具体的には図3のようなテスト環境を用意し、Wireshark▼を使ってパケットをキャプチャーした。
複数の接続が独立して動作
実際にパケットをキャプチャーした結果を見ると、一見HTTP/1.1のほうが明らかに冒頭にリクエストが集中し、レスポンスがその後に立て続けに発生しているように見える(図4(a))。実はHTTP/1.1では、それぞれのリクエスト-レスポンスの独立性が高いため、複数ポートを使って並行してリクエストを発行できる。このため、今回用意したような小さなサイトでは、リクエストが最初に一気に送られてしまうのだ。
これを確認するため、TCPのセッションを遡って、3ウエイハンドシェーク▼のやり取りをチェックした(同(b))。SYNフラグが有効なパケットは、都合12個ある。6個のファイルに対してそれぞれTCPのコネクションを張って、独立してリクエストしているとわかる。Webサイトを構成するコンテンツの各要素の間に依存性があまりないことから、こうした転送が可能になっている。
逆にHTTP/2の場合を見ると、複雑な処理をいろいろしている(図5(a))。ただよく見ると、いかにもリクエストの情報が入っていそうな「HEADERS」という情報が付与されたパケットが最初の方に集中して、いかにもデータを送っていそうな「DATA」という属性のパケットが後半に集中している。
一般にHTTP/2はTLS/SSL▼を使ってコネクションを形成する。これをHTTP/2のRFC▼では「h2」と呼ぶ。しかし規格上は▼平文でのアクセスも認めていて、「h2c」という名称が与えられている。
TLS/SSLを使う場合は、その経路を利用して通信するので、TCPのコネクションが一つになるのは想像しやすい。そこでここでは、平文でアクセスした際もTCPのコネクションを一つしか使っていないことを確認した(同(b))。3ウエイハンドシェークの最初の二つのやり取りだけがパケットとしては絞り込まれており、コネクションは1本しかないことがわかる。
パソコンやMacなどで動作するフリーのパケットキャプチャーソフト。入手先はhttps://www.wireshark.org/。
TCPでコネクションを確立するときの処理。最初にコネクション開始を要求する側が「SYN」パケットを送信。要求を受ける側が了解する場合は「SYN+ACK」を返信する。これに要求する側が「ACK」を返すと、コネクションが確立される。
Transport Layer Security/Secure Sockets Layerの略。
Request For Commentsの略。IETFが発行する文書はすべてRFCと呼ばれ、番号で管理されている。
FirefoxやChromeなど一般的に使うWebブラウザーは、TLS/SSLを利用したアクセス方法しか用意していない。今回はHTTP/2を実装したサーバー「nghttp2」に付属するユーティリティである「nghttp」を使ってアクセスした。