Wi-Fi帧间间隔全解析：SIFS、DIFS、AIFS与抓包时序

做了这么多年无线网络调试，我最常被问到的问题就是：为什么同一台 AP 下面，有的帧发得急，有的帧却要等半天？抓包抓到一大段数据，看起来每一帧之间都夹着长短不一的“空白时间”，有人觉得是网络卡，有人觉得是驱动 Bug，其实只要把 Wi-Fi 分布式协调功能（DCF）里那套帧间间隔规则搞清楚，这些空白时间就全都解释得通了。

DCF 是 802.11 系里最基础的信道接入机制，而帧间间隔就是它最重要的时间标尺。这篇我打算从 DCF 的底层逻辑讲起，把 SIFS、PIFS、DIFS、EIFS 这几个间隔的实际意义、计算公式、在抓包里的表现一次说透，顺带聊一下 QoS 时代由 DCF 演化出来的 AIFS。适合做协议开发、无线测试、网络优化，以及正在啃 802.11 文档的读者参考。

1. DCF 的底层逻辑：没人是“老大”，全靠规则抢信道

1.1 为什么 Wi-Fi 要设计成“分布式”

Wi-Fi 网络和移动蜂窝网络最大的差别，就是没有一个“中央调度器”来给每个人排班。基站可以给手机分配时隙、频率资源，但 Wi-Fi 里的 AP 虽然名字里带“点”，它并不控制每个终端的发送时间。所有站点看到的是同一个半双工无线信道，谁想发数据，谁就得先去“听”信道，再按统一规则抢。

这种“大家自觉”的接入方式，就是 DCF 的设计初衷。DCF 基于 CSMA/CA 思想，也就是载波侦听多址接入/冲突避免。这里的“冲突避免”四个字很关键。有线以太网用的是 CSMA/CD，冲突之后靠检测再重传；无线环境做不到边发边听，所以 Wi-Fi 必须在发之前就尽量避开冲突。怎么避开？第一靠侦听，第二靠随机回退，第三就靠帧间间隔。

1.2 载波侦听 + 网络分配向量，先分清信道忙不忙

载波侦听分两个层面：物理载波侦听和虚拟载波侦听。

物理层面是射频前端做 CCA（Clear Channel Assessment），能量高于阈值就认为信道忙。虚拟层面靠每个帧里的 Duration 字段，这个字段告诉所有收听到这个帧的第三方站点：接下来多少微秒内信道会被占用。第三方读到 Duration 后，会在本地设置一个倒计时，这个倒计时叫 NAV（Network Allocation Vector），相当于在自己的日历上划掉一段“别打扰”的时间。

为什么要用两套机制？因为无线信号会被遮挡、会衰减，A 站点能听到 AP，但不一定能听到 B 站点，这就是经典“隐藏节点”问题。物理侦听只能在本地起作用，虚拟 NAV 能弥补一部分盲区。这套机制不是 DCF 的全部，但它决定了站点判断“信道忙/闲”的方式，而帧间间隔正是在“信道空闲到什么程度”这个问题上起作用。

1.3 从 DIFS 到退避，DCF 完整流程是怎么走的

常规数据帧的发送流程大致是这样的：

1. 站点想发数据，先检查物理信道和 NAV。如果信道空闲，就等待一个 DIFS；DIFS 过后信道仍空闲，且站点此前没有因为连续发送进入退避状态，就可以直接发送。
2. 如果发现信道忙，或者刚刚发送过一帧，则要执行随机退避。站点在 0 到竞争窗口 CW 之间随机挑一个数作为退避计数，每经过一个 SlotTime 且信道空闲，计数减一；信道一旦忙就冻结，等信道变空并等到 DIFS 后再继续减。
3. 退避计数减到 0，站点开始发数据帧。
4. 接收方收到正确数据后，等一个 SIFS，立刻回复 ACK。
5. 其他站点在 ACK 之后，重新进入信道竞争流程。

这套流程里最容易被忽略的，就是第 1 步和第 4 步中出现的 DIFS 和 SIFS。为什么接收方回 ACK 要用 SIFS，而新站点发数据要等 DIFS？为什么 DIFS 比 SIFS 长？这些不是随便定的，它们决定了整条链路的优先级关系，下面详细拆。

2. 帧间间隔家族：SIFS、PIFS、DIFS、EIFS 之间的关系

2.1 三个基础档位：长度、优先级和公式

标准里帧间间隔常见的有四类：SIFS、PIFS、DIFS 和 EIFS。前三个是基础档位，EIFS 是特殊情况下用的扩展间隔。

