Wi-Fi 7時代の「見えない律速」を解く：RTS/CTSとBlockACKが支配するパケットの深淵
Wi-Fi 7（IEEE 802.11be）が登場し、Multi-Link Operation（MLO）が夢のようなスループットを語る今、我々エンジニアが改めて直視すべきは、無線空間という「共有メディア」の残酷な現実だ。
どれだけ物理層（PHY）が進化しても、CSMA/CAという歴史的遺産から逃れることはできない。特に高密度環境における「隠れ端末問題」と、その解決策である RTS/CTS ハンドシェイク、そして高効率転送を支える BlockACK の挙動を理解せずに、ハイエンドなネットワーク設計は不可能だ。
今回は、パケットレベルの挙動からLinuxカーネルのチューニングまで、無線インフラの極致を探求する。
—
1. 無線の「空気を読む」制御フレームの真相
無線LANにおいて、パケットは常に「衝突」のリスクと隣り合わせだ。隠れ端末問題、すなわちアクセスポイント（AP）を介して互いに見えない2台のクライアントが同時に送信を開始すれば、空間上で信号は衝突し、フレームは塵と化す。
RTS/CTSハンドシェイクの再評価
RTS (Request to Send) と CTS (Clear to Send) は、現代の爆速Wi-Fiにおいても極めて重要な「物理的沈黙」を強制する仕組みだ。
- RTS (Frame Control: 0x0B): 送信元が「送信の予約」を周囲に通知。
- CTS (Frame Control: 0x0C): APが「送信許可」をブロードキャストし、周囲の端末に
NAV(Network Allocation Vector) を設定させる。
このハンドシェイクは、オーバーヘッドゆえに「悪」とされがちだが、パケットサイズが大きく、かつ遅延の許容範囲が狭いリアルタイム通信においては、再送コストを支払うより遥かに安上がりな保険となる。
2. BlockACK：ストリームの飽和を防ぐ「約束事」
802.11n以降、Wi-Fiの効率を劇的に向上させたのが BlockACK (Block Acknowledgment) だ。フレームごとに ACK を待つ非効率な往復を排除し、最大64フレーム（802.11ax/beではさらに拡張）を連続送出し、最後にまとめて成否を確認する。
この仕組みは、TCPの Window Size と相性が良い。もし BlockACK のウィンドウサイズを適切に設定していない場合、TCPの Slow Start が完了する前にバッファが溢れ、スループットが頭打ちになる。
LinuxカーネルでのTCPバッファチューニング
Wi-Fiの特性を活かし、RTTを最小化しつつパイプラインを維持するための sysctl 設定例を記す。
# TCPウィンドウサイズの拡大と自動チューニングの最適化
# 高速かつ安定したWi-Fi環境では、バッファを広めにとるのが定石
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 送信キューの長さを調整（Wi-Fi特有のバッファブリートを抑制）
# 物理層の再送待ちでキューが溜まるのを防ぐ
net.core.netdev_max_backlog = 5000—
3. 脆弱性とパフォーマンスのトレードオフ
セキュリティの観点から見ると、制御フレームは格好の攻撃対象だ。特に CTS フレームの偽装（Spoofing）により NAV タイマーを不正に延長すれば、当該チャネルを物理的に麻痺させる「無線DoS攻撃」が可能となる。
脆弱性回避のためのインフラ設計
1. Management Frame Protection (802.11w): 制御フレームを暗号化・認証することで、偽造された Deauthentication や CTS による介入を防ぐ。これはWPA3環境下では必須設定だ。
2. TLSハンドシェイクの最適化:
TLS 1.3 を導入し、RTTを削減する。0-RTT (Zero Round Trip Time) を活用すれば、クライアントは接続確立の最初のパケットでアプリケーションデータを送信できる。Wi-Fiの不安定なハンドシェイク時間を考慮すると、この1RTTの短縮がUXに与える影響は計り知れない。
—
4. 現場で使える「泥臭い」デバッグの心得
仕様書を追うだけでは見えない挙動を可視化するには、tcpdump を使った無線モニタリングが不可欠だ。
# モニタモードのインターフェースで制御フレームをキャプチャする
# -s 0: 全パケットを取得
# -i mon0: モニタモード設定済みの無線IF
# -e: MACヘッダーを表示（BlockACKやRTS/CTSのシーケンスを確認）
sudo tcpdump -i mon0 -s 0 -e type mgt or type ctlこのコマンドから流れてくる BlockACK Request のシーケンス番号を確認すれば、どの段階でフレームが消失しているか（環境要因の物理層エラーか、APの処理能力不足か）を推測できる。
最後に：ネットワークを「理解」するということ
Wi-Fi 7が提供する320MHz帯域やMLOといった強力な武器も、下位プロトコルの挙動を理解しなければただの「宝の持ち腐れ」だ。
RTS/CTSのオーバーヘッドを恐れず、BlockACKのバッファ管理を突き詰め、TLSのハンドシェイクを極限まで削ぎ落とす。この「パケットに寄り添う」姿勢こそが、最高レベルのインフラアーキテクトに求められる美学であると私は信じている。
技術は常に進化する。しかし、パケットが行き交うその瞬間の挙動だけは、いつの時代もエンジニアにとって最も「熱い」戦場であり続けるのだ。
コメント