【入門編】HTTP/2フロー制御(Flow Control)の仕組み – HTTPプロトコル・通信規格実践ガイド

皆さん、こんにちは！ 最先端のネットワークをひたすら追いかけ、パケットの鼓動を感じながら日々を過ごしているアーキテクトの〇〇です。

今回は、皆さんが普段何気なく使っているWebサイトの裏側で、驚くほど賢く、そして力強く動いている技術「HTTP/2」について、その心臓部とも言える「フロー制御（Flow Control）」の仕組みにスポットを当ててみましょう。

HTTP/2って「速い」ってよく聞きますよね？ でも、ただ速いだけじゃダメなんです。速くても、相手が受け取れないほどの勢いでデータを送りつけたら、どうなると思いますか？ そう、パンクしちゃいますよね。

その「パンク」を防ぐための、HTTP/2のとても優しい気遣いが「フロー制御」なんです。さあ、一歩ずつ理解していきましょう！

—

HTTP/2、速さの裏に隠された「優しさ」：フロー制御とは？

なぜフロー制御が必要なのか？ 現実世界の例えで考えてみよう

皆さんは、誰かに手紙や荷物を送るとき、相手の郵便受けや玄関が荷物で溢れかえっているのに、さらに大量の荷物を送りつけたりしませんよね？ 「きっと今、受け取れないだろうな」とか「これ以上送ったら迷惑かな」って、想像しますよね。

インターネットの世界でも全く同じことが言えます。

あなたがWebサイトを見るとき、ブラウザ（クライアント）とWebサーバーの間で、たくさんのデータが行き交っています。画像、テキスト、動画など、さまざまな情報がパケットという小さな荷物になって、次々と送られてくるんです。

ここで問題になるのが、「送信する側（サーバー）が速すぎて、受信する側（ブラウザ）が処理しきれない」という状況です。

例えば、スーパーハイウェイを猛スピードで走るトラック（サーバー）が、細い山道しか走れない軽自動車（ブラウザ）に大量の荷物を無理やり渡そうとするようなもの。軽自動車はたちまち荷崩れを起こし、動けなくなってしまいますよね。

これがデジタルな世界で起きると、

  • 受信側のメモリが溢れてアプリケーションがクラッシュする
  • 処理が追いつかず、通信が止まってしまう
  • 最悪、サーバーやクライアントがダウンしてしまう

といったトラブルに繋がります。これでは、せっかくHTTP/2が「速い」プロトコルなのに、その真価を発揮できません。

そこで登場するのが、HTTP/2の「フロー制御」という仕組みです。
「相手が受け取れる量だけデータを送る」
このシンプルなルールを守るための、非常に賢いメカニズムなんですよ。

TCPのフロー制御と何が違うの？

「あれ？ TCPにもフロー制御ってあったような…」と思った方もいるかもしれませんね。素晴らしい視点です！

その通り、TCP（Transmission Control Protocol）にもフロー制御の仕組みはあります。TCPは、ネットワークの土台となる層で、通信路全体（コネクション全体）に対して「いまこの通信路はどれくらいのデータを受け入れられるか」を管理しています。

しかし、HTTP/2はTCPの上に乗っかるアプリケーション層のプロトコルです。HTTP/2は一つのTCPコネクションを使い回して、複数のリクエストとレスポンスを同時にやり取りできますよね（これを「マルチプレクシング」と言います）。

そうなんです、TCPのフロー制御だけだと、「この通信路全体で受け取れる量」しか制御できません。でもHTTP/2では、「この通信路の中の、個々のやり取り（ストリーム）ごとに、あとどれくらいデータを受け取れるか」を細かく制御したいんです。

例えるなら、TCPが「この郵便局全体で今日、あと何通手紙を受け取れるか」を管理するのに対し、HTTP/2は「郵便局の中の、窓口Aではあと何通、窓口Bではあと何通受け取れるか」を個別に管理するイメージです。

