企业官网建设流程全解析

简介：这是一份围绕WiFi 6（即IEEE 802.11ax标准）空口速率计算的技术资料，适合网络工程师、无线网络运维人员以及正在备考无线技术认证的学习者阅读。文档从五个关键因素入手——MIMO空间流数量、Symbol与保护间隔GI、调制编码方式、码率以及有效子载波数量——逐项解释它们如何影响最终的空口速率，并结合华为AP4050DN等多射频设备实例，阐明实际建链速率通常“就低不就高”的规则，帮助读者建立从理论峰值到实际速率的完整换算思路。文件为单个PDF文档，大小204KB，内容篇幅紧凑、结构清晰，适合在碎片时间快速查阅。已有179人学习下载，对需要理解WiFi 6速率构成、定位无线性能瓶颈，或为网络规划与优化提供依据的人来说，是一份高效实用的速查手册。

1. WIFI6空口速率计算：标称2402Mbps，为什么现场只能跑一半

第一次接触无线项目的人，最容易在三句话里翻车：路由器包装印着AX3000，手机连接状态显示2402Mbps，实际测速却只有一半。这个差距不是设备缩水，而是因为“空口速率计算”本身就依赖一组可变参数。同样做WIFI6空口速率计算，算80MHz还是160MHz、算短GI还是长GI、算MCS11还是MCS9，结果能差出两倍以上。这套计算是无线网优、AP选型和现场排障的基本功，也是判断“协商速率是不是被环境压制”的第一把尺子。下面按我自己的计算习惯，把公式、参数、代码和踩过的坑完整拆一遍。

2. 空口速率公式拆解：5个参数怎么凑出一个2402Mbps

2.1 先建立公式：一个OFDM符号里能装多少比特

空口速率也叫PHY Rate，指的是物理层在无线介质上每秒钟能搬运多少比特。它和“你下载能跑多快”差着一层协议开销，但它是所有上层吞吐的上限。计算它的核心不是“带宽×效率”这种模糊估算，而是先搞清楚一个OFDM符号里能装多少信息比特，再除以这个符号占用的时间。

PHY Rate (Mbps) = 数据子载波数 × 调制阶数比特数 × 编码率 × 空间流数 / (符号时长 + GI)

以Wi-Fi 6最常见的80MHz带宽、单流、MCS11、短GI为例，一步一步算：

• 80MHz带宽下有980个数据子载波
• MCS11对应的调制方式是1024QAM，每个子载波承载10比特
• 编码率是5/6，即FEC前向纠错后，每6个编码比特里只有5个是真正的用户信息比特
• OFDM符号时长是12.8微秒，短GI是0.8微秒，总时长13.6微秒

带入公式：980 × 10 × 5/6 ÷ 13.6 = 600.5Mbps。这就是80MHz下一条空间流的理论最高速率。如果路由器是2条空间流，乘以2，得到1201Mbps；如果是160MHz带宽，数据子载波翻倍，再乘以2条流，就得到2402Mbps。市场上所谓AX3000路由器的5G标称2402Mbps，就是这么算出来的。

2.2 决定速率的5个变量：从MCS到空间流怎么取值

上面公式里有5个关键变量，任何一个取错，结果都会偏离现场实际协商速率。

其中MCS（Modulation and Coding Scheme）是最容易搞混的。Wi-Fi 6的MCS范围是0到11，MCS0是BPSK，每子载波1比特，抗干扰能力最强；MCS11是1024QAM，每子载波10比特，需要非常好的信噪比。两个设备协商出来的MCS通常不是一个固定值，它会随信号强度自动升降。做空口速率计算时，我一般会先看终端当前协商的MCS是多少，再反推“如果环境好一点，它能升到哪一档”。

2.3 带宽翻倍为什么速率接近翻倍：子载波与FFT的关系

不少刚上手的人会问：Wi-Fi 6把OFDM符号时长从Wi-Fi 5的3.2微秒拉长到12.8微秒，等于每个符号慢吞吞跑了4倍时间，为什么速率不降反升？

关键在于子载波数量。Wi-Fi 6把子载波间隔从312.5kHz缩小到78.125kHz，等于把同一段频谱切得更细。Wi-Fi 5在80MHz下只有234个数据子载波，Wi-Fi 6在同样的80MHz下能塞进980个数据子载波，数量大约是4.19倍。子载波多了，符号时长也变成了4倍，二者基本抵消，剩余的提高来自调制阶数从256QAM的8比特升到1024QAM的10比特，加上子载波利用率的细微提升。

