QUICとCUBICの深層：次世代トランスポート層でパケットロスとどう向き合うか
こんにちは。夜な夜なパケットキャプチャを開き、Wiresharkのタイムスタンプの揺らぎに一喜一憂しているシニアネットワークエンジニアの私です。
Web APIのレイテンシ削減、あるいはモバイル回線環境における接続断の抑制を狙って、HTTP/3（QUIC）の導入を進めている現場も多いことでしょう。「TCPのHead-of-Lineブロッキングを解消した」「UDPベースだからハンドシェイクが速い」といった華やかなメリットの裏側で、私たちインフラエンジニアやバックエンドエンジニアが絶対に避けて通れないのが、「輻輳制御（Congestion Control）」の泥臭い現実です。
QUICはUDPの上で動くトランスポートプロトコルですが、その信頼性と輻輳制御の多くは、長年インターネットを支えてきたTCPの知見を受け継いでいます。特に標準的なQUIC実装（GoogleのChromiumやLinuxの`quiche`など）でデフォルト採用されることの多い「CUBIC（キュービック）」アルゴリズムは、現代の高速・大帯域ネットワークにおけるデファクトスタンダードです。
今回は、このQUIC上のCUBICがパケットロス発生時にどのような数学的挙動を示し、私たちのWeb APIやインフラにどう影響するのか。実務の現場で役立つチューニングの勘所と共にお届けします。
—
1. なぜQUICでもCUBICなのか？ TCPから引き継がれる輻輳制御のDNA
インターネットは「ベストエフォート」の集合体です。ルーターのバッファ溢れによるパケットロスは不可避であり、それを検知して送信レートを絞るのが輻輳制御の役割です。
古くから使われてきたTCPの「Reno」アルゴリズムは、線形（リニア）にウィンドウサイズを増加させるため、帯域が太く遅延（RTT）が大きい回線（いわゆるBDP：Bandwidth-Delay Productが大きい環境）では、真の回線容量に到達するまでに途方もない時間がかかるという致命的な弱点がありました。
これを解決するために生まれたのがCUBICです。CUBICは、ウィンドウサイズの増加を時間（$t$）の三次関数（Cubic function）で行います。
CUBICのウィンドウサイズ制御の哲学
CUBICの最大の特徴は、「パケットロスが発生した直前のウィンドウサイズ（$W_{max}$）を基準にし、そこから遠いときはアグレッシブに、近づくにつれて緩やかにウィンドウを増やす」という非線形なアプローチにあります。
- ロス直後の大幅な縮小: パケットロスを検知すると、ウィンドウサイズを一定割合（通常は30%、ベータ係数 $\beta = 0.7$）縮小します。
- プラトー（平坦な領域）の形成: $W_{max}$ に近づくにつれて増加曲線が「平坦」になり、リンクの限界速度（ボトルネック）の手前で慎重に探索を行います。
- 変曲点以降の爆発的増加: $W_{max}$ を超えた後は、再びアグレッシブにウィンドウを拡大し、他のフローに奪われた帯域を奪還しに行きます。
この特性により、CUBICは「帯域が太く、遅延が大きいグローバルな通信（大陸間通信など）」において、回線を飽和させずに最大限のスループットを引き出すことが可能なのです。
—
2. パケットロス発生時のQUIC/CUBIC通信フロー
TCPと異なり、QUICではパケットロスが起きても、それが「どのストリームのものか」で全体のブロックが起きません。しかし、トランスポート層全体としての輻輳ウィンドウ（Cwnd）は縮小されます。
以下に、QUIC（CUBIC）がパケットロスを検知して復帰するまでのパケットのやり取りと内部状態の変化をシーケンスとして示します。
[Client / QUIC] [Server / QUIC (CUBIC)]
| |
|— [Packet #101 (Data)] —————————->| (正常受信)
|— [Packet #102 (Data)] – – – – X (途中でロスト) —>|
|— [Packet #103 (Data)] —————————->| (Out-of-Order受信)
| |
| (ACK返送) |
|<-- [ACK (Ack_Delay, Largest_Ack=103)] ---------------|
| |
| ※ Packet #102 の欠損を検知 (Loss Detection / PTO) |
| |
|--- [Packet #104 (Retransmit of #102)] -------------->|
| |
| === CUBIC 輻輳制御の内部演算 === |
| 1. W_max = 現在のCwnd |
| 2. Cwnd = Cwnd 0.7 (ベータ乗算で縮小) |
| 3. 立方根の関数に基づき復帰曲線の計算開始 |
| |
|— [Packet #105 (New Data, 縮小されたCwnd内)] ——->|
QUICの優れた点は、ACKフレームに `Ack Delay`（受け取ってから返すまでの遅延時間）が明示的に含まれているため、正確な往復遅延時間（RTT）の測定が可能な点です。これにより、CUBICの関数計算の精度がTCP時代よりも飛躍的に向上しています。
—
3. 実務で知るべき主要パラメーターとチューニング
インフラエンジニアとしてNginxやEnvoy、あるいはGo/Rustで書かれたQUICサーバー（`quiche`や`quic-go`など）を運用する際、以下のパラメーターを意識することがパフォーマンス最適化の鍵となります。
① 初期輻輳ウィンドウ（Initial Congestion Window: IW）
- 意味: コネクション確立直後に、スロースタートで送信できるパケット数（通常は10セグメント分、QUICのRFC 9000系では最大10〜32パケット程度が推奨されることが多い）。
- 現場のTips: クラウドのロードバランサーやCDNのエッジサーバー設定で、このIWが小さすぎると、初回のAPIリクエスト（ペロードが小さい場合でも）の往復回数が増え、TTFB（Time to First Byte）が劣化します。
② ベータ係数（CUBIC Beta）
- 意味: ロス時のウィンドウ縮小率（デフォルトは `0.7`）。
- 現場のTips: 衛星回線や極端にロス率の高いモバイル網では、`0.7`では縮小しすぎてスループットが出ない場合があります。逆に、バッファローターが密集するオンプレミス環境では、アグレッシブすぎるとバッファブルートを引き起こすため、デフォルト値からの変更は慎重に行うべきです。
—
4. 実装・検証コード例：QUIC/HTTP/3通信のデバッグと確認
現代の開発現場では、アプリケーションコードから直接QUICの輻輳制御アルゴリズムを弄ることは稀ですが、HTTP/3対応クライアントを用いてその挙動を確認したり、サーバー側の設定を行うことは日常茶飯事です。
以下に、HTTP/3（QUIC）をサポートしたツールやコードの具体例を示します。
A. `curl` を使ったHTTP/3（QUIC）の強制接続とレスポンス確認
実務でAPIサーバーが正しくHTTP/3（QUIC）で応答しているか、またCUBIC等の輻輳制御下でどのようにハンドシェイクが行われているかをCLIで検証します（要HTTP/3対応のBoringSSL等でビルドされたcurl）。
–http3 を指定して強制的にQUIC経由でリクエストを送信する
-v (verbose) をつけることで、Alt-SvcヘッダーやHTTP/3交渉のログが詳細に出力されます
curl -iv –http3 https://api.example.com/v1/health
出力ログのイメージ（一部抜粋）:
Connected to api.example.com (203.0.113.50) port 443 (#0)
Using HTTP/3, the HTTP/2 successor
Connected via QUIC (version 1, cipher TLS_AES_128_GCM_SHA256)
B. Python（`aioquic`）を用いたQUICクライアントの概念実装
バックエンド間の通信や独自のテストツール作成でよく使われるPythonの`aioquic`ライブラリを用いた、QUIC接続の骨組みです。トランスポート層の挙動（CUBICを含む輻輳制御）は通常ライブラリやOSカーネル層（あるいはquiche等のユーザーランドスタック）に委譲されますが、接続設定を行う際のイメージを掴んでください。
import asyncio
from aioquic.asyncio import connect
from aioquic.h3.client import H3_CLIENT_PROTOCOL
from aioquic.h3.connection import H3Connection
from aioquic.quic.configuration import QuicConfiguration
async def test_quic_api_call():
# QUICクライアントの設定を初期化
configuration = QuicConfiguration(is_client=True)
# サーバー証明書の検証をスキップする場合（開発・検証環境用）
configuration.verify_mode = False
# サーバーのエンドポイントへQUIC接続を確立
# （内部的にUDPソケットが開き、CUBICによるスロースタートが始まります）
async with connect(
“api.example.com”,
443,
configuration=configuration,
create_protocol=H3_CLIENT_PROTOCOL
) as client:
# HTTP/3クライアントとしての通信プロトコルインスタンスを取得
h3_conn: H3Connection = client._h3_connection
# リクエストの送信（GETメソッド）
stream_id = h3_conn.send_headers(
stream_id=client.get_next_available_stream_id(),
headers=[
(b”:method”, b”GET”),
(b”:path”, b”/v1/metrics”),
(b”:authority”, b”api.example.com”),
(b”:scheme”, b”https”),
],
)
h3_conn.send_data(stream_id=stream_id, data=b””, end_stream=True)
print(f”QUIC Stream #{stream_id} でリクエストを送信しました。”)
イベントループの実行
if __name__ == “__main__”:
asyncio.run(test_quic_api_call())
—
5. シニアが教える！QUIC/CUBIC運用のトラブルシューティングTips
最後に、現場で実際にハマりがちなポイントと、その切り分け手法を共有します。
1. 「UDPブロック」によるフォールバックの罠
- 企業のプロキシや古いファイアウォール（FW）では、UDPの443番ポートが塞がれていることがあります。QUICはUDPベースであるため、これがブロックされると、接続は自動的にTCP（HTTP/2）へとフォールバックします。
- デバッグ手法: ブラウザの開発者ツールや`curl -iv`で、`alt-svc`ヘッダーが正しく返ってきているか、実際にUDPパケットが流れている（Wireshark等でUDP/53以外の443へのトラフィックがある）かを確認してください。
2. バッファブロート（Bufferbloat）とCUBICの衝突
- CUBICは回線帯域を限界まで使い切ろうとする性質があるため、中間ルーターのキューが大きすぎる環境（安価なルーターや一部のクラウドインフラ）では、RTTが異常に跳ね上がります。
- 対策: サーバー側のLinuxカーネルパラメータ（`net.core.rmem_max`や輻輳制御アルゴリズムの選択）を見直し、必要に応じてBBR（Bottleneck Bandwidth and Round-trip propagation time）などのロスベースではなくモデルベースの輻輳制御との比較検証を行ってください。
—
まとめ
QUICのCUBICは、長年TCPで培われてきた信頼性の高いアルゴリズムをベースにしつつ、QUICの正確なRTT計測やストリーム独立性と結びつくことで、より洗練された帯域活用を実現しています。
「なぜかモバイル環境でAPIの応答がもたつく」「パケットロス率がわずかなのにスループットが出ない」といった壁にぶぶつかったときは、ぜひ今回のCUBICの数学的特性や輻輳ウィンドウの縮小・復帰メカニズムを思い出してください。パケットの挙動を解像度高くイメージできるようになれば、ネットワークのトラブルシューティングはぐっと面白くなります。
それでは、次のパケット解析の旅でお会いしましょう。
コメント