SIFS 全称 Short Interframe Space，短帧间间隔。它最短，优先级最高。802.11 标准里，SIFS 由几个固定时延折算而来，包括收发切换时间、MAC 处理时延和本底噪声检测时间，所以它不只是一个“规定数字”，而是硬件能力的极限体现。

PIFS 全称 PCF Interframe Space，是给可选的点协调功能 PCF 用的，长度等于 SIFS 加上一个 SlotTime。DIFS 全称 DCF Interframe Space，是给普通 DCF 数据帧用的，长度等于 SIFS 加上两个 SlotTime。关系式一目了然：

• SIFS：硬件极限时延的折算值
• PIFS = SIFS + 1 × SlotTime
• DIFS = SIFS + 2 × SlotTime

也就是说，除了 EIFS 之外，所有间隔都建立在 SIFS 这个基准上。要理解为什么 DIFS 要多加两个 Slot，需要知道 SlotTime 的作用。SlotTime 既要保证物理层能在一个时隙内完成能量检测和信道状态判定，也给退避计数器留出“滴答”节拍。多出来的一个 Slot，就构成了不同访问类别的等待等级。

2.2 不同 PHY 下的典型数值

很多人学到 DCF，第一反应是找一张“帧间间隔数值表”背下来。但真正到现场就会遇到一个问题：不同 PHY 下的数值不一样，2.4GHz 和 5GHz 不一样，甚至同一个 2.4GHz 频段里，传统模式和混合保护模式还不一样。

这里特别容易踩的坑是 2.4GHz。802.11g 和 802.11n 在 2.4GHz 下，既可能使用短时隙 9μs，也可能为了兼容 802.11b 老终端而回退到 20μs 长时隙。如果周围有大量老旧设备，整个 BSS 都会采用保守参数，DIFS 会跟着拉长。所以我们判断帧间间隔是否异常前，必须先看 BSS 使能了哪种保护机制，不要拿着 5GHz 的数值去硬套 2.4GHz。

2.3 SIFS 为什么能“插队”？优先级的本质

帧间间隔的本质是给不同帧类型分优先级。优先级越高，等待时间越短。SIFS 最短，所以 ACK、CTS 这类帧可以在所有竞争者之前“插队”。举个例子：A 站点给 B 站点发数据，B 在 SIFS 后立刻回 ACK；而第三方 C 站点此时也在等信道，它至少要等 DIFS 才可能发送。SIFS 比 DIFS 短得多，所以 B 的 ACK 总能先于 C 的新数据帧出去。

如果 ACK 也等 DIFS 再发，情况就完全变了。C 和 B 可能同时等到 DIFS 结束，两边都认为信道空闲，争抢 ACK 的发送机会，这样会导致大量不必要的冲突和重传。所以，把接收方的确认帧安排在最短间隔，不是“偏心”，而是为了尽量减少冲突窗口。

PIFS 的优先级介于 SIFS 和 DIFS 之间。实际网络中，PCF 很少部署，但 PIFS 并没有完全消失，一些管理帧、Beacon 帧发送，以及某些厂商主动信道扫描的实现里，会用 PIFS 来优先抢占信道。理解了这一点，抓包时看到个别帧的间隔比 DIFS 短、比 SIFS 长，就不会以为是异常，很可能是 PIFS 在起作用。

3. 帧间间隔怎么控制一次真实收发流程

3.1 发送方视角：等 DIFS，必要时候还要退避

把视角切到发送方。站点想发一帧普通数据，发现信道已经空闲超过 DIFS，它就可以立即发送，不需要额外退避。注意，这个“立即发送”的前提是没有其他排着队的待发帧，或者刚经历过一次成功发送。如果刚发完一帧，即使信道空闲也要重新启动退避，这是为了给其他等待站点一个公平机会。

那为什么还要额外退避？因为 DIFS 只解决“帧间时间标尺”的问题，没有解决“多个站点同时到达 DIFS 终点”的问题。设想一下，两个站点都盯着同一个 AP，信道一空，它们同时在 DIFS 结束后发帧，还是会碰撞。随机退避的意义，就是让可能同时发送的站点在 0 到 CW 之间取一个随机数，把碰撞从必然事件变成概率事件。DCF 的公平性，其实就靠“DIFS + 随机退避”这一步撑起来。

我做过一个比较极端的测试：在同一信道放 20 个终端，都不限速跑流量。刚开始以为最大瓶颈会是 AP 的吞吐能力，结果抓包看到大量碰撞和重传，信道利用率并不高。后来把其中一个终端的驱动参数改成更长的竞争窗口，其他不变，整体吞吐反而略有提升。这个现象说明，竞争参数对网络整体行为的影响，往往比单个终端“多快发出”更重要。

