企业官网建设流程全解析

做无线网络这一行，早几年被问到最多的一句话就是：WiFi 6 到底比 WiFi 5 快多少？很多人张口就报协商速率，2402Mbps、1201Mbps，可实际用 iperf3 一打流，往往只有几百兆，于是开始怀疑设备是不是被坑了。其实 802.11ax（WiFi 6）真正值钱的地方，并不只是 1024-QAM 带来的那点峰值速率提升，而是 OFDMA 这套资源分配机制带来的多用户并行能力。这篇就围绕 802.11ax 的 OFDMA 资源分配展开，把 RU、HE-SIG-B、Trigger Frame 这些平时容易绕晕的概念串起来讲清楚，也会把我自己在真实设备上的验证方法、踩坑记录一并分享出来。适合刚开始接触 WiFi 6 协议开发、做无线网优调试，或者单纯想搞清楚“为什么 WiFi 6 在人多的地方更稳”的朋友。

1. OFDMA 到底解决了什么问题

1.1 传统 OFDM 的痛点

在 802.11ax 之前，802.11a/g/n/ac 用的都是 OFDM，这种技术的思路是把一个信道分成很多正交子载波，同一时刻所有子载波都服务于同一个终端。也就是说，无论这个终端是传大文件还是只发一个几十字节的 ACK，都要独占整个信道的全部子载波，时间上严格串行。

这个机制在终端少的时候问题不大，但在高密度场景下就很尴尬。比如一个会议室里 30 台设备同时在用，一台设备发一个很小的确认帧，占着整个 20MHz 或者 80MHz 信道，其他设备只能在旁边等着，等它发完再通过 CSMA/CA 竞争信道，赢了才能用自己的全信道资源。更麻烦的是，管理帧、控制帧这类短报文非常频繁，每一次都走完整的信道竞争、退避、确认流程，大量空口时间都浪费在排队和碰撞退避上，真正传业务数据的占比反而很低。

我用一个收费站类比来说明：传统 OFDM 就像一条只有一根车道的收费站，不管后面排队的是一辆小面包车还是一辆大货车，每次只放一辆车通过，后面的车哪怕再急也得等着。车一多，整条路就变成停车场。

1.2 OFDMA 的核心理念与设计出发点

OFDMA 的思路很简单：既然一个信道里有很多子载波，为什么不能把这些子载波按不同数量切成小组，分给不同的终端同时使用？每个小组就是一个资源单元（Resource Unit，RU），不同终端可以在同一个信道里各自占用不同的 RU 并行收发，这就是 802.11ax 相对 802.11ac 最大的协议层变化。

从物理层角度看，OFDMA 能成立是因为 802.11ax 把子载波间隔从 312.5kHz 缩小到了 78.125kHz，OFDM 符号时长从 3.2μs 拉长到 12.8μs。子载波间隔变小、符号变长，意味着一个符号内的子载波数量变多了，可以更灵活地划分子组。打个比方，原来一条马路只是单车道，现在路还是那么宽，但被重新画线划成了好几条窄车道，不同方向的车可以各走各的道。

OFDMA 的价值主要有三点。第一是降低时延，多个终端可以在同一时刻并行传输，不需要反复竞争信道；第二是提升频谱利用率，短帧、控制帧也可以和其他业务一起复用信道，不再单独占满整个带宽；第三是改善高密度场景的公平性，AP 可以主动调度不同终端的 RU，而不是让所有终端靠“抢”来决定谁先发。

1.3 上行和下行两条路径都要管

OFDMA 在实际工作中分成下行和上行两种情况，这也是很多初学朋友容易搞混的地方。

下行 OFDMA 由 AP 主动发起。AP 把要发给多个终端的数据打包进一个 HE MU PPDU（多用户物理层协议数据单元），在帧里标明每个终端各自用哪个 RU，一口气发出去。终端收到后解析 HE-SIG-B 字段，找到属于自己的 RU 位置，取走属于自己的数据。

上行 OFDMA 则没有那么简单，因为多个终端要同时往 AP 发数据，如果没有统一指挥，时间、频率、功率都对齐不了。802.11ax 的解决办法是让 AP 先发一个 Trigger Frame（触发帧），这个帧里包含了每个终端允许使用的 RU、传输时长、MCS、目标接收功率等信息，终端收到触发帧后在指定时间、指定 RU 上同时发送 HE TB PPDU。所以上行 OFDMA 本质上是一个“AP 点名，终端按点应答”的机制。

