在维基百科中是这样说的:
请求发送 (RTS) 帧:RTS 和 CTS 帧为具有隐藏站的接入点提供可选的冲突减少方案。站点发送 RTS 帧作为发送数据帧之前所需的双向握手的第一步。
为什么 RTS/CTS 方法在 IEEE 802.11 中是可选的,而不是每次都用于提供冲突减少(隐藏/外部问题的最小化)?
在维基百科中是这样说的:
请求发送 (RTS) 帧:RTS 和 CTS 帧为具有隐藏站的接入点提供可选的冲突减少方案。站点发送 RTS 帧作为发送数据帧之前所需的双向握手的第一步。
为什么 RTS/CTS 方法在 IEEE 802.11 中是可选的,而不是每次都用于提供冲突减少(隐藏/外部问题的最小化)?
它是可选的原因是在 802.11 中 RTS 和 CTS 是管理帧。管理帧以与 ESS 关联的所有客户端支持的最低基本/基本/所需数据速率发送,这通常远低于用于正常单播流量的数据速率。
这样做的原因是所有连接到 BSS 的客户端必须只支持配置为基本/基本/必需的 ESS 数据速率(这意味着如果您想支持旧客户端,所需的数据速率不能包括数据较新标准的费率)。因此,这些是唯一可以保证能够被所有客户端理解的数据速率。
这意味着 RTS 和 CTS 帧将使用不成比例的“通话时间”,并使频谱的使用效率低得多。作为一个例子(非常基本/粗略),假设您有一个小数据帧要以 600 Mbps 的速度传输。但是,ESS 的基本数据速率为 12 Mbps(对于大多数网络仍然支持的 802.11a/g 客户端来说,这是一个相当不错的信号)。RTS 和 CTS 帧可能各自占用数据帧的 50 倍的传输时间。这需要从一个“时隙”到 101 个“时隙”的总传输时间。效率低很多。
具有 RTS/CTS 的一些优点但更有效的替代解决方案是 CTS-to-Self 机制。这允许无线站向自己发送一个 CTS 帧,为它的传输清除空气。这并没有缓解隐藏节点问题等问题,但确实降低了对效率的影响。
大多数网络不使用 RTS/CTS 或 CTS-to-Self,因为它们对性能的负面影响比它们试图缓解的问题更大。
好吧,为了回答我自己的问题,它是可选的,因为只有在要发送长消息时才值得使用。对于可以快速发送的东西,最好只发送它而不是用 RTS/CTS 保护它并发送(很可能)过时的控制数据包。