3.2 接收方视角：SIFS 后回 ACK，为什么不能早也不能晚

接收方收到一帧数据，首先做 CRC 校验。校验正确，按标准在 SIFS 后回 ACK；校验失败，什么都不回，等发送方超时重传。

SIFS 的“窗口”非常窄。回得太早，可能意味着硬件还没来得及完成接收切换；回得太晚，第三方站点可能已经插进来，ACK 就失去了优先权。所以 SIFS 不是随便定的，它必须大于等于射频收发切换时间加最大处理时延，同时又必须明显短于 DIFS，这样接收方才能抢在普通数据帧前面完成确认。

实际经验里，抓包时看到“数据帧结束到 ACK 开始”的间隔，通常比理论 SIFS 大那么几个微秒。这很正常，因为抓包软件记录的时间戳受无线接收链路、驱动中断、网卡时钟精度影响，SIFS 真正发生在芯片内部，外面用普通网卡是不可能精确量到的。想测精确值，得靠专业仪器的 PHY 层时间戳或芯片级日志。

3.3 RTS/CTS 和错误帧后的 EIFS

DCF 里还有两种特殊的收发流程，能把帧间间隔的作用看得更清楚。

第一种是 RTS/CTS 握手。当数据帧很长，或者网络里隐藏节点比较多，站点会让 RTS Threshold 触发 RTS/CTS。发送方在 DIFS 后先发 RTS，接收方在 SIFS 后回 CTS，发送方收到 CTS 后又等 SIFS 发数据，接收方再等 SIFS 回 ACK。每一程都是 SIFS 衔接，而 RTS/CTS 帧里的 Duration 字段会把这段时间预约下来，告诉所有第三方：这一段时长的信道谁都别碰。DIFS 只在最开始出现一次，后续靠 SIFS 一路绿灯。

第二种是错误帧之后的 EIFS。站点收到一个 CRC 错误、根本解不出 Duration 字段的帧时，它不知道对方还要占用信道多久，如果还按 DIFS 来等，很容易在一个正在进行的交换过程中间抢发，造成碰撞。标准规定这种情况下要等一个更长的 EIFS。EIFS 大致等于 SIFS + DIFS + 最低速 ACK 的传输时间，目的就是给那些已经开始的正常交换流出足够时间完成。抓包软件里经常能看到某次接收错误后，下一帧的间隔明显变长，这就是 EIFS 在起保护作用，不是网络出故障。

4. QoS 时代的变化：从 DIFS 到 AIFS

4.1 传统 DCF 的不足，EDCA 带来了什么

DCF 把所有数据帧一视同仁，都等 DIFS、用同一套退避参数。这对普通浏览网页没问题，但一旦同时跑语音、视频、文件下载，问题就来了：语音帧和下载帧一样抢信道，谁也抢不过谁，语音延迟和抖动就会非常难看。于是 802.11e 引入了 EDCA，也就是增强分布式信道访问。

EDCA 把业务分成四个访问类别：语音 VO、视频 VI、尽力而为 BE、背景 BK。为了给它们分优先级，一个最直接的办法就是让不同类别的帧等待不同长度的帧间间隔。这个让不同 AC 使用的帧间间隔，就叫 AIFS，全称 Arbitration Interframe Space，仲裁帧间间隔。

4.2 AIFS 的计算公式和典型 AIFSN 配置

AIFS 的计算比 DIFS 多了一步：先根据 AC 查到一个 AIFSN（AIFS Number），再乘以 SlotTime，加上 SIFS，得到 AIFS。公式写出来是：

AIFS[AC] = AIFSN[AC] × SlotTime + SIFS

这里要注意，AIFSN 的值越大，AIFS 越长，优先级反而越低。常用默认配置如下：

以 5GHz OFDM 参数为例，SIFS=16μs、Slot=9μs，AC_BE 的 AIFS = 3×9+16=43μs，比传统 DIFS 34μs 多了 9μs。AC_VO 的 AIFS = 2×9+16=34μs，正好等于传统 DIFS，但它的 CWmin 更小，退避时间平均更短，所以语音依然占优。

4.3 WMM 开启后帧间间隔为什么会“变大”

很多人在 WMM 开启前后的对比测试里发现，普通数据帧之间的“等待时间”变长了，于是怀疑 WMM 不是优化而是劣化。其实这背后的逻辑很清晰：WMM 启用后，AC_BE 业务的 AIFSN 默认是 3，而不是 DCF 的 2。换算出来的 AIFS 就比传统 DIFS 多了一个 SlotTime，所以普通业务在标准配置下反而多等了一个时隙。

这是为了给语音和视频留出更短的等待窗口。如果 AC_BE 的 AIFSN 也被设成 2，那么语音和视频相对于普通数据的优势就只能靠 CW 的大小来体现，区分度变弱。在重度负载场景，这个差异会直接影响体验。所以做 QoS 优化时，一定要把 AIFSN、CWmin、CWmax 三项参数一起看，只看某一个很容易得出错误结论。

4.4 802.11ax 里，帧间间隔还是这么重要吗

到了 802.11ax，Wi-Fi 引入了 OFDMA，AP 可以像调度员一样把信道划分成多个资源单元，同时给多个终端发数据。有人觉得 DCF 要被“集中调度”取代了，帧间间隔是不是就没那么重要了？实际上不是。OFDMA 的上行多用户传输，仍然要先通过传统 DCF 竞争拿到 TXOP，再由 AP 用触发帧分配资源。终端收到触发帧后，还是在 SIFS 后回复数据，这个时间标尺并没有消失。

802.11ax 还引入了一些新的时间参数，但它的地基依然是 DCF 那套谁先等够时间谁先说话的逻辑。理解 DCF 的帧间间隔，对看懂 HE Trigger-based PPDU 的时序非常有帮助。所以不要觉得协议更新了，底层时序规则就过时了。

5. 现场实战：观测帧间间隔与常见误区

5.1 抓包软件里的时间戳，能不能直接当作帧间间隔？

常见做法是打开 Wireshark，点一个数据帧，看“Time delta from previous captured frame”，把它当作帧间间隔。这个字段确实是上一帧到当前帧的时间差，但它不等于协议意义上的帧间间隔。原因有两个：一是普通无线网卡在驱动里加了自己的时间戳，这个时间戳通常来自软件时钟，粒度不够；二是抓包位置可能在 AP 或终端，射频传播时延、接收链路处理时延都会被记进去。

如果是抓空口报文，我更建议做定性判断：看 ACK 相对上一帧是不是明显比周边帧间隔短，看某些帧后面是不是多了一段异常长的间隔。想要定量验证 SIFS 是否达标，得用支持 PHY 层时间戳的专用抓包设备，或者直接读芯片的 MAC 事件日志。普通网卡抓出来的数据，不适合做微秒级仲裁。

5.2 容易踩的四个坑

第一，把 DIFS 当成固定值。DIFS = SIFS + 2×SlotTime，不同 PHY、不同频段、是否开启短时隙，都会让它变化。拿一个常量去比对所有抓包样本，一定会误判。

第二，把 EIFS 当成异常。错误帧之后出现一段明显更长的间隔，很多时候是 EIFS 在正常保护信道。先看前一个帧是不是 CRC 错误或无法解析，再决定要不要查问题。

第三，忽略 2.4GHz 的老旧兼容模式。同一个 2.4GHz 网络里，如果存在 802.11b 终端，BSS 可能采用 20μs 长时隙，所有间隔整体拉长。这不是设备坏了，是协议为了向下兼容做的保护。

第四，在普通网卡抓包数据里测微秒级间隔。普通网卡的定时精度达不到微秒级验证要求，用它测出来的 SIFS 和 DIFS 只能当参考。真要较真，用专业工具或芯片日志。

5.3 给开发/测试同学的小建议

如果你是做无线驱动或协议栈开发的，建议把帧间间隔相关逻辑打点输出到日志里。至少能看到每个数据帧对应的“本帧发送前的信道空闲时间”，用它判断驱动是否严谨地执行了 DIFS/EIFS。很多驱动为了追吞吐，会把某些不必要的等待跳过，短期看性能漂亮，长期看公平性和兼容性都会出问题。

如果你是做 Wi-Fi 测试的，拿到一个新平台后，先做一遍“间隔基线测试”：在干净信道里用固定速率灌流量，统计 ACK 与数据帧之间的时间差分布。先确认基线正常，再去做复杂场景测试。很多看似玄学的吞吐量问题，最后定位下来都是芯片的 SIFS 超标或 EIFS 处理顺序不对。协议栈的这类缺陷，只有回到时间线上才能看得清楚。

这个系列写到这一篇，正好卡在 DCF 最关键的时间标尺上。我自己调试无线问题时，第一反应永远是先抓包，第二反应就是算时间。很多所谓“谁抢占了信道”“为什么这帧慢了”的问题，只要把帧间间隔代入进去，立刻就有了方向。希望这篇能帮你把 Wi-Fi 竞争时序这块拼图补上。后面如果继续写 DCF 的退避、竞争窗口和重传策略，我会把吞吐量模型也拉进来，看看这些微秒级参数最后怎么变成你手机里的真实速率。