4、MAC层速率与广播：广播帧强制使用基础速率集

说到广播帧的速率问题，我得先跟你聊聊一个常见的误区。很多人觉得WiFi里的广播帧跟数据帧一样，可以自由选择速率。其实不是这样的。广播帧在MAC层有一个硬性规定——它必须使用基础速率集里的速率来发送。

为什么会有这个规定？你想想看，广播帧是发给所有站点的。如果我用一个高速率发出去，那些离得远的、信号差的设备可能就收不到了。所以协议设计者干脆规定：广播帧只能用最保守的速率。

4.1 基础速率集到底是什么？

基础速率集，说白了就是AP和所有关联站点都必须支持的速率集合。我习惯把它理解成「保底速率池」。每个BSS（基本服务集）在Beacon帧里都会广播这个集合。

举个例子，一个802.11n的AP，它的基础速率集可能是这样的：

速率 (Mbps)	调制方式	是否强制
1	DSSS	是
2	DSSS	是
5.5	CCK	是
11	CCK	是
6	OFDM	可选
12	OFDM	可选
24	OFDM	可选

注意看，1、2、5.5、11 Mbps是强制支持的。6、12、24 Mbps是可选的。广播帧只能从强制支持的那些速率里选。

4.2 速率选择策略：谁来决定用哪个速率？

嗯，这里有个有意思的问题。既然基础速率集里有多个速率可选，那广播帧到底用哪个？

我记得在早期的项目里，很多AP厂商直接写死用1 Mbps。为什么？因为1 Mbps覆盖范围最大，最保险。但这样做有个问题——太慢了。

后来我参与过一个大型场馆的WiFi部署，客户投诉说广播风暴导致网络卡顿。我一查，AP的广播帧全用1 Mbps发。一个1500字节的广播帧，在1 Mbps下要占将近12毫秒的空中时间。你想想看，如果AP每秒发10个广播帧，光广播就占了120毫秒的无线介质时间。

现在的速率选择策略一般分几种：

• 固定最低速率：直接用基础速率集里的最低值，比如1 Mbps。覆盖最好，但效率最差。
• 自适应选择：AP根据当前网络状况，从基础速率集里选一个相对高的速率。比如在干扰小的环境下用11 Mbps。
• 混合策略：管理帧（Beacon、Probe Response）用低速率，数据广播帧用较高速率。

4.3 低速率带来的长时占用问题

这才是本章的核心痛点。低速率广播帧对网络性能的影响，比你想象的要严重得多。

咱们来算一笔账。一个标准的以太网MTU是1500字节，加上MAC头、FCS，在无线介质上实际传输的数据量大约是1544字节。

速率 (Mbps)	传输时间 (微秒)	相对1 Mbps的倍数
1	12352	1x
2	6176	2x
5.5	2246	5.5x
6	2059	6x
11	1123	11x
24	515	24x

看到差距了吗？1 Mbps下传一个广播帧要12.3毫秒，而24 Mbps只需要0.5毫秒。差了将近24倍。

我曾经在一个仓库项目里遇到过这种情况。仓库里有上百台扫码枪，它们会频繁发送ARP广播。AP配置不当，广播帧全用1 Mbps发。结果扫码枪经常超时断连。我抓包一看，无线介质上广播帧占了将近40%的占用时间。后来我把广播帧基础速率调到11 Mbps，问题立刻缓解了。

4.4 核心知识框架

为了让你更直观地理解广播帧速率选择的整个逻辑，我画了一张流程图：

4.5 实际项目中的调优建议

说了这么多理论，最后给你几个我在实际项目中用过的调优方法：

1. 检查AP的广播速率配置：很多AP默认用1 Mbps。我建议至少调到6 Mbps（OFDM）。如果覆盖范围允许，调到11 Mbps甚至24 Mbps更好。
2. 区分管理帧和数据广播帧：Beacon帧用低速率保证覆盖，ARP、DHCP等数据广播帧用较高速率。
3. 减少不必要的广播：有些广播是可以优化的。比如用静态ARP表减少ARP广播，用DHCP中继减少跨网段广播。
4. 抓包验证：用Wireshark抓个包，看看广播帧实际用了什么速率。我习惯在过滤条件里写 wlan.fc.type_subtype == 0x0008 来过滤Beacon帧，看它的速率信息。