Wi-Fi 4 (802.11n) の深淵：MIMOが変えたワイヤレスの物理層と、現代のエンジニアが今なお向き合うべき「最適化」の真実
ネットワークエンジニアの諸君、あるいはプロダクトのパフォーマンス限界と日々格闘するテックリードの諸君。最新のWi-Fi 7が喧伝される今、なぜあえて「Wi-Fi 4 (IEEE 802.11n)」の深淵に触れるのか。それは、現代の高度に抽象化されたネットワークスタックにおいても、物理層（PHY）でのMIMO（Multiple-Input Multiple-Output）の挙動が、エンドツーエンドのパケット到達時間に依然として決定的な影を落としているからだ。
かつて「革命」と呼ばれたWi-Fi 4。2.4GHz帯の混雑と干渉の中で、いかにして物理的な限界を突破し、空間を多重化したのか。そのメカニズムと、現代のLinuxカーネルレベルでのチューニングについて深掘りしていこう。
—
1. MIMOという「空間の魔法」：物理層の内部挙動
IEEE 802.11nが導入したMIMO技術は、単なるアンテナの増設ではない。これまでマルチパス（反射波）として通信の敵と見なされていた電波の多重反射を、あえて「情報搬送の味方」に変えた点が最大の発明だ。
物理層において、送信側は複数のアンテナから異なるデータストリーム（空間ストリーム）を同時に送り出す。これを受信側で信号処理し、空間的な相関関係を利用して分離する。数式で言えば、チャネル行列 $H$ を推定し、受信信号ベクトル $y = Hx + n$ （$n$はノイズ）から元の送信ベクトル $x$ を逆行列演算によって復元する作業だ。
この「行列演算」こそが、Wi-Fi 4の真骨頂である。しかし、物理層でどれほど効率的に空間多重化を行っても、上位層でTCPのウィンドウ制御が適切でなければ、そのスループットは宝の持ち腐れとなる。
—
2. カーネルレベルのチューニング：TCPバッファとRTTの呪縛
Wi-Fi 4環境下では、再送率が高くなるリスクがある。パケットロスが発生した際、TCPの混雑制御アルゴリズムが即座にウィンドウサイズを絞り込むと、物理層のMIMOで確保した帯域が死ぬ。
特に、レイテンシを極限まで削るためには、TCPの初期ウィンドウサイズ（initcwnd）とバッファ管理が鍵を握る。Linux環境において、スループットを最大化するための設定例を以下に示す。
# TCPウィンドウサイズの動的調整を最適化する
# メモリを消費するが、高遅延・高帯域な環境でのスループット低下を防ぐ
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# 混雑制御アルゴリズムをBBRに変更（Wi-Fiのようなロスが生じやすい環境に最適）
sysctl -w net.ipv4.tcp_congestion_control=bbr
# TCP Fast Openを有効化し、ハンドシェイクのRTTを1往復削減
sysctl -w net.ipv4.tcp_fastopen=3TCP Fast Openを有効にすることで、TLSハンドシェイクのオーバーヘッドを劇的に抑え、Wi-Fi 4の不安定なリンクであっても、接続開始時のパケットロスによる遅延を最小限に抑えることが可能だ。
—
3. セキュリティとヘッダー圧縮の均衡点
Wi-Fi 4の時代、WPA2の脆弱性（特にKRACK攻撃）は歴史に刻まれている。インフラアーキテクトとして、物理層の脆弱性をカバーするのは上位層の責務だ。
通信量が増大する中で、TLS 1.3の採用は必須だ。TLS 1.3はハンドシェイクを1回に短縮しており、Wi-Fi 4の不安定なマルチパス環境でも、ネゴシエーション中に切断される確率を大幅に下げられる。また、HTTP/2やHTTP/3 (QUIC) を利用する場合、HPACK や QPACK によるヘッダー圧縮が重要になる。
Wi-Fi 4でボトルネックになりやすい小さなパケットの連続送信を避けるため、アプリケーション側では以下のようにヘッダーを最適化すべきだ。
# HTTP/2ヘッダー圧縮の概念的実装イメージ
# 静的テーブルを活用し、頻出するヘッダーをインデックス化することで
# ペイロードの占有率を物理層の制限内で最大化する
hpack_encoder = HPackEncoder()
header_data = {
":method": "GET",
":path": "/api/v1/data",
"user-agent": "Custom-IoT-Client/1.0"
}
# エンコードによりヘッダーサイズを数バイトまで削減可能
compressed = hpack_encoder.encode(header_data)—
4. 現場の教訓：なぜWi-Fi 4は今も手強いのか
Wi-Fi 4が未だに現場で現役である理由は、その「枯れた安定性」にある。しかし、現代のアプリが要求するスループットに対し、2.4GHz帯のチャネル幅（最大40MHz）はあまりに狭い。
もしあなたがWi-Fi 4環境のインフラを保守しているのであれば、以下の「泥臭い」鉄則を忘れないでほしい。
1. チャネル設計: 2.4GHz帯において 1ch, 6ch, 11ch 以外の選択は、パケット衝突による再送の嵐を招く。
2. 保護フレーム: RTS/CTS を有効にし、隠れ端末問題を物理的に抑制すること。これはスループットをわずかに下げるが、極端な遅延スパイクを防ぐための「保険」だ。
3. パケット集約: Wi-Fi 4で導入された A-MPDU を活用するため、低レートのレガシーデバイスを極力排除すること。1台の802.11bデバイスが混入するだけで、空間多重の効率は劇的に低下する。
結びに
Wi-Fi 4のMIMO技術は、ワイヤレス通信を「点と点」から「面と空間」の演算へと昇華させた。最新の規格に目を奪われがちだが、パケットが物理層の行列演算を通り抜け、暗号化され、カーネルのバッファで整列し、アプリケーションに届くまでのプロセスを理解することこそが、真のインフラエンジニアの嗜みである。
諸君、技術は進化しても、パケットが泥臭く電波に乗って飛んでいる事実は変わらない。その挙動を深く理解し、コードの行間をチューニングし続けることが、我々の誇りなのだ。
コメント