【入門編】HTTP/2におけるストリーム状態遷移図(Stream States) – HTTPプロトコル・通信規格実践ガイド

こんにちは！技術メディア編集部の主筆ライターです。

日々のWeb開発やインフラのメンテナンス、本当にお疲れ様です！ブラウザで何気なく見ているWebサイト。その裏側では、私たちが想像するよりもはるかにドラマチックな通信のドラマが繰り広げられています。

さて、今回はWebの高速化を支える主役の一つ「HTTP/2」、その中でも少し通なテーマである「ストリーム状態遷移（Stream States）」について深掘りしていきましょう。

「状態遷移図」なんて言葉を聞くと、なんだか複雑なプログラムの図や、分厚い英語の仕様書を思い浮かべて身構えてしまいますよね。でも、安心してください！一歩ずつ、身近な例えを交えながら優しく紐解いていきますので、一緒に楽しくマスターしていきましょう！

—

そもそも「HTTP/2のストリーム」ってなに？

HTTP/1.1の時代、ブラウザは画像やCSSを読み込むために、いくつものコネクション（道路）を同時に繋いで頑張っていました。しかし、HTTP/2では「1本の太いコネクションの中に、いくつもの仮想的なレーン（通り道）を作る」という画期的な仕組みが導入されました。

この仮想的なレーンのことを「ストリーム」と呼びます。

郵便配達でイメージしてみよう！

HTTP/2のストリームを分かりやすく例えるなら、「1本の大きなパイプラインの中を走る、個別のトロッコ」です。

昔のHTTP/1.1は、手紙を1通送るたびに、わざわざ新しい郵便受けを設置しに行くようなもどかしさがありました。しかし、HTTP/2は1本の大きな地下トンネル（コネクション）を掘り、その中をたくさんのトロッコ（ストリーム）が「荷物（データ）」を乗せて、行き来できるようにしたのです。

このトロッコたちは、それぞれが「今どこを走っていて、荷物を積み込んでいるのか、それとも目的地に着いて空っぽになったのか」という“今の状態”を持っています。これが今回のお題である「ストリーム状態遷移」の正体です。

—

ストリームの4つの主要な状態を覗いてみよう！

HTTP/2の世界では、1つのストリーム（トロッコ）が生まれてから消滅するまでに、いくつかの「状態（ステータス）」を渡り歩きます。代表的な4つの状態を見ていきましょう。

[idle (何もなし)]
↓ (リクエストの送信)
[open (両方向で通信中)]
↓ (片側が送信完了)
[half-closed (片側通行)]
↓ (両方完了)
[closed (お片付け完了)]

1. `idle`（アイドル：まだ何も起きていない待機状態）

ストリームが生まれたばかりの、まっさらな状態です。まだ何のデータも流れていません。例えるなら、「新しく組み立てられた、まだ誰も乗っていないピカピカのトロッコ」ですね。

2. `open`（オープン：絶賛会話中！）

ブラウザからサーバーへリクエストを送り、サーバーからもデータが返ってきている、一番活発な状態です。この状態の時は、お互いに自由にデータを送り合うことができます。例えるなら、「トンネルの中を、お互いに荷物を投げ入れ合いながら走っているトロッコ」のイメージです。

3. `half-closed`（ハーフクローズ：片側だけお仕事終了）

「リクエストは送り終えたけれど、サーバーからの返事の続きをまだ待っている」という、ちょっと片想いのような状態です。自分からの送信は終わったけれど、相手からの受信はまだ終わっていません。例えるなら、「行き荷を降ろし終えて、帰りの荷物を待っている状態」ですね。

4. `closed`（クローズ：お疲れ様でした！）

すべてのやり取りが完了し、ストリームとしての役割を終えた状態です。この状態になったトロッコは解体され、メモリの領域も解放されます。例えるなら、「車庫に戻ってピカピカに掃除されたトロッコ」です。

—

各状態における「フレーム送信の可否」のルール

さて、ここからがネットワークエンジニアの腕の見せ所です。
「今、自分のストリームがどの状態にあるか」によって、次にどんなデータを送っていいか（フレームを送信していいか）のルールが厳密に決まっています。

ルールを破ると、サーバーから「ちょっと何勝手に送ってきてるの！」と怒られてしまいます（プロトコルエラーという形でコネクションを切断されてしまいます）。

ざっくり分かる送信ルール早見表

「ハーフクローズ状態のときは、もう自分からデータ（`DATA`）を送っちゃいけないんだな」といったように、今の状態に合わせた節度ある通信が求められます。これがHTTP/2の美しくも堅牢な仕組みです。

—

実務・デバッグで役立つ！ブラウザの裏側を覗き見しよう

「理屈は分かったけれど、実際のネットワークではどう見えているの？」
そんな疑問に答えるため、実務の現場やトラブルシューティングですぐに使える、開発者向けの視点をお届けします。

現代のブラウザ（Google ChromeやFirefoxなど）の「開発者ツール（F12キー）」を開き、「ネットワーク（Network）」タブを覗いてみてください。
そして、列のヘッダーを右クリックして「Protocol」や「Stream」といった項目を表示させてみましょう。

すると、次のような情報が目の前に現れます。

[Chrome Developer Tools のネットワークタブのイメージ]
Name Status Protocol Stream Size Time
————————————————————–
index.html 200 h2 3 1.2 kB 45 ms
style.css 200 h2 5 4.5 kB 52 ms
app.js 200 h2 7 12.0 kB 61 ms

お気づきでしょうか？
各リソースの横にある `Stream: 3`, `Stream: 5`, `Stream: 7` という奇妙な数字。これがまさに、ブラウザとサーバーの間で今まさに駆け抜けている「ストリーム（トロッコ）の番号」そのものです！

💡 現場のプロからのワンポイントアドバイス

HTTP/2では、ブラウザから始まるクライアント側のストリーム番号は「奇数（1, 3, 5, 7……）」を使うというルールがあります（サーバー側からプッシュする通信は偶数を使います）。
もし、パケットキャプチャツール（Wiresharkなど）を使って通信を解析する機会があれば、この奇数・偶数のルールを思い出してみてください。「あ、今クライアントがストリーム3番でリクエストを投げたな」と、パケットの動きが生々しく手に取るように分かるようになりますよ！

—

まとめ

今回は、HTTP/2のストリーム状態遷移について、郵便配達のトロッコに例えながら優しく解説しました。

ストリームとは、1本のコネクションの中を走る仮想的な「トロッコ」である。
状態（States）には、`idle`（待機）、`open`（会話中）、スキーマが変わる `half-closed`（片側終了）、そして `closed`（終了）がある。
状態によって次に送っていいフレームのルールが決まっており、これを守ることで高速かつ安全な通信を実現している。

インフラやネットワークの世界は、一見すると難解な用語のオンパレードに見えますが、こうして身近な世界に置き換えてみると、エンジニアたちの優れた工夫とロマンがひしひしと伝わってきますよね。

日々の開発やインフラ運用の片隅で、「今、あのパケットはどの状態のトロッコに乗っているんだろうな」と想像力を膨らませていただけたら、これほど嬉しいことはありません。

それでは、また次回の技術解説でお会いしましょう！快適なネットワークライフを！