この柔軟な制御が、HTTP/2が効率的に動作するための鍵なんです。

HTTP/2フロー制御の心臓部：「ウィンドウ」と「WINDOW_UPDATEフレーム」

さあ、いよいよHTTP/2のフロー制御の具体的な仕組みに入っていきましょう。

キーワードは以下の二つです。

1. ウィンドウ（Window）: 「データをあとどれくらい受け取れるか」を示す窓
2. `WINDOW_UPDATE`フレーム: 「窓を広げたよ！もっと送っていいよ！」と伝えるメッセージ

「ウィンドウ」という名の「受け入れ可能量」

HTTP/2のフロー制御では、データを受け取る側（受信側）が、「あとこれだけのデータなら受け入れられますよ」という容量を「ウィンドウ」という数値で管理しています。この数値は、バイト単位で表現されます。

例えば、ブラウザがサーバーに対して「今、私にはあと1MBのデータを受け入れる余裕がありますよ」と伝えたとします。この「1MB」がウィンドウのサイズです。

サーバーは、このウィンドウの範囲内でしかデータを送ることができません。もしサーバーが1.5MBのデータを送りたいと思っても、ブラウザのウィンドウが1MBなら、とりあえず1MBだけ送って、残りは待つことになります。

例えるなら、コップに水を注ぐとき、コップの容量（ウィンドウ）を見ながら水を注ぐようなもの。コップから溢れないように、慎重に注ぎますよね。

`WINDOW_UPDATE`フレーム：「窓を広げる魔法のメッセージ」

さて、サーバーからデータが送られてきて、ブラウザがそのデータを受け取って処理を終えたとします。すると、ブラウザは再びデータを受け入れる余裕ができますよね。

このとき、ブラウザはサーバーに対して「受け取った分、また窓を広げたよ！もっと送っていいよ！」というメッセージを送ります。これが、まさに`WINDOW_UPDATE`フレームと呼ばれる特別なメッセージなんです。

この`WINDOW_UPDATE`フレームには、「これだけのバイト数分、窓を広げたからね」という具体的な数値（ウィンドウ増加量）が含まれています。

サーバーは、この`WINDOW_UPDATE`フレームを受け取ると、自分の持っている「ブラウザのウィンドウサイズ」を更新し、再びデータを送れるようになります。

このやり取りを繰り返すことで、送信側は受信側の処理能力を超えないように、賢くデータを送り続けることができるわけです。

二つの異なる「窓」：ストリームとコネクション

HTTP/2のフロー制御が面白いのは、この「ウィンドウ」が二つのレベルで管理されている点です。

1. ストリーム単位のフロー制御: 個々のリクエスト/レスポンス（ストリーム）ごとに管理される窓
2. 接続単位のフロー制御: HTTP/2の通信全体（TCPコネクション全体）で管理される窓

この二つの窓が、両方とも開いていないと、データは送れません。

1. ストリーム単位のフロー制御（各窓口のキャパシティ）

先ほどの郵便局の例で考えてみましょう。

郵便局には、手紙を受け付ける窓口、小包を受け付ける窓口など、複数の窓口がありますよね。
ストリーム単位のフロー制御は、「個々の窓口（ストリーム）が、それぞれあとどれくらいの荷物（データ）を受け取れるか」を管理しているイメージです。

例えば、

  • ストリーム1（WebページのHTML取得）: あと10KB受け入れ可能
  • ストリーム2（画像ファイル取得）: あと1MB受け入れ可能
  • ストリーム3（CSSファイル取得）: あと50KB受け入れ可能

といった形で、それぞれのやり取りごとに個別のウィンドウが設定されます。これにより、たとえ一つのストリームで大きなデータが来て処理に時間がかかっていても、他のストリームの通信が滞りにくくなります。

2. 接続単位のフロー制御（郵便局全体のキャパシティ）

