企业官网建设流程全解析

简介：《WiFi6空口速率计算》PDF是一份面向网络工程师、无线运维人员及通信学习者的技术资料，系统梳理802.11ax峰值速率的五大决定因素：天线流数、Symbol与GI、编码方式、码率、有效子载波数量，并结合华为AP4050DN等设备实例，说明实际建链速率“就低不就高”的取值逻辑。资源包共1个PDF文件，大小约204KB，内容精炼、公式与图示配合，便于快速查阅。目前已有179人学习下载。读者可借此掌握空口速率计算公式及各项参数含义，理解MIMO、1024QAM、256阶FFT等关键概念，并在实际无线网络规划中估算理论峰值、定位速率瓶颈，为后续调优或排障提供理论支撑。

1. 标称 2400Mbps 的 Wi-Fi 6 网卡，为什么实测只有 700Mbps？

网卡协商出了 2400Mbps，Speedtest 却只有 700 多，这不是硬件缩水，而是大部分人第一次接触 WIFI6空口速率计算时的直觉偏差。厂商标的 2400Mbps 是空口速率，也叫 PHY Rate、协商速率，指的是物理层在最理想信道条件下每秒钟能往空气里塞多少比特；而浏览器里看到的吞吐，是经过协议开销、重传、竞争窗口层层盘剥之后剩下来的数值。这篇文章就是把空口速率这件事拆开：它由哪些参数相乘得到，怎么手算一遍 80MHz 下的 2400Mbps，以及为什么 Wi-Fi 6 能比 Wi-Fi 5 快出将近三倍。适合做无线网络规划、AP 选型、弱电交付和无线排障的工程师，读完后你能拿着任意一组协商参数，自己把理论速率算出来。

2. 空口速率是怎么叠出来的：从 WiFi4/5 到 WiFi6 的关键参数变化

2.1 先分清两件事：空口速率和实际吞吐

空口速率描述的是“调制符号经过天线发出”这一层的速度，它不包含发送前加的 PLCP 前导码、信标帧、ACK 确认帧、帧间间隔和信道竞争时间。只要两台设备在协商时确定了频宽、空间流数、MCS 调制阶数和 GI 长度，这个数值就会固定下来，哪怕信道里一个包都没传，它也在那儿。

实际吞吐则要打很多折扣。一个 1500 字节的以太网帧，在 802.11 里会被加上几十字节的 MAC 头、PLCP 头和 FCS，每发一个数据帧之前要先听信道、退避、发 RTS/CTS，收完数据还要等 SIFS 再回 ACK。这些开销在 802.11ac 时代大约吃掉三到四成的空口速率，Wi-Fi 6 引入 OFDMA 和更长的符号时长后也没能完全消除。所以看到协商速率 2400Mbps、实际 TCP 单向 700-900Mbps 是很正常的现象，前提是你得先把空口速率算准，否则根本判断不了是协议开销导致的，还是 AP 配置、干扰、网卡驱动出了问题。

2.2 WiFi6 在物理层加了什么：符号时长、子载波间隔与 OFDMA

很多人问 wifi4和wifi5和wifi6的区别，从空口速率这个维度看，差别全在物理层参数上。Wi-Fi 4（802.11n）和 Wi-Fi 5（802.11ac）用的是 3.2 微秒的 OFDM 符号，子载波间隔是 312.5kHz；Wi-Fi 6（802.11ax）把子载波间隔缩小到 78.125kHz，OFDM 符号时长拉长到 12.8 微秒，正好是前者的四倍。

子载波变密，同一个频宽里就能塞进更多子载波。20MHz 频宽里可用的数据子载波从 Wi-Fi 5 的 52 个增加到 234 个，40MHz 从 108 个增加到 468 个，80MHz 从 234 个增加到 980 个，160MHz 则达到 1960 个。子载波数量乘以每个符号的时长，得到的有效符号速率并没有变慢太多，因为符号时长放大的同时子载波数量也按比例放大，真正带来速率提升的是更高的调制阶数，也就是 1024-QAM。

