Wi-Fiの「見えない敵」を撃ち落とせ：隠れ端末問題とRTS/CTSの深淵なる最適化
Wi-Fi 7（IEEE 802.11be）の登場により、マルチリンクオペレーション（MLO）や320MHz幅の広帯域が叫ばれる昨今ですが、物理層の根本的な課題は今も昔も変わりません。それは「隠れ端末問題（Hidden Node Problem）」です。
インフラエンジニアとして現場に立つと、理論上のスループットと実測値の乖離に頭を抱えることが多々あります。その原因の多くは、無線媒体の共有という特性上、互いの存在を認識できない端末同士が同時にフレームを射出し、空中線上でパケットの衝突（コリジョン）を誘発していることにあります。今回は、この古典的かつ現代でも無視できない課題に対し、RTS/CTSハンドシェイクを軸としたプロトコルレベルのチューニングと、その先にあるトランスポート層の最適化について掘り下げます。
—
物理層の悲劇：なぜRTS/CTSが必要なのか
キャリアセンス（CSMA/CA）は、送信前に無線媒体が空いているかを確認しますが、物理的障害物や距離によって端末Aが端末Bの送信を検知できない場合、これらは無力です。衝突したパケットはAP（アクセスポイント）側でCRCエラーとなり、結果として再送制御（Retry）が走り、スループットは指数関数的に減衰します。
ここで登場するのが RTS (Request to Send) と CTS (Clear to Send) です。
1. 送信側が RTS フレームを送信。
2. APがそれを受信し、周囲全体に向けて CTS をブロードキャスト。
3. この CTS を傍受した「隠れ端末」は、一定期間の媒体予約（NAV: Network Allocation Vector）を認識し、送信を控える。
このハンドシェイクはオーバーヘッドを生みますが、高密度環境や障害物の多いオフィス・工場フロアでは、衝突による再送コストよりも遥かに低コストな「安定剤」となります。
RTS/CTSしきい値のチューニング（Linux/hostapd）
現代のAPでは、フレームサイズに応じてRTS/CTSを動的に適用するのが定石です。hostapd を利用したLinuxベースのAP構築では、rts_threshold を適切に設定することで、オーバーヘッドと衝突回避のバランスを制御します。
# /etc/hostapd/hostapd.conf
# RTS/CTSを有効化するための設定例
# 2347は最大値（RTSを使わない）、低く設定するほど厳しい制御が行われる
rts_threshold=2347
# 混雑した環境では、フラグメンテーションしきい値と併用して調整を行う
# 物理層の安定性が著しく低い場合は、1000〜1500程度まで下げて検証する
fragm_threshold=2346—
TCPスタックとRTT削減：無線環境の「泥臭い」チューニング
隠れ端末問題が完全に解決できない環境下では、再送によるRTT（Round Trip Time）の跳ね上がりが避けられません。ここで、トランスポート層、特にTCPの挙動を無線特有の仕様に合わせて最適化します。
1. BBR混雑制御アルゴリズムの採用
従来の CUBIC はパケットロスを混雑の兆候と捉えますが、Wi-Fiの再送による一時的な遅延を誤認してウィンドウサイズを過剰に絞り込みます。Googleが開発した BBR (Bottleneck Bandwidth and Round-trip propagation time) は、ロスではなく伝送帯域とRTTに基づいて制御を行うため、Wi-Fi環境との親和性が極めて高いです。
# カーネルパラメータでBBRを有効化する
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
# 設定を永続化する場合
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf2. TLSハンドシェイクの最適化（TLS 1.3）
無線環境ではハンドシェイクの往復回数（RTT）が致命的です。TLS 1.3への移行は必須ですが、さらに 0-RTT (Zero Round Trip Time Resumption) を活用することで、セッション再開時のオーバーヘッドを排除できます。ただし、リプレイ攻撃のリスクには注意が必要です。
—
ネットワーク脆弱性とパケットヘッダーの保護
隠れ端末問題の解決は、単なるスループット向上だけでなく、セキュリティにも直結します。通信が衝突して再送が繰り返される隙を突いた中間者攻撃や、管理フレームの偽装によるDoS攻撃のリスクが高まるからです。
特に、802.11w (Protected Management Frames) の強制は、現代のインフラ構築における必須要件です。管理フレームを暗号化することで、悪意のある攻撃者がRTS/CTSのNAVを操作して通信を妨害するような挙動を防御します。
セキュリティ強化のための設定例（hostapd）
# 管理フレームの保護を有効化（必須）
ieee80211w=2
# WPA3-SAEの採用（OWEと併用）
wpa_key_mgmt=SAE
rsn_pairwise=CCMP GCMP—
結論：現場のプロとして
Wi-Fiの最適化に「魔法のボタン」は存在しません。隠れ端末問題に対するRTS/CTSの設定、BBRによるTCP制御、そしてWPA3による堅牢なフレーム保護。これらを一つひとつ、現場の電波環境（スペクトラムアナライザの波形や、iw コマンドによるパケットロス率の観測）を見ながら積み上げていく。
その泥臭い作業こそが、インフラアーキテクトとしての真価を問われる瞬間です。教科書的な設定に依存せず、自身のネットワークの「声」を聞き、パケットの流れを可視化すること。それが、次世代の高速無線通信を使いこなす唯一の道です。
コメント