所以Wi-Fi 6单流空口速率比Wi-Fi 5单流快30%~40%，而不是快4倍。厂商宣传的“Wi-Fi 6速率翻倍”，更多是靠更多空间流、更大带宽、OFDMA调度效率一起堆出来的。这个认知对后续做容量规划很重要：别指望只靠升级到Wi-Fi 6，单终端单流速率就能有质的飞跃。

3. WIFI4、WIFI5和WIFI6的区别：一张参数表看懂三代速率变化

3.1 三代空口速率对比表：WIFI4、WIFI5、WIFI6参数一览

把这几年被问得最多的“wifi4和wifi5和wifi6的区别”浓缩成一张表，参数上的差异就藏在这些行里：

注意Wi-Fi 4和Wi-Fi 5的符号时长都是3.2微秒，子载波间隔完全相同，差别主要在调制阶数从64QAM升到256QAM，于是MCS上限从7提升到了9。Wi-Fi 6则把整个物理层换成更细的子载波粒度，符号时长拉长4倍，也为OFDMA这种多用户调度打下了基础。

3.2 符号时长变大反而更快：子载波间隔变小是关键

单看符号时长，Wi-Fi 6的12.8微秒比Wi-Fi 5的3.2微秒慢了4倍，但如果只盯着这个数字，就会得出“Wi-Fi 6更慢”的错误结论。

OFDM符号时长和子载波间隔互为倒数。Wi-Fi 5的子载波间隔是312.5kHz，Wi-Fi 6缩到78.125kHz，正好是前者的四分之一，对应符号时长就是4倍。间隔变小意味着每个子载波占的频带更窄，同一段带宽里能放的子载波更多。Wi-Fi 6的20MHz能放234个数据子载波，而Wi-Fi 5的20MHz只有52个。

把两代放在同一个80MHz带宽下看，Wi-Fi 6的数据子载波数是980，Wi-Fi 5是234，大约是4.19倍。再考虑调制从8比特提到10比特，以及GI总时长的选择，单流峰值从433Mbps升到600Mbps就解释得通了。

3.3 从空口速率计算反推路由器标称值：AX3000里的574和2402

很多人看到路由器号称AX3000，以为5G频段能跑3000Mbps。实际上这个数字是2.4GHz和5GHz两个频段的理论速率相加。

先算2.4GHz部分：2条空间流、40MHz带宽、MCS11、短GI，数据子载波468个。468 × 10 × 5/6 × 2 ÷ 13.6 = 573.5Mbps，厂商取整叫574Mbps。再算5GHz部分：2条空间流、160MHz带宽、MCS11、短GI，数据子载波1960个。1960 × 10 × 5/6 × 2 ÷ 13.6 = 2402Mbps。574 + 2402 = 2976，约等于3000，这就是AX3000的由来。

这个反推过程对做网络选型很有用。看到任何标称速率，先拆带宽、空间流、MCS和GI，就能判断它是在什么理想条件下算出来的。比如某些标称AX6000的设备，如果5G是4条流跑160MHz，理论值达到4804Mbps，再加上2.4GHz的1148Mbps，才凑出接近6000的总数。如果AP的回传网口只有1Gbps，那5G的空口速率再高，实际吞吐也会被网口卡死。

4. 用Python把空口速率算出来：20行脚本、三组验证用例

4.1 一个可以直接抄的Python脚本

公式本身不复杂，但每次手算容易把GI、MCS这些东西搞混。我习惯把它写成一个函数，需要对比时直接调用。

# phy_rate.py —— Wi-Fi 4/5/6 空口速率计算 # 用法示例： # python phy_rate.py 80 1 11 0.8 # python phy_rate.py 160 2 11 0.8 import sys # 各协议、各带宽下的数据子载波数（常用工程值） HT_SUBCARRIERS = {20: 52, 40: 108} # Wi-Fi 4 VHT_SUBCARRIERS = {20: 52, 40: 108, 80: 234, 160: 468} # Wi-Fi 5 HE_SUBCARRIERS = {20: 234, 40: 468, 80: 980, 160: 1960} # Wi-Fi 6 # 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), # 256QAM 10: (10, 3/4), 11: (10, 5/6), # 1024QAM } def phy_rate(data_subcarriers, mcs, streams=1, gi_us=0.8, symbol_us=12.8): bits, code_rate = MCS_TABLE[mcs] symbol_time_us = symbol_us + gi_us # 符号总时长，单位微秒 bits_per_symbol = data_subcarriers * bits * code_rate * streams return bits_per_symbol / symbol_time_us # 比特/微秒，数值上等于Mbps if __name__ == "__main__": bw = int(sys.argv[1]) streams = int(sys.argv[2]) mcs = int(sys.argv[3]) gi = float(sys.argv[4]) print(round(phy_rate(HE_SUBCARRIERS[bw], mcs, streams, gi), 1))