理解了这两条路径之后，接下来要深入的核心自然就浮出来了：RU 是怎么划分的，AP 又是怎么把这些 RU 分给不同终端的。

2. 资源分配的核心：RU 与信道划分

2.1 RU 是什么，里面到底有多少子载波

RU 是 OFDMA 资源分配的最小单位，802.11ax 标准里定义了 26-tone、52-tone、106-tone、242-tone、484-tone、996-tone 等几种 RU 类型。这里的 tone 指的就是子载波，26-tone RU 表示这个 RU 包含 26 个子载波，带宽大约是 26×78.125kHz≈2.03MHz。

不过并不是 RU 里所有子载波都用来传数据。每个 RU 里都要留出导频子载波用于信道估计和相位跟踪，剩下才是数据子载波。下面是各类型 RU 的详细参数，这个表在做速率估算时非常有用：

这里特别提醒一句，网上有些资料为了简化会把 26-tone RU 写成“两个导频、24 个数据子载波”，但在实际抓包解析时，你还会看到 DC 子载波、null 子载波、guard tone 这些概念。简单理解就是：不是所有子载波都能干活，物理信道两侧要留保护带，中心频点附近也要留空，防止直流偏置和相邻信道干扰。所以一个 20MHz 信道虽然总共有 256 个子载波，但真正能用于 RU 划分的只有 242 个左右。

2.2 不同信道宽度下的 RU 组合规则

RU 划分的规则决定了 AP 能把信道切成多少片。以 20MHz 信道为例，可以全部切成 9 个 26-tone RU，也可以切出 4 个 52-tone RU，或者 2 个 106-tone RU，再不济就是一个完整的 242-tone RU 给单个用户用。当然也可以混合分配，比如一个 20MHz 信道里同时存在 106-tone + 52-tone + 26-tone 的组合，只要不超出信道总容量就行。

40MHz 信道可以拆出 18 个 26-tone RU，80MHz 信道可以拆出 37 个 26-tone RU，160MHz 则是在两个 80MHz 上各做一次 RU 分配。需要注意的是，当信道带宽大于 20MHz 时，中心频点附近会单独留出一个 26-tone RU 的位置，协议里叫 center 26-tone RU。这个 RU 不是在所有帧里都会被分配，如果分配了，需要在 RU Allocation 字段的最高位做个特殊标记，后面讲报文结构时还会提到。

从实际操作角度讲，RU 组合规则的细节一般不需要工程师去背，标准里给了完整表格，写解析代码时直接查表即可。但有一个原则要记住：RU 越细，能同时服务的用户数越多，但每个用户的可用子载波越少，单用户峰值速率越低；RU 越粗，单用户体验越好，但能并行服务的用户数就少了。AP 的调度器就是在“多用户并行”和“单用户速率”之间找平衡。

2.3 RU 大小如何与业务需求匹配

分配 RU 不能一刀切。一个只发心跳包、状态上报的 IoT 设备，一次就几个字节的数据，给它分配一个 242-tone RU 纯属浪费；一个正在看高清视频或者传大文件的终端，如果只给一个 26-tone RU，实际速率会低到没法用。

正常调度器的思路是这样：小 RU 优先给短报文、低优先级、对时延不敏感的小流量设备；大 RU 优先给持续发送、对吞吐有要求的业务。比如一个 20MHz 信道被切成 9 个 26-tone RU，AP 可以让 9 个智能插座同时上报状态，每个插座的数据都在自己的小 RU 里并行传完，这在传统 OFDM 机制下需要 9 次完整的信道竞争和传输，效率差距肉眼可见。

MCS（调制编码策略）也会影响 RU 的选择。同样一个 26-tone RU，终端信道质量好、支持 256QAM 甚至 1024QAM 时能传更多 bit，但信道质量差时调度器只能降低 MCS，这时小 RU 的数据承载能力就更有限。所以 AP 调度器通常还会参考终端反馈的信道状态信息和重传率，动态调整 RU 大小和 MCS 的组合。

2.4 OFDMA 与 MU-MIMO 的叠加关系

很多人以为 OFDMA 和 MU-MIMO 是同一回事，实际上两者是互补的。OFDMA 是在频域上区分用户，MU-MIMO 是在空间域上区分用户。802.11ax 允许这两者叠加使用：同一个 RU 上可以同时给多个空间流用户传输数据。

