WREDの深淵：パケットを「捨てる」という究極の輻輳制御術
ネットワークエンジニアの端くれなら、一度は「なぜ、貴重なパケットをわざわざ捨てるのか？」という問いに突き当たるはずだ。バッファが溢れる前に、あえてランダムにパケットを破棄するWRED（Weighted Random Early Detection）は、一見すると非合理的な破壊行為に見える。しかし、これはTCPという「礼儀正しい暴君」を制御するための、極めて高度な調教術なのだ。
今日は、ルータのバッファで起きている「断末魔」と、それをいかに飼いならすかという深淵の話をしよう。
—
1. テール・ドロップという名の「パニック」
WREDを理解するには、まずその対極にある「テール・ドロップ（Tail Drop）」の惨状を知る必要がある。
バッファが物理限界に達した瞬間、到着したパケットは容赦なく捨てられる。この時、同じタイミングでそのリンクを利用している多数のTCPセッションが一斉にパケットロスを検知する。すると何が起きるか。すべてのTCPフローが同時に TCP Window Size を半分に絞り込む「グローバル同期（Global Synchronization）」が発生する。
結果として、リンク使用率は急落し、その後再び各フローが一斉にウィンドウを拡大しようとしてリンクが飽和する。この「波」の繰り返しが、ネットワークのジッターを増大させ、特にTLSハンドシェイクのようなレイテンシに敏感な通信を地獄へ叩き落とす。
2. WREDの内部挙動：確率論による「平和的介入」
WREDは、このパニックを未然に防ぐ。キューの深さを監視し、閾値（Min-Threshold から Max-Threshold）の間で、確率的にパケットをドロップさせる。
重要なのは、「ランダムに」という点だ。特定のフローだけを狙い撃ちするのではなく、確率論的に間引くことで、一部のTCPフローだけを先に減速させる。これにより、グローバル同期を回避し、帯域幅を常に高密度で維持しつつ、キューの肥大化を防ぐのだ。
WREDのパラメータチューニング（Cisco IOS例）
実務において、適当な数値設定は毒にも薬にもなる。以下の設定は、一般的なデータセンターのバックボーンを想定した一例だ。
! クラスマップでトラフィックを定義
class-map match-any DATA-TRAFFIC
match dscp af11
! ポリシーマップでWREDを適用
policy-map QOS-POLICY
class DATA-TRAFFIC
bandwidth remaining percent 30
! Min: ドロップ開始、Max: ドロップ率が最大になる地点、Mark: ドロップの確率（1/x）
random-detect dscp-based
random-detect dscp af11 40 80 10
! 解説: 40パケットでドロップ開始、80パケットで最大ドロップ率、
! 10パケットに1回の確率で間引くという設定。3. トランスポート層の最適化とTLSハンドシェイクへの影響
WREDを適切に設定することは、単なるスループット向上ではない。TLS 1.3のような高速ハンドシェイクを行う現代のWebにおいて、最初の数パケットがドロップされることは致命的だ。
TCP Initial Window (IW) が拡大傾向にある現代において、バッファをパツパツに詰め込むことは、RTT（Round Trip Time）の増大を招く。WREDはキューの平均長を低く保つため、結果として Bufferbloat を抑止し、TLSハンドシェイクのRTTを安定させる効果がある。
Linuxカーネル側のチューニング（BBRの併用）
WREDと相性が良いのが、Linuxカーネルの BBR（Bottleneck Bandwidth and RTT）アルゴリズムだ。WREDでキューを制御しつつ、送信側で BBR を利用することで、パケットロスを「輻輳のシグナル」としてより正確に解釈できるようになる。
# BBRを有効にするための設定
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
# TCPバッファサイズの最適化
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"4. セキュリティとパケットドロップの相関
セキュリティ専門家が注目すべきは、WREDによるドロップが「サイドチャネル」になり得るかという点だ。非常に限定的だが、DDoS攻撃の緩和において、WREDの閾値を調整することで、攻撃トラフィックを優先的にドロップさせ、正当なトラフィックのハンドシェイクを維持するという「防御的WRED」の運用も可能である。
しかし、過度な調整は ICMP Unreachable や TCP RST を誘発し、トポロジーの露見を招くリスクもある。パケットドロップを単なる障害と捉えるのではなく、トラフィック管理の「武器」として認識すること。それが、一段上のインフラアーキテクトに求められる視点だ。
—
最後に：ネットワークは「生き物」である
WREDは魔法ではない。設定した閾値がネットワークの物理特性やトラフィックパターンと合致していなければ、ただのパケットロス製造機に成り下がる。
まずは show policy-map interface を叩き、drop カウンタが正しく機能しているかを確認せよ。その数字が、あなたのネットワークの「健康状態」を雄弁に物語っているはずだ。ネットワークは決して教科書通りには動かない。パケットの行方を見守り、泥臭くチューニングを繰り返したその先にだけ、真の最適化が待っている。
コメント