こんにちは！Webの裏側を支えるネットワークの世界へようこそ。インフラエンジニアの視点から、普段何気なく使っているブラウザとサーバーの会話の秘密を紐解いていくこのブログ。今回は、HTTP/2のパフォーマンスを大きく左右する「SETTINGS_INITIAL_WINDOW_SIZE（初期ウィンドウサイズ）」という、ちょっと名前が長いけれどめちゃくちゃ重要なパラメータについてお話しします。
「なんだか難しそうな英語が出てきたな……」と思いましたよね？大丈夫です！一歩ずつ、身近な例えから優しく紐解いていきましょう。
—
1. そもそもHTTP/2の「ウィンドウサイズ」ってなに？
まずは、HTTP/2が私たちの手元にWebページを届けてくれる仕組みを、少しだけ振り返ってみましょう。
昔のHTTP/1.1では、お店のレジに一列に並ぶように、1つの通信（コネクション）につき1つのファイルしかやり取りできませんでした。これだと、大きな画像をダウンロードしている間、次に表示したいテキストが後ろで待たされてしまいますよね。
そこでHTTP/2では、「マルチプレクシング（多重化）」というスーパーテクニックが使われるようになりました。これは、1本の太い水道管（コネクション）の中に、何本もの細いホース（ストリーム）を同時に通して、画像もテキストもまとめて一気に届けちゃおうという仕組みです。
郵便配達の荷物制限で考えてみよう
このHTTP/2の仕組みを、「郵便配達員さんが家まで荷物を届けてくれる様子」に例えてみましょう。
サーバー（郵便局）からあなたのパソコン（自宅）へ、たくさんの荷物（画像やスクリプト）が送られてきます。もし、郵便配達員さんが自分のキャパシティを無視して、一度に無限の荷物をあなたの家のポストに突っ込もうとしたらどうなるでしょうか？
そう、あなたの小さなポストはすぐにパンクしてしまい、大切な荷物が地面に散らばってしまいますよね。
そこでインターネットの世界では、「フロー制御（流れのコントロール）」というルールがあります。
「私のパソコンは、今これだけの大きさの荷物なら受け取れるよ（ウィンドウサイズ）」という受け皿の大きさを、サーバー側にあらかじめ伝えておくんです。
サーバー側は、あなたが「これだけ受け取れるよ」と言ったサイズ（枠）を確認してから、その分の荷物を送り出します。そして、あなたが荷物を受け取るたびに「受け取ったよ！」と小まめに連絡帳（ACK）を書き込み、次の荷物を送ってもらう……このキャッチボールを繰り返しながら、安全にデータを運んでいるのです。
—
2. 高遅延ネットワーク（宇宙や移動中）での落とし穴
ここで、今回の一番のテーマである「高遅延ネットワーク」のお話をします。
「高遅延」とは、要するに行き来の時間がかかる場所のことです。例えば、
- 電波の届きにくい地下鉄やトンネルの中を走るスマホ
- 海の上を航海中の豪華客船からの通信
- 地球と宇宙ステーションの通信（これは極端ですが！）
こうした環境では、サーバーからあなたの手元にデータが届くまで、そして手元から「受け取ったよ」という返事がサーバーに届くまで、物理的にどうしても時間がかかります。
デフォルト値のままだとどうなるの？
HTTP/2が標準で定めている「初期ウィンドウサイズ（`SETTINGS_INITIAL_WINDOW_SIZE`）」のデフォルト値は、実は 65,535バイト（約64KB） と、現代のインターネット環境からするとかなり小さめに設定されています。
先ほどの郵便配達の例で考えてみましょう。
- あなたの家のポスト（ウィンドウサイズ）： 64KBしか一度に受け取れない
- 通信の往復にかかる時間（遅延）： 1回やり取りするのに0.2秒かかる
サーバーは「64KB送ったら、一度止まって相手の返事を待たなきゃいけないルールだな」と判断します。
そのため、たとえあなたが超高速な光回線や5Gを使っていても、サーバーは64KB送り終えた瞬間に「ピタッと手が止まって、あなたの返事を待つ時間」が発生してしまうのです。
「あれ、電波のバーは立ってるのに、Webページの表示がなんだかワンテンポ遅いな……」と感じる原因の正体は、まさにこの「小さなウィンドウサイズのせいで、通信が何度も律儀に立ち止まっているから」なんですね。
—
3. パラメータを最適化して、スループットを爆発させよう！
ここで登場するのが、「SETTINGS_INITIAL_WINDOW_SIZEパラメータの最適化」です。
サーバーとブラウザが最初に挨拶をかわすとき（セッションの確立時）、サーバーに対してこう伝えてあげるのです。
> 「ねえ、私の受け皿（ウィンドウサイズ）は64KBよりもっと大きいよ！最初からもっとたくさんの荷物をドカンと送ってくれて大丈夫だよ！」
この初期ウィンドウサイズを、例えば 1MB や 2MB といった大きな値に設定し直してあげるとどうなるでしょうか？
サーバーは、あなたからの「もっとちょうだい！」というGOサインを受けて、途中で立ち止まることなく、大容量のデータを一気に流し続けます。結果として、高遅延な環境であっても、ネットワークのパイプラインを常に満タンにしておくことができ、スループット（単位時間あたりのデータ転送量）が劇的に向上するというわけです。
—
4. 実務で使える設定例とチューニングのポイント
「じゃあ、ウィンドウサイズは大きければ大きいほど正義なんだな！ 今すぐ限界まで大きくしよう！」と思ったそこのあなた、ちょっと待ってくださいね。
インフラの世界には「過ぎたるは及ばざるが如し」という言葉があります。
ウィンドウサイズをあまりにも巨大にしすぎると、今度はサーバー側やクライアント側の「メモリ（RAM）」を圧迫する原因になります。もし途中で通信が切断されたとき、未確認の巨大なデータを一時的に保持し続けなければならなくなるため、サーバーのメモリがパンクしてしまうリスク（DDoS攻撃の標的になるリスクも含め）があるのです。
そのため、ネットワークの特性やサーバーの負荷状況に応じた「ちょうどいい塩梅」を見つけることが大切になります。
代表的なWebサーバーの設定例
例えば、世界中で広く使われているリバースプロキシ兼Webサーバーの Nginx では、HTTP/2のウィンドウサイズを以下のようなディレクティブで調整することができます。
http {
# HTTP/2の設定ブロック
# クライアント（ブラウザなど）へ送信する際の初期ウィンドウサイズを調整します
# デフォルトの64KBから、例えば256KB（262144バイト）に拡張する場合の例
http2_window_size 256k;
# ※注意: クライアント側からサーバーへ送る際のサイズは、
# http2_max_concurrent_streams や各クライアントの実装に依存します。
}
上の設定ファイルは、Nginx環境でHTTP/2のウィンドウサイズを拡張する際の設定例です。環境に合わせて数値を調整してくださいね。
現場で役立つ選定基準のガイドライン
1. 一般的なWebサイト・APIサーバーの場合
- デフォルトの 64KB から、256KB 〜 1MB あたりに引き上げるのが、メモリ消費と速度向上のバランス点としてよく選ばれます。
2. グローバル向けやモバイル・高遅延環境がメインの場合
- ユーザー層の回線品質がバラバラで遅延が大きいことが分かっている場合は、思い切って 1MB 〜 2MB 程度まで広げ、スループットの低下を防ぐアプローチが有効です。
3. IoT機器やメモリが極端に少ない環境の場合
- 無理に大きくせず、デフォルト値のましかもしくは控えめなサイズに留め、メモリ溢れを防ぐ安全策をとるのが無難です。
—
5. まとめ
いかがでしたでしょうか？今回は少し硬い名前の「SETTINGS_INITIAL_WINDOW_SIZE」について、郵便配達の例えを交えながら優しく解説してみました。
- HTTP/2のウィンドウサイズは、受け皿（ポスト）の大きさである。
- 高遅延ネットワークでは、デフォルトの小さいサイズ（64KB）だと通信が何度も立ち止まってしまう。
- パラメータを適切に最適化（拡張）することで、通信の待ち時間をなくし、スループットを大きく引き上げることができる。
- ただし、大きくしすぎるとメモリを圧迫するため、サービスの特性に合わせた「適切なバランス（256KB〜1MB程度）」を見極めることがプロの腕の見せ所。
ネットワークの裏側で行われているパケットたちのこんなドラマを想像できるようになると、インフラのチューニングが何倍も楽しくなってきますよね。
ぜひ、ご自身の身近なシステムや検証環境でも、このパラメータを意識して触ってみてください。それでは、また次回の技術解説でお会いしましょう！
コメント