Wi-Fi 6 还改了多用户机制，把整个信道按频率切成不同大小的 RU 资源块，可以同时给多个终端分配不同的子载波，这就是 OFDMA。它不直接提高单条链路的空口速率，但能把零碎的小包合并到同一个下行帧里发给多个终端，减少竞争开销，从而把实际吞吐往空口速率方向拉近一点。算空口速率时 OFDMA 本身不参与乘法，它只影响你最终能拿到几成。

2.3 空口速率的标准公式：四个乘数拆开看

Wi-Fi 6 的单流空口速率可以写成这样一个式子：

单流速率 = 数据子载波数 × 每子载波比特数 × 码率 × 符号速率

每子载波比特数由调制阶数决定：BPSK 是 1、QPSK 是 2、16-QAM 是 4、64-QAM 是 6、256-QAM 是 8、1024-QAM 是 10。码率是前向纠错编码的冗余比例，比如 5/6 表示每 6 个编码比特里只有 5 个是有效数据。符号速率是 OFDM 符号每秒钟能发多少个，等于 1 除以“符号时长 + 保护间隔 GI”。

最后把单流速率乘上空间流数 NSS，就得到整条链路的空口速率。802.11ax 最多支持 8 个空间流，但实际消费级 AP 很少超过 4 流，手机通常只有 2 根天线。整个公式看起来长，真正需要查表的只有三个数：频宽对应的数据子载波数、MCS 对应的调制比特和码率、GI 对应的符号速率。下面两章就把这些值全部列出来，用 80MHz 的算例走一遍。

3. 手算 80MHz 下的 WiFi6 空口速率：MCS、GI 和空间流怎么取值

3.1 取数：80MHz 的数据子载波、符号速率和 GI

先列数据子载波数。802.11ax 在不同频宽下使用不同大小的 FFT，20MHz 的 FFT 是 256、40MHz 是 512、80MHz 是 1024、160MHz 是 2048。扣掉保护边带、DC 空子载波和导频后，剩下的数据子载波数量如下表：

注意这里的“数据子载波”不是 RU 的概念。一个 80MHz 信道可以切分成多个 RU 给不同终端用，比如 2 个 242 吨 RU，或者 1 个 996 吨 RU；但算整条链路最大空口速率时，我们默认把全部 980 个数据子载波都分给同一个终端，用整信道传输。

符号速率取决于 GI。802.11ax 的 OFDM 数据符号本身是 12.8 微秒，GI 有 0.8、1.6、3.2 微秒三种，符号速率就是 1 除以 12.8 加 GI 的和：

很多厂商标称速率用的是 0.8 微秒 GI，因为能拿到最漂亮的数字；实际部署中，AP 可能因为覆盖距离、抗多径需要自动切到 1.6 甚至 3.2。后面你会看到，GI 从 0.8 换到 1.6，80MHz 双流的空口速率会从 2402Mbps 掉到 1088Mbps 附近，这个差距足以让排障方向完全跑偏。

3.2 从 MCS 0 到 MCS 11：调制阶数和码率的对照表

MCS 是 Modulation and Coding Scheme，Wi-Fi 6 把它从 Wi-Fi 5 的 0-9 扩展到了 0-11。MCS 0 到 7 沿用 802.11ac 的调制方式，MCS 8 和 9 是 256-QAM，新增的 MCS 10 和 11 是 1024-QAM。每子载波比特数要乘以码率才是有效数据比特，下面这张表直接用“有效比特/子载波”这一列，算速率时不用再乘一遍码率。

从这张表能直观看出 Wi-Fi 6 相对 Wi-Fi 5 的速率优势。Wi-Fi 5 最高只到 MCS 9，每子载波有效比特是 6.667，符号时长只有 3.6 微秒；Wi-Fi 6 在同样 80MHz 双流下，MCS 11 的每子载波有效比特是 8.333，符号时长拉长到 13.6 微秒但子载波数量从 234 涨到 980，几项相乘之后，速率从 867Mbps 跳到 2402Mbps，这正好是很多人觉得“换了个 Wi-Fi 6 路由器也没变快”却又说不清差在哪的根源。

