こんにちは!ネットワークやWebの仕組みに触れ始めたばかりの皆さん、日々のインフラ学習お疲れ様です。「WebブラウザにURLを入力してから画面が表示されるまで」の裏側では、目にも止まらない速さで膨大なデータが行き交っていますよね。
今回は、現代のWebを支える超重要技術、「HTTP/2」の心臓部である「バイナリフレーミング層」と「ストリーム多重化」について、一緒に紐解いていきましょう!
「なんだか難しそうな英語が並んでいるな…」と感じた方も大丈夫です。一歩ずつ、身近な例えを交えながら優しく解説していきますので、ぜひ最後までリラックスして読んでいってくださいね。
—
1. 昔の仕組み(HTTP/1.1)にあった「大渋滞」の問題
まずは、HTTP/2が登場する前(HTTP/1.1の時代)のWebの世界を覗いてみましょう。
皆さんがお気に入りのニュースサイトやショッピングサイトを開いたとき、ブラウザは文字(HTML)だけでなく、たくさんの画像やアイコン、デザインファイル(CSS)、プログラム(JavaScript)などを同時にサーバーからダウンロードしています。
HTTP/1.1の仕組みを、「1通ずつしか手紙を送れない郵便配達員」に例えてみましょう。
1. 配達員は、サーバー(郵便局)へ行って「このページのHTMLをください」と頼みます。
2. サーバーからHTMLを受け取って、ユーザーの元へ届けます。
3. HTMLを読んだブラウザが「あ、画像Aも必要だ!」と気づくので、配達員はもう一度サーバーへ走ります。
4. 画像Aを届けて…次は画像Bを取りに行って…と、1つの荷物(TCP接続)につき、1往復しかできませんでした。
これを解決するためにブラウザは「じゃあ配達員を6人同時に走らせよう!」と工夫(ドメインの分割や並列接続)しましたが、それでも大勢のファイルが押し寄せると、郵便局の前で大渋滞が起きてしまいました。これが、ネットワーク用語でいう「ヘッド・オブ・ライン・ブロッキング(Head-of-Line Blocking:行頭ブロック)」という現象です。先頭の大きな荷物がつかえせば、後ろの小さな荷物がすべて待たされてしまう、もどかしい構造でした。
—
2. HTTP/2の救世主:「バイナリフレーミング層」と「ストリーム多重化」
このもどかしい渋滞を根本から解決したのが、HTTP/2の主役である「バイナリフレーミング層」と「ストリーム多重化」です。
一歩ずつ、その仕組みを分解して理解していきましょう!
バイナリ(0と1の世界)で荷物を小さくパッキングする
HTTP/1.1の頃は、人間が読むことができる文字(テキスト形式)で「GET /index.html HTTP/1.1」のようにやり取りしていました。これは分かりやすい反面、コンピューターにとっては少し「おしゃべりで、かさばる」通信でした。
HTTP/2では、この通信内容をコンピューターが大好きな「バイナリ(0と1のデータのかたまり)」に変換します。そして、すべてのデータを「フレーム(小包)」という小さなダンボール箱に詰め替えるのです。これが「バイナリフレーミング層」の正体です。
1本の道路で同時に荷物を運ぶ「ストリーム多重化」
バイナリという小さな小包に分解できるようになったことで、魔法のような芸ワザが可能になりました。それが「ストリーム多重化」です。
これを、「1本の太い高速道路を走る、相乗りトラック(単一のTCP接続)」に例えてみましょう。
- 高速道路(TCP接続)は1本だけ作ります。たくさんの道路を作ると準備が大変だからです。
- その1本の道路を、色々な荷物(HTML、画像A、画像B)の小包が、まるでダンスのパス回しのように細切れになりながら、同じトラックに相乗りして同時に走っていきます。
- サーバー側に到着すると、小包に書かれた「これは画像Aの欠片だよ」「こっちはHTMLの欠片だよ」という番号(ストリームID)を見て、きれいにパズルみたいに組み立て直されます。
これにより、大きな画像ファイルの到着を待たずに、小さなテキストファイルが先を越して画面に表示されるようになり、体感速度が劇的に向上しました。これがHTTP/2の真骨頂です!
—
3. 実務で役立つ設定とNginxでの確認方法
「理屈は分かったけれど、実際の現場やサーバーの設定ではどうなっているの?」気になりますよね。
現代のWebサーバー(NginxやApacheなど)では、HTTP/2は標準的、あるいはデフォルトで有効化されています。
ここでは、実務でよく使われるNginxを例に、HTTP/2がどのように有効化され、動いているのかをコードを見てみましょう。
NginxでのHTTP/2有効化設定例
設定ファイル(通常は /etc/nginx/conf.d/default.conf や nginx.conf)の中で、HTTPS(SSL/TLS)を有効にしているブロックに http2 というキーワードを添えるだけです。
server {
listen 443 ssl; # 443番ポートでHTTPSの待ち受けを行います
http2 on; # ここでHTTP/2のバイナリフレーミング層・多重化を有効化します!
server_name example.com;
ssl_certificate /path/to/cert.pem; # SSL証明書のパス
ssl_certificate_key /path/to/key.pem; # 秘密鍵のパス
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
- 実務のワンポイントアドバイス: 古いNginxのバージョン(1.25.0未満)では、
listen 443 ssl http2;という書き方をしていましたが、新しいバージョンでは上記のようにhttp2 on;を独立して書く構文が推奨されています。現場のサーバーをアップデートする際は、バージョンによる違いに少しだけ気をつけましょう!
—
4. 自分のブラウザでHTTP/2の動きをのぞいてみよう
百聞は一見にしかず。あなたのパソコンからも、この「ストリーム多重化」の恩恵を確認することができます。
1. ChromeやEdgeなどのブラウザで適当なWebサイトを開きます。
2. キーボードの F12 キーを押して、「開発者ツール(デベロッパーツール)」を開きます。
3. 「ネットワーク(Network)」タブをクリックします。
4. 画面を再読み込み(F5)し、一覧の上部にあるカラム(NameやStatusなどが並んでいるバー)の上で右クリックします。
5. メニューの中から「Protocol(プロトコル)」にチェックを入れて表示させます。
すると、読み込まれたファイルたちの並びに h2(これがHTTP/2の略です!)という文字が並んでいるのが見えます。1つのドメイン(同じサーバー)に対して、ずらっと h2 の通信が並び、1本の接続上でどれだけ多くのリクエストが同時並行(多重化)で処理されているかが一目でわかりますよ。
—
まとめ
今回は、HTTP/2のバイナリフレーミング層とストリーム多重化の仕組みについて解説しました。
- バイナリフレーミング層: データを「0と1の小包(フレーム)」に効率よくパッキングする仕組み。
- ストリーム多重化: たった1本のTCP接続(高速道路)の上で、複数のデータを細切れにして同時に並行やり取りする技術。
- ヘッド・オブ・ライン・ブロッキングの解消: 渋滞の原因を取り除き、Webの表示速度を劇的に高速化させた。
インフラやネットワークの世界は一見すると呪文のような用語が多くて圧倒されがちですが、身近な「郵便配達」や「高速道路」に置き換えてみると、エンジニアたちがどんな課題を解決したかったのかがクリアに見えてきますよね。
ぜひ今日の帰り道や作業の合間に、ブラウザの開発者ツールを開いて h2 の世界を覗いてみてください。パケットたちが元気に駆け回る姿が目に浮かぶはずです。それでは、また次回の技術解説でお会いしましょう!
コメント