Wi-Fi DCF机制详解：从CSMA/CA到退避算法，一文看懂空口竞争

开头我先说个现象：很多做Wi-Fi调优、嵌入式联网、路由器开发、甚至无线协议排查的人，翻了很多802.11的文档，帧结构、扫描、连接过程都聊过了，但一碰到“为什么这个设备发消息要等这么久”“为什么两台设备一抢信道就猛重传”这类问题时，还是会卡壳。答案基本都指向同一个底层机制——DCF（Distributed Coordination Function，分布式协调功能）。这是Wi-Fi介质访问控制的基石，也是本篇要单独拉出来讲透的核心内容。

DCF解决的问题很简单：所有Wi-Fi设备共享同一个无线信道，而无线电天生是半双工的，谁先说、说多久、说完怎么让下一个人接上，必须要有一套公共的“排队规则”。否则所有人都抢着开口，结果就是谁也听不清。这篇我按基本访问流程一条线走下来，从为什么无线不能用有线那套冲突检测，到DIFS/SIFS/时隙这些时间参数到底在设计什么，再到二进制指数退避的具体算法和抓包实测怎么验证，最后讲几个容易踩的细节。适合刚开始啃802.11协议的工程师，也适合被“信号满格但总是卡”折腾过的运维同学，读完你至少能看懂空口抓包里那些帧与帧之间间隔的意义。

1. 为什么无线不能照搬有线的冲突检测

有线以太网大家都很熟，CSMA/CD（载波侦听多路访问/冲突检测），核心逻辑是“边发边听”：发送的同时一直在监听线缆上的电平，如果发现电平异常、电压突变，说明有两个站同时在发，立刻停止，然后等随机时间重传。这个机制在铜缆上成立，因为发射和接收共享同一根线，发送时自己发出的信号会被自己收到，一旦叠加了别人的信号就能检测出来。

但无线射频这条路径走不通，原因有三个。

第一个原因是物理层的收发隔离。绝大多数Wi-Fi设备在同一时刻只有一套射频前端，天线在发送和接收之间切换。发送的时候，发射功率通常在几十毫瓦到几百毫瓦，而接收路径要处理的信号往往在微瓦甚至纳瓦量级，中间差了上百分贝。如果真要做到“边发边听”，从电路上就得付出巨大代价去隔离发射信号对接收机的压制，这在成本和功耗上都不现实。所以Wi-Fi设备在单链路上必须要么发、要么收，半双工是硬约束。

第二个原因是动态范围问题。就算设备能同时收发，无线信道里每个接收点的信号强度差别悬殊，近处的强信号会把远处的弱信号完全淹没。有线以太网里电平只有0和1两态，冲突检测阈值好定；无线信道里“弱信号的正常接收”和“强信号的冲突叠加”在幅度上难以区分，硬做冲突检测很容易误判。

第三个原因也是最经典的——隐藏节点问题。设备A和设备C都在设备B的覆盖范围内，但A和C互相听不见。A正在给B发数据的时候，C去做载波侦听，发现信道是“空闲”的，于是C也启动发送，结果B处收到两个信号叠加，全部损坏。这就是CSMA/CD的“先听后说”策略在无线环境下的盲区。A和C谁也听不到谁，冲突检测从源头就不成立。

所以802.11标准委员会换了一条路：有线用CSMA/CD，无线就用CSMA/CA（CA = Collision Avoidance，冲突避免）。怎么避免？核心思路不是“检测冲突”，而是“尽量避免冲突”：

• 发送之前先侦听信道，信道忙就等着，不抢。
• 信道从忙变闲后，不要立刻冲出去发，而是先等一段固定间隔（DIFS），再执行一个随机退避计数。
• 发完之后接收方要回一个ACK确认；如果发方没等到ACK，就认为这次发送失败，重新走“等DIFS+随机退避”的流程。

这套规则就是DCF基本访问流程的骨架。它不能完全消除冲突，但能把冲突概率压到可以接受的范围，同时用ACK超时兜底，保证每一次“数据+确认”的完整事务。只要理解了“无线听不到冲突，只能靠规则躲冲突”这个前提，后面所有时间参数和退避算法的设计动机就都顺了。

