【実務・中級編】QUICの輻輳制御(Congestion Control)アルゴリズム – HTTPプロトコル・通信規格実践ガイド

TCPの呪縛を解き放つ——QUIC輻輳制御（Congestion Control）の深層と現場でのチューニング実践

現場で日々ネットワークのトラフィックと格闘しているエンジニアの皆さん、お疲れ様です。

「HTTP/3はUDPを使っているから速い」——Web業界ではそんなフレーズが独り歩きしがちです。しかし、インフラやプロトコルの深部を知る私たちから言わせれば、それは半分正解で半分は言葉足らずです。単にUDPへ置き換えただけでは、パケットは過酷なパブリックインターネットの波に呑まれ、壊滅的なパケットロスとパケット再送の嵐（ネットワーク崩壊）を引き起こします。

HTTP/3（そしてその基盤となるQUICプロトコル）が真の威力を発揮している最大の理由は、「UDPの上に、TCP以上に高度で洗練された『輻輳制御（Congestion Control）』をユーザー空間で構築したこと」にあります。

今回は、RFC 9002で標準化されているQUICの輻輳制御アルゴリズムの仕組みから、TCPとの決定的な相違点、CUBICやBBRといったアルゴリズムの選択肢、さらには実際にcurlやプロキシサーバー（Envoy）、Python（aioquic）を用いたデバッグ・設定手法まで、現場目線で徹底的に解説します。

—

1. なぜTCPの輻輳制御ではダメだったのか？ QUICが解決した3つの歴史的課題

QUICの輻輳制御を理解するには、まず「TCPが長年抱えてきた構造的な限界」をQUICがどう克服したかを知る必要があります。基本アルゴリズムの思想（Slow StartやCongestion Avoidance）自体はTCPを踏襲していますが、その「パケットの計測精度」が次元違いに進化しています。

課題①：ACKのあいまいさ問題（ACK Ambiguity）の排除

TCPでは、パケットが再送された際、送信元が受け取ったACKが「最初に送ったパケットへのACK」なのか「再送したパケットへのACK」なのか判別できません（ACK Ambiguity）。これにより、往復遅延時間（RTT）の計測が歪み、正確な輻輳判定が困難でした。

QUICでは、パケット番号（Packet Number）が単調増加（Monotonic Increase）します。再送データであっても、新しいパケット番号が割り当てられます。
これにより、「どのパケットに対するACKか」が100%一意に特定でき、正確なRTT計測が可能になりました。

課題②：ACK Delay（明示的な遅延報告）の導入

受信側ルーターやNICがACKをまとめて返す「Delayed ACK」はTCPでも使われますが、送信側は「ネットワークの遅延」なのか「相手のACK処理遅延」なのか区別できませんでした。

QUICの`ACK`フレームには、受信側がパケットを受け取ってからACKを返すまでに費やした時間を明示する`ACK Delay`フィールドが存在します。送信側はこれを計測RTTから差し引くことで、純粋なネットワークの物理遅延を算出できます。

[ QUICのRTT計算イメージ ]

課題③：カーネルOSからの解放（Plug-and-Playな柔軟性）

TCPの輻輳制御（CUBICやBBR）を変更・チューニングするには、Linuxカーネルのアップデートや`sysctl`の変更、あるいはカーネルモジュールのロードが必要でした。これは大規模な本番環境では非常にハードルの高い作業です。

QUICはユーザー空間（アプリケーション層）で動作します。Webサーバー（Nginx, Envoy）やアプリのライブラリ（quiche, msquic等）を差し替えるだけで、最新のBBRv3などを即座にテスト・適用できるプログラマビリティを手に入れました。

—

2. QUICの代表的な輻輳制御アルゴリズム：CUBIC vs BBR

QUICの設計は「プラグイン可能（Pluggable）」です。トランスポート層の責務でありながら、アルゴリズムを自由に切り替えられます。実務で選定対象となるのは主に以下の2つです。

CUBIC (RFC 8312ベース)

アプローチ: パケットロス駆動（Loss-based）
挙動: パケットロスが発生するまで送信ウィンドウ（`cwnd`）を3次関数的に拡大し、ロスが起きたら一気に減速します。
適した環境: 帯域が安定しており、パケットロスが主に「ネットワーク混雑」を意味する有線LANやデータセンター間通信。
現場の現実: Wi-Fiや5Gなどのモバイル回線では、電波干渉による「混雑以外の非意図的パケットロス」でも速度が急降下してしまい、スループットが安定しないデメリットがあります（Bufferbloat問題の発生）。

