ウェブサイトを見ているとき、画像やテキストがパッと一瞬で表示されると気持ちがいいですよね。現代のウェブを裏で支える「HTTP/2」という仕組みは、まさにその「速さ」を実現するために生まれました。
HTTP/2の最大の特徴といえば、1本の通信回線（コネクション）の上で、いくつものデータを同時にやり取りできる「マルチプレクシング（多重化）」という技術です。たくさんのリクエストを同時に送れるなんて、まるで魔法のようですよね。
でも、ちょっと待ってください。
もし、サーバー側がものすごい勢いでデータを送りすぎて、あなたのパソコンの「受け皿（メモリ）」がパンクしてしまったらどうなるでしょうか？ パソコンは処理しきれずにフリーズしたり、データをこぼしたりしてしまいますよね。
そこで登場するのが、今回スポットを当てる「WINDOW_UPDATE（ウィンドウ・アップデート）フレーム」です。
今回は、このWINDOW_UPDATEが果たす「フロー制御」の仕組みについて、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！
—
1. 郵便受けと配達員に例える「フロー制御」
ネットワークの世界を分かりやすくするために、「大量の手紙（データ）を届ける郵便配達員」と「あなたの家の郵便受け（バッファ）」を想像してみてください。
HTTP/2のマルチプレクシングは、1人の優秀な配達員が、いくつもの引き出し（ストリーム）から同時に手紙をあなたに配るようなものです。配達員はとっても仕事が早いので、あなたの家の郵便受けのキャパシティなどお構いなしに、どんどん手紙を突っ込もうとします。
もし、あなたがのんびりとお茶を飲んでいる間に、配達員が何千通もの分厚いカタログを郵便受けに詰め込んだらどうなるでしょう？ そう、郵便受けはあっという間にあふれかえってしまいますよね。
これを防ぐために、郵便受けにはルールがあります。
「私の郵便受けには、いま〇〇MB分の空きがあります。だから、その分だけ手紙を入れていいですよ！」と、配達員に定期的に伝える仕組みです。
この「空き容量の通知票」こそが、HTTP/2における WINDOW_UPDATEフレーム なのです。
—
2. WINDOW_UPDATEフレームの正体と役割
HTTP/2では、データを細かく分割して「フレーム」というカプセルに入れてやり取りします。その中のひとつであるWINDOW_UPDATEフレームは、データを運ぶのではなく、「もっとデータを送っていいよ（あるいは、ちょっと待って）」と交通整理をするための専用チケットです。
このフロー制御は、次の2つのレベルで行われます。
1. ストリームレベル（個別の引き出し）
- 例えば、「画像A」を受け取るための引き出し、「動画B」を受け取るための引き出し、それぞれの単位で行う制御です。
2. コネクションレベル（家全体の玄関）
- ネット回線（TCPコネクション）全体で、どれくらいのデータを受け取れるかという全体的な制御です。
どちらのレベルでも、「ここまでなら受け取れるよ」という枠（ウィンドウサイズ）があらかじめ決まっており、データを受け取るたびにその枠が小さくなっていきます。そして、枠が少なくなってきたら、WINDOW_UPDATEフレームを使って「ウィンドウサイズをこれだけ増やして（追加の枠をちょうだい）！」とサーバーにお願いするわけです。
—
3. ウィンドウサイズの増分はどうやって決まる？
それでは、実際に「どれくらいのサイズを増やしてお願いするのか」という計算の仕組みを見ていきましょう。と言っても、難しい数式を使うわけではないので安心してくださいね。
基本の考え方はこうです。
- 初期ウィンドウサイズ: 最初にお互いが約束する受け皿の大きさ（例: 65,535バイトなど）。
- 消費（Consumption）: データを受信するたびに、ウィンドウの残りサイズが減っていきます。
- 回復（Replenishment）: アプリケーションがデータを処理し終えたら、その処理した分だけ、ウィンドウのサイズを元に戻す（増分を通知する）WINDOW_UPDATEを送信します。
例えば、以下のような流れになります。
1. サーバーから `10,000バイト` のデータが届く。
2. クライアント側のウィンドウの残りサイズが `10,000バイト` 減る。
3. クライアントのアプリがそのデータを無事に読み込み、「よし、この分のスペースが空いたぞ！」と判断する。
4. クライアントはサーバーに対して、「増分（Increment）として 10,000バイト を追加してね！」というWINDOW_UPDATEフレームを送る。
5. サーバーはウィンドウの残り枠が増えたので、安心して次のデータを送り続ける。
このキャッチボールがあるおかげで、受信側の処理能力を超えてデータが送りつけられる「オーバーフロー」を防ぎながら、限界ギリギリのスピードで高速通信ができるというわけです。
—
4. 実際のパケットやログを覗いてみよう
実務でネットワークのデバッグをしていると、ブラウザの通信解析ツール（Developer Tools）やパケットキャプチャ（Wiresharkなど）で、このWINDOW_UPDATEがやり取りされている瞬間に出会うことがあります。
言葉だけだと少し抽象的なので、内部でどのようにやり取りされているのか、イメージしやすいように疑似的なログや設定の雰囲気を見てみましょう。
【パケットのやり取りのイメージ】
[Client] —> HEADERSフレーム (リクエスト送信) —> [Server]
[Client] <--- DATAフレーム (データ 16,384バイト) <--- [Server] (残りウィンドウが減る)
[Client] <--- DATAフレーム (データ 16,384バイト) <--- [Server] (残りウィンドウが減る)
[Client] ---> WINDOW_UPDATE (増分: 32,768バイト) —> [Server] (“もっと送ってOK！”)
[Client] <--- DATAフレーム (次のデータ群...) <--- [Server]
このように、データ（DATA）を受け取るたびに、受信側が「ここまで処理したよ、枠を戻して！」とこまめにWINDOW_UPDATEを送り返しているのが、HTTP/2の裏側のリアルな挙動です。
開発や運用でのワンポイントアドバイス
もし、巨大なファイルをダウンロードしている最中に「なんだか途中で通信がピタッと止まってしまう……」といったトラブルに直面したときは、このフロー制御が怪しい場合があります。
プロキシサーバーやロードバランサー、あるいはアプリケーション側のバッファサイズ設定（NginxやApacheなどのチューニングパラメータ）が適切でないと、ウィンドウの更新がうまく行われず、通信が詰まってしまうことがあるんです。そんなときは、「あ、今WINDOW_UPDATEのキャッチボールで目詰まりが起きているのかもな」と視点を向けられると、プロフェッショナルなトラブルシューティングにグッと近づけますよ！
—
まとめ
今回は、HTTP/2の縁の下の力持ちである「WINDOW_UPDATEフレーム」とフロー制御について紐解いてみました。
- マルチプレクシングは便利だけど、受信側の受け皿があふれる危険がある。
- それを防ぐために、郵便受けの空き状況を伝える「WINDOW_UPDATEフレーム」が存在する。
- データを受け取って処理したら、その分の増分を相手に知らせて、安全かつ高速な通信を維持している。
普段私たちが何気なく使っているブラウザの裏側では、こうした細かい「思いやり（制御）」のパケットが絶妙なタイミングで行き交っています。
仕組みが分かると、ネットワークの向こう側で起きていることがまるで目の前で動いているように感じられて、より一層エンジニアリングが楽しくなりますよね。
一歩ずつ、確実に知識を積み重ねていきましょう！
コメント