先说个我个人经常被问到的问题为什么以太网用 CSMA/CD而 Wi-Fi 用的是 CSMA/CA为什么不直接把那套“碰撞检测”搬过来用这个问题看起来简单但真要讲透能扯出不少东西。虽然现在主流以太网基本都是全双工CSMA/CD 已经进了教科书但理解这套机制背后的物理约束恰恰是搞懂 Wi-Fi 协议设计逻辑的最佳入口。这篇文章就从物理信道差异说起把这两个协议掰开揉碎再加上实际组网里跟碰撞相关的排查经验给还在啃计算机网络、或者日常被无线干扰折磨的朋友做个参考。1. 题目背后的考点你真的理解“检测”和“避免”的区别吗这个问题能成为经典是因为它问的不是“Wi-Fi 怎么工作的”而是“为什么 Wi-Fi 不沿用成熟方案”。要答得漂亮得先明确两个词的本质碰撞检测Collision Detection允许发默认会有冲突发的时候边发边听一旦发现撞了立刻停下然后随机退避重发。碰撞避免Collision Avoidance尽量不让冲突发生发之前先“打招呼”确认信道没人用了再发发送成功后还要等对方确认。从字面看避免比检测“高级”但技术选型从来不是越高级越好而是看物理条件允不允许。以太网能检测是因为有线信道里信号的传输是可控、可预测的Wi-Fi 没法检测是因为无线信道的物理特性从根本上堵死了这条路。这个逻辑链很长下面一步步拆。1.1 有线世界的成熟方案CSMA/CD 到底是怎么实现的先回顾一下以太网的 CSMA/CD 完整过程全是考点设备要发送数据时先监听信道。信道上有信号就不发等信道空闲后还要等一个帧间隙Interframe GapIFG才“趁机”发送。边发送边检测碰撞——网卡在发送的同时会持续“听”线路上的电压异常。如果两帧信号叠加导致电压超过阈值就判定碰撞发生。判定碰撞后所有发送方立即停止并发送一个Jam 信号阻塞信号用来放大碰撞事件确保所有站点都能察觉到。所有站点进入随机退避退避时间通过二进制指数退避算法计算然后重新监听、发送。这套机制在 10Mbps 半双工以太网里能高效运行核心前提是发送设备自己说话的同时能听到别人说话。有线介质里信号沿铜缆或光纤传播能量衰减相对可控设备收发电路可以做到“同时发送、同时接收”。发送端通过比较自己发出的信号和线上混合信号就能迅速判断有没有发生冲突。最关键的一点有线信道里两个节点之间的距离上限和信号传播时间是可计算的。以太网能算出“最小帧长”保证碰撞能被抓住——比如经典以太网最大传输距离对应单程传播延迟大约 25μs所以最小帧长被设置成 64 字节。这个计算看着枯燥但它说明了碰撞检测的可行性是建立在确定性物理参数上的。1.2 一句话总结以太网的优势以太网能检测碰撞底裤逻辑就三条发送器可以边发边收收发电路隔离度高。信号衰减有界同一信道上相距最远的两个节点的信号强度差异不会太离谱。信道介质是封闭的外部干扰因素很少。但这三条在无线环境里全部失效。2. 无线信道凭什么不行三大物理硬约束Wi-Fi 不采用检测机制原因不是设计者保守而是物理规律不允许。我在给新人解释时通常会把这几个原因按“致命程度”排序。2.1 藏不住的软肋信道的半双工本质先问一个问题如果一个人在一间房里大喊大叫同一时刻他能听到别人用同样的音量说话吗显然不能因为自己的声音会把别人的声音完全淹没。Wi-Fi 设备就是这个问题。无线网卡在某个频段发射信号时接收电路如果同时收听会直接被自己发射的信号饱和根本分辨不出信道上是“别人也发信号了”还是“只有我在发”。要用工程手段做全双工理论上可以搞自干扰消除但功耗、成本和复杂度对消费级设备极不友好。因此Wi-Fi 设备在同一信道上要么发、要么收物理上做不到一边发送一边监听碰撞。没有“边发边听”的能力碰撞检测就是空中楼阁。2.2 动态范围与远近效应就算能听也听不真切假设技术上能让设备边发边收无线环境还有一个更棘手的问题——远近效应。发射功率相同的前提下离得近的节点信号到接收端时的强度可能比离得远的节点高出好几个数量级。想象一下有人在你耳边喊话同时另一个人在 500 米外喊话你只能听到耳边的人。在无线环境里两个节点同时发送接收端看到的信号叠加效果不再是简单的“112”强信号会把弱信号完全压掉。如果要靠检测信号幅度变化来判断碰撞就得面对一个复杂的动态范围问题收到强信号时你无法判断它是“别人正常发送的强信号”还是“两个远端弱信号叠加后变强的结果”。阈值设高了漏检设低了误检。以太网不会遇到这个问题。同一段同轴电缆或双绞线上信号衰减差异再大也有上限而且收发电路可以通过接口规范保证基本一致的参考电平。2.3 最经典的杀手锏隐蔽终端问题这是 Wi-Fi 放弃碰撞检测最重要的一个原因。举一个最典型的例子节点 A 和节点 C 都连接着同一个 AP接入点但 A 和 C 之间距离较远或者中间隔着障碍物两者互相听不到对方的信号。现在 A 开始给 AP 发送数据AP 能听到 A同时 C 也要给 AP 发数据C 监听信道发现信道“安静”——因为它根本听不到 A 的信号。于是 C 也把数据发出去了结果在 AP 处发生碰撞。这个场景里碰撞发生的位置是接收端而发送端 C 根本感知不到有另一个发送者在工作。就算 C 具备边发边听的能力它“听到”的信道状态和接收端 AP 看到的状态完全是两回事。这就像你在一栋楼的 A 区喊话B 区的人不知道你在喊他也开始喊结果楼中间的一个收听者收到了混合噪音。隐蔽终端问题彻底证明了在无线环境里发送端对信道状态的判断是不可靠的。既然没法准确预判碰撞发生那老老实实“避免碰撞”就是比“事后检测”更理性的策略。顺带一提还有个相对的“暴露终端问题”A 向 B 发送C 能听到 A 但不在 B 的接收范围内C 因为听到 A 在发送就推迟自己的发送其实它的发送并不会影响 B 的接收这导致信道利用率下降。这两个问题贯穿了 Wi-Fi 协议演进的整个历史后面讲的 RTS/CTS 也是围绕其中一个场景设计的。3. 碰撞避免是怎么落地的CSMA/CA 的实际工作流程CSMA/CA 并不是一个单点机制它是一套组合拳。我从最基础的发送流程讲起再往后扩展你会发现这套设计比表面看起来精巧得多。3.1 先听后发载波侦听的两个层面Wi-Fi 里的“侦听”分两层物理载波侦听Physical Carrier Sensing通过射频电路检测信道上的实际信号能量。如果能量超过阈值通常是 -82dBm 附近不同芯片有差异就认为信道忙。虚拟载波侦听Virtual Carrier Sensing通过解析帧头里的 Duration/ID 字段知道信道会被占用多长时间然后启动一个网络分配向量NAV定时器。如果 NAV 还没倒计时结束即使物理信道看起来是空闲的协议栈也会认为信道“忙”。这个双层设计解决了一个很实际的问题有时候物理层收到的信号强度很低不足以判定“忙”但帧头解析能让我们知道“后面还有一段数据要传完”。比如两个相距较远的节点各自给 AP 发数据AP 侧的信号强度可能刚好在阈值边缘物理侦听会漏报但虚拟侦听可以从别人只言片语的帧头里判断出信道占用情况。实际发送时节点发现信道空闲后并不会立刻发送而是等待一个分布式帧间间隔DIFS再进入退避倒计时。整个流程是检查信道是否空闲。空闲则等待 DIFS时间长度固定802.11a/g 是 34μs802.11b 是 50μs。在退避窗口内随机选一个退避计数值每经过一个时隙Slot Time且信道保持空闲计数值减一。计数到 0 时发送数据帧。等接收方回复 ACK如果在确认时间内没收到认为帧丢失进入指数退避重发。这里的退避时间不是固定的而是一个随机数乘以时隙长度。随机化是为了避免多个节点同时等待到 DIFS 结束后一起发送——如果退避时间完全一样那大家又同时撞上去了。这就像红绿灯刚变绿时所有车都同时起步肯定挤在路口如果每辆车随机延迟一拍通行效率反而更高。3.2 发送前划地盘RTS/CTS 的握手艺术针对隐蔽终端问题802.11 协议里设计了一个可选机制RTS/CTS 握手。节点 A 要发送数据前先发一个RTS请求发送帧里面带有源地址、目的地址和接下来要占用的信道时长。接收端 B 收到 RTS 后如果信道允许就回复一个CTS允许发送帧。CTS 的作用是告诉“所有能听到 B 的节点”B 马上要接收数据了你们先别发。注意这个关键细节CTS 的覆盖范围是 B 的辐射范围。之前 A 听不到 C但 C 听到的可能是 B因为 C 能收到 B 的 CTS所以 C 会更新自己的 NAV保持沉默。这样一来隐蔽终端问题在“接收端广播覆盖范围内”被解决了。很多教材把这个机制画得很复杂本质上它就是发送者先问一句“我要发了行不行”接收者再广播一声“都安静我要收东西了”。这个机制能显著降低长数据帧被碰撞的概率但代价是额外消耗两个控制帧的时间和信道资源。所以在实际环境中当数据帧较短、传输速率较高时RTS/CTS 的开销可能超过碰撞带来的损失很多路由器默认关闭它。3.3 数据帧拿到确认ACK 与重传机制Wi-Fi 数据链路层有一个很容易被忽略但极其重要的设计接收方必须回复 ACK。有线以太网不要求接收方确认——因为发送方能通过检测机制知道自己发送成功还是碰撞了。Wi-Fi 完全相反发送方发出数据帧后相当于“盲发”自己无法确定信道另一端是否干净地收到了。所以接收方收到数据后经过一个短暂的SIFS短帧间间隔就回发 ACK。这里为什么用 SIFS 而不是 DIFSSIFS 短一些大约 16μs802.11a/g。它的优先级更高ACK 必须抢在别人可能接入信道之前返回。如果 ACK 等太长时间其他节点可能认为信道空闲而开始发送反过来干扰接收方发出的 ACK。这是一种“让确认最先走”的信道接入优先策略。对发送方来说如果发出数据后没收到 ACK它无法区分以下原因数据帧碰撞被破坏。数据帧因为干扰被破坏。数据帧发出去但 ACK 被碰撞/干扰。对方收到帧但 CRC 错校验失败。无论哪种原因统一处理退避重传。这个设计看着暴力但正是因为它不区分失败原因、只管重试链路层才能保持简单可靠。上限重试次数一般由驱动配置通常设成 7 次或更多超过后上层协议会收到失败通知。4. 一码归一码两种机制的全维度对比下面这张表是我在教学和面试辅导里最常用的一张基本把两个协议的核心差异都装进去了。对比项有线以太网CSMA/CD无线 Wi-FiCSMA/CA信道访问方式检测到碰撞后停止发送前尽量避免碰撞收发同时性发送时可同时接收同一信道无法同时收发信道介质封闭、有界、可预测开放、动态、互相干扰隐蔽终端问题不存在信号全局可达存在且影响很大发送确认机制无链路层 ACK必须 ACK 确认帧间间隔设计简单IFG复杂DIFS/SIFS/PIFS 等碰撞处理方法Jam 信号 指数退避二进制指数退避 重传信道状态判断依赖自身发送信号对比依赖物理侦听 虚拟侦听半双工适用场景老式集线器时代目前主流仍存在半双工接入单独看每一行可能觉得琐碎但整体去看两类协议设计的哲学差异很清晰以太网假设“冲突是常态但可感知”。Wi-Fi 假设“冲突是常态但不可感知所以要努力避免”。还有一个可以延伸的知识点全双工以太网出现之后交换机的每个端口和终端之间建立了独立的收发通道物理上不可能碰撞所以 CSMA/CD 成了历史。而 Wi-Fi 至今还没法做到泛在的全双工所以 CSMA/CA 和它的各种变体依然是主导。这段话通常能帮读者理解“为什么现在还在学 CSMA/CD”它是理解网络协议演进的关键并不是说今天还在用。5. 看看 802.11 协议栈里的进阶设计从 DCF 到 EDCA如果只停留在 CSMA/CA 本身对实际组网帮助有限。802.11 协议族发展过程中除了基础的 DCF分布式协调功能还有不少围绕“减少碰撞、提高信道利用率”的设计。这里挑几个跟碰撞避免直接相关的聊聊。5.1 DCF 与 EDCA不同业务怎么争抢信道早期的 802.11 基础接入机制叫DCF所有站点一视同仁。后来负载和业务复杂了语音、视频、普通数据混在一起如果都用同一套退避参数视频流可能被文件下载挤占得没法看。于是 802.11e 引入了EDCA增强分布式信道接入本质是把流量分类成四个接入类别语音最高优先级视频尽力而为普通数据背景低优先级每个类别有不同的仲裁帧间间隔和最小/最大竞争窗口。语音的等待时间更短、竞争窗口更小所以抢到信道概率更高。这个设计的核心思路还是建立在 CSMA/CA 之上——用参数差异化来改变碰撞概率分布而不是改变“先听后发”的基本规则。5.2 竞争窗口的指数变化逻辑CSMA/CA 里有个容易忽略的细节竞争窗口Contention Window, CW不是一个固定值。初次发送时竞争窗口取最小值比如 15 或 31然后随机选一个退避计数值。如果发送失败竞争窗口翻倍31 → 63 → 127以此类推直到达到最大值。发送成功后竞争窗口重置为最小值。这样设计的逻辑很直观信道越拥堵、重传越多说明碰撞风险越大就让每个节点更“谦让”一些随机退避范围更大降低再次碰撞概率。这跟以太网的二进制指数退避如出一辙。实测环境里如果周边干扰很强你会观察到很多设备的物理层传输速率很低——很大一部分原因就是退避时间越来越长实际上“评估”到的信道忙时间也变长了。5.3 调制速率回退与碰撞的联动关系新手经常搞混一件事把 Wi-Fi 速率慢全归结为信号差。实际上在干扰严重的环境里碰撞才是主要矛盾。802.11 有一个链路速率自适应机制当发送失败次数增加时驱动会自动降低调制编码方案MCS等级比如从 802.11ac 的 MCS7 降到 MCS5速率从 65Mbps 降档到 52Mbps。速率降下来单个帧占用信道的时间变长碰撞的概率反而进一步增加。这是一个恶性循环碰撞 → 重传 → 速率回退 → 帧占用信道更久 → 更多碰撞 → 更多重传。所以排查 Wi-Fi 慢的时候不能只看 RSSI接收信号强度必须同时关注重传率和信道利用率。我自己调网络时一般先把重传率压到 5% 以下再看信号强度顺序反了容易白忙活。6. 实践中的碰撞规避与排查技巧纸上谈兵够了说说实际组网里怎么用这套理论解决问题。6.1 信道选择不是玄学大多数人买来路由器顺手就自动信道选择实际上自动信道在干扰密集的居住环境里经常做错判断。路由器扫描到的“空闲信道”往往只是“没人用的频段”但如果邻区基站信号泄漏功率较高实际干扰依然大。我的经验是手动选信道2.4GHz 只用 1、6、11 这三个互不重叠的信道。前提是周围邻居都在用不同信道你得扫一遍周边 AP 分布再选。5GHz 频段可用信道多干扰相对小但要注意雷达避让DFS信道和室内功率限制不同地区的法规不同别盲目把信道开到高功率的 DFS 频段上。当然现在很多企业级 AP 支持后台射频调优算法会定期扫描干扰和邻区动态调整信道和功率。家用路由器只要不是太老的型号也可以打开“自动调优”模式让它在凌晨自动重选信道能明显减少上班前和上班后的信道重叠问题。6.2 降低隐蔽终端影响的具体做法在办公室或宿舍这种多台设备分布在不同角落的场景隐蔽终端问题可能让 AP 收包成功率很低。遇到这种问题我的调整顺序是降低 AP 发射功率让信号覆盖范围刚好覆盖必要区域减少“远处听不到的邻居”数量。如果数据包大多是视频流等长帧在 AP 管理面打开 RTS/CTS 阈值调低强制更多节点握手。检查 2.4GHz 频段上非 Wi-Fi 设备无线鼠标、微波炉、蓝牙设备、USB 3.0 接口的干扰情况这类干扰和 Wi-Fi 帧头混在一起会让虚拟载波侦听失效表现为频繁丢包。特别注意第 2 点RTS/CTS 阈值默认值通常很大如 2347 字节意味着只有很长的帧才会触发握手。如果你视频通话或投屏很多可以手动把阈值调到 500 字节左右让更多大帧先握手。但别调太低否则每个普通数据帧都先发 RTS/CTS吞吐率反而会下降。6.3 抓包确认碰撞而不是盲调参数我见过很多朋友“感觉网络卡”——直接重启路由器、改信道但问题依旧。我建议在动手之前先取证用工具抓包或者登录 AP 看统计信息里的 MCS 速率分布、重试帧比例和信道占用率。以“碰撞为判断依据”来看现象如果重传率高但 RSSI 很好大概率是碰撞或干扰。如果重传率高且 RSSI 很差大概率是信号问题。如果 RSSI 好、重传率低但网速慢大概率是设备性能、AP 带宽或连接数饱和。不同原因的处理方式完全不同。碰撞问题靠调信道、调功率、开 RTS/CTS 解决信号问题靠加 AP、调整摆放、换天线解决性能问题靠升级硬件。所以每次都先做判断再动配置能省很多无用功。6.4 链路层 ACK 丢失引发的高层 TCP 重传这里补充一个比较隐蔽但很常见的问题Wi-Fi 的链路层 ACK 是发给 AP 的而 TCP 的 ACK 是端到端的两者不是一回事。如果 AP 和终端之间的链路层 ACK 频繁丢失Wi-Fi 终端会反复重传数据帧。重传次数一多TCP 报文在 AP 缓存里堆积最终触发 TCP 超时或重复确认表现为应用层下载速度极慢。有些路由器固件里可以打开“帧聚合”和“A-MSDU”相关选项减少每帧开销降低信道占用时间从而间接减少链路层碰撞概率。特别是对大量小包场景帧聚合效果好得很明显。如果路由器不支持这些高级选项那就优先保证信号质量和低重传率链路层的稳定性比“理论协商速率”重要得多。7. 考试与面试里这个问题的标准回答方式如果是为了学习和应试除了理解概念还得会组织表达。这道题的实际考察点是“通信协议设计要服从物理环境的约束”。给你一个分层作答的提纲首先说明 CSMA/CD 和 CSMA/CA 的中文全称一句话点出本质区别检测是有线环境的可行解法避免是无线环境的现实妥协。接着利用三条物理原因解释 Wi-Fi 为什么不能照搬 CSMA/CD无法同时收发、远近效应导致的动态范围问题、隐蔽终端问题。然后介绍 CSMA/CA 的机制组合物理载波侦听 虚拟载波侦听、DIFS 等待、随机退避、ACK 重传机制。最后补充 RTS/CTS 作为隐蔽终端问题的重要缓解手段并指出它存在开销代价。这套表述逻辑考场上基本能拿到大部分分数。它同时体现了“你不仅知道结论还知道结论背后的因果链条”。网络领域的面试官往往喜欢顺着这个话题追问“如果让你设计一个无线协议你会尝试使用碰撞检测吗”这种开放问题。我的回答思路通常是如果系统能保证发送端和接收端的视野基本一致且实现足够快的自干扰消除碰撞检测在特定场景还可以再讨论但成本极不划算。8. 从这个问题延伸出去的思考现在回到最初的问题上。为什么 Wi-Fi 选择“碰撞避免”而非“碰撞检测”根本答案浓缩成一句话碰撞检测依赖于“发送时能感知信道变化”而无线信道的半双工特性和介质开放性导致发送端无法可靠感知接收端的真实状态因此Wi-Fi 只能在发送前尽可能避免碰撞并用确认与重传来兜底。把这个结论再往前推一步会发现很多无线协议设计都逃不开这层约束。蓝牙的跳频、ZigBee 的载波侦听、蜂窝网络的上行调度本质上都在解决同一个问题——共享的开放介质下如何让多个设备靠谱地用同一段频谱。有线的确定性共享介质是特殊的无线的不可预知性才是常态。我个人在实际组网里最大的感受是很多 Wi-Fi 问题不用上升到协议层面就能解决但如果你对“为什么 Wi-Fi 会这样表现”没有基本理解排查时很容易做出错误的配置决策比如在拥堵环境里关掉 RTS/CTS或者盲目增大发射功率让更多设备进入互相听不见又互相干扰的尴尬状态。把 CSMA/CA 的逻辑理清楚了这些配置层面的事情就不再是“凭感觉”而是有理有据的取舍。最后分享一个小习惯我在培训新人时总让他们先画一张“隐藏终端拓扑图”——为什么 A 和 C 听不到彼此为什么只听 AP 的话就能避免冲突。这张图画通以后再回去看 RTS/CTS 和 NAV 定时器所有协议细节都会变得非常自然。技术方案看起来复杂背后的物理直觉其实简单这就是这个经典问题值得反复玩味的原因。