BBR (Bottleneck Bandwidth and RTT)

アプローチ: モデル駆動（Bandwidth & RTT-based / Google開発）
挙動: パケットロスではなく、パイプラインの最大帯域幅（`BtlBw`）と最小往復時間（`RTprop`）を常時計測し、その「パイプを満たす最適なパケット量（BDP: Bandwidth Delay Product）」を維持します。
適した環境: パケットロス率が一定数存在するモバイル回線（4G/5G）、長距離・高RTTの国際標準回線、動画配信やリッチAPI通信。

—

3. シーケンスと主要パラメーター（RFC 9002）

QUICの輻輳制御の内部状態は、RFC 9002において明確に定義されています。基本的なステート遷移と、絶対に押さえておくべきパラメーター（変数）を確認しましょう。

状態遷移シーケンス

[ Slow Start (低速スタート) ]
|
| (cwnd >= ssthresh またはパケットロス/ECN検出)
v
[ Congestion Avoidance (輻輳回避) ]
|
| (パケットロス検出)
v
[ Recovery Period (回復期間) ]
|
| (暗号化パケットのACK完了)
v
[ Congestion Avoidance に復帰 ]

エンジニアがデバッグで追うべき重要パラメーター

`congestion_window` (`cwnd`):

一度にネットワーク上に送信できる未承認データの最大バイト数。

`bytes_in_flight`:

送信済みだが、まだ相手からのACKを受け取っていない（飛行中の）データの合計バイト数。常に `bytes_in_flight <= cwnd` を維持するよう制御されます。

`ssthresh` (Slow Start Threshold):

Slow Start（指数関数的成長）から Congestion Avoidance（線形成長）へ移行する閾値。

`kMinimumWindow`:

RFC 9002で定義される最小`cwnd`。通常は `2 max_datagram_size`（約2900バイト）。どれだけ過酷な混雑が起きても、通信を完全に寸断させないためのセーフティネットです。

—

4. 実務での実装・設定・デバッグ手順

ここからは、実際に手元や本番環境でQUICの輻輳制御を試すための具体的な設定やコード、デバッグ手順を紹介します。

① Envoy ProxyでのQUIC輻輳制御設定（YAML）

モダンなマイクロサービスでHTTP/3のエッジプロキシとして使われるEnvoyの設定例です。Envoyは内部でGoogleの`quiche`ライブラリを使用しており、輻輳制御アルゴリズムを指定できます。

envoy.yaml の一部抜粋
static_resources:
listeners:

name: listener_http3

address:
socket_address:
protocol: UDP # QUICはUDP上で動作する
address: 0.0.0.0
port_value: 443
udp_listener_config:
quic_options:
# QUICの接続・輻輳制御に関するオプション
enabled: true
filter_chains:

transport_socket:

name: envoy.transport_sockets.quic
typed_config:
“@type”: type.googleapis.com/envoy.extensions.transport_sockets.quic.v3.QuicDownstreamTransport
enable_early_data: true # 0-RTTを有効化
downstream_tls_context:
common_tls_context:
tls_certificates:

certificate_chain: { filename: “/etc/envoy/certs/server.crt” }

private_key: { filename: “/etc/envoy/certs/server.key” }

# HTTP/3プロトコルオプションの指定
clusters:

name: api_service

type: STRICT_DNS
http3_protocol_options:
# envoyがサポートしている場合、BBRを明示的に指定可能（デフォルトはCUBICまたはBBR）
quic_protocol_options:
max_concurrent_streams: 100
# 初期パケットサイズやバッファサイズの調整で輻輳制御を最適化
initial_stream_window_size: 65536 # 64KB

② Python（aioquic）によるアルゴリズム明示サーバーの実装

Pythonの標準的なQUIC実装である`aioquic`を使用すると、アプリケーションコード側で直接輻輳制御アルゴリズムを選択・検証できます。

import asyncio
from aioquic.asyncio import serve
from aioquic.quic.configuration import QuicConfiguration
from aioquic.quic.connection import BBR_ALGORITHM, CUBIC_ALGORITHM

async def main():
config = QuicConfiguration(
is_client=False,
alpn_protocols=[“h3”], # HTTP/3のALPN設定
)
# 証明書の読み込み
config.load_cert_chain(“server.crt”, “server.key”)

# ★ 輻輳制御アルゴリズムの指定 (BBR または CUBIC)
# ネットワーク特性に合わせて変更してベンチマークを実施
config.congestion_control_algorithm = “bbr” # “cubic” も選択可能

print(“[INFO] QUIC Server starting with BBR Congestion Control…”)