2. 关键时间参数：DIFS、SIFS、时隙是全局节奏器

DCF整个流程都建立在几个精心设计的“等待时间”上。这些时间因为802.11物理层不同而有所差异，802.11a/g/n/ac的OFDM体系一组数值，802.11b是另一组，802.11ax即Wi-Fi 6在20MHz带宽下又有所调整。但设计逻辑是一致的：不同功能的帧之间，等待时间越短，说明优先级越高。

常用的DCF时间参数值（OFDM体系，802.11a/g/n/ac，20MHz）如下：

802.11b那套是：Slot Time 20 μs，SIFS 10 μs，DIFS 50 μs。你写代码做时序模拟或者估算吞吐上限时，一定要先确认自己用的是哪套PHY参数，混用的话计算结果会差出一大截。

为什么要有这么多层时间？因为无线介质上“沉默就是话语权”。一台设备保持沉默的时间越长，就意味着越多的设备有了插入机会；而系统通过规定“谁必须等更久才能开口”，就实现了功能和优先级上的区分。

SIFS最短，只有16微秒，它留给ACK、CTS这类帧。数据帧到达接收端之后，接收端只需要校验FCS、确定帧类型，然后立刻回ACK，这个过程不需要竞争信道，因为信道状态是确定的——刚才数据帧还在占用信道，其他站都在等，ACK插在SIFS这个空档里发出去，几乎不可能被抢。SIFS高效的本质是：利用“当前信道占用方刚结束发送”的确定性，让紧跟着的响应帧毫不费力地拿回话语权。可以把它理解为“插队特权”，特权只给真正需要快速反馈的控制帧。

DIFS则长得多，34微秒。普通数据帧必须在信道空闲后先等满DIFS才能开始退避或发送。这个长度确保了当两个站在同一个时刻发现信道空闲时，任何一方都不能立刻发，这段时间让所有站都进入“准备竞争”的状态。为什么DIFS恰好是SIFS加两个时隙而不是一个？因为需要给ACK这类SIFS响应留出充足的时间窗口，避免数据帧的DIFS等待和上一帧的ACK回收出现重叠。

然后是时隙（Slot Time）9微秒。它有两个任务：一是提供退避计数的时钟粒度，二是让物理层的载波侦听有足够时间去稳定判断信道忙闲。如果时隙太短，一台设备刚检测到信道状态变化，发出的信号还在空中飞，别的设备根本来不及感知，退避机制就会失效；如果太长，每次退避等待浪费的时间就多，整体吞吐率直线下降。9微秒是标准委员会在物理层检测时间、传播延迟、处理时延之间折中出来的结果。

EIFS相对特别：当一台设备收到一个无法正确解码的帧时，它不能立刻用DIFS，而要等待更长的EIFS。原因是它不知道那个错误帧的接收者是谁，害怕自己冒然插入会踩到一个正在进行的重传流程。EIFS的长度设计得比DIFS长，实际上是给“我不知道发生了什么”的状态一个缓冲期，避免干扰一个可能是SIFS级的响应。这是在错误场景下的保守策略。

这几个时间参数看起来只是枯燥的微秒数，但它们共同决定了不同帧的接入优先级，也在物理上划定了DCF的基本行为边界。搞透了它们，再去看抓包文件里帧间隔，很多过去觉得“奇怪”的现象会突然解释得通。

3. 基本访问流程的完整时序：从信道空闲到ACK到达

DCF基本访问流程，标准里叫“Distributed Coordination Function basic access procedure”。标准把行为拆得很细，但归拢起来就是下面这条线。我按实际发生的顺序从头讲一遍。

3.1 持续侦听与初始判断

设备有数据帧要发时，第一步不是直接发，而是持续侦听信道。这里要分两种情况。

情况一：信道本来就空闲，而且设备在发这个帧之前没有再发送过其他帧，那它可以等完一个DIFS直接发送。注意这个细节——如果信道一直空闲，且设备没有待发送的后继帧，DIFS之后可以不用退避。这种情况发生在两个连续发送之间间隔了很久的场景，竞争风险低，直接发不会有大问题。

