こんにちは！技術メディア編集長のネットワークアーキテクトです。
日頃からWebサイトを作ったり、インフラの構築やトラブルシューティングに向き合っていると、「もっと通信を速くしたい！」「遅延の原因を根本から断ち切りたい！」という熱い思いに駆られますよね。
HTTP/2が登場したとき、「1本の道路（TCPコネクション）のうえで、複数の荷物（ストリーム）を同時に往復させられる（マルチプレクシング）」と聞いて、私たちは大きな衝撃を受けました。あれは本当に画期的な技術でした。
しかし、現実のインターネットの世界は甘くありません。「トンネルの手前で大渋滞が起きたら、中の車がすべて動かなくなる」というTCP特有の持病（Head-of-Line Blocking問題）は、どれだけHTTP/2が頑張っても完全に解決することはできませんでした。
そこで登場したのが、次世代の通信規格 「HTTP/3（およびその基盤であるQUIC）」 です。
今回は、そのHTTP/3の心臓部ともいえる「フロー制御（ストリームレベルとコネクションレベル）」について、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！難解な英語の仕様書は一旦置いておいて、リラックスして読んでくださいね。
—
1. なぜ「フロー制御」が必要なの？ 〜郵便配達の例え〜
突然ですが、想像してみてください。
あなたはものすごく足の早い超人（サーバー）です。相手は、少し小柄でデスクの上が書類の山でいっぱいの新入社員（クライアント）だとしましょう。
ここであなたが、相手の状況もお構いなしに、一秒間に1000通もの手紙を送りつけたらどうなるでしょうか？
新入社員の机の上はすぐに溢れかえり、「もう無理です！これ以上置けません！」とパニックになってしまいますよね。届いた手紙は床に散らばり、大切な書類がどこに行ったか分からなくなってしまいます。
ネットワークの世界でも全く同じことが起き言えます。
サーバーがどれだけ高速にデータを送れようとも、受け取る側のクライアントの「メモリ（バッファ）」には限界があります。この「受け手のキャパシティを超えてデータを送りつけ、メモリをパンクさせる事故」を防ぐための仕組みこそが、ここで解説するフロー制御なのです。
—
2. HTTP/3（QUIC）のフロー制御がすごい理由
HTTP/3の土台である「QUIC」は、UDPをベースに作られています。TCPとは違い、QUICの中には「たくさんの独立したレーン（ストリーム）」が走っています。
ここでポイントになるのが、フロー制御が「2つの階層」で行われているという点です。
1. ストリームレベルのフロー制御（個別の荷物ごとの制限）
2. コネクションレベルのフロー制御（全体を合わせた総量制限）
「なぜ2つも必要なの？」と思いますよね。これも身近な例えで考えてみましょう。
ストリームレベルとコネクションレベルの二重チェック
例えば、あなたが大きな倉庫を経営していて、トラックで荷物を送る場面を想像してください。
- コネクションレベル：あなたの倉庫から、その配送先へ送る「総荷物量」の限界（例：合計で100箱まで）。
- ストリームレベル：個別のお届け物（Aさん宛ての荷物、Bさん宛ての荷物）ごとの「個別の限界（例：Aさん宛ては30箱まで）」。
もし、Aさん宛ての荷物がいくら余裕であっても、倉庫全体の限界（100箱）に達していれば、これ以上別の荷物をトラックに積むことはできませんよね。
HTTP/3はこの2つを巧みに組み合わせることで、特定の重いファイル（例えば巨大な動画データ）が通信全体の枠をすべて食いつぶしてしまい、他の軽いデータ（例えばページの文字情報）が全く届かなくなるという悲劇を防いでいるのです。
—
3. バッファ枯渇を防ぐ「クレジット更新メカニズム」
では、このフロー制御は具体的にどのように動いているのでしょうか？
ここで登場するのが、「クレジット（受給枠）方式」という仕組みです。
通信が始まるとき、受け手（クライアント）は送り手（サーバー）に対して、こう伝えます。
> 「私、今10KB分のメモリをあなたのために空けておいたので、まずは10KB分のクレジット（切符）をあげます！」
サーバーはこのクレジットをもらって初めて、安心してデータを送信し始めます。
サーバーがデータを送るたびに、手元のクレジットの残高は減っていきます。
クレジットがなくなったらどうなる？
サーバーが10KBを送り切ると、手元のクレジットは「0」になります。この瞬間、サーバーはピタッとデータの送信をストップします。無理やり送るとメモリが溢れてしまうからです。
ここで、クライアント側で変化が起きます。
受け取ったデータを無事に処理し終わって、メモリに空きができたとします。「よし、机の上を片付けたから、またスペースができたぞ！」と気づいたクライアントは、サーバーに向けて次のようなメッセージを送ります。
> 「お疲れ様です！データを処理したので、新しく追加で20KB分のクレジットを差し上げます！」
このメッセージ（QUICパケットでは `MAX_DATA` や `MAX_STREAM_DATA` と呼ばれます）を受け取ったサーバーは、「やった！また送っていいんだな！」と、通信を再開します。
この「データを受け取る ➔ 処理して机を空ける ➔ 追加のクレジットを送る」というキャッチボールこそが、バッファ枯渇を防ぎ、ネットワークの平和を保つクレジット更新メカニズムの正体です。一歩ずつ見ていくと、とってもシンプルで理にかなった仕組みですよね！
—
4. 現場で役立つ！パラメーター調整のイメージとコード例
さて、ここからは少し実践的なお話です。
実際に私たちがNginxやGo言語などでWebサーバーを構築する際、このフロー制御の初期値をどのように意識すればよいのでしょうか。
例えば、Go言語のモダンなHTTP/3ライブラリ（`quic-go` など）では、コネクションやストリームの初期ウィンドウサイズ（クレジットの初期値）をコードで設定することができます。
以下に、実務の現場をイメージした設定のサンプルコード（Go言語）を記載します。日本語のコメントを添えているので、動きをイメージしてみてください。
package main
import (
“log”
“net/http”
“github.com/quic-go/quic-go”
“github.com/quic-go/quic-go/http3”
)
func main() {
// QUICサーバーの設定をカスタマイズするオブジェクトを作成します
quicConfig := &quic.Config{
// 【コネクションレベルの初期ウィンドウサイズ】
// 通信全体の初期メモリ枠を「512KB」に指定します。
// 高速な回線であれば大きくし、メモリが限られた環境なら小さく調整します。
MaxIncomingStreams: 1000,
// ここでは説明のため概念的な設定を交えていますが、
// quic-goでは内部のバッファ管理やフロー制御の枠（Window）が
// ネットワークの状況（RTTなど）に応じて自動的に最適化されます。
}
// HTTP/3サーバーのインスタンスを定義
server := http3.Server{
Addr: “:443”,
QuicConfig: quicConfig,
}
log.Println(“HTTP/3サーバーを起動しています（ポート: 443）…”)
// ※実際の証明書ファイルパスなどを指定してTLS/QUICリスナーを起動します
// err := server.ListenAndServeTLS(“server.crt”, “server.key”)
// if err != nil {
// log.Fatal(err)
// }
}
実務のデバッグでの着眼点
もし、あなたが開発しているWebアプリケーションやAPIで「なぜかレスポンスの途中でデータがぴたっと止まってしまう」「ファイル転送が途中でフリーズする」というトラブルに遭遇したときは、Wiresharkなどのパケットキャプチャツールを開いてみてください。
QUICのレイヤーで以下のようなパケットが頻繁にやり取りされているかを確認するのが、プロのトラブルシューティングの第一歩です。
- `STOP_SENDING` や `RESET_STREAM` が出ていないか？
- クライアントからの `MAX_DATA`（クレジット追加の合図） が遅延していないか？（ネットワークの遅延や、クライアント側のCPU高負荷が原因で、処理が追いつかずにクレジットを出せていないケースがよくあります）
—
おわりに
今回は、HTTP/3（QUIC）のフロー制御について、ストリームレベル・コネクションレベルの違いと、クレジット更新メカニズムの裏側を解説しました。
一見すると難しそうな「フロー制御」という言葉も、「お互いのキャパシティに合わせて、送りすぎないようにチケットをやり取りする優しい約束事」だと捉えると、パケットの動きがイキイキと見えてきませんか？
ネットワークやインフラストラクチャの世界は、こうした細やかな気配りの積み重ねで動いています。今回の記事が、あなたの日常の開発やインフラの学びの小さなヒントになれば、ライターとしてこれ以上の喜びはありません。
それでは、また次回の技術解説でお会いしましょう！快適なネットワークライフを！
コメント