server = await serve(
“0.0.0.0”,
443,
configuration=config,
create_protocol=lambda args, kwargs: None # 実際のハンドラプロトコルを指定
)

await asyncio.Future() # サーバーを永続実行

if __name__ == “__main__”:
# asyncio.run(main())
pass

③ QLOGとqvisを使用した「パケットとcwndの可視化」デバッグ

現場で「なぜかHTTP/3が遅い」「パケット詰まりが起きている」というトラブルが発生した際、Wiresharkだけでは暗号化されたQUICの内部状態（`cwnd`の推移など）を追うのが困難です。
そこで標準化されているログフォーマットが`QLOG`です。

`curl`（HTTP/3有効版）を叩く際に環境変数を付与することで、輻輳制御イベントのログを出力できます。

curl実行時に QLOGDIR 環境変数を指定すると、指定ディレクトリに .qlog ファイルが生成される
export QLOGDIR=”./qlog_output”
mkdir -p $QLOGDIR

HTTP/3（QUIC）を指定してリクエストを送信
curl –http3-only -v https://your-quic-server.com/api/v1/data

生成された .qlog ファイルを確認（JSON形式の構造化ログ）
ls -l $QLOGDIR
例: 8f23a9e1…qlog

生成された`.qlog`ファイルを、Webツールである [qvis (QUIC log visualizer)](https://qvis.quictools.info/) にドラッグ＆ドロップすると、下図のように`cwnd`や`bytes_in_flight`の動的な上がり下がりがグラフィカルに可視化されます。

チェックポイント1: ロスが発生した瞬間に `cwnd` が半分に落ち込んでいるか？（CUBICの特徴）
チェックポイント2: `bytes_in_flight` が `cwnd` の天井に張り付いてボトルネックになっていないか？
チェックポイント3: `ACK Delay` の値が異常に大きく算定されていないか？

—

5. シニアエンジニアからの現場Tips：運用の落とし穴

最後に、実際のプロダクション環境にHTTP/3・QUICを投入する際にハマりがちなポイントを共有しておきます。

1. UDPミドルボックス（FW/ISP）による帯域制御（UDP Throttling）

企業内ネットワークや一部の保守的なISPでは、UDP通信を「DNSやNTP、もしくはDDoS攻撃の捨てパケット」とみなして、著しい帯域制限をかけたり破棄（Drop）したりするケースがあります。

対策: クライアント側（ブラウザやアプリSDK）には、必ずTCP（HTTP/2やHTTP/1.1）への自動フォールバック機構（Alt-Svcヘッダーの正しい運用）を実装してください。QUICが詰まったら即座にTCPへ引き返す設計が鉄則です。

2. 初期ウィンドウサイズ（Initial Window）の調整

QUICの接続確立直後、最初に送信できるデータ量（`Initial Window`）はRFC 9002において通常 10 × max_datagram_size (約14KB) が推奨されています。
一般的なWeb APIのレスポンス（数KBのJSON）であれば、Slow Startを挟むことなく1往復（1-RTT）どころか0-RTTで全データ送信が完了します。小規模なAPI通信が多い場合は、輻輳制御が本格駆動する前に通信が終わるため、初期ウィンドウの設計がレスポンスタイムを大きく左右します。

3. Web API/モバイルアプリバックエンドには「BBR」を一推しする理由

ユーザーが電波の不安定な移動体（電車内や地下鉄）からアクセスするスマホアプリの場合、CUBICでは一度パケットロスが起きると復帰に時間がかかります。
APIサーバーのQUICスタック（Envoy, Nginx, Cloudflare等）でBBRを選択しておくことで、モバイル回線でのテイルレイテンシ（p99などの遅延スパイク）が大幅に改善される事例が相次いでいます。

—

まとめ

QUICの輻輳制御は、単にTCPのマネをしただけのものではありません。
「単調増加するパケット番号」や「明示的なACK Delay」といった構造的改良により、ネットワークの状態をかつてない精度でプログラミング可能な領域へと昇華させました。

インフラエンジニアやWeb APIのアーキテクトとしては、単に「HTTP/3を有効にした」で満足するのではなく、「どのような通信特性のクライアントに対して、どの輻輳制御アルゴリズム（CUBIC/BBR）を割り当てるべきか」まで踏み込んで設計すること。それこそが、これからのHTTP/3時代に求められる真のインフラエンジニアリングです。

ぜひ、皆さんの環境でも`qlog`を仕込み、パケットが駆け巡る美しい輻輳制御のグラデーションを観察してみてください。