举个例子，AP 有 4 根天线，一个 80MHz 信道被切成两个 RU，RU1 里用两条空间流给终端 A 传视频，同时用另外两条空间流给终端 B 传文件；RU2 里再用两条空间流给终端 C 传数据。这样频域和空域都被充分利用了，效率自然比单独用 OFDMA 或单独用 MU-MIMO 高得多。

协议上，一个 HE MU PPDU 最多可以调度 8 个用户，每个用户最多 4 条空间流，单个 PPDU 的总空间流数不超过 8。实际能调度几个用户，还要看 AP 的硬件能力、天线数量以及终端的 MU-MIMO 反馈能力。这里有个经验：很多中低端家用路由器虽然在包装上印了 MU-MIMO，但实际只支持 OFDMA，或者只支持下行 MU-MIMO，上行 MU-MIMO 基本是摆设，测试时不要被宣传参数误导。

3. OFDMA 资源分配在报文里是怎么表达的

3.1 下行 HE MU PPDU 里的 HE-SIG-B 字段

对于搞协议分析和驱动开发的人来说，光知道 RU 的划分规则还不够，得能从报文里读出 AP 到底把哪个 RU 分给了哪个用户。下行多用户传输靠的是 HE MU PPDU，这个帧的 HE-SIG-B 字段就是 RU 分配信息的载体。

HE-SIG-B 分为公共字段和用户特定字段两部分。公共字段里有一个 RU Allocation 子字段，长度是 8 bit，其中低 7 位是 RU 排列索引，最高位表示中心 26-tone RU 是否被分配。协议里把“某信道宽度下、某 RU 组合方式”和索引对应成了一张大表，比如 20MHz 下 9 个 26-tone RU 对应的索引是多少、106+52+26 混合组合对应多少，都在表里定义。解析时直接拿这个 7 位索引查表，就能还原出 RU 的排列方式。

接着用户特定字段会给每个用户列出 STA-ID、MCS、NSTS（空间流数）、编码方式等信息。所以整个解析逻辑是：先查公共字段确认 RU 分布，再看用户字段确认每个用户和 RU 的对应关系。实际开发中，如果用 Wireshark 看抓包结果，这些字段都已经解码好了，不需要自己写查表逻辑；但如果要做底层板卡调试，还是得理解这套结构，不然会被各种 Walsh、ID 索引绕晕。

3.2 上行 OFDMA：Trigger Frame 怎么指挥终端

上行 OFDMA 的资源分配信息不是放在 HE-SIG-B 里，而是在 AP 发送的 Trigger Frame 中。Trigger Frame 的结构同样有 Common Info 和 User Info List，Common Info 里携带触发类型、UL Length、上行带宽、GI 和 LTF 类型等公共参数，User Info 里则有每个终端的 AID12、RU Allocation、UL MCS、空间流分配、UL Target Receive Power 等信息。

这个 UL Target Receive Power 字段值得单独说一下。上行多用户同时传输时，如果两个终端距离 AP 远近不同、发射功率又一样，AP 接收到的信号强度就会差别很大，近端强信号会把远端弱信号“吃掉”。所以 AP 会在触发帧里告诉每个终端：你发过来的信号到达我这儿时希望是多少 dBm，终端再根据自身路径损耗估算值调整发射功率，让不同终端的到达功率基本一致。

Trigger Frame 的类型也很有讲究。最常见的是 Basic Trigger，用于普通的上行 OFDMA 数据传输；还有一种叫 BSRP Trigger 的，Poll 各终端有多少数据要发。AP 在调度上行资源前，往往会先发一个 BSRP 问一遍各终端的 Buffer 状态，知道谁有数据、有多少数据之后，再决定下一轮 RU 分配。这个机制保证了上行资源不会白白分给无数据可发的终端。

3.3 抓包实操：从空中看一次 OFDMA 交互

纸上谈兵没用，我一般会用支持 monitor 模式的网卡直接抓空口报文，观察 OFDMA 是否真的在工作。推荐用 Intel AX210 或者 MT7916 这类对 802.11ax 解码支持比较好的网卡做测试，在 Linux 下开 monitor 模式的命令大致如下：

ip link set wlan0 down iw dev wlan0 set type monitor ip link set wlan0 up