3.3 完整算例：2400Mbps 是怎么凑出来的

现在用 80MHz、2 空间流、MCS 11、GI 0.8 微秒这组参数完整算一遍。先算单流：

单流速率 = 980 × 10 × 5/6 × 73529 = 980 × 8.333 × 73529 = 600.5Mbps

再乘上 2 个空间流，得到 1201Mbps。如果终端和 AP 都是 2×2 天线，最终协商速率就是 1201Mbps。那 2402Mbps 哪里来的？是 4 个空间流或者 160MHz 双流的场景。换成 160MHz 后数据子载波变成 1960，单流速率翻倍到 1201Mbps，双流就是 2402Mbps。

把常见组合算出来看看：

这里能看到一个常见的厂商标称套路：一台 Wi-Fi 6 路由器写 AX3000，往往是 2.4G 的 574Mbps 加上 5G 的 2402Mbps，两个频段各自独立计算后相加。如果你在终端上看到协商速率只有 1201Mbps，先别急着怀疑网卡缩水，看看是不是双天线 80MHz 的配置，这是当前手机和笔记本最常见的组合。

4. 把计算工具化：速查表与一段能复用的 Python 脚本

4.1 先定五元组：频宽、流数、MCS、GI、帧格式

每次算空口速率之前，先确认五个参数，缺一个都算不对：频宽是 20/40/80/160 中的哪一个；空间流数 NSS 是多少；协商到的 MCS 索引是多少；GI 是 0.8/1.6/3.2 微秒；帧格式是 HT、VHT 还是 HE。前四项在公式里都有明确位置，第五项经常被忽略，但 802.11n 的 40MHz 数据子载波是 108 个，802.11ax 的 40MHz 是 468 个，拿错帧格式整条公式都会错。

在 Windows 网卡状态里能看到“链接速度”，显示 1201/2402 这类数字；在 Linux 下用iw dev wlan0 link可以直观看到tx bitrate: 1201.0 MBit/s MCS 11 80MHz EHT这样的输出，里面的 MCS 和频宽就是算出来的结果反过来验证用的。如果拿不到终端的协商信息，也可以在路由器后台看已连接设备的 PHY Rate，厂商固件通常会把 MCS、频宽、流数一起显示出来。

4.2 一段 20 行以内的脚本算出全部 MCS 速率

手算一次两次还行，如果要对比多台 AP、多个 MCS 下的速率曲线，还是写个几行的脚本更省事。下面这段 Python 把数据子载波数、MCS 表和 GI 参数集中定义，输入频宽、空间流和 GI，直接打印出 MCS 0-11 的全部速率。

# wifi6_phy_rate.py DATA_SUBCARRIERS = {20: 234, 40: 468, 80: 980, 160: 1960} SYMBOL_US = 12.8 # 802.11ax OFDM 数据符号时长，微秒 # MCS: (调制比特, 码率) MCS_TABLE = { 0: (1, 1/2), 1: (2, 1/2), 2: (2, 3/4), 3: (4, 1/2), 4: (4, 3/4), 5: (6, 2/3), 6: (6, 3/4), 7: (6, 5/6), 8: (8, 3/4), 9: (8, 5/6), 10: (10, 3/4), 11: (10, 5/6) } def phy_rate(bw_mhz, mcs, nss=1, gi_us=0.8): subcarriers = DATA_SUBCARRIERS[bw_mhz] bits_mod, coding_rate = MCS_TABLE[mcs] symbol_rate = 1_000_000 / (SYMBOL_US + gi_us) # 每秒符号数 return subcarriers * bits_mod * coding_rate * symbol_rate * nss if __name__ == "__main__": bw = int(input("频宽 MHz(20/40/80/160): ")) nss = int(input("空间流数: ")) gi = float(input("GI 微秒(0.8/1.6/3.2): ")) print("MCS 速率(Mbps)") for mcs in range(12): rate_mbps = phy_rate(bw, mcs, nss, gi) / 1_000_000 print(f"{mcs:>3} {rate_mbps:>10.1f}")

