RTS对无线性能的影响

问题描述

年前在家，发现所有的设备都会时不时地遇到网速极慢的情况。一番排查后发现，问题总是在设备连接到 2.4G WiFi 之后出现。考虑到邻居的路由器信号非常强，我初步怀疑是干扰导致的速度极慢。那有什么办法可以提升 2.4G WiFi 的抗干扰能力呢？在网上搜查一番后，我发现了一种很高深的说法——降低路由器的 RTS 值即可提升路由器在强干扰环境中的性能。

理论

首先搜索一下什么是 RTS。Wikipedia 是这么说的：

This protocol was designed under the assumption that all nodes have the same transmission ranges, and does not solve the hidden terminal problem. The RTS/CTS frames can cause a new problem called the exposed terminal problem in which a wireless node that is nearby, but is associated with another access point, overhears the exchange and then is signaled to back off and cease transmitting for the time specified in the RTS.

RTS/CTS is an additional method to implement virtual carrier sensing in carrier sense multiple access with collision avoidance (CSMA/CA). By default, 802.11 relies on physical carrier sensing only, which is known to suffer from the hidden node problem.

The RTS/CTS packet size threshold is 0–2347 octets. Typically, sending RTS/CTS frames does not occur unless the packet size exceeds this threshold. If the packet size that the node wants to transmit is larger than the threshold, the RTS/CTS handshake gets triggered. Otherwise, the data frame gets sent immediately.

IEEE 802.11 RTS/CTS mechanism could help solve exposed node problem as well, only if the nodes are synchronized and packet sizes and data rates are the same for both the transmitting nodes. When a node hears an RTS from a neighboring node, but not the corresponding CTS, that node can deduce that it is an exposed node and is permitted to transmit to other neighboring nodes.[1] If the nodes are not synchronized (or if the packet sizes are different or the data rates are different) the problem may occur that the exposed node will not hear the CTS or the ACK during the transmission of data of its neighbor.

简单的来说，RTS/CTS 机制是用来减少无线信道中的冲突的。在经典的“隐藏终端”问题中，基站 A 向基站 B 发送了数据，而基站 C 并未侦测到基站 A 的存在（这可能是基站的位置分布导致的），也向基站B发送了数据，最后基站 A 和基站 C 的数据同时到达基站 B，导致所有的数据都丢失了。RTS/CTS 机制则相当于要求所有基站在发送数据前先要说一声“我要发数据了”，也就是 Request To Send (RTS)；而接受数据的基站会在信道变空闲后回复“你可以发数据了”，也就是 Clear To Send (CTS)。这样就多了一步握手的协议，确保了之前那样的冲突不会发生。

实验

路由器中的 RTS 门槛说的是同一个东西。RTS 门槛是一个位于 0 - 2347 之间的整数。它的意思是，发送大小大于这个值的封包前需要进行 RTS/CTS 机制。如果设置成 0，就意味着总是进行 RTS/CTS 机制；如果设置成 2347，那么就意味着从不进行 RTS/CTS 机制，因为以太网的最大封包大小是 1518 字节。我的路由器中的默认值便是 2347，如图：

那么改变 RTS 门槛的值，到底会不会提升 2.4G WiFi 的性能呢？我决定实际测试一下。为了测试的科学性，我关闭了两个 5G 频道、断开了无关设备的连接、仅将两台测试电脑连接到了 2.4G 频道上。接着，我在不同的 RTS 门槛下，运行相同的网络性能测试。我设置的测试含有 3 条 1M 封包的线程和 3 条 500K 封包的线程，每个线程发送 100M 数据。

RTS门槛=2347

RTS门槛=2200

RTS门槛=2000

RTS门槛=1800

RTS门槛=1600

RTS门槛=1400

RTS门槛=1200

RTS门槛=1000

RTS门槛=800

RTS门槛=600

RTS门槛=400

（没有测试）

RTS门槛=200

（没有测试）

RTS 门槛=0

分析一下这些数据点，做了个简单的统计：

横轴是 RTS 门槛值，纵轴是带宽和响应时间。由于测试了很多不同的数值，测速表现都没有发生明显的变化，我就没有进一步地去测试 400 和 200 这两个值。但依然可以发现的是，不同的 RTS 门槛值对于无线网络的性能几乎没有影响。

后续

后来又观察了一段时间，我发现路由器的 2.4G WiFi 的频段一直在不停的切换。由于 Smart Connect 开启后无法手工指定频段，我关闭了 Smart Connect 并手工设定了 2.4G WiFi 的频段，就没有再出现过网速极慢的问题；后来升级成了最新版的官方固件，即便是开启 Smart Connect 后也没有出现之前的问题。基本可以确定，网速极慢并非 RTS 参数的问题，而是 2.4G WiFi 的频段不停切换导致的；而后者大概率是改版梅林固件的玄学问题。