Wi-Fi 7時代の通信品質を左右する「沈黙の1分」：DFS回避と極限のパケット最適化戦略
Wi-Fi 7の到来により、6GHz帯の開放は私たちネットワークエンジニアにとって福音となりました。しかし、依然として5GHz帯は家庭内無線LANのメインストリートです。ここで我々を悩ませるのが、気象レーダーとの共存を強制する DFS (Dynamic Frequency Selection) という名の「不可避な介入」です。
本稿では、このDFSが引き起こす物理層の切断が、上位レイヤー、具体的には TLS ハンドシェイクや TCP の輻輳制御にどのような「負の遺産」を残すのか、そしてそれをどう緩和すべきかについて、現場の知見を込めて深掘りします。
DFSによる「CAC」という名の強制停止
DFSの挙動はシンプルですが、実運用では残酷です。アクセスポイント（AP）が気象レーダー波を検知した瞬間、そのチャネルは即座に停止します。その後、新たなチャネルへ移動する際には CAC (Channel Availability Check) が走り、最低でも60秒間（気象レーダーの場合は10分間）の静寂が義務付けられます。
この間、クライアントとの通信は完全に途絶します。これがWebRTCなどのリアルタイム通信や、長期セッションを維持する TLS 接続において何を引き起こすか。パケットが消失するだけでなく、ルーティングテーブルの再構築や BSSID の再スキャンが誘発され、再接続までのコストが指数関数的に増大します。
インフラ設計におけるDFS回避策
プロフェッショナルな環境では、DFSの影響を物理的に排除するのが鉄則です。可能な限り W52 (36, 40, 44, 48ch) や W53 (52, 56, 60, 64ch) のみを固定利用するか、最近であれば6GHz帯（Wi-Fi 6E/7）へのトラフィックオフロードを徹底すべきです。
TLSハンドシェイクとRTT削減への執着
DFSによる瞬断が発生した際、最も脆弱なのは TLS のハンドシェイクです。特に TLS 1.3 であっても、RTT (Round Trip Time) の増加はユーザー体感に直結します。
接続が復旧した直後、TCP のスロースタートアルゴリズムが再始動します。ここで重要なのは、TCP バッファの初期値チューニングです。Linux カーネルにおいて、無線環境特有のパケットロスを想定したチューニング例を挙げます。
# /etc/sysctl.conf への追記例
# ネットワーク復旧時の立ち上がりを高速化するため、初期ウィンドウサイズを拡張
net.ipv4.tcp_slow_start_after_idle = 0
# 再送アルゴリズムを無線環境に強いCUBICに変更
net.ipv4.tcp_congestion_control = cubic
# バッファサイズを最適化（16MBを上限に動的調整）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216ヘッダー圧縮とパケットロス耐性の向上
無線区間でのロスは避けられません。特に DFS による一時的な干渉が頻発する環境では、QUIC (HTTP/3) の採用が極めて有効です。QUIC は UDP ベースであるため、TCP のようなヘッドオブラインブロッキング（HOLブロッキング）を回避できます。
また、パケットロス発生時の再送効率を上げるため、ROHC (Robust Header Compression) を意識した設計も重要です。Wi-Fi 7の Multi-Link Operation (MLO) を活用すれば、片方のリンクでDFSが発生しても、もう片方のリンクでセッションを維持するという、極めて冗長性の高い通信経路を確保できます。
エンジニアへの提言：実測なき最適化は無意味
インフラアーキテクトとして、以下のコマンドを用いて、現在のAPがどの程度「レーダー波」を検知しているか、定期的にログを監視すべきです。
# LinuxベースのAPやコントローラーでのDFSイベント監視例
# dmesgやsyslogからDFSイベントを抽出するワンライナー
tail -f /var/log/syslog | grep -iE "DFS|radar|channel"もし頻繁にDFSイベントが発生しているなら、それは設定の不備か、周辺環境のノイズ源（近隣の気象観測所など）による不可避な干渉です。この場合、ソフトウェアレベルでのチューニングには限界があります。
まとめ：次に打つべき手
1. 帯域の選別: DFSを避けるために6GHz帯の活用を優先せよ。
2. プロトコル選定: TLS 1.3 + QUIC で再送オーバーヘッドを最小化せよ。
3. カーネルチューニング: TCP の輻輳制御パラメータを無線特性に合わせて最適化せよ。
ネットワークの本質は「いかにパケットを届けるか」ではなく、「届かない時間をいかに短く、そして届かないことをユーザーに感じさせないか」にあります。DFSという物理的な制約を技術でねじ伏せるのが、私たちエンジニアの矜持です。
コメント