这段代码的逻辑很好理解：先取带宽对应的数据子载波数，再从MCS表里取出每子载波比特数和编码率，三者相乘得到每个符号承载的信息比特数，最后除以符号总时长。因为比特/微秒就等于Mbit/s，所以不需要再额外乘任何单位换算系数。

脚本默认按Wi-Fi 6的12.8微秒符号时长算，如果要用Wi-Fi 4/5，手动把symbol_us改成3.2即可。GI参数根据终端实际协商值传，0.8和1.6是最常用的两个短GI和长GI档位。

4.2 用三组已知速率验证脚本结果

脚本写完先不急着用，跑三组已知结果验证一下。这三组数值都是厂商标称和驱动里常见到的，能对上就说明参数表没写错。

print(round(phy_rate(HE_SUBCARRIERS[80], 11, 1, 0.8), 1)) # 80MHz 1流 MCS11 print(round(phy_rate(HE_SUBCARRIERS[80], 11, 2, 0.8), 1)) # 80MHz 2流 MCS11 print(round(phy_rate(HE_SUBCARRIERS[160], 11, 2, 0.8), 1)) # 160MHz 2流 MCS11

输出结果应该是600.5、1201.0和2402.0。这三个数字分别对应80MHz单流峰值、80MHz双流峰值、160MHz双流峰值。第二组和第三组正是很多路由器标称值里反复出现的数字。如果跑出来不一致，先检查MCS表里的编码率是不是写成了5/6以外的值，再检查GI有没有被错误地叠进符号时长里。

4.3 把WIFI4、WIFI5、WIFI6放进同一个循环对比

实际选型时经常要对比三代设备在同一带宽下的表现，写一个循环把三张子载波表都过一遍会更直观：

def compare(table, symbol_us, gi_us, max_mcs, name): for bw, subcarriers in sorted(table.items()): rate = phy_rate(subcarriers, max_mcs, 1, gi_us, symbol_us) print(f"{name} {bw}MHz MCS{max_mcs} 单流: {rate:.1f} Mbps") compare(HT_SUBCARRIERS, 3.2, 0.4, 7, "Wi-Fi 4") compare(VHT_SUBCARRIERS, 3.2, 0.4, 9, "Wi-Fi 5") compare(HE_SUBCARRIERS, 12.8, 0.8, 11, "Wi-Fi 6")

这里分别给三代协议传了不同的符号时长和GI，因为Wi-Fi 4/5的短GI是0.4微秒，而Wi-Fi 6最短只能到0.8微秒。注意Wi-Fi 4不支持80MHz带宽，所以循环里只会输出20MHz和40MHz两行。看到Wi-Fi 4的40MHz单流只有150Mbps，而Wi-Fi 6能到286.8Mbps，就很容易理解“同样一条流，为什么换到Wi-Fi 6路测数据能翻一倍”。

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

5.1 GI取值与符号总时长：算出来的速率差几十Mbps

现象：用脚本算出600Mbps，终端连接信息里显示的却是567Mbps，差出30多Mbps。

原因：终端或AP实际协商用的是长GI（1.6微秒），不是短GI（0.8微秒）。把GI加进符号总时长后，分母从13.6微秒变成14.4微秒，速率自然掉下来。有些驱动在信号一般时会主动切长GI来提升抗多径能力。

解决：先查协商结果里的GI字段，再决定用哪个值代入计算。Linux下直接看iw命令输出里的rx bitrate，Windows下看无线网卡状态的“链路速度”旁是否有GI标识。没有明确标识时，建议把0.8和1.6两种GI都算一遍，看哪个数字和驱动显示更接近。

5.2 有效子载波和数据子载波：导频不是用来传用户数据的

现象：有同事把80MHz的有效子载波数当成数据子载波数，算出来的结果偏高，和驱动对不上。

原因：Wi-Fi 6 80MHz信道里，有效子载波数量接近1000个，但其中有一部分是导频子载波，用于信道估计和相位跟踪，不承载用户数据。常见工程值里，数据子载波取980个，剩余的部分是导频、直流子载波和保护边缘。

