Wi-Fiの「見えない渋滞」を制御せよ：WMMからTCPチューニングまで、極限のパケット制御術
Wi-Fi 7（IEEE 802.11be）の登場により、マルチリンクオペレーション（MLO）が注目を集める昨今ですが、どんなに高速な物理層を手に入れても、パケットを送り出す「順序」と「優先度」を制御できなければ、リアルタイム通信はジッターの海に飲み込まれます。
今回は、インフラアーキテクトやテックリードの視点から、Wi-Fi環境下におけるQoS（WMM）の深淵と、その上に乗るTCP/TLSスタックの最適化戦略について、現場の泥臭い知見を交えて解説します。
—
1. WMMの再定義：EDCAパラメータが制御する「待ち時間」の正体
多くのエンジニアが「WMMは単なる優先度付け」と誤解していますが、本質はEDCA (Enhanced Distributed Channel Access) による競合ウィンドウ（CWmin / CWmax）と仲裁フレーム間隔（AIFSN）の動的な調整です。
Wi-Fiの空き待ち（バックオフ）において、Voice (AC_VO) クラスは他のクラスよりも遥かに短い AIFSN を持ち、より高い確率で無線媒体を占有します。ここで重要なのは、サーバー側のカーネルパラメータとこの無線QoSをどう同期させるかです。
LinuxにおけるWMM優先度のマッピング
アプリケーションの DSCP 値を、OSレベルで適切にWi-Fiの UP (User Priority) へ変換する必要があります。iptables や nftables を用いて、特定トラフィックをタグ付けする手法は基本中の基本です。
# 特定のリアルタイム通信（例えばWebRTCのメディアストリーム）にDSCP EF(46)を付与する例
# これにより、Wi-FiドライバがWMMのVoiceキューへパケットを適切にルーティングする
nft add rule inet filter output ip dscp set 46—
2. RTT削減とTLSハンドシェイクの最適化
Wi-Fi環境下では、電波干渉によるパケットロスがTCPの再送制御（RTO）を誘発し、指数関数的なバックオフを引き起こします。これを回避するには、トランスポート層での「攻め」のチューニングが不可欠です。
TCPバッファと擁塞制御アルゴリズムの最適化
高遅延・高ロス環境では、デフォルトの CUBIC よりも BBR (Bottleneck Bandwidth and RTT) が圧倒的に優位です。BBRはパケットロスを「擁塞」ではなく「ノイズ」として扱うため、無線環境でのスループット低下を最小限に抑えます。
# sysctl.conf での設定例
# BBRの有効化とTCPバッファの最適化
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_congestion_control = bbrまた、TLS 1.3の導入は必須です。0-RTT（Early Data）を利用すれば、ハンドシェイクのラウンドトリップを1回削減でき、Wi-Fiの不安定なハンドシェイク時間を劇的に短縮できます。ただし、リプレイアタックの脆弱性には細心の注意が必要です。
—
3. ヘッダー圧縮とパケット集約の呪縛
Wi-Fi 6/7では A-MPDU (Aggregate MAC Protocol Data Unit) による集約が行われますが、あまりに巨大な集約は、パケットロス発生時の再送コストを増大させます。
- 脆弱性への視座: 暗号化されていない管理フレーム（特に
802.11wが無効な環境）では、Deauthentication攻撃によるセッション切断が容易です。インフラ設計としては、PMF (Protected Management Frames)の強制有効化が絶対条件です。 - ヘッダー圧縮:
ROHC (Robust Header Compression)は本来VoIP向けですが、IoT機器等でMTUを小さくせざるを得ない場合、IPヘッダーの肥大化によるオーバーヘッドを無視できません。可能な限りQUIC (HTTP/3)を採用し、ヘッダー圧縮とパケットロス耐性をアプリケーション層で吸収するアーキテクチャへの移行を強く推奨します。
—
4. 現場からの警鐘：なぜ「高速なWi-Fi」でも遅いのか？
多くの現場で遭遇する「謎の遅延」の正体は、実はAP（アクセスポイント）内部のCPUボトルネックではなく、クライアント側の「省電力機能」によるスリープと復帰のサイクルにあることが多いです。
特にIoTデバイスにおいて、WMM-PS (Power Save) が有効な場合、APはパケットをバッファに溜め込み、デバイスのビーコン待ちを強制します。レイテンシを極限まで削る必要がある場合は、クライアント側で iw コマンドを叩き、電力管理モードを無効化する検証も必要です。
# クライアント側で無線インターフェースの電力管理を無効化（検証用）
sudo iw dev wlan0 set power_save off—
結びに：通信の品質は細部に宿る
Wi-Fi 7が提供する広帯域幅は魅力的ですが、インフラアーキテクトが向き合うべきは、相変わらず「いかにして無線の不確実性をロジックで制御するか」という古典的かつ本質的な課題です。
WMMによる優先制御を土台に、BBRやTLS 1.3といった最新のトランスポート技術を積み上げる。この一見地味なチューニングの積み重ねこそが、ユーザーに「まるで有線LANのような体験」を提供するための唯一の道筋です。
貴方のネットワークが、今日も最適化されたパケットで満たされていることを願っています。
コメント