一方、接続単位のフロー制御は、「郵便局全体（TCPコネクション全体）として、あとどれくらいの荷物（データ）を受け取れるか」を管理しています。

たとえ各窓口（ストリーム）のウィンドウが開いていたとしても、郵便局全体としての受け入れ容量（接続単位のウィンドウ）が上限に達していれば、それ以上データを受け取ることはできません。

これは、郵便局全体のスタッフ数や、保管スペースの限界のようなものです。いくら窓口が空いていても、これ以上は無理！という全体としての限界があるわけです。

両方の窓が開いていないとデータは流れない！

重要なのは、データが送信されるためには、そのストリームのウィンドウと、接続全体のウィンドウの両方が開いている必要がある、という点です。

どちらか一方でも閉じている（0バイトになっている）場合、そのデータは送信されず、待機状態になります。これによって、受信側が本当に処理できる量だけが送られてくる、という賢い制御が実現されているんですね。

フロー制御の具体的な流れを見てみよう

クライアント（ブラウザ）とサーバーの間で、データがどのようにやり取りされるか、簡単な流れで追ってみましょう。

1. 初期ウィンドウの決定:

  • クライアントとサーバーは、HTTP/2接続を確立する際に、お互いに「初期ウィンドウサイズ」を通知し合います。これは「とりあえずこれだけのデータなら受け取れますよ」という最初の窓の大きさです。
  • HTTP/2の仕様では、ストリームウィンドウと接続ウィンドウの初期値はそれぞれ`65,535バイト`（約64KB）と定められています。

2. サーバーからデータ送信:

  • サーバーは、クライアントのウィンドウサイズを見て、その範囲内でデータを送信します。データを送信すると、サーバーは自分の持っている「クライアントのウィンドウ」をその分だけ減らします。

3. クライアントのデータ受信と処理:

  • クライアントはデータを受け取り、それを処理します（画面に表示したり、メモリに格納したり）。
  • データを受け取るたびに、クライアントのウィンドウは減少していきます。

4. `WINDOW_UPDATE`フレームの送信:

  • クライアントは、一定量のデータを処理し終えるか、ウィンドウが少なくなってきたら、「もうこれだけ処理できたから、窓を広げてね！」という意味で`WINDOW_UPDATE`フレームをサーバーに送ります。
  • このフレームには、「どれくらいの量、窓を広げたか」という増加量が記載されています。

5. サーバーのウィンドウ更新と再送信:

  • サーバーは`WINDOW_UPDATE`フレームを受け取ると、自分の持っている「クライアントのウィンドウ」をその増加量分だけ広げます。
  • 再びウィンドウが開いたので、サーバーは残りのデータを送信したり、新しいデータを送信したりできるようになります。

この一連のスマートなやり取りが、目に見えないところで常に繰り返されているんです。

フロー制御の設定を調整してみよう（実践編）

HTTP/2のフロー制御は、デフォルト設定でも多くのケースで問題なく機能しますが、特定の状況（例えば、非常に大きなファイルを頻繁にやり取りする、またはネットワークが非常に高速で受信側の処理能力が追いつかない可能性がある場合など）では、このウィンドウサイズを調整することでパフォーマンスを改善できることがあります。

ここでは、代表的なWebサーバー（Nginx, Apache）や、HTTP/2対応のCLIツール（curl）での設定例を見てみましょう。

Nginxでの設定例

Nginxでは、`http2_initial_window_size`と`http2_initial_connection_window_size`というディレクティブで、ストリームとコネクションの初期ウィンドウサイズを設定できます。

http {
# … 省略 …

server {
listen 443 ssl http2;
server_name example.com;

# ストリームごとの初期ウィンドウサイズを調整 (デフォルト: 65535バイト)
# 例えば、1MB (1048576バイト) に増やす場合
http2_initial_window_size 1m; # 1メガバイト

# 接続全体の初期ウィンドウサイズを調整 (デフォルト: 65535バイト)
# 例えば、16MB (16777216バイト) に増やす場合
http2_initial_connection_window_size 16m; # 16メガバイト

# … その他の設定 …
}
}

