802.11a/g wifi 路由器上标称的是 54Mbps，除个8，至少也有 6MB/s 啊。为什么实际速度只有 2M 多呢？网上的解释大多语焉不详，我只好班门弄斧了，欢迎指正。Wifi 通信在一
802.11a/g wifi路由器上标称的是 54Mbps，除个8，至少也有 6MB/s 啊。为什么实际速度只有 2M 多呢？网上的解释大多语焉不详，我只好班门弄斧了，欢迎指正。
Wifi 通信在一个给定的载波频段(频道）上进行，就像大家在大厅里说话一样，每个人说话都会干扰到其他人。
为什么不多搞一些频道呢？一方面，可以不申请许可就使用的 ISM 频段在适合无线通信的 2.4GHz 区域是很有限的；另一方面，为了保证通信速度，频道不能太窄。在 802.11a/g(wifi 协议）中，频道宽度是 22MHz，共划分出 14 个频道(其中有些频道在有些国家不属于 ISM 频段）。每个频道对周围的频道也有干扰(见下图），这就是无线路由器有十几个频道，但只有相隔较远的 1、6、11 频道才能同时使用的原因。
聪明的读者一定想到了，既然大家互相都能听到，那么听到旁边没有其他人在说话的时候再发言呗。这就是载波监听(CSMA，Carrier Sense Multiple Access）技术。但问题不是这么简单。
第一个问题是，如下图所示，1、2、3 排成一条线，1要给2说话，此时3正在给2说话，但1不知道这个事实，2同时听到1和3的话，就全乱了。在现实世界中，我们也许遇到过这样的尴尬。
第二个问题是，人的耳朵和嘴巴是“全双工”的，也就是能够同时收发；但无线通信目前还没有实现全双工，也就是只能在收发之间切换，在说话的时候就听不到周围的声音。因此，在发送过程中实时监听载波，是不现实的。
为了避免冲突，802.11 引入了 Request to Send (RTS) 和 Clear to Send (CTS)。在下图中，节点1要给2发送一帧，首先发送 RTS 帧。1周围的节点听到 RTS 后，就会沉默下来。目标节点2收到 RTS 后，会回复 CTS 帧，让2周围的节点闭嘴。1收到 CTS 后，就可以开始发送数据了。为了保证数据能被准确收到，2还要回复一个 ACK 表示确认。
无线天线发送和接收模式的切换需要时间，协议需要保证回复帧开始发送时天线已经从发送状态切换到接收状态，因此又增加了一些帧间隔。
其中，SIFS (Short Interframe Space) 是 RTS 和 CTS 的间隔，也是 CTS 和数据帧的间隔，也是数据帧和 ACK 的间隔。为了保证不发生冲突，从 ACK 结束后到下一帧开始传输之前，要有更长的 DIFS (Distributed Interframe Space)。在 802.11a OFDM PHY(正交频分复用的物理层）中，这些间隔是：
802.11a 的zui长帧长是 1536 字节，就是 12288 bit，加上6个表示纠错编码结束的额外 bit，共 12294 bit。根据下表，在 54Mbps 传输速度下，需要用 57 个符号。TCP ACK 有 76 个字节，加上6个额外 bit 共需要 614 bit，根据下表需要用 3 个符号。802.11 ACK 只需要1个符号。
在发送真正的数据之前，还要发送Preamble。Preamble 是用于训练接收方的，让接收方知道什么样的信号对应什么样的数据，该用哪个天线接收等。这些 Preamble 需要 20 µs 才能传输完成。承载数据的每个符号需要 4µs 时间传输。
TCP 的传输过程是，首先发送 TCP data，再回复 TCP ACK。传输 TCP data 和 TCP ACK 的过程，分别需要经过 DIFS、802.11 Data、SIFS、802.11 ACK。下表(摘自[1]）计算出了一个 TCP packet 传输需要的时间。
| TCP data | TCP ACK | |
| DIFS | 34 µs | 34 µs |
| 802.11 Data |
20 µs + 57 * 4 µs/symbol = 20 µs + 228 µs = 248 µs |
20 µs + 3 * 4 µs/symbol = 20 + 12 µs = 32 µs |
| SIFS | 16 µs | 16 µs |
| 802.11 ACK |
20 µs + 1 * 4 µs/symbol = 20 µs + 4 µs = 24 µs |
= 24 µs |
| Frame exchange total | 322 µs | 106 µs |
| Transaction Total | 428 µs |
因此，每秒钟能进行 1000000/428 = 2336 次 TCP packet 传输。1536 字节去掉 20 字节的 IP header 和 40 字节的 TCP header，就是 1476 字节的 TCP payload。这意味着数据传输速率可达 3.45 MB/s(1000进制）或 3.29 MB/s(1024进制）。考虑到 TCP 的滑动窗口协议允许在收到 TCP ACK 之前发送新的 packet，实际传输速度可能更快。
上述速率是理想情况下的理论速率。在真实的网络环境中，
- 无线网络帧长一般设置为 1500 字节而不是 1536 字节；
- TCP 发送方和接收方要竞争使用信道，会增加额外的控制开销；
- 如果多个设备接入同一个接入点(AP），就要竞争使用信道，不仅要让出一部分信道给其他人，还要增加控制信令的额外开销；
- 无线网络传输没有有线那么稳定，信道的干扰和信源的移动都可能导致传输错误，需要重传；
- TCP 本身还有拥塞控制机制，不可能一直以理论zui高速率发送。
这些因素综合起来，实测的数据传输速率只有 2.3 MB/s(1024进制）左右。从 3.29M 到 2.3M 还是有挺大差距的，上面哪个因素比较重要，或者还有什么我没考虑到的因素，我还想不明白。欢迎各位朋友一起讨论。
评论