情况二：信道处于忙状态，或者设备刚发完一个帧又要继续发下一个帧。这时候设备必须等待信道从忙变空闲，再等一个DIFS，然后执行退避算法，退避计数器减到0之后才能发送。为什么刚发完下一帧反而要退避？因为“刚发完”意味着你在上一个竞争周期里赢过了别人，如果不强制退避，一个设备可能会连续霸占信道，其他设备永远抢不到机会。这种公平性保护是DCF的重要组成部分。

3.2 退避槽的递减与冻结

进入退避阶段后，设备从竞争窗口CW（Contention Window，竞争窗口）里随机选一个整数，乘以时隙9微秒，就是退避需要等待的总时间。比如选中退避数5，就需要等待5个时隙，即45微秒。

窗口大小在最小值之间浮动，后面详述。

退避的递减有个关键规则：只有在信道持续空闲的时隙里，计数器才递减；信道一旦变忙，计数器立刻冻结，直到信道再次空闲并等完DIFS后，才从冻结位置继续递减。这一条是DCF公平性的核心。试想一下，如果信道忙时不冻结，设备A退避到3的时候被信道忙打断，等信道空了大家都重新随机选数，那设备A过去等待的时间就白费了，每次都前功尽弃，永远发不出去。有了冻结机制，设备A下次恢复时直接从剩余3个时隙继续倒数，它仍然保留着比后加入者更早发送的权利。这样一来，所有设备都“按先来后到+随机扰动”的方式有序推进，长时间看公平性有保障。

从工程角度看，这个机制还带来一个间接效果：设备在退避期间实际上是在持续跟踪信道的忙闲状态。只要出现一次“FREEZE”，就说明空中还有其他竞争者的流量，系统会自动推迟发送，从而在宏观上实现了多个站点之间的信道时间分配。

3.3 发送数据帧与接收端响应

当退避计数器减到0，设备用当前选择的调制速率把数据帧发出去。这里有个容易被忽略的点：发送完成后，发送方并不会立即认为帧已经成功，它会开启一个ACK超时定时器，等待接收方的确认。

接收方在正确收到数据帧且通过FCS校验后，等待SIFS（16μs），然后回复一个ACK帧。因为ACK用的是SIFS间隔，它比任何等待DIFS的数据帧都有优先权，所以这段“数据+ACK”的交换过程会作为一个不可分割的整体完成，中间不会夹进别的站的数据发送。

为什么需要ACK？因为无线信道随时随地都可能被干扰、多径衰落、叠加冲突。发送方自己不知道信号在空中损坏了，它必须依赖接收方的显式确认来判断“上一步到底成了没有”。这就是DCF实现可靠交付的基本逻辑——每发一个帧都要拿一个确认，没有确认就重来。

3.4 成功与失败的处置

发送方收到ACK后，流程画上句号。如果还有下一个待发帧，那就要重新执行整个竞争流程去抢信道，这样保证每个帧都是公平竞争的产物。如果没收到ACK，在定时器超时后，发送方判断发送失败，于是把竞争窗口翻倍，重新随机选退避值，再走一遍“等DIFS+退避”的流程。

失败的原因可能很多：帧在空中被干扰了、两个站同时发送导致冲突了、接收方不在覆盖范围内等等。发送方无法从失败中区分具体原因，它只能选择重发。同时，为了避免一个帧无限重发占用资源，标准设置了重试上限：短帧的重试上限通常为7次，长帧为4次。一旦超过上限，发送方就丢弃这个帧，向上层报告传输失败，由上层协议（如TCP）决定要不要再做端到端重传。

3.5 基本访问流程与RTS/CTS的关系

这里多提一句RTS/CTS，虽然本篇标题是“基本访问流程”，但它和RTS/CTS是DCF并列的两种访问方式。基本访问就是上面说的“DATA+ACK”直来直去；RTS/CTS则是在数据发送前先用两个短控制帧“握手”——发送方发RTS，接收方回CTS，然后才开始真正的DATA交换，整套过程用SIFS串起来：

发送方发RTS → 等待SIFS → 接收方回CTS → 等待SIFS → 发送方发数据帧 → 等待SIFS → 接收方回ACK

RTS/CTS的价值在于降低冲突代价。RTS和CTS帧很短，即使它们互相冲突，损失的时间也很有限；而数据帧往往很长，最坏情况下会占用信道好几毫秒，直接在数据阶段冲突的代价极大。不过RTS/CTS默认是关闭的，因为它的握手开销在信道比较空闲、数据帧又不太长的时候很不划算。工程上通常设置一个RTS阈值，只有当帧长超过阈值时才启用RTS/CTS保护。

4. 退避算法：二进制指数退避是怎么算出来的

退避算法是DCF里最容易被一句话带过、但实际最多细节的部分。它直接决定了网络在竞争激烈时的稳定性和公平性。

4.1 竞争窗口的取值与变化规律

802.11标准规定，每个发送设备维护一个竞争窗口CW，它始终处于两个边界之间：

• CWmin（最小竞争窗口）：802.11a/g/n/ac OFDM体系下为15。
• CWmax（最大竞争窗口）：同一体系下为1023。

设备发送前，从[0, CW]这个闭区间里按均匀分布随机取一个整数，记为backoff。实际等待时间就是backoff × Slot Time，也就是9微秒的整数倍。

第一次发送的时候，CW取CWmin的值15，相当于退避槽数从0到15随机选一个，平均7.5个时隙。发送失败后，为什么选择翻倍策略？以A、B两个站点为例：假设它们同时抢信道，同时发帧导致冲突。下一次它们各自从[0,15]里随机选退避数，A选了5，B选了12，A等45微秒后先发，B还在等——冲突解决了。但如果A和B的下一次随机数又撞车，再次冲突之后，CW翻倍到31，两个站从更大的范围里选数，撞车的概率显著降低。冲突次数越多，CW越大，可选范围越广，大家错开发送时机的能力就越强。

CW的翻倍规则与上限对应如下：

实际标准按PHY不同有差异。OFDM体系下，CWmin=15、CWmax=1023；11b下CWmin=31、CWmax=1023。翻倍运算在达到CWmax后就不再继续增大，但重试次数继续累计，直到超过重试上限丢弃帧。

这里有一个容易搞混的点：CW翻倍是从第二次发送尝试开始的。也就是说，第一次发的时候用CWmin，失败一次重试时CW翻到31，失败两次重试时翻到63。CW的封顶是1023，就算你重试了100次，它也只停在1023，不会再涨了。

4.2 退避计数与冻结的协同

选好退避数之后，设备在每个空闲时隙将计数器减1。如果信道在某个时隙中间变忙了，计数器冻结在当下的数值，直到信道空闲且再次等待完一个DIFS后继续递减。

举个例子：设备A选择退避数8。前3个时隙信道空闲，计数器从8减到5。第4个时隙，隔壁设备的帧到了，信道变忙，计数器冻结在5。信道忙了约2ms后恢复空闲，A等完一个DIFS（注意，这里等的是完整的DIFS，不是剩余时间），然后继续从5往下数。为什么等完整的DIFS？因为要保证和其他当时准备竞争的设备站在同一条起跑线上，同时也确保上一帧的ACK和后续帧交换有完整的SIFS保护期。

很多刚接触DCF的人会问：退避数的随机范围为什么要均匀分布，而不是用别的方式？均匀分布的目的就是不给任何特定设备偏向。如果改为某种“优先小退避数”的分布，那竞争窗口形同虚设，一些设备会因为总是选到小数而持续抢占信道；反过来，如果偏向大数，整个信道的利用率会降低。均匀随机数是在公平和效率之间的最直接选择。

4.3 不同AC队列的差异化退避

Wi-Fi 4之后引入的EDCA（增强分布式信道访问）并没有推翻DCF，而是在DCF的退避机制上加了四个优先级队列：语音（AC_VO）、视频（AC_VI）、尽力而为（AC_BE）和背景（AC_BK）。它们各自有独立的CWmin和CWmax，以及不同的仲裁帧间间隔AIFS。这就是为什么视频通话时下载任务并不一定会把带宽抢光——视频队列的CWmin更小、AIFS更短，在退避竞争里占优。EDCA是DCF的扩展，理解DCF的退避过程仍然是理解EDCA的基础。