ポイント:

  • `m` はメガバイト、`k` はキロバイトを表します。
  • これらの値を大きくしすぎると、受信側のリソース（メモリなど）を過度に消費する可能性があるので、慎重に調整しましょう。

Apache HTTP Serverでの設定例

Apacheでは、`mod_http2`モジュールが提供するディレクティブで設定します。


ServerName example.com
Protocols h2 http/1.1
SSLEngine on
# … その他のSSL設定 …

# ストリームごとの初期ウィンドウサイズを調整 (デフォルト: 65535バイト)
# 例: 1MB (1048576) に増やす場合
H2StreamWindowSize 1048576

# 接続全体の初期ウィンドウサイズを調整 (デフォルト: 65535バイト)
# 例: 16MB (16777216) に増やす場合
H2ConnectionWindowSize 16777216

# … その他の設定 …

ポイント:

  • Apacheでは、バイト数を直接数値で指定します。
  • こちらもNginxと同様、設定値を大きくしすぎるとリソース消費に注意が必要です。

curlコマンドでの確認例

実際にHTTP/2で通信する際に、クライアント側（curl）からフロー制御の初期ウィンドウサイズを指定して試すこともできます。

ストリームの初期ウィンドウサイズを1MBに、接続の初期ウィンドウサイズを16MBに設定してリクエスト
curl –http2 \
–http2-initial-window-size 1048576 \
–http2-initial-connection-window-size 16777216 \
https://example.com/

これらの設定は、サーバーとクライアントがお互いの初期受け入れ可能量を調整し合うためのものです。パフォーマンスチューニングの一環として、これらの値を調整することで、特に高遅延・高帯域幅の環境下でのスループット改善が期待できる場合があります。

フロー制御の重要性：縁の下の力持ち

HTTP/2のフロー制御は、普段意識することのない「縁の下の力持ち」のような存在です。しかし、これがなければ、HTTP/2が提供する高速性や効率性は、あっという間にボトルネックになってしまいます。

  • リソースの保護: 受信側のメモリやCPUが過負荷になるのを防ぎます。
  • 通信の安定性: データが途中で失われたり、再送されたりする頻度を減らし、安定した通信を実現します。
  • 公平なリソース配分: 複数のストリームが同時に動いている場合でも、特定のストリームが帯域幅を独占するのを防ぎ、全体としてスムーズな通信を促します。

HTTP/2が「高速」かつ「信頼性がある」のは、この賢いフロー制御の仕組みがしっかりと機能しているからなんですね。

まとめ：HTTP/2の賢い交通整理役

今回は、HTTP/2の「フロー制御」について、なぜそれが必要なのか、そして具体的にどのような仕組みで動いているのかを、現実世界の例えを交えながら深掘りしてきました。

ポイントは以下の3つです。

1. フロー制御は、受信側が処理しきれない量のデータを送信側が送りつけないための「優しさ」と「賢さ」です。
2. 「ウィンドウ」がデータの受け入れ可能量を、「`WINDOW_UPDATE`フレーム」がその窓を広げるメッセージの役割を果たします。
3. フロー制御は、個々の「ストリーム単位」と通信全体の「接続単位」の二つのレベルで機能し、両方の窓が開いていないとデータは送信されません。

HTTP/2の進化は、単に速いだけでなく、いかに効率的で安定した通信を実現するかという、プロトコルの「作法」を洗練させてきた歴史でもあります。このフロー制御も、その作法の一つであり、私たちが快適にWebを利用できるための大切な仕組みなんです。

パケットの一つ一つが、まるで命を持っているかのように賢くネットワークを駆け巡る。そんなHTTP/2の世界を、これからも一緒に探求していきましょう！

それでは、また次回の記事でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました