RTS/CTS 是什么
发送数据前先用两个短帧预约信道：发送方发出 RTS（请求发送），接收方回 CTS（清除发送）。听到 CTS 的邻居终端会设置退避计时器，在这段时间内保持安静。这个机制主要用来缓解隐藏节点问题——两个终端都能听到 AP，却听不到对方，直接发送就会在同一时刻撞车。
代价与触发条件
代价是每传一帧都要多两次握手，吞吐明显下降，因此默认只在帧长超过阈值时启用，阈值通常为 2347 字节。实践中的结论是：RTS/CTS 属于兜底手段，把阈值调低在确有隐藏节点症状的高密场景可以临时缓解，但更推荐通过增加 AP、降低功率来从根源上减少隐藏节点。
基本信息
| 触发方式 | 帧长超过 RTS 阈值时启用 |
|---|---|
| 默认阈值 | 通常为 2347 字节，等于关闭或仅长帧触发 |
| 核心用途 | 缓解隐藏节点带来的冲突 |
| 代价 | 每帧多两次握手，空口开销上升 |
| 替代做法 | 增加 AP、降低功率、优化点位以减少隐藏节点 |
抓包观察方式
抓包观察方式
# 监听模式抓包，分别过滤 RTS 与 CTS
wlan.fc.type_subtype == 27 # RTS
wlan.fc.type_subtype == 28 # CTS
# 观察 RTS 与 CTS 的比例是否正常
# CTS 数量明显偏少说明接收侧未响应，多为隐藏节点或干扰启用与禁用对照
| 设置 | 效果 | 适用 |
|---|---|---|
| 阈值 2347（默认） | 几乎不启用，开销最小 | 一般场景 |
| 降低阈值 | 冲突减少但开销上升 | 确有隐藏节点的局部区域 |
| 全量启用 | 冲突显著减少、吞吐明显下降 | 极特殊的排查与验证场景 |
典型使用场景
- 信号强度正常但重传率偏高：排查是否为隐藏节点
- 高密部署局部体验差：评估是否需要临时降低阈值
- 老旧终端与 AP 距离差异大：这类不对称环境更容易出现隐藏节点
- 验证优化效果：抓包对比 RTS/CTS 比例与重传率变化
- 点位复核：判断通过增加 AP 能否替代保护机制
- 现场排障教学：用抓包直观展示隐藏节点的发生过程
信号强但重传率高、双方互相听不到，是隐藏节点的典型特征，先确认症状再调阈值，不要一上来就全局启用。