块确认解决什么问题
802.11 传统模式下每个数据帧都要单独回一个 ACK，在高聚合、高吞吐场景里确认帧本身就会吃掉大量空口时间。Block ACK（块确认，BA）随 802.11n 引入：发送方连续发出一组 MPDU，接收方用一个 BA 帧携带位图回传，一次性告知哪些帧收到、哪些需要重传。它和 A-MPDU 聚合是配套关系，没有 BA，聚合度越高确认开销越难承受。
基本信息
| 引入标准 | 802.11n（HT），11ac/11ax 沿用 |
|---|---|
| 协商帧 | ADDBA Request / Response、DELBA |
| 协商粒度 | 每个 TID（业务优先级）一条会话 |
| 窗口大小 | Buffersize 字段，常见取值 64 |
| 配套机制 | A-MPDU 聚合、A-MSDU 聚合 |
典型使用场景
- 大文件传输与备份：帧越聚合，逐帧 ACK 的开销占比越高，块确认收益越明显
- 高清视频回传与推流：稳定高码率下减少确认帧抢占空口时间
- 802.11ac/ax 高带宽链路：只有聚合加块确认才能把标称速率跑成实际吞吐
- 排障「聚合已开但吞吐仍低」：确认 BA 会话是否真的协商成功
- 多厂商互联互通测试：不同厂商对窗口大小与超时的实现存在差异，需要列入用例
Wireshark 过滤与判读
Wireshark 过滤与判读
wlan.fixed.category_code == 3 # 块确认类别（Block Ack）
wlan.fixed.action_code == 0 # ADDBA Request：发起协商
wlan.fixed.action_code == 1 # ADDBA Response：接受或拒绝
wlan.fixed.action_code == 2 # DELBA：结束会话
wlan.ba # 所有块确认相关帧（数据量大，先过滤再看）
wlan.ba.control # 展开可见窗口起点与位图ADDBA 字段读法
| 字段 | 含义 | 异常表现 |
|---|---|---|
| Dialog Token | 本次协商的事务标识 | 短时间内大量重复出现说明协商在反复重来 |
| Starting Sequence Number | 接收窗口的起始序号 | 与发送侧不一致会造成位图错位、重传异常 |
| Buffersize | 接收侧可缓存的 MPDU 数量 | 取值过小会限制实际聚合度 |
| Timeout | 会话保持时间（单位 TU） | 到期未续会退回逐帧 ACK |
块确认按 TID 分别协商：掉一条 TID 的 BA 会话只影响那一个优先级队列，排查时先按 TID 分组看，再判断影响面是全网还是少数业务。
抓包时 BA 帧数量极大，先用显示过滤器定位，再看 ADDBA 是否成对出现，最后看 BA 位图里是否频繁出现未确认位。