5. 抓包实测：从空口记录验证DCF基本流程

理论讲完，来点实际的。如果你用的网卡支持监听模式（Monitor mode），可以用Wireshark抓空口包，直接观察DCF流程落地后的帧序列。我自己在调试一批高密度办公区AP时经常这么干，比只看调试日志有用得多。

5.1 开启监听模式并抓包

在Linux环境下，把无线网卡切入monitor模式：

注意要把信道固定下来，否则网卡会跟着AP跳信道，抓不到连续对话。

Wireshark打开抓包文件，只显示数据帧：

你会在包列表里看到大量Data帧。对于每个Data帧，展开802.11 MAC header里的Frame Control字段，能看到一个很关键的位：Retry位。如果Retry位为1，说明这个帧是重传帧。

再看重传帧的比例：

统计一下重传帧数量占总数据帧数量的百分比。正常稳定环境下，这个比例在5%以下，如果长期超过10%，说明空口竞争或干扰已经到了需要干预的程度。

5.2 从帧间隔反推信道竞争状况

DCF的等待时间在抓包里不会显示为显式字段，但你可以通过帧到达时间（frame.time_delta）观察设备之间的相对间隔。

有一种典型场景：办公室里几十台笔记本同时刷网页。抓包文件里的Data帧到达时间会呈现“鼓点式”的节奏——一段时间密集到达，紧接着一段时间只有零星几帧。这就是DCF退避在起作用：信道一旦被大量流量占满，新进入的设备必须不断冻结退避计数器，等待时长被拉长，表现上就是密集流量窗口里不断夹杂着重传和退避的静默期。

更精细的分析可以用Wireshark的IO Graph，按数据帧和重传帧画两条线。如果重传帧的曲线在业务高峰期和数据帧曲线同步冲高，说明竞争冲突是主要问题；如果重传率很高但数据帧本身不多，那更可能是干扰、信号弱或者隐藏节点问题。

5.3 用信道统计确认空口占用情况

如果不想抓包，Linux下还有更省事的接口——iw dev wlan0 survey dump：

返回的数据里有一组关键值：

• active time：信道累计有效时间
• busy time：信道被检测为忙的时间
• receive time：收到帧的时间
• transmit time：本机发送的时间

用busy time除以active time可以粗略估算信道占用率。比如active time 10秒，busy time 7秒，占用率70%。这时候你把抓包文件里的重传率结合来看，很容易形成闭环判断：信道忙到什么程度、冲突多做少，一目了然。

顺带说明一个抓包时的盲区：普通网卡抓不到ACK帧，因为ACK在物理层就处理掉了，驱动一般不会把它作为802.11管理帧或数据帧上抛。所以你在Wireshark里看不到一个完整的“Data+ACK”配对。常用的替代方法是去看帧间间隔：如果数据帧之间紧跟着约16 μs的SIFS间隔间隔，那基本可以推断刚才有ACK插在中间（需要支持物理层确认的网卡才能捕获）。所以普通抓包不能100%验证ACK流程，但它足以验证退避、重传、帧序这些DCF的核心行为。

6. 实际工程里最常见的四个疑问与调优切入点

最后聊几个我在实际调优和排查中反复遇到的、和DCF强相关的问题。这些内容标准文档里写得很含蓄，项目里却直接影响体验。

6.1 为什么DCF的极限效率这么低

很多人算过速率的账之后会问：802.11ac 80MHz、256QAM、MCS9的物理速率可以到433Mbps左右，但实际TCP下载能跑到300Mbps已经谢天谢地。多出来的开销去哪了？答案就在DCF的时间参数里。

