Wi-Fi 7時代のQoS再考：WMMから紐解くパケット優先制御の深淵
Wi-Fi 7（IEEE 802.11be）の到来により、我々はついに「無線LANはベストエフォートである」という過去の常識を脱ぎ捨てようとしている。しかし、いくらスループットが向上しようとも、物理層の下でパケットが「どのように扱われるか」という決定論的な制御を理解していなければ、真の低遅延通信は実現できない。
今回は、インフラエンジニアとして避けては通れない、WMM（Wi-Fi Multimedia）に基づくQoS制御の深層と、それが現代の高速ネットワークスタックに与える影響について解説する。
—
WMMが司る「生存圏」の優先度：AC_VOからAC_BKまで
Wi-FiのMACフレームヘッダー内にある QoS Control フィールド。ここには3ビットの UP (User Priority) が存在し、これがWMMの4つのアクセスカテゴリ（AC）にマッピングされる。
- AC_VO (Voice): 極限の低遅延が求められる音声パケット。EDCAパラメータの
AIFSNは最小値を取り、競合ウィンドウも最小に設定される。 - AC_VI (Video): 帯域幅と遅延のバランスが重要な動画ストリーム。
- AC_BE (Best Effort): Webトラフィックや一般的な通信。
- AC_BK (Background): バックアップやログ転送など、優先度が最も低いもの。
無線区間において、なぜこのACの理解が重要なのか。それは、AIFS（Arbitration Inter-Frame Space）と CWmin/CWmax（Contention Window）というパラメータが、動的にパケットの送信機会を奪い合っているからだ。
もしサーバーサイドでTCPの DSCP（DiffServ Code Point）値を正しく設定し、それをルーターが無線層の UP 値にマッピングできていなければ、あなたの渾身のアプリケーション通信は、単なる AC_BE の海に沈むことになる。
—
Linuxカーネルとパケットチューニング：QoSの現場
ネットワークインフラにおいて、Linuxホストがパケットを送出する際、どのようにQoSタグを付与すべきか。tc（Traffic Control）コマンドを用いた基本的な制御フローを例示する。
# eth0インターフェースのqdiscをfq_codelに変更し、バッファブロートを抑制する
# fq_codelはフローごとの公平性を保ちつつ、遅延を最小化する現代の標準
tc qdisc add dev eth0 root fq_codel
# 特定のポート(例: 443)を通るパケットにDSCP値を付与し、無線AP側でAC_VIへマッピングさせる準備をする
iptables -t mangle -A POSTROUTING -p tcp --dport 443 -j DSCP --set-dscp 34ここで重要なのは、DSCP 値 34（AF41）を付与することで、AP側がこれを AC_VI に引き継げるようにすることだ。これにより、無線区間での AIFSN が短縮され、競合確率が劇的に低下する。
—
RTT削減とTLSハンドシェイクの最適化
Wi-Fi 7や6Eの環境下であっても、TLS 1.3のハンドシェイクに時間がかかれば意味がない。特にモバイル環境では、CWND（Congestion Window）の立ち上がりが遅延のボトルネックとなる。
TCPバッファの最適化
Linuxカーネルのチューニングにより、Wi-Fiの「揺らぎ」を吸収しつつ、高スループットを維持する設定を推奨する。
# /etc/sysctl.conf への追記例
# 高速なWi-Fi環境でのスループット最大化とバッファ調整
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# TCPウィンドウのスケーリングを有効化し、BDP(Bandwidth Delay Product)を最適化
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# BBRアルゴリズムの有効化（パケットロスを輻輳と誤認しないための必須設定）
net.ipv4.tcp_congestion_control = bbrBBR（Bottleneck Bandwidth and RTT）は、パケットロスを輻輳とみなしてウィンドウサイズを絞る CUBIC とは異なり、無線特有の瞬間的な干渉によるロスに動じない。Wi-Fi環境において、BBR は現代のインフラ構築における「最強のカード」だ。
—
セキュリティとヘッダー圧縮の罠
最新の規格では、Robust Header Compression (RoHC) や、TLS 1.3の暗号化によってパケットサイズが最適化されている。しかし、セキュリティ専門家が注意すべきは、QoS Control フィールド自体が暗号化されない（または認証されない）ことによるサイドチャネル攻撃の可能性だ。
悪意のあるクライアントが、全てのトラフィックを AC_VO として送信し続ける「QoS不正要求」は、APのAirtimeを占有する強力なDoS攻撃になり得る。これを防ぐには、AP側で WMM Admission Control を有効にし、各ACへのトラフィック量にレートリミットを設けることが、エンタープライズレベルの防衛策となる。
—
まとめ：エンジニアとして持つべき視座
Wi-Fiのパケットは、空中の電子の海を泳ぐ、極めて不安定な存在だ。UP 値の理解は、単なる仕様の暗記ではない。それは、限られた電波資源をいかに「賢く」分け与えるかという、インフラ設計の哲学そのものだ。
1. DSCPからWMMへのマッピングを設計せよ: アプリケーション層から無線層まで、一気通貫で優先度を伝播させる。
2. 輻輳制御アルゴリズムは BBR 一択: 無線LANの環境下では、CUBIC を捨てて BBR を採用せよ。
3. APのAirtime Fairnessを疑え: QoS Control を悪用するクライアントを監視し、全体のスループットを守る設計を忘れてはならない。
技術は常に進化する。しかし、パケットを制御し、最適化するという我々の泥臭い作業が、ユーザーの「サクサク動く」という感動を支えている。この本質を見失わないでほしい。
コメント