这段代码的逻辑就是把公式里的四个乘数拆成变量传入，subcarriers从频宽表里取，bits_mod * coding_rate对应 MCS 表的有效比特，1_000_000 / (SYMBOL_US + gi_us)算出符号速率，最后乘 NSS。输出结果可以直接和厂商标称速率对比。比如输入80 2 0.8，MCS 11 那行会打出 1201.0Mbps；输入160 4 0.8，MCS 11 打出 4804.0Mbps。

参数上要注意三点：SYMBOL_US 固定 12.8 微秒只适用于 802.11ax，如果是 802.11ac 要改成 3.2；GI 输入必须是微秒单位，脚本内部转成符号速率时用了 1_000_000 换算；NSS 超过物理天线数没有意义，4 流必须 AP 和终端都有 4 根天线，实际消费级终端极少支持。脚本里没有处理 MU-MIMO 和 OFDMA，因为这两者不改变单条链路的空口速率计算。

4.3 常用组合速查表：2.4G 与 5G 的标称速率来历

把所有组合全列出来不现实，最常用的就是 MCS 11、GI 0.8 下不同频宽和流数的组合。这张表基本覆盖了市面上所有 Wi-Fi 6 路由器和终端的标称速率来源：

我说几个常见的对应关系：很多 Wi-Fi 6 手机是 2×2 天线、80MHz，协商速率 1201Mbps；部分旗舰手机支持 160MHz，协商 2402Mbps；路由器标 AX1500 一般是 2.4G 287 加 5G 1201；AX3000 是 2.4G 574 加 5G 2402 或 2.4G 287 加 5G 2402 的变体；AX5400 通常把 5G 做成 4 流 80MHz 的 2402 加 160MHz 降级使用，实际协商要看终端能力。速查表的用途是让你在产品页面看到 AX 后面的数字时，能快速反推它的频宽和流数配置，避免被“AX5400 一定比 AX3000 快一倍”这种话带偏。

5. 空口速率计算避坑指南：5 个最容易翻车的细节

这套计算最坑人的地方不在公式，而在取值。我踩过的和帮别人排查过的坑，集中在下面五个，每一条都是“现象 → 原因 → 解决”的完整链路。

5.1 把 256 个子载波当成数据子载波来算

现象：用公式算 20MHz 单流 MCS 11，有人算出来 160Mbps 甚至更高，和标准值 143Mbps 对不上。原因：20MHz FFT 是 256 个点，但其中包含 DC 空子载波、导频和保护边带，真正能传数据的只有 234 个。直接拿 256 乘，结果自然偏大。解决：用上表的数据子载波数，20MHz 取 234、40MHz 取 468、80MHz 取 980、160MHz 取 1960。记法很简单，把频宽除以 20 再乘 234，得到的就是对应数据子载波数，80MHz 就是 4×234=936，但这个近似值会略小于真实的 980，所以还是查表最稳。

5.2 GI 两边不一致，速率对不上号

现象：AP 后台显示协商速率 1201Mbps，按 MCS 11 80MHz 双流反推明明是 2402，差了整整一倍。原因：终端可能只支持 1 个空间流，或者用了 160MHz 的一半。但还有一种隐蔽情况是 GI 不一致，比如 AP 固定用 3.2 微秒 GI，双流 80MHz MCS 11 速率只有 1201×12.8/16=907Mbps 左右，与后台显示的数值差得很远。解决：先看协商信息里的 GI 字段，再在路由器后台把 GI 改成 Auto，让设备按信道质量选。0.8 微秒 GI 适合近距离无多径环境，远距离或高干扰环境下 AP 会自动切到长 GI，速率看起来会掉一截，这不一定是故障。

5.3 拿 WiFi5 的帧参数套 WiFi6 的速率