每次数据帧发送前，至少要消耗：等待信道的DIFS 34μs、平均退避时间约CWmin/2 × 9 = 67.5μs，再算上PLCP前导码和物理层头、MAC头、ACK帧时间、SIFS等，这些固定开销在小帧场景下占比极高。以1500字节数据帧为例，在MCS7（65Mbps，20MHz 40ns GI）下，数据本身的空中时间约180μs，而固定开销约150μs以上，有效利用率只剩一半左右。小包场景如语音、游戏遥测数据就更难看，所以Wi-Fi优化里常看到“大帧聚合能大幅提升吞吐”，本质上就是减少每帧需要付出的DCF固定开销的次数。

这也是为什么Wi-Fi 6引入OFDMA后，把多个用户的小帧在同一个发送机会里塞进不同资源单元，从而降低人均DCF开销——但OFDMA的调度部分不属于DCF，它是集中式调度的思路，DCF仍然用于上行随机接入和其他竞争流量。

6.2 重传率高就降低速率？顺序搞反了

很多现场工程师遇到“信号差点”的第一反应是把最低速率调低，让设备能连上。但当你把速率门槛降低，DCF层面会出现一个副作用：慢速率的设备在空中占用信道的时间更长。一个1Mbps的长帧在空中的时间可能是54Mbps相同长度帧的54倍，其他设备全部要陪着这个慢设备等待。结果是重传率未必降下来，整个AP服务的所有设备反而一起变卡。

我的经验是：先看重传的分布，确认哪些设备在重传，再看它们的信号强度和速率。如果某个设备持续以最低速率工作且重传占比高，优先考虑降低该设备的发射速率限制或调整其漫游阈值，而不是动AP的公共配置。DCF是按设备独立竞争的，一个行为异常的设备会拖累整个信道里所有设备的DCF流程。

6.3 RTS阈值到底要不要调

RTS阈值默认是2347字节，大多数场景下接近最大值，等于基本关闭RTS/CTS。当环境中存在明显的隐藏节点问题时——常见于高密度办公隔间、大量隔断遮挡的环境——重传率会居高不下，因为冲突发生在接收端，发送端靠ACK超时才能发现。

遇到这种情况，我建议先把RTS阈值调到1000字节左右试试：大于1000字节的帧走RTS/CTS握手，小于1000字节的短帧仍然走基本访问。观察12小时内的重传率变化。如果重传率明显下降，再逐步微调阈值，找到你自己的环境里“握手开销和重传损失”的平衡点。如果调低后重传率没有明显变化，说明冲突不是主要矛盾，把阈值调回去，问题可能出在干扰或功率配置上。

6.4 兼容性模式对DCF参数的影响

有些AP为了兼容老设备，会把Slot Time从9μs改成20μs，DIFS也跟着变成50μs（802.11b的时序）。这意味着所有连接到这个AP的设备都退回到802.11b的时间体系，每次发送增加约20μs以上的额外开销，物理速率上限也受影响。实际测下来，仅仅因为一个老设备导致整网从OFDM时序退回11b时序，AP总吞吐率可以跌掉20%以上。

所以日常巡检时，我会顺手确认AP的无线配置里没有强制开启“11b兼容”或“b/g protection”。如果真有老设备必须接入，尽量用5GHz频段单独开一个低速率SSID分流，让主力设备留在OFDM参数下，避免个别设备破坏所有人的DCF节奏。

6.5 为什么Wi-Fi 7了还在讲DCF

有人觉得DCF是802.11远古时代的遗产，新标准应该抛弃它。实际情况是Wi-Fi 6/6E/7依然保留了DCF作为基本竞争访问机制。区别在于，OFDMA和MU-MIMO提供了更高效的集中式调度路径，但调度没有覆盖到的场景——比如一个设备突然有紧急上行小包要发、新设备要接入、AP要发送管理帧——仍然要退回DCF的竞争流程。它的定位像是“默认通道”：有调度时走快车道，没有调度时靠DCF保证每个设备至少在某个时间点能挤进信道。

我做高密度场景优化时，仍然会盯DCF相关的指标——每站的退避时间、重传率、信道利用率。这些指标反映的是“竞争环境”是否健康，而DCF就是构成这个竞争环境的基本法律条文。理解它，不是为了在新标准里找到替代方案，而是为了在所有新特性失效时，仍然能解释空口上正在发生什么。