先日 Deno のv1.9がリリースされ、HTTP/2 に対応したサーバを立てられるようになった。
この記事では Deno で実際にサーバを立てながら、HTTP/2 の特徴を見ていく。
動作確認は以下の環境で行った。
- Deno
1.9.0 - Google Chrome
90.0.4430.72 - curl
7.54.0
TLS の利用が必須
Deno で HTTP/2 対応のサーバを立てるためには、TLS の利用が必須である。
これは Deno に特有のことではなく、現在の主要なブラウザは全て、TLS 上でのみ HTTP/2 を利用できるようになっている。
仕様上では TLS を使わなくても HTTP/2 を利用できることになっているが、実務においては TLS の利用が前提になっていると考えていいと思う。
そのため、ローカル環境で HTTP/2 を利用したい場合はまず、TLS の準備をする必要がある。
その手順については以前ブログにまとめており、今回もこの方法で準備した。localhost.numb86.netというドメインで TLS を使える状態になっている。
ALPN によるプロトコルのネゴシエーション
HTTP/2 で通信を行うには、サーバとクライアントの両方が HTTP/2 に対応している必要がある。
主要なブラウザは全て対応しているので、あとはサーバさえ対応していれば HTTP/2 での通信が行える。
サーバが HTTP/2 に対応しているのかの確認は、ALPN という方式で行われる。
HTTP 通信を行う際には、まず TCP のハンドシェイクが行われる。
そしてその後 TLS のハンドシェイクを行い、それが終わってから HTTP メッセージの送信が始まる。
ALPN では、TLS ハンドシェイクの際に、使用可能なプロトコルのリストをクライアントが渡す。そしてサーバはその中から、どのプロトコルを使って通信を行うのかを決め、クライアントに渡す。
このようにして、どのプロトコルで通信をするのかが決まるのである。
クライアントが渡すリストのなかに HTTP/2 が入っており、サーバがそれを選べば、HTTP/2 での通信が始まる。
ALPN で選択できるプロトコル一覧は、以下で確認できる。
Transport Layer Security (TLS) Extensions
Deno で指定できるのは、今のところhttp/1.1とh2のようだ。
指定がなかった場合は HTTP/1.1 が採用される。
Deno 1.9 Release Notes | Deno Blog
実際にサーバを立てて、確認してみる。
server.tsという名前で以下のコードを書き、$ deno run --unstable --allow-net --allow-read server.tsで実行する。
const listener = Deno.listenTls({ port: 8443, certFile: "./cert.pem", keyFile: "./privkey.pem", alpnProtocols: ["h2", "http/1.1"], }); for await (const conn of listener) { handleConn(conn); } async function handleConn(conn: Deno.Conn) { const httpConn = Deno.serveHttp(conn); for await (const { respondWith } of httpConn) { respondWith(new Response("Hello!\n")); } }
こうするとhttps://localhost.numb86.net:8443/で HTTP/2 に対応したサーバにアクセスできるはずなので、curl で確認してみる。
$ curl https://localhost.numb86.net:8443/ Hello! $ curl -I https://localhost.numb86.net:8443/ HTTP/2 200 date: Fri, 16 Apr 2021 23:22:33 GMT content-length: 7
HTTP/2 を使った通信になっているのが分かる。
-vフラグをつけると、ALPN の情報も得られる。
$ curl -v https://localhost.numb86.net:8443/ * ALPN, offering h2 * ALPN, offering http/1.1 * ALPN, server accepted to use h2 < HTTP/2 200
クライアントがh2とhttp/1.1を提示して、サーバがh2を使うことにしているのが分かる。
コードのalpnProtocolsの部分を書き換えて、alpnProtocols: ["http/1.1", "h2"],にしてみる。
* ALPN, offering h2 * ALPN, offering http/1.1 * ALPN, server accepted to use http/1.1 < HTTP/1.1 200 OK
そうすると、http/1.1が選ばれる。
alpnProtocolsの行をコメントアウトすると、ネゴシエーションが上手くいかない。
やり取りは HTTP/1.1 で行うことになる。
* ALPN, offering h2 * ALPN, offering http/1.1 * ALPN, server did not agree to a protocol < HTTP/1.1 200 OK
フレーム
HTTP/2 になっても、HTTP のシンタックスは変わらない。HTTP の利用者は違いを意識しなくても利用できる。
だがその中身は大幅に変わっており、HTTP/1.1 とは全くの別物になっている。
HTTP/2 の最大の特徴は、データをバイナリ形式にエンコーディングして送受信するということ。HTTP/1.1 ではプレーンテキストでデータを送受信していた。
Deno で TCP サーバを書いて、確認してみる。
const listener = Deno.listenTls({ port: 8443, certFile: "./cert.pem", keyFile: "./privkey.pem", }); for await (const conn of listener) { const buffer = new Uint8Array(128); await conn.read(buffer); const decode = new TextDecoder().decode(buffer); console.log(decode); // 受け取ったデータを表示する conn.write(buffer); conn.closeWrite(); }
alpnProtocolsを設定していないので、HTTP/1.1 でやり取りが行われる。
この状態で$ curl https://localhost.numb86.net:8443/を実行してリクエストを送ると、以下のログが流れる。
GET / HTTP/1.1 Host: localhost.numb86.net:8443 User-Agent: curl/7.54.0 Accept: */*
次にalpnProtocolsを設定して HTTP/2 を利用するようにして、同様の確認を行う。
すると、流れるログは以下のようになる。
PRI * HTTP/2.0 SM d?�&���A���� ^�i������M3z�%�P��S*/*
HTTP/1.1 はテキスト、HTTP/2 はバイナリで、やり取りを行っている。
そして HTTP/2 は、HTTP メッセージをバイナリ形式に変換するだけでなく、小さく分割してから送信している。
このひとつひとつの小さなバイナリデータを、フレームと呼ぶ。
HTTP/2 に対応しているクライアントやサーバは、HTTP メッセージをフレームへと分解してから送信し、それを受け取った側はフレームを組み立て HTTP メッセージを再構成していることになる。
なぜこんな面倒なことをしているのかというと、これによって、ひとつの TCP 接続のなかに複数の HTTP メッセージを混在させることができるからである。フレームという単位でやり取りが行われるため、ひとつの HTTP メッセージが TCP 接続を専有してしまうということがなくなった。
ストリーム
ひとつの TCP 接続のなかに複数の HTTP メッセージを混在させることができるということは、複数の HTTP メッセージを並列的に処理できるということである。
この概念を、ストリームという。ストリームは概念であり、実体はない。TCP 接続のなかにあるひとつひとつの HTTP メッセージをストリームと読んでいるに過ぎない。
各フレームは、自分がどのストリームに所属するのかを示す情報を持っている。そのため、フレームを受け取ったクライアントやサーバが、ストリーム毎にフレームを組み立てて、HTTP メッセージを復元することができる。
この仕組みによって、ひとつの TCP 接続のなかで、あたかも複数の TCP 接続が生まれているかのような状況になる。
実際 HTTP/2 は、ストリーム単位でのフロー制御を行っている。これはまさに TCP におけるフロー制御と同じメカニズムである。
フロー制御とは、一度に送信するデータの量について送信側と受信側で調整を行っていくプロセスで、輻輳制御などのために行われる。
つまり HTTP/2 の通信では、ストリームと TCP の 2 つのレベルでフロー制御していることになる。
HTTP/2 におけるフロー制御については、以下の記事が分かりやすかった。
パフォーマンスの向上
ストリームによって、パフォーマンスの向上が期待できる。
具体的に言うと、同一オリジンに対してはひとつの TCP 接続しか発生しないので、オーバーヘッドを削減できる可能性がある。
HTTP/1.1 では同一オリジンへのアクセスでも複数の TCP 接続が発生する可能性があり、その場合はその度に TCP ハンドシェイクが行われる。TLS 通信なら、さらに TLS のハンドシェイクも行われる。
HTTP/2 なら、これらのハンドシェイクはオリジン毎に一度で済む。
実際にサーバを書いて確認してみる。
まずはalpnProtocolsをコメントアウトして、HTTP/1.1 での挙動を調べる。
const ORIGIN = "https://localhost.numb86.net:8443"; const html = ` <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>HTTP/2</title> </head> <body> <img src="/deno1.jpeg" width="200"> <img src="/deno2.jpeg" width="200"> <img src="/deno3.jpeg" width="200"> <img src="/deno4.jpeg" width="200"> <img src="/deno5.jpeg" width="200"> <img src="/deno6.jpeg" width="200"> <br> <img src="/deno7.jpeg" importance="low" width="200"> <img src="/deno8.jpeg" importance="low" width="200"> <img src="/deno9.jpeg" importance="low" width="200"> </body> </html> `; const listener = Deno.listenTls({ port: 8443, certFile: "./cert.pem", keyFile: "./privkey.pem", // alpnProtocols: ["h2", "http/1.1"], }); for await (const conn of listener) { console.log(conn.rid, conn.remoteAddr); // このログを結果を調べる handleConn(conn); } function getPath(url: string): string { return url.slice(ORIGIN.length); } async function handleConn(conn: Deno.Conn) { const httpConn = Deno.serveHttp(conn); for await (const { request, respondWith } of httpConn) { const path = request.url.indexOf("http") === 0 ? getPath(request.url) : request.url; switch (true) { case /^\/$/.test(path): { respondWith( new Response(html, { status: 200, headers: { "Content-Type": "text/html" }, }) ); break; } case /\.jpeg$/.test(path): { const number = Number(path.slice(5, -5)); const resource = number <= 6 ? "./deno1.jpeg" : "./deno2.jpeg"; const data = await Deno.readFile(resource); respondWith( new Response(data, { status: 200, headers: { "Content-Type": "image/jpeg" }, }) ); break; } default: { respondWith( new Response("Not Found\n", { status: 404, headers: { "Content-Type": "text/plain" }, }) ); break; } } } }
deno1.jpegとdeno2.jpegという名前で適当な画像を用意した上で、ブラウザでhttps://localhost.numb86.net:8443/にアクセスする。
そうすると以下のログが流れ、複数の TCP 接続が行われていることが分かる。
4 { transport: "tcp", hostname: "127.0.0.1", port: 62489 }
9 { transport: "tcp", hostname: "127.0.0.1", port: 62494 }
13 { transport: "tcp", hostname: "127.0.0.1", port: 62495 }
17 { transport: "tcp", hostname: "127.0.0.1", port: 62496 }
19 { transport: "tcp", hostname: "127.0.0.1", port: 62497 }
25 { transport: "tcp", hostname: "127.0.0.1", port: 62498 }
次にalpnProtocolsをアンコメントして、HTTP/2 で通信を行ってみる。
すると今度は、TCP 接続はひとつしか存在しない。
4 { transport: "tcp", hostname: "127.0.0.1", port: 63630 }
さらに、HTTP メッセージを並列的に処理できるという特徴により、「処理の重いレスポンスのせいで後続のリクエストをいつまでも送信できない」という問題を回避できるようになる。
HTTP/1.1 ではひとつの TCP で同時にやり取りできるのは、ひとつの HTTP メッセージだけである。
そのため、ひとつのオリジンに対してひとつの TCP 接続しか行えないとすると、同一オリジンから複数のリソースを取得したい場合に相当な時間がかかることになる。ひとつひとつ逐次処理していくことになる。
そのためブラウザは、ひとつのオリジンに対して複数の TCP 接続を行うことで、並列的なやり取りを可能にしている。
しかし TCP 接続を増やし続けることには、コストがある。サーバとクライアント、それからネットワーク経路上の中間機器のCPU やメモリを、消費することになる。
しかも先程も書いたように、TCP 接続を増やせば増やすほどオーバーヘッドが増える。
そのため主要なブラウザは、TCP の同時接続数を 6 つまでに制限している。
これは、7 つ以上のリソースを同一オリジンから同時に取得する場合、後続のリソースの取得については待機状態が発生することを意味する。
HTTP/2 ではひとつの TCP 接続のなかでほぼ無制限に並列的に処理できるので、待機状態は発生しない。
先程のコードでこのことを確認できる。
今度はサーバのログではなく、ブラウザの挙動を確認する。
なお、素材は以下のページのものを使っている。
Artwork | Deno
まずは HTTP/1.1。
同時に 6 つの画像までしか、ダウンロードできない。
続いて HTTP/2。
全ての画像を並列してダウンロードできていることが分かる。
現代のウェブページやウェブアプリケーションは、画像やスクリプトファイルなど、多数のリソースによって構成されている。
巨大なひとつのリソースをダウンロードするのではなく、それほど大きくはないリソースを多数ダウンロードする、という傾向が強い。
そのため、余計なハンドシェイクを減らし、複数のリソースを並列的にダウンロードできる HTTP/2 を利用することで、パフォーマンスを大きく改善できる可能性がある。
ストリームの優先順位
全てのストリームを平等に並列処理するのではなく、特定のストリームを優先的に処理して速くレスポンスを返して欲しいケースもある。
例えばスタイルシートや JavaScript ファイルはブラウザの描画処理に影響を与えるので、早めに取得しておきたい。逆に、後回しにしても影響が少ないリソースもあるかもしれない。
HTTP/2 には、各ストリームに優先度を設定するため仕組みが用意されている。
これを使うことで、優先的にレスポンスを返して欲しいストリームを、サーバに伝えることができる。
優先順位の設定については以下の記事が分かりやすかった。
HTTP/2 が提供しているのは優先順位を伝えるための仕組みだけで、優先順位を決定するロジック等は定義されていない。
どのように優先順位を決めるのかは、実装によって異なる。
実際には、ブラウザが自動的に決めることになる。<img src="img/1.png" importance="high">のようにアプリケーションの開発者が指定できるようなのだが、それも参考にしつつ、最終的にはブラウザが決定する。
そしてサーバも、その優先順位に必ず従わなければならないわけではない。そのため、目安くらいに考えておいたほうがよいのかもしれない。
ドメインシャーディングはアンチパターンになる
前述の通り、HTTP/1.1 ではひとつのオリジンに対して 6 つしか TCP を同時接続できない。
この制限に対処するために、様々な工夫が用いられてきた。
例えば、CSS スプライトなどを使って複数のリソースをひとつのファイルにまとめることで、HTTP リクエストの数を減らすことができる。
他にも、ドメインシャーディングというテクニックが使われていた。
これは、意図的に複数のドメインからリソースを配信することで、TCP の接続数の制限を回避する手法。
ドメインが異なるということはオリジンが異なるということなので、6 つ以上の同時接続を実現できる。
例えばexample.comとsub.example.comの 2 つのドメインからリソースを配信することで、合計で 12 個まで TCP を同時接続できるようになる。
だがこのドメインシャーディングは、HTTP/2 を利用できる環境においては不要になる。
既述したように、HTTP/2 ではひとつの TCP 接続のなかで並列的に HTTP メッセージを送受信できる。 わざわざドメインを分けて配信する必要はない。
むしろドメインを分けることで、せっかくひとつの TCP 接続で済んでいたものが、example.comとsub.example.comのふたつの TCP 接続に増えてしまう。
こうするとオーバーヘッドが増えてしまう。手間を掛けて HTTP/2 のメリットを捨てていることになる。
このように、HTTP/2 の恩恵を最大限に引き出すためには、HTTP/2 の仕組みや原理をしっかり理解しておく必要がある。
そうしないと、間違ったテクニックや効果のないテクニックを使い続けることになってしまう。
これはどのような技術やプロトコルにも言える。利便性の高いインターフェイスのおかげで簡単に使えるとしても、互換性のおかげで違いを意識しないで済んだとしても、その中身や背景について詳しく理解していればしているほど、性能を引き出せるようになる。
HTTP ヘッダの圧縮
ウェブの用途が広がり、HTTP が高機能になるにつれ、HTTP ヘッダは肥大化していった。特に Cookie などの情報を持っている場合、サイズはかなり大きくなる。
しかも HTTP はステートレスな通信なので、ヘッダは毎回送信される。
このため、大きなオーバーヘッドが発生しやすい。
HTTP/2 ではHPACKという形式で HTTP ヘッダを圧縮することで、このオーバーヘッドの削減を図っている。