然后可以用 tshark 抓取特定类型的帧。Trigger Frame 在无线帧头里的 type/subtype 对应关系是 Control/Trigger，可以在 Wireshark 里过滤wlan.fc.type_subtype == 0x04来观察。抓到一个 Basic Trigger 后，点开 User Info List，能看到 AID、RU Allocation、UL MCS、Target RSSI 等字段，这些就是 AP 给各终端安排资源的具体证据。

有一次我在一个多终端办公环境里抓包，看到一个 80MHz 带宽的 Trigger Frame，User Info 里同时列了 5 个终端的 RU 分配信息，分别是不同大小的 RU 和不同的目标接收功率。从那以后，我对 OFDMA 的感知就不再是“宣传页上的功能”，而是能实实在在看见的东西。这里提醒一句：如果你的测试网卡只支持到 802.11ac，是解不出 HE 相关字段的，看不到 RU 信息，所以测试前先确认网卡能力。

3.4 终端能力确认与 AP 侧配置

做 OFDMA 测试前，最好先确认终端有没有对应的能力位。Linux 下可以用iw phy phy0 info查看 HE Capabilities，重点关注 OFDMA 相关的能力位以及支持的 RU 大小。有些老网卡虽然能连上 WiFi 6 路由器，但在能力协商时根本没有声明支持 OFDMA，AP 自然不会给它分配小 RU，这时候你看着协商速率是 WiFi 6，实际走的还是老一套单用户传输。

AP 侧也一样。以 hostapd 为例，要开启 802.11ax，需要在配置里加：

ieee80211ax=1 he_oper_chwidth=2 he_oper_centr_freq_seg0_idx=0

ieee80211ax=1是开启 HE 模式的总开关，he_oper_chwidth设置 HE 操作信道宽度，我这里给的是 80MHz 的示意。不同版本的 hostapd 对参数命名有差异，有些厂商固件还会在 Web 界面专门提供“上行 OFDMA”开关，但背后的逻辑是一样的：HE 开启之后，OFDMA 调度能力才存在，具体能调度多好，还要看驱动实现。

4. 真实场景下的调度策略与性能影响

4.1 AP 调度器是如何决策的

OFDMA 资源分配表面上是个物理层概念，但真正决定用户体验的是 MAC 层的调度器。AP 会综合考虑每个终端的 Buffer 状态、队列优先级、历史速率、信道质量、支持的 MCS，以及当前信道的整体负载，然后决定这一轮 RU 怎么切、切多大、给谁用。

一个比较典型的调度流程是：AP 先周期性发 BSRP，让终端上报“我缓存里有 X 字节要发”；然后调度器根据这些信息，把大 RU 分给数据量大的终端，小 RU 分给数据量小的终端；如果信道质量差的终端分到大 RU，还会伴随 MCS 降级，保证传输可靠性。实际产品里，各家方案的调度算法差别很大，有的偏向公平性，有的偏向低时延，有的偏向最大化吞吐，这也是为什么同一个路由器刷了不同固件后，多用户体验会有明显差异。

4.2 高密度场景下 OFDMA 的收益到底有多大

802.11ax 发布时官方宣传说相比 802.11ac 在高密度场景平均吞吐提升 4 倍，这个数字不是跑单用户打流跑出来的，而是多用户密集场景下的统计收益。OFDMA 减少的是协议开销和碰撞退避时间，这对小报文密集的场景特别明显。

我实测过一个 30 台终端同时在线、其中有 20 台在持续上报小数据的办公环境。关闭 OFDMA 时，大量终端的 ACK 和状态上报报文排队等待信道，空口利用率很高但有效吞吐很低，时延抖动也大；开启 OFDMA 之后，AP 一个触发帧就能让多台上报终端同时发出数据，信道竞争次数大幅下降，时延明显变得平稳。相反，如果只有一两台终端在传大文件，OFDMA 的优势几乎体现不出来，因为根本不需要并行调度，单用户独占大 RU 反而更高效。

4.3 打流实验：怎么量化 OFDMA 的收益

如果你想自己验证 OFDMA 的实际效果，我建议准备一台支持 802.11ax 的 AP、至少两台支持 HE 的终端，然后用 iperf3 做多用户上行并发测试。测试时注意固定测试变量：把 AP 的信道和带宽固定，例如锁定在 36 信道、80MHz；所有终端连接同一个 SSID，关闭不必要的漫游和省电；先只跑一个终端的上行业务作为基线，再同时跑多台终端的上行业务，记录总吞吐和每台终端的平均时延。

