Wi-Fiの「見えざる衝突」を制する：隠れ端末問題とRTS/CTSの深層最適化
現代のWi-Fi環境において、スループットの低下や突然のパケットロスに頭を抱えるエンジニアは多いはずだ。Wi-Fi 7の登場により Multi-Link Operation (MLO) や 320MHz 幅の広帯域が喧伝されているが、物理的な電波の特性――すなわち「隠れ端末問題（Hidden Node Problem）」は、どれほど規格が進化したとしても、依然として避けられないインフラの「急所」である。
今回は、この古典的かつ現代的な課題に対し、RTS/CTSメカニズムの挙動をパケットレベルで解剖し、極限環境での最適化手法を紐解いていく。
—
隠れ端末問題がもたらす「負の連鎖」
隠れ端末問題とは、アクセスポイント（AP）からは双方の端末（STA AとSTA B）が見えているが、端末同士は物理的な距離や障害物によって互いの送信信号を検知できない状況を指す。
このとき、STA AとSTA Bが同時に CSMA/CA を経てフレームを送出すると、AP側でデータフレームのコリジョン（衝突）が発生する。APは ACK を返せず、送信元は「伝送路が混雑している」と判断して Contention Window (CW) を指数関数的に増大させる。結果として、TCPの Slow Start がリセットされ、RTT は跳ね上がり、スループットは崩壊する。これが、オフィスや高密度環境で「電波強度はあるのになぜか遅い」という事象の正体だ。
—
RTS/CTSが引き起こすオーバーヘッドと閾値の妙
この衝突を回避するために用意されたのが RTS (Request to Send) と CTS (Clear to Send) だ。
1. RTS: 送信元が「データを送るための予約」をAPに送る。
2. CTS: APが「周囲の端末に対して、一定時間黙るように」という指令をブロードキャストする。
この仕組みは衝突回避には極めて有効だが、すべてのフレームに対して適用すれば、RTS/CTS 制御フレーム分のオーバーヘッドが通信帯域を食いつぶす。ここで重要になるのが RTS Threshold（RTS閾値）のチューニングだ。
RTS Thresholdの最適解を導く
デフォルトでは 2347 bytes に設定されていることが多いが、これは実質的に「RTS/CTSを無効化する」のと同じ意味を持つ。
高密度なIoT環境や、パケットロスが致命的な TLS ハンドシェイクを行うサーバ間通信では、この値を意図的に下げる必要がある。例えば、MTUサイズの境界や、主要なペイロードサイズに合わせて調整を行う。
# Linuxの無線インターフェースでRTS閾値を設定する例
# 1500バイト以上のフレームに対してRTS/CTSを強制する
sudo iw dev wlan0 set rtsthreshold 1500
# 設定を確認する
iw dev wlan0 get rtsthreshold—
TLSハンドシェイクとTCPバッファの相関
隠れ端末問題が引き起こすパケットロスは、TLS ハンドシェイクにおいて特に悪影響を及ぼす。Client Hello や Server Hello の断片が消失すれば、TCP Retransmission が発生し、TLSの Cipher Suite ネゴシエーションがタイムアウトするリスクが高まる。
これを緩和するためには、単にWi-Fi側を調整するだけでなく、OS側のTCPスタックのチューニングも必須だ。
# TCPの初期輻輳ウィンドウ（initcwnd）を拡大し、ハンドシェイクを高速化する
# ip route add コマンドでデフォルトゲートウェイに対して適用
sudo ip route change default via 192.168.1.1 dev eth0 initcwnd 10また、Header Compression（特に ROHC や TCP/IP Header Compression）を有効にすることで、RTS/CTS の制御下でのペイロード効率を最大化できる。AP側のファームウェアが Airtime Fairness をサポートしている場合、低速なレガシー端末がチャネルを占有しないよう、明示的にポリシングを行うべきだ。
—
実務的なトラブルシューティングの勘所
現場で「何が起きているか」を正確に把握するには、Wireshark を用いたモニターモードでのパケットキャプチャが不可欠だ。
- チェックポイント1:
Retryビットが立っているフレームの割合を観察せよ。これが10%を超えるようなら、隠れ端末による衝突か、干渉源の存在が濃厚だ。 - チェックポイント2:
NAV (Network Allocation Vector)の値を注視せよ。CTSフレームによって設定されるNAVが適切に機能しているか、送信元端末がそれを尊重しているかを確認する。
もし特定の高負荷なIoTデバイスがボトルネックになっている場合、AP側で Minimum Data Rate を引き上げ、低速な MCS index を使用するデバイスを強制的に切り離すのが、ネットワーク全体の健全性を守るための「泥臭い、しかし正攻法」な解決策となる。
—
結びに代えて：プロトコルと物理層の狭間で
Wi-Fi 7がもたらす Puncturing（干渉部分を避けて帯域を使う技術）は、物理層レベルでの隠れ端末問題解決に一石を投じるだろう。しかし、それでもなお、ネットワークインフラを設計する我々に求められるのは、パケットが物理層の制約をどう乗り越え、TCP層でどう解釈されるかという「全体俯瞰の視点」だ。
設定値は常に現場の環境に従属する。教科書通りの数値を鵜呑みにせず、モニターモードのキャプチャデータこそが、貴方が直面するネットワークの唯一の正解であることを忘れないでほしい。
さて、次にトラブルシュートに向かうのは、貴方の環境だろうか。パケットは嘘をつかない。それを読み解く力こそが、真のインフラアーキテクトの武器となる。
コメント