Wi-Fi 7の真髄：MLO（Multi-Link Operation）がもたらす「無線通信の再定義」と、カーネルレベルの最適化
Wi-Fiの進化を追い続けてきた我々にとって、Wi-Fi 7（IEEE 802.11be）の登場は、単なる「スループットの向上」以上の衝撃でした。特にMLO（Multi-Link Operation）の実装は、これまでWi-Fiが抱えていた「単一帯域への依存による不安定さ」という原罪に対する、プロトコルレベルでの回答です。
今回は、インフラエンジニアやテックリードの視点から、MLOが内部で何を行っているのか、そしてそのパフォーマンスをTCP/IPスタックでどう受け止めるべきかを深掘りします。
—
MLO（Multi-Link Operation）のパケットレベルでの挙動
従来のWi-Fiでは、デバイスは2.4GHz、5GHz、6GHzのいずれか1つのリンクを選択して通信していました。どれほど高性能なルーターでも、物理層での「混雑」や「干渉」という壁は回避不能でした。
MLOは、この制約を破壊します。Multi-Link Device (MLD)は、複数の周波数帯域（Link）を束ねることで、単一の論理リンクとして振る舞います。ここで重要なのは、単なる負荷分散（Load Balancing）ではなく、パケットの複製と冗長化（Packet Duplication）を許容している点です。
内部挙動の核心
- STR（Simultaneous Transmit and Receive）: 複数のリンクで同時に送受信を行う仕組み。これにより、一方の帯域がチャネル競合（CCA: Clear Channel Assessment）で詰まっていても、もう一方のリンクでパケットを流し込める。
- リンクアグリゲーションの進化: MAC層の最上位にMLD管理エンティティが配置され、シーケンス番号の整合性を保ちつつ、異なるリンクへパケットを分散配置する。
これにより、無線環境特有の「バースト的なパケットロス」を回避し、ジッター（Jitter）を劇的に抑制します。
—
ネットワーク・トランスポート層への影響とチューニング
MLOの恩恵を最大化するには、LinuxカーネルレベルのTCPスタックの調整が不可欠です。Wi-Fi 7が提供する低いRTT（往復遅延時間）を活かすためには、バッファの肥大化による遅延を避けつつ、パイプラインを埋める必要があります。
Linuxカーネルの推奨チューニング（sysctl）
パケットロスが激減するMLO環境下では、デフォルトのTCPバッファ設定は過剰（または過小）になりがちです。以下のパラメータをチューニングし、BDP（Bandwidth Delay Product）を適正化してください。
# /etc/sysctl.conf への追記例
# ネットワーク帯域幅が広いWi-Fi 7では、受信バッファの最小/デフォルト/最大値を引き上げる
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 輻輳制御アルゴリズムをBBRに設定
# 高速な無線環境において、パケットロスを輻輳と誤認するCubicより、スループットと遅延のバランスに優れたBBRが適している
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr—
セキュリティとTLSハンドシェイクの最適化
インフラアーキテクトが懸念すべきは、リンク切り替え時（あるいは同時使用時）のセキュリティコンテキストの継続性です。
Wi-Fi 7では、MLOのマルチリンク環境下でも、認証セッションは統合的に管理されます。しかし、アプリケーション層のTLSハンドシェイクにおいては、RTTの短縮が鍵となります。
TLS 1.3の活用
TLS 1.3の0-RTT（Zero Round Trip Time Resumption）を有効にすることで、再接続時のハンドシェイクを極限まで短縮できます。MLOによる物理層の安定性と組み合わせることで、ユーザー体験は「無線であることを忘れるレベル」にまで到達します。
# PythonでのセキュアなHTTP通信例（TLS 1.3 + 0-RTTを想定）
import ssl
import http.client
# TLS 1.3を強制し、効率的なハンドシェイクを促進するコンテキスト
context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.minimum_version = ssl.TLSVersion.TLSv1_3
conn = http.client.HTTPSConnection("your-secure-service.local", context=context)
conn.request("GET", "/api/v1/data")
# 物理層のMLOにより、TCPコネクションの再確立が非常に高速化されているはず—
トラブルシューティングと脆弱性への備え
MLOは強力ですが、新たな攻撃ベクトルも内包しています。
1. リンク間推論攻撃（Cross-Link Inference）: 複数の帯域を監視することで、トラフィックのパターンから秘匿情報を抽出する試みです。
2. 管理フレームの改ざん: Wi-Fi 7ではProtected Management Frames (PMF)が必須ですが、インフラ側でこれを確実に有効化し、古いレガシーデバイスの混入を許さないポリシー（WPA3-Enterpriseの厳格運用）を徹底してください。
現場で役立つ観測コマンド
現在接続されているデバイスが、どのリンクをどれだけ使用しているかは iw コマンドで追跡可能です。
# 接続中のリンク状況を確認（要 Wi-Fi 7 対応NIC）
iw dev wlan0 station dump
# 出力結果から、複数のリンクでMLOが有効（active）になっているかを確認する結論：ネットワークの「ゆらぎ」を消す時代へ
MLOは単なる通信速度の向上ツールではありません。それは、無線という不安定なメディアを、有線イーサネットに近い「決定論的なインフラ」へと押し上げるための技術です。
エンジニアである我々は、この技術を享受するだけでなく、バックエンドのTCP/IPスタックやアプリケーション層が、その「高速で安定した土管」を適切に使いこなせるよう、設計を見直す時期に来ています。まずは手元のAPの設定を見直し、物理層からアプリケーション層までを一貫した「低遅延戦略」で塗り替えてみてください。
コメント