提到 ax绝大多数人第一时间想到的不是斧头而是 Wi-Fi 6 背后的 802.11ax 标准。这没错但我更愿意把 ax 看成一套完整的调度哲学。为什么这么讲因为我用 802.11ac 的 AP 和 802.11ax 的 AP 在同一个高密度会议室做过切换测试终端数量超过三十个之后旧 AP 的 ping 时延开始跳变最高飙到四百多毫秒而新的 ax AP 在同样的压力下平均时延稳定在十几毫秒。速率确实变快了但这并不是唯一的原因真正解决拥堵的是 AP 主动把信道、时间、空间资源分配给每一个终端。今天想跟你聊一聊的就是这套 ax 调度机制的核心逻辑、现场调优方法以及我踩过的几个大坑。无论你是在管理企业无线还是单纯想弄明白为什么 Wi-Fi 6 号称专为高密度场景而生都值得往下看。1. 为什么 ax 必须把调度放在首位——802.11ac 时代留下的烂摊子1.1 共享信道上的“无序抢路”是万恶之源我们先回到 802.11ac 时代。无线局域网的所有终端工作在同一信道上协议用的是 CSMA/CA也就是“先听后说、随机退避”。这个机制在终端少的时候很高效但在高密度场景就成了灾难。想象一个会议室里三十个人同时打开视频会议每个终端都想争取上行信道大家互相听不到或者等待随即进入指数退避空口利用率大量消耗在退避和碰撞上。我做测试时看到过一个很极端的案例在 802.11ac 下有三十台终端同时做文件上传整台 AP 的空口利用率已经接近 90%但真正传输有效数据的比例不到 40%剩下全被退避、控制帧和碰撞消耗了。这就是为什么需要 ax不能再让终端无序竞争必须由 AP 统一调度。于是 OFDMA、MU-MIMO、TWT 这些机制一起出现全部服务于“调度”这一个核心目的。1.2 OFDMA 的意义不是快而是“多路并发”OFDMA 是 ax 调度里最具代表性的实现。它可以把一个信道在频域上切分成多个资源单元RU每个 RU 分配给不同的终端。这样说有点抽象我习惯用车道来类比802.11ac 时代20MHz 信道是一条双向两车道所有车排队走到了 ax这条路变成了一条多车道高速中间加了隔离带小车、货车可以并排走。但要注意OFDMA 并不会提高单个终端在满负载下的极限速率它提升的是“多终端并行时的整体效率和时延”。这也是为什么有人用 iperf3 单终端测速感觉 ax 跟 ac 没什么差别因为单终端根本触发不了 OFDMA。要想体会 ax 调度的效果必须同时跑多个终端。这是我对很多新入行工程师强调的第一点。1.3 MU-MIMO 让空间流也参与调度ax 的 MU-MIMO 和 OFDMA 是配合工作的。802.11ac 只支持下行 MU-MIMO而且最多四个终端同时收ax 不仅支持上行 MU-MIMO还放宽到 8x8。也就是说AP 可以在同一时刻利用多根天线形成的不同空间路径向多个终端进行收或发。这给调度器带来了额外的维度不仅要决定每个终端占用哪个 RU、用多大带宽还要决定哪些终端可以在空间上复用同一个频段。如果调度算法不好MU-MIMO 的配对会很差甚至比不开还慢。很多企业 AP 默认开启 MU-MIMO但在实际环境中因为终端分布杂乱、天线对准度差性能收益不如预期。所以 ax 调度并不是一个固定功能它更像是 AP 固件里那套实时决策逻辑这也是为什么不同厂商的 ax AP 在真实场景表现差异巨大。2. ax 调度核心机制拆解从 RU 到触发帧再到 TWT2.1 资源单元RU的分配逻辑与常见组合OFDMA 中的最小资源单元是 26 个子载波一个 20MHz 信道大约有 256 个子载波不考虑导频和预留可以切成多个 RU。最常见的分配组合有九个 26 子载波 RU、四个 52-RU 加一个 26-RU、两个 106-RU 加一个 26-RU、以及一个 242-RU 等情况。不同组合决定了同一时刻能服务的终端数。调度器分配 RU 时主要看三个信息终端缓存的数据量Buffer Status、信道质量CSI、业务优先级。比如某个终端一直传小包给它分一个 26-RU 就够了因为小包用窄 RU 发送速度快、占资源少如果某个终端有大文件要发可以给它分配 106-RU 甚至更大。20MHz 下最多九个 RU但如果信道质量差终端需要更低的 MCS 和更高的发射功率RU 也不能分得太碎。这块没有统一公式完全看 AP 厂商的算法。2.2 上行调度靠的是触发帧而不是终端自觉ax 和 802.11ac 最大的不同之一是上行方向的确定性。在 802.11ac 中上行数据仍然是各个终端自由竞争在 ax 中终端不能随意发送上行数据必须先收到 AP 发送的 Trigger Frame。触发帧里面带了一串调度信息比如每个终端可以占用哪个 RU、用哪个 MCS、什么时候开始发。终端收到后按约定发送碰撞在根源上被消除。这个机制在实验室里很漂亮但实际调试时要注意触发帧的周期。如果触发间隔过长终端缓存数据等太久用户会感觉上行卡顿如果触发间隔过短Trigger Frame 自身占用的空口开销又会上升影响了系统吞吐量。我在现场通常建议先看 AP 的触发帧间隔配置很多厂商默认在 1ms 上下办公场景可以先从 1.5ms 试视频会议多的场景适当压到 1ms。这个参数需要结合终端数量来微调。2.3 TWT 很美好但调度不好就是灾难TWT 是 ax 里的省电调度协议AP 给每个终端分配一个“唤醒窗口”其他时间深度睡眠。对于电池供电的物联网终端这功能很香但对于实时性强的业务如果 AP 算法不成熟终端可能因为错过唤醒时间导致连接假死。我在一个物流仓库遇到过一次很典型的问题开启 TWT 后仓库的无线扫描枪每两分钟掉线一次数据库里全是重连日志。后来怀疑是 TWT 周期和扫描枪的休眠策略冲突直接把 TWT 关掉后问题消失。所以我的建议是在混合业务场景下先不要急着全局开启 TWT要么通过单独 SSID 隔离 IoT 设备要么按终端类型策略下发。调度的本质不是把所有省电机制打开而是让每种终端找到合适的传输节奏。3. 实操如何在真实网络里把 ax 调度调出效果3.1 先确认终端是否真的在走 HE 速率在动手调参数之前先确认你的终端真的在用 802.11ax 接入。我看过太多项目后台显示“Wi-Fi 6”但实际终端协商速率只有 72Mbps一看连接在 2.4GHz 的 802.11n。判断方法很简单在 Linux 终端执行iw dev wlan0 link查看tx bitrate如果速率前面带HE就是 802.11ax带VHT是 802.11ac带HT是 802.11n。更完整的信息可以用iw dev wlan0 station dump能看到每个终端的 last ack signal、tx packets、rx bytes 等用来排查终端侧的接入问题很管用。如果手机端iPhone 可以连电脑用无线诊断工具安卓装一个 Wifi Analyzer 或者从开发者模式看连接信息。记住一个原则ax 调度再好终端不支持 HE一切都白搭。3.2 关键参数的调优顺序与推荐值根据我的实战经验调优应按“信道—频宽—功能—协议”的顺序来。第一是信道。选一个干净的 5GHz 信道可以用安卓上的 Wifi Analyzer 或 AP 自带频谱分析避开雷达信道和邻频干扰。2.4GHz 只有 1、6、11 三个不重叠信道但实际环境中干扰很大建议高密度场景尽量压到 5GHz。第二是频宽。很多初学者喜欢把频宽拉到 160MHz认为速率最高。但高密度园区里 160MHz 意味着只有少数信道可用而且容易被雷达信号和邻居 AP 干扰反而导致频繁切换。我常用的做法是 80MHz兼顾速率和抗干扰。第三是功能开关。确认 OFDMA、MU-MIMO、BSS Coloring 都开启。BSS Coloring 是 802.11ax 的另一项调度辅助技术它在帧里加一个颜色标识让接收端能快速判断干扰帧是否来自同一 BSS从而减少退避提升同频共存效率。第四是协议参数包括触发帧间隔、TWT 策略、MCS 限制等这些要看厂商支持程度。参数办公场景推荐值信道/频宽5GHz / 80MHzOFDMA开启MU-MIMO开启BSS Coloring开启TWT办公终端先关闭IoT 单独 SSID 开启触发帧间隔1ms ~ 2ms最小接入速率12Mbps ~ 24MbpsQoS 映射开启VLAN DSCP 正确标记3.3 用 iperf3 做一次“多终端并行压力测试”调完之后需要验证效果。单终端测速无法验证 OFDMA正确的做法是准备十台以上的终端同时在 5GHz 连接同一个 SSID然后在服务端和客户端跑 iperf3 UDP。比如我在现场常用命令# 服务端建议放在有线侧服务器 iperf3 -s # 每个无线终端上执行 iperf3 -c 服务器IP -u -b 20M -t 60 -P 4看三个指标总吞吐、丢包率、每条流的抖动。对比开启 ax 调度前后的数据你会发现同样 50 台终端丢包率可以从 5% 降到 0.5% 以下。如果丢包率没有明显改善大概率是终端或者 AP 固件没有真正进入 OFDMA 模式需要回头检查触发帧和 RU 分配。4. 常见问题与排查技巧实录4.1 OFDMA 开了为什么测速还是没提升这是问得最多的问题。根本原因通常是测试方法不对。OFDMA 的优势在于多用户并发不是单用户峰值。单终端测试时OFDMA 甚至可能因为调度开销导致速率轻微下降。所以先跑多终端测试。另一个原因是 AP 调度器可能把 OFDMA 关闭了或者因为兼容性问题回退到传统模式。有的企业 AP 在固件里有一个“兼容模式”选项开启后会自动禁用 OFDMA。如果确认都打开了还可以看 AP 的 debug 日志搜索 triggering 字段看有没有下发 Trigger Frame。我遇到过一种情况终端虽然支持 802.11ax但驱动默认没有启用 HE需要在网卡驱动参数里打开。所以说不要只看接入点终端侧同样要检查。4.2 老设备在 ax AP 下频繁掉线怎么办802.11ax AP 兼容 802.11a/b/g/n/ac但混合模式会让一些老终端的漫游行为变保守。原因是 BSS Coloring 和 OFDMA 改变了帧结构老终端不认识这些新字段如果 AP 没有正确处理老终端会认为信道一直忙从而触发退避甚至掉线。处理办法先关掉 BSS Coloring 试试再把 OFDMA 对 legacy 终端的保护打开有些厂商叫“兼容传统设备”。如果还是不稳可以单独给老终端开一个 802.11ac 的 SSID不混合在 ax SSID 里。不要迷信“一个 SSID 搞定所有”在关键业务场景分开永远比混跑稳定。4.3 上行卡顿严重但下行测速正常上行调度和下行调度的路径不一样。下行 AP 主动发数据就行上行必须先等 Trigger Frame。如果终端不在触发列表里就只能用传统 EDCA 竞争那体验自然差。排查步骤先看 AP 侧有没有启用 Uplink OFDMA然后检查触发帧周期。在 Wireshark 里抓包时可以用显示过滤器定位 Trigger Frame比如wlan.fc.type_subtype 0x000d不同版本字段名可能不一样看它是不是周期性出现间隔是不是合理。如果触发帧只有少量说明调度器认为终端不需要上行资源这可能是 QoS 队列优先级没有正确标记导致的。解决方法是把语音、视频业务的 DSCP 标记正确让 AP 优先调度。4.4 问题速查表症状可能原因快速解决动作OFDMA 没效果单终端测试无法触发多用户调度多终端同时跑 iperf3 UDP后台显示 11ax 但速率低终端协商在 2.4GHz / 11n检查终端位置开启双频引导老终端掉线BSS Coloring 干扰关闭 BSS Coloring或独立 SSID上行卡顿Trigger Frame 间隔太长缩短触发间隔抓包验证触发周期无线扫描枪隔几分钟掉线TWT 与休眠策略冲突关闭 TWT或单独 SSID 隔离 IoT5. 除了参数ax 调度还要看这些“隐形指标”5.1 空口利用率和重传率才是更真实的体检报告调完参数后不要只看信号强度。信号强度只是“听见”的水平真正影响体验的是空口利用率和重传率。我一般会在 AP 上开一个周期的统计接口看 channel busy 比例如果 5GHz 的 channel busy 长期超过 70%即使每个终端看起来都是满格信号实际体验也会很差。另一个指标是重传率正常办公场景建议控制在 5% 以下如果超过 10%说明干扰或调度的频域资源没有匹配好需要回看 RU 分配日志。很多人喜欢把 RSSI 截图发给别人证明“信号很好”其实没有任何说服力。无线网络调优看队列、看时延、看重传比看信号强度有用得多。5.2 固件版本比想象中重要得多同样一台 AP固件不同ax 调度能力天差地别。我遇到过某厂商在早期固件里 OFDMA 下行是能用的但上行触发帧一直有 bug导致视频会议上传卡成幻灯片。后来升级到另一个次要版本问题直接消失。所以我去客户现场的第一件事就是看 AP 固件版本和发布说明。不要小看这种“软优化”ax 调度算法很新厂商迭代频繁一个补丁可能就是完全不同的表现。如果你发现某个功能开了之后反而问题更多先别急着怀疑硬件去查官网更新日志很可能答案就在某个已修复的 issue 里。5.3 我的最终测试习惯最后分享一个我自己的习惯每次调优完成后我不会急着交付而是留出至少半天时间在正常业务高峰期再做一轮多终端压力测试和漫游测试。我会记录 TCP 往返时延的 P99而不仅是平均值。平均值漂亮不代表体验好P99 才是真正影响用户感知的指标。如果 P99 保持在 30ms 以内基本说明 ax 调度已经稳了如果某个终端突然跳到 100ms 以上就赶紧查它是不是被调度器漏掉了。