解决：做空口速率计算时，数据子载波直接使用协议表里给出的值：20MHz用234，40MHz用468，80MHz用980，160MHz用1960。不同芯片厂商的文档里个别子载波数会有几个数字的出入，以IEEE标准表或驱动协商结果为准，不要在公式里混用有效子载波总数。

5.3 MCS索引映射错：MCS9不是1024QAM

现象：用Wi-Fi 5的思维算Wi-Fi 6，看到MCS9就以为是4096QAM或1024QAM，速率算得特别高。

原因：MCS索引是跨协议共享的，MCS9在Wi-Fi 5和Wi-Fi 6里都对应256QAM、编码率5/6，每子载波8比特。只有MCS10和MCS11才属于1024QAM。厂商宣传“支持1024QAM”说的是上限，不代表终端当前协商到了这一档。

解决：把MCS表打印出来贴在工位旁边。算之前先确认三个数字：调制阶数、编码率、子载波比特数。下面是常用索引对应关系，MCS7、MCS9、MCS11是三代的最高档，最容易张冠李戴。

5.4 空间流不是单纯乘流数：每流MCS可以不同

现象：AP是4×4 MIMO，手机是2×2，按4条流算出来的速率，现场永远跑不到。

原因：空口速率公式里的空间流数要取“终端实际支持的流数”和“AP实际协商的流数”里较小的那个。更重要的是，多流场景下每一条流的MCS可能不同。信号差的时候，第二流可能掉到MCS7，而第一流还在MCS11。这时正确做法是把每条流各自算出的速率相加，而不是先算单流再乘流数。

解决：从驱动里读到每条流的MCS再计算。Linux下iw station dump会显示每个已连接客户端的rx/tx bitrate，如果看到多行bitrate，说明是多流各自协商的结果。加快部署时需要记住：双流MCS11的理论值约1201Mbps，但现场信号稍微波动，第二流跌到MCS9，总速率马上降到约1033Mbps。

5.5 拿空口速率当作实际吞吐：协议开销还没扣

现象：空口速率算出600Mbps，iperf TCP测试只有400Mbps出头，第一反应是设备有问题。

原因：空口速率是物理层承载用户信息的纯速率，它没算MAC层帧头、确认帧、帧间间隔、Beacon、退避和重传。这些开销在干净环境里大约占20%~30%，干扰严重时更多。拿空口速率直接预测吞吐，就是把理论马力当成轮上马力。

解决：工程里用“空口速率 × 0.7~0.8”作为单终端实际吞吐上限的粗估。比如2402Mbps的空口速率，回传和终端都理想时，测速能到1.6~1.9Gbps就已经是合理范围。低于这个范围优先查干扰和重传率，高于这个范围基本是厂商标称口径和实测口径不一致。

6. 算完空口速率之后：三个现场验证习惯

6.1 用协商速率反查AP配置

拿到现场设备的协商速率后，我习惯先反推一遍。Linux下用一条命令就能看到客户端的实际物理速率和信号强度：

iw dev wlan0 station dump | grep -E "signal:|rx bitrate:|tx bitrate:"

如果协商速率是567Mbps而不是600.5Mbps，说明GI跑在1.6微秒；如果协商速率只有433Mbps，说明MCS掉到了MCS9。这个信息能直接告诉我AP的频宽设置是否生效、信道干扰是否压制了调制等级。

6.2 用空口速率估算真实吞吐上限

用计算值乘以0.7到0.8，得到吞吐预估上限，再和iperf3实测值对比。偏差在20%以内属于正常，偏差超过30%时，我会先查AP的射频利用率、客户端的重传率和同信道的其他AP数量。记住空口速率是个黑匣子的出口，不是实测承诺。

6.3 别忘了一条被低估的回传链路

最后是这些年调Wi-Fi 6最容易翻车的血泪经验：空口速率算完，记得看一眼AP的网口。一个双流160MHz的Wi-Fi 6 AP，空口速率已经到2402Mbps，如果网口只有1Gbps，实测最高也就940Mbps左右。给客户做方案时，我会把“空口速率需要回传链路预留50%余量”写进配置要求里，避免验收时双方都尴尬。

先把理论值算清楚，再对照驱动里的协商速率，最后用iperf实测校准，这套流程我每次做无线优化都会走一遍。建议你拿到自己的设备后，也把这几个数字算出一张表，以后遇到标称值和现场值对不上时，能少很多猜测。希望帮到你。

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