结果通常会看到两种情况：如果 AP 的 OFDMA 调度做得好，多终端并发时总吞吐不会比单终端低太多，各终端的时延曲线也比较平稳；如果 OFDMA 没生效或者调度策略很粗糙，并发时的总吞吐可能掉得很厉害，时延曲线抖动也严重。这里有个容易踩的坑：有些 AP 固件默认没开上行 OFDMA，只开了下行 OFDMA，这时候你测上行并发性能自然没有提升，测试前务必确认 AP 侧开关。

5. 常见问题与排查技巧

5.1 常见问题速查表

5.2 为什么 WiFi 6 协商速率很高，实际吞吐上不去

这是大家问得最多的一个问题。要明白一个前提：协商速率是物理层在最理想条件下的极限速率，实际吞吐要扣掉协议开销、导频开销、MAC 层竞争、重传、干扰等因素。即使是 160MHz、2x2、MCS11 协商到 2402Mbps，实际 TCP 打流能跑到一半就已经表现不错了。

OFDMA 在这里的角色也要正确理解：它不是用来提升单用户峰值速率的，而是让多个用户能更高效地共享信道。所以如果你只有一台终端，跑不满协商速率不一定是 OFDMA 的问题，先查信号强度、频段干扰、天线流数和 AP 配置。如果多台终端并发时整体体验明显变差，这反而是 OFDMA 调度发挥作用的场景。

5.3 关于 Realtek rtl8852be 等终端的兼容性经验

很多笔记本和 USB 网卡用的是 Realtek 方案，比如项目里经常见到的 Realtek RTL8852BE WiFi 6 PCIe Adapter。这类网卡在 Windows 下驱动相对完整，日常使用没问题，但在 Linux 下做协议调试就要留个心眼。rtl8852be 在 Linux 下主要靠 rtw89 驱动，内核版本太老时不支持，monitor 模式的支持也有限，我试过在部分内核版本下开 monitor 抓包，HE 字段解码不全，很多 Trigger 帧解析不出来。

实际项目中，我会把这类网卡当作“普通终端”来测兼容性，而不是当作协议分析工具。如果你手上只有 rtl8852be 的终端，又怀疑 OFDMA 工作不正常，最靠谱的办法是换一张 Intel AX210 或 MTK 的测试网卡做对照。另外记得先升级终端驱动和 AP 固件，Realtek 网卡对部分 AP 的 HE 能力协商存在兼容问题，表现为能连上但吞吐异常、掉线频繁，升级驱动通常能解决大部分问题。

5.4 几个值得记住的实战细节

最后分享几个实操中总结出来的细节。第一，测试 OFDMA 一定要制造“多用户上行小包并发”的场景，单用户测试、纯下行大流量测试都说明不了问题；第二，抓包时如果看到 AP 周期性发 Trigger Frame，且 User Info 里同时列出多个终端的 RU 分配，说明 OFDMA 在工作，不用再看别的指标；第三，AP 的 OFDMA 调度参数在很多固件里不开放给用户，所以不要盲目相信路由器后台里的“OFDMA 开关”，抓包才是验证手段；第四，2.4GHz 频段因为可用 RU 数量有限、干扰大，OFDMA 收益不如 5GHz 明显，实际部署时优先把高密度终端放在 5GHz。

我个人在实际操作中的体会是，OFDMA 这套机制最考验的不是物理层能不能实现，而是 AP 的调度器够不够聪明。标准把规则定得很细，但同一个 AP 芯片、不同固件版本，多用户表现可能完全不同。所以做 WiFi 6 优化时，别只盯着协商速率和天线数量，多抓几次空口报文，看看 Trigger Frame 的调度间隔和 RU 分配是否合理，很多“路由器不好用”的问题都能在报文里找到答案。

再补充一个小技巧：如果你想把某个终端固定在某个 RU 上观察行为，可以人为限制终端带宽或者调整 AP 侧的最小 RU 分配策略，不同方案商的接口不一样，但思路是共通的。这个内容后续还可以往 BSRP 调优、上行 OFDMA 随机接入（UORA）方向扩展，那套机制在 IoT 场景里更能体现价值，有机会再单独写一篇。