现象：有人在计算时把符号时长填成 3.2 微秒，算出来的 80MHz 双流 MCS 11 只有 560Mbps 左右，比实际协商低一半。原因：3.2 微秒是 802.11ac 的符号时长，Wi-Fi 6 的符号时长是 12.8 微秒，但子载波数是 Wi-Fi 5 的四倍，所以总速率反而是 Wi-Fi 6 更高；如果只改了符号时长不改子载波数，结果会完全错乱。解决：先确认帧格式。EHT 或 HE 的 PPDU 用 12.8 微秒；VHT 用 3.2 微秒，且数据子载波要按 802.11ac 的表取，80MHz 取 234 个而不是 980 个。最简单的方法是先看无线抓包里 Radio Tap Header 的 MCS 和带宽字段，再决定用哪张表。

5.4 把 MCS 11 当成常态

现象：排障时有人拿 MCS 11 的理论速率去对比现场测速，发现只有两三成，断定链路有问题。原因：MCS 11 需要非常高的信噪比才能维持，1024-QAM 对相位噪声和干扰极其敏感，距离稍远、隔一堵墙、周围有 5G 邻频干扰，速率立刻掉到 MCS 7 甚至 MCS 5。市面上的“标称速率”全部取 MCS 11 + 最短 GI，属于天花板数值。解决：看实际协商速率而不是标称值。终端从远处走回 AP 跟前，观察协商速率是否逐步爬升；如果贴近 AP 也只能协商到 MCS 5-7，才需要考虑天线、驱动或 AP 发射功率问题。理论计算用来理解上限，实际排障要用持续变化的实时速率。

5.5 拿空口速率去对打流测试结果

现象：空口速率 2402Mbps，iperf3 打满只有 900Mbps，有人开始怀疑设备有问题。原因：空口速率没有扣除任何协议开销。一个 802.11 数据帧的 MAC 头、PLCP 前导、SIFS、ACK、Beacon、重传和竞争窗口全部要占用时间，OFDMA 能提升效率但无法消除这些固定开销；再加上 TCP 的 ACK 往返和窗口限制，实际单向 TCP 吞吐通常在空口速率的 45%-70%，UDP 能高一些但也到不了标称值。解决：把计算值先乘以 0.6 做预估，再对比实测；如果实测连预估的一半都不到，再往下查信道干扰、重传率和 AP 的无线电配置。空口速率只是第一道公式，网络能不能跑满它还取决于第二道公式——协议效率和信道状况。

6. 一个验证习惯：用抓包里的 PHY 速率反推计算对不对

算完之后总得验证。最直接的办法是抓无线报文看 PHY 速率。在 Linux 上把无线网卡切到 monitor 模式后抓包，Wireshark 里展开 Radio Tap Header，能看到Data Rate、MCS index、Bandwidth和NSS字段，这些就是设备实际发每个帧时用的物理参数。比如抓到 MCS 11、80MHz、NSS 2，那这帧的空口速率就是 1201Mbps；如果 MCS 降到 7，速率就掉到 433Mbps 附近。拿这个真实值去对比你的计算脚本，能帮你发现到底是公式用错，还是设备协商参数本来就不是你想象的那组。

另一种验证方式是 iperf3 打流后做一次粗算。在同一房间无干扰环境下，TCP 单向吞吐大约是空口速率的 0.55-0.7 倍。协商 1201Mbps 的链路，iperf3 跑到 650-850Mbps 属于正常；隔墙后协商掉到 574Mbps，实测 250-400Mbps 也算正常。如果协商速率和实测吞吐的比值明显低于 0.5，再去抓包看重传率和信道利用率，这时候问题基本不在速率计算，而在干扰和空口竞争。

我的习惯是每拿到一台新 AP，先按它的频宽、流数和 MCS 支持能力算一张速率表，贴在本机排障文档里；遇到无线慢的反馈，先看协商速率落在表的哪一行，再决定是否值得深入抓包。这套方法帮我排掉过不少“无线慢”但实际是终端离 AP 太远、速率早就在 MCS 5 挂着的问题。希望帮到你。

本文还有配套的精品资源，点击获取