在日常使用 Wi-Fi 的时候，我们经常会遇到两个让人头疼的问题：
时延高（延迟大）：比如打游戏的时候，人物突然“瞬移”，语音通话出现明显卡顿。
掉包（丢包严重）：比如视频会议里，画面一顿一顿的，声音断断续续。
那么，Wi-Fi 的时延和掉包，到底受什么因素影响？今天我们就来做一次“拆解”，从不同角度看看网络延迟是怎么叠加出来的。
一、时延是怎么产生的？
可以把 Wi-Fi 的传输过程想象成快递运输：
应用层排队：就像快递包裹在仓库里等待打包出库。
内核和驱动处理：快递打包、分拣上车。
退避等待（Backoff）：马路很拥挤，你的车得等红灯或者让别人先走。
空口传输（Air Tx）：真正上路运送包裹。
重传（Retrans）：如果包裹在途中丢了，得再送一次。
接收处理：快递送到客户家门口，还要签收。
每一环节都会耗时，累加起来就变成了我们感受到的“延迟”。
图示：Wi-Fi Latency Breakdown
二、为什么会掉包？
掉包的原因也不少，常见的几类包括：
信号不好：就像快递小哥找不到门牌号，包裹送不进去。
干扰严重：好几辆车挤在一条小路上，撞在一起，结果都送不出去。
队列溢出：仓库里堆满了包裹，来不及处理，后面的只能扔掉。
省电机制：终端在“睡觉”，结果错过了配送，包裹被退回。
所以，掉包并不是单一的“信号差”，而是多方面原因叠加的结果。
三、MAC 层的小秘密：谁能先发？
Wi-Fi 并不是“谁急谁先走”，而是有一套排队规则，叫 EDCA 队列。
它把流量分成四类：语音（VO）、视频（VI）、普通（BE）、后台（BK）。
语音：优先级最高，几乎一有机会就先发（因为打电话不能卡）。
后台下载：优先级最低，需要等很久才轮到。
图示：EDCA QoS Queue Parameters
这就是为什么你在下载大文件的时候，如果路由器没有做好 QoS，语音或游戏会被“拖慢”。
四、Bufferbloat：看不见的“塞车”
很多人家里带宽很大，但一旦有人看视频、开下载，延迟就飙升到 500ms 甚至 1s。
原因就是 Bufferbloat —— 队列太长，数据在路上堆积，就像高速路口大堵车。
解决办法：开启 智能队列管理（比如 FQ-CoDel/CAKE），让数据包分流排队，不让实时业务被卡死。
图示：Bufferbloat Comparison
五、聚合：吞吐量和延迟的权衡
Wi-Fi 为了提高效率，会把很多小包合并成一个“大包”一起发，叫 A-MPDU 聚合。
好处是效率高、吞吐量大，但坏处是 延迟变长，因为要等更多小包凑齐。
下载大文件时：聚合越多越好。
打游戏、语音时：聚合太多会让延迟明显变大。
图示：Aggregation vs Throughput & Latency
六、常见的坑
高 MCS 并不总是好：信号差时高阶调制会频繁重传，反而更慢。
TXOP 不是越大越好：一个人霸占空口太久，其他人只能干等。
过度聚合：看似吞吐量漂亮，但延迟对实时应用极不友好。
忽视 Bufferbloat：是大多数“明明带宽够用却卡顿”的根源。
七、总结
Wi-Fi 的时延和掉包，就像是“快递网络”的整体效率问题：
道路情况（信号和干扰）
交通规则（MAC 队列和调度）
仓库效率（系统缓冲和协议处理）
运力安排（带宽、QoS、聚合策略）
真正的优化要点是：
把实时流量（语音、游戏）和大流量下载区分开；
合理使用 QoS/EDCA；
控制队列长度，避免 Bufferbloat；
根据场景选择合适的频段和带宽。
这样，你的 Wi-Fi 才能既“跑得快”，又“跑得稳”。