帯域の調停者たち：Strict PriorityとWFQが織りなすQoSの深淵とパケットスケジューリングの極意
ネットワークの現場において、「なぜか高負荷時に特定のAPIレスポンスだけが跳ね上がる」「TLSハンドシェイクのレイテンシが不規則に揺らぐ」といった不可解な現象に直面したことはないだろうか。L2/L3スイッチやルーターのCPUやASICは、10Gbps、あるいは100Gbpsという圧倒的な物量で流れてくるイーサネットフレームを、毎秒ナノ秒単位の精度でさばき続けている。
物理ポートの帯域が限界に達した瞬間、そこに出現するのが「輻輳（Congestion）」という名の物理的制約だ。この限界領域において、どのパケットを先に送り出し、どのパケットを一時的なバッファの奥底へ追いやるかを決定するのがキューイングアルゴリズム（Queueing Algorithm）である。
今回は、ネットワークインフラの心臓部であるスイッチの出力ポートに焦点を当て、厳格優先キューイング（Strict Priority Queuing: SPQ）と重み付きフェアキューイング（Weighted Fair Queuing: WFQ）の内部挙動を、パケットレベルの視点から徹底的に解剖する。単なる教科書的な定義の解説ではない。TLSハンドシェイクの最適化、TCPウィンドウ制御、そして現場のアーキテクトが知るべき実践的なチューニングの極意まで、深く潜っていこう。
—
1. 出力ポートの現実：パケットがバッファで直面する物理的真実
スイッチの内部アーキテクチャにおいて、パケットは入力ポートからクロスバススイッチを経由し、最終的に出力ポートのメモリー（出力キュー）にエンキューされる。このとき、単一のFIFO（First-In, First-Out）キューだけでは、現代の多様なトラフィックをハンドリングすることは不可能だ。
音声通話（VoIP）のRTPパケット、データベースの同期トランザクション、大規模なバックアップファイル転送、そしてHTTPSの暗号化ストリームが、同じ優先度でFIFOの列に並んだとする。大容量バックアップが帯域を食い潰した瞬間、背後につかされたVoIPのパケットは深刻なジッタ（Jitter）とパケットロスに見舞われ、音声は完全に破綻する。
これを防ぐために、ハードウェア（ASIC/NP）レベルで複数のキュー（通常は4〜8個）が用意され、それらをどのようなポリシーでディスパッチ（デキュー）するかを定義するのがスケジューラである。
—
2. 厳格優先キューイング（SPQ）の冷徹さと諸刃の剣
パケットレベルの内部挙動
Strict Priority Queuing（SPQ）は、その名の通り「最も優先度の高いキューにパケットが存在する限り、他の低優先度キューのパケットは1ビットたりとも送出しない」という極めて硬派なアルゴリズムだ。
ハードウェア的には、優先度の高いキュー（例: Queue 7）のポインタを常に監視し、空でない場合は最優先でラインレートの送出処理を行う。
[ Queue 7 (Voice) ] ───(最優先)───┐
[ Queue 6 (Critical) ] ──────────┼───> [ 物理ポート (Line Rate) ]
[ Queue 2 (Best Effort) ] ───────┘ (Q7が空くのを待つ)この挙動は、リアルタイム性を要求されるトラフィックに対して絶対的な低遅延（Low Latency）を保証する。
TLSハンドシェイクとRTT削減への寄与
現代のWebインフラストラクチャにおいて、クライアントとサーバー間のセッション確立にはTCPの3ウェイハンドシェイクに加え、TLS 1.3であれば1-RTT（場合によっては0-RTT）の暗号化ネゴシエーションが伴う。
もし、このクリティカルなTLSハンドシェイクパケット（Client HelloやServer Hello）が、大容量のHTTPレスポンスやオブジェクトストレージのフェッチによってバッファ溢れを起こしていたらどうなるか。RTT（Round Trip Time）は跳ね上がり、最初のバイトが描画されるまでの時間（TTFB）が致命的に悪化する。
SPQを用いてコントロールプレーンやシグナリングトラフィック（HTTPSのハンドシェイクやBGP、SNMP等）を最高位のキューに割り当てることで、輻輳時においてもハンドシェイクの遅延を最小限に抑え、体感パフォーマンスを劇的に改善できる。
SPQの致命的な罠：スタベーション（飢餓状態）
しかし、SPQには設計者を破滅に導く重大なリスクがある。もし最高優先度のキューに、無限にパケットを流し続ける暴走プロセスやDDoS攻撃、あるいは巨大なストリーミングデータが流れ込んだ場合、それより下位のキュー（Queue 0〜Queue 6）のパケットは永久にデキューされない（Starvation / 飢餓状態）。
そのため、実運用においては、SPQを適用するキューに対して必ずポリシング（Policing）や帯域制限（Rate Limiting）をかけ、高優先度トラフィックの最大量を物理帯域の一部に制限することが鉄則となる。
—
3. 重み付きフェアキューイング（WFQ）の優美な調停
公平性と帯域保障の数学的アプローチ
SPQの「強者生存」の哲学に対し、Weighted Fair Queuing（WFQ）は「各セッションやクラスに対するリソースの公平な分配」を目的として設計された。
WFQは、トラフィックを複数のフローやクラスに分類し、それぞれに「重み（Weight）」を割り当てる。ビット単位の公平な処理（Bit-by-Bit Fair Queuing）をパケット単位で近似するために、各パケットの仮想的な終了時刻（Virtual Finish Time）を算出し、その値が最も小さうパケットから順に送出していく。
数式的な厳密さはさておき、その実動作のイメージはこうだ。
- クラスA（重要DB）に重み
10 - クラスB（一般Web）に重み
5 - クラスC（ベストエフォート）に重み
1
物理回線が完全に輻輳した状態であっても、WFQはそれぞれの重みに比例した帯域を確実に保証しつつ、特定のフローがすべての帯域を占有することを防ぐ。
TCPバッファチューニングとWFQのシナジー
LinuxカーネルのTCPスタック（CUBICやBBRなど）は、パケットロスを検知するか、あるいはACKの返却遅延（RTTの増大）を検知して輻輳ウィンドウ（cwnd）をダイナミックに調整する。
もしスイッチのバッファ管理が粗雑なFIFOや単純なドロップテール（Drop-Tail）であると、バッファが溢れた瞬間に大量のTCPパケットが同時にドロップし、複数のTCPセッションが同時にタイムアウトしてグローバル・シクロニ支援（Global Synchronization）を引き起こす。結果としてリンクの使用率が急低下し、回復に時間がかかる。
WFQ（あるいはその進化系であるCBWFQやWREDの組み合わせ）は、キューごとに適切なバッファしきい値を持ち、公平にパケットを管理するため、TCPのフロー制御アルゴリズムと極めて相性が良い。各TCPセッションが自律的に帯域をシェアし、バッファ溢れによる致命的な再送嵐を未然に防ぐことができる。
—
4. 実践：Cisco IOS-XE / Linuxにおけるキューイングポリシーの実装例
理論を理解したところで、実際のネットワーク機器やLinuxサーバー環境における設定のアプローチを見てみよう。ここでは、Cisco Catalyst/Nexusスイッチを想定したMQC（Modular QoS CLI）によるSPQとWFQ（CBWFQ）のハイブリッド構成を例示する。
実装シナリオ
1. 音声・シグナリング: SPQを使用し、絶対的な低遅延を確保（帯域制限付き）
2. クリティカルDBトラフィック: WFQ（CBWFQ）を用いて帯域の50%を保証
3. 一般ベストエフォート: 残りの帯域を分配
! --- 1. トラフィックの分類 (Access Control Lists & Class Maps) ---
ip access-list extended ACL_VOICE
permit udp any any range 16384 32783 ! RTP音声ストリームのポート範囲
ip access-list extended ACL_DB
permit tcp any host 192.168.100.10 eq 1521 ! Oracle DB等へのアクセス
class-map match-any CM_VOICE
match access-group name ACL_VOICE
class-map match-any CM_DB
match access-group name ACL_DB
! --- 2. ポリシーマップの定義 (Policy Map) ---
policy-map QOS_EGRESS_POLICY
class CM_VOICE
! 音声には厳格優先(SPQ)を適用し、暴走を防ぐため最大帯域を20Mbpsに制限
priority level 1 20000
class CM_DB
! 重要DBトラフィックには帯域の50%を帯域保証（WFQベースのCBWFQ）
bandwidth percent 50
class class-default
! 残りはベストエフォートとして公平に処理
fair-queue
! --- 3. 物理インターフェースへの適用 ---
interface GigabitEthernet0/0/1
description === Uplink to Core Switch ===
service-policy output QOS_EGRESS_POLICYLinuxカーネル（tc コマンド）での同等制御
Linuxルーターやホストの egress（送信）側で同様の制御を行いたい場合は、Traffic Control（tc）とHTB（Hierarchical Token Bucket）/SFQ（Stochastic Fairness Queueing）を組み合わせる。
#!/bin/bash
# 物理インターフェース eth0 のルートQdiscをHTBに設定
tc qdisc add dev eth0 root handle 1: htb default 30
# 親クラスの設定（回線速度 1Gbps）
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit ceil 1000mbit
# 1. 優先キュー用クラス（音声など、最大100Mbps）
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50mbit ceil 100mbit prio 1
# 2. データベース用クラス（帯域保証 400Mbps）
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 400mbit ceil 1000mbit prio 2
# 3. ベストエフォート用クラス
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 550mbit ceil 1000mbit prio 3
# ベストエフォートクラス配下にSFQ（WFQのLinux実装に近いフェアキューイング）を適用
tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
# フィルター設定（DSCP値やポート番号に基づく分類）
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 5060 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dport 1521 0xffff flowid 1:20このLinuxの設定例では、prio 1 のクラスに対してトークンバケットベースの優先制御を行いつつ、ベストエフォートトラフィックに対しては sfq（Stochastic Fairness Queueing）を適用することで、特定セッションによる帯域の独占を防いでいる。
—
5. セキュリティとパフォーマンスの交差点：DDoSとQoSの罠
インフラアーキテクトがしばしば見落とす重大なセキュリティリスクに、「QoS設定の不備を突いたDDoS攻撃」がある。
前述のSPQにおいて、もし「高優先度キュー（VoIPやシグナリング）」へのアクセス認証やIPアドレス制限、あるいはポリシングが適切に実装されていない場合、攻撃者はその高優先度キューを標的にしてジャンクパケットを送り込むことができる。
スイッチのASICは設定に忠実に従い、攻撃パケットを最優先（Strict）で処理し続けるため、重要な管理トラフィックや暗号化ハンドシェイクを含めたすべての正常なトラフィックが完全に排除（Starvation）される。QoSのために施した設定そのものが、アタッカーにとっての「自社網を麻痺させるための特急レーン」に変貌してしまうのだ。
対策の鉄則
1. 厳格なポリシング（Policing / Rate Limiting）の常時有効化: SPQを適用するキューには必ず上限値を設定し、それを超えたトラフィックは即座にドロップまたは低優先度キューへ降格（Remarking）させる。
2. コントロールプレーン保護（CoPP / CPPr）: スイッチ自身のCPU宛てのパケットを処理するコントロールプレーンにおいても同様のキューイングとレートリミットをかけ、コントロールプレーンの枯渇を防ぐ。
—
結びにかえて：トレードオフをデザインする知性
Strict Priority Queuingは「速さの極限」を追求する冷徹な孤高のランナーであり、Weighted Fair Queuingは「秩序と調和」を重んじる洗練された調停者である。
どちらか一方だけを盲信すれば、一方はシステムの脆弱性を生み、もう一方はリアルタイム性の欠如を招く。現代のハイパフォーマンスネットワークの設計とは、この二つのアルゴリズムの特性を深く見極め、アプリケーションの特性（TLSハンドシェイクのレイテンシ、DBのスループット、音声のジッタ耐性）に合わせて適切なキューへパケットを誘導する、極めて知的で泥臭いエンジニアリングの営みに他ならない。
パケットがスイッチのASICを通過するその数マイクロ秒の挙動に思いを馳せ、あなたのネットワークアーキテクチャを今一度見つめ直してほしい。
コメント