千兆宽带最让人头疼的一幕，往往发生在玩游戏的时候。

家里拉了 1000 兆光纤，配了上千块钱的路由器，平时测速轻松跑满，看 4K 视频进度条随便拖。

晚上在电脑上开一局游戏，延迟稳稳保持在十几毫秒。这时候如果家里有人在手机上备份相册，或者电脑后台顺手下了个文件。

游戏延迟就会突然跳到两三百毫秒。技能按下去慢半拍，人物走位开始莫名回弹。

打开任务管理器看一眼，下载速度其实只有几十兆，千兆带宽连十分之一都没占满。

只要把下载暂停，游戏延迟立刻恢复正常；一旦继续下载，卡顿马上又回来。

大部分人遇到这种情况，第一反应是运营商虚标，或者是路由器性能不够。

其实都不是。网络变卡根本不是带宽不够，恰恰相反，是因为现代路由器里的缓存配得太大了。

在计算机网络里，这个折磨了全世界十几年的问题，叫 Bufferbloat，缓冲区膨胀。

2010 年 11 月，一个叫 Jim Gettys 的老哥在家里抓到了它。

Gettys 不是什么路人甲，他是贝尔实验室的资深研究员，X Window 的共同发明人，互联网早期的核心工程师之一。

他发现自己家里只要有人往云端同步照片，视频会议就会瞬间卡死，延迟从 20 毫秒飙到 1200 以上。千兆网络，就跑个照片同步，不至于吧。

他在自家路由器上挂了抓包工具，花了几周时间，终于搞明白了。

这事其实是个历史遗留问题，得从 1988 年的一个老设计说起。

那一年，Van Jacobson 发表了奠定现代网络通信的经典论文，正式提出了 TCP 拥塞控制算法。

这套算法的核心逻辑是：把「丢包」，当成了判断网络拥堵的唯一信号。

当时路由器的内存极小，采用的是最基础的尾部丢弃（Drop-tail）策略。缓冲区一旦装满，多出来的数据包直接被丢掉。发送端只要检测到丢包，TCP 拥塞控制就会立刻介入，把拥塞窗口（cwnd）直接砍半，强制发送方减速。

虽然天天丢包，但由于路由器里根本没有多余内存去排长队，所有人的端到端延迟一直被死死压在几十毫秒以内。

丢包虽然难看，但整个系统跑得又快又公平。

到了 2000 年前后，内存芯片的价格大跌。

路由器厂商突然意识到，几十兆的内存只要几毛钱，塞进路由器里跑分特别好看，「零丢包」是个绝佳的卖点。于是从光猫到家用路由，大家开始无节制地堆缓存。

但他们没想到，Van Jacobson 在 1988 年设计的那个刹车系统，靠的就是丢包来踩刹车。

你把丢包消灭了，等于把刹车拆了。

大文件传输的时候，成千上万个大数据包涌进路由器，巨大的缓存池照单全收，一个不丢。发送端以为前方一路畅通，源源不断地把数据塞进来。

数据包在路由器内存里排成长龙。

这时候你在游戏里按了一个技能键，这个只有几十字节的小包，得排在前面成千上万个大体积数据包后面慢慢排队。

很多人不知道，千兆宽带的下行虽然有 1000 兆，但往外发数据的上行带宽，往往被运营商卡在 50 兆左右。

路由器内存里积压的 10MB 数据，顺着这个小出口一点点往外挤，全部发完需要整整 1.6 秒。

按照先进先出的规矩，你的游戏按键包必须等前面的大文件全部发完。你的操作根本没在光纤里堵车，是在自家路由器的内存芯片里，活活排了 1.6 秒的队。

Gettys 搞清楚这件事以后，觉得又可气又荒唐。全世界花了上千亿美元铺更粗的光纤，结果因为几块钱的便宜内存芯片，让整个网络反而变得越来越迟钝。

带宽提速了上百倍，延迟却被大缓存毁掉了。

2012 年，当年设计出拥塞控制算法的 Van Jacobson 带着团队做了一个新算法，叫 CoDel。它不再看队列堆了多少包，而是盯每个包在内存里待了多久。超过 5 毫秒，直接扔。

只要主动扔掉几个包，发送端就会立刻感知到拥堵主动减速，内存里的长队迅速散开，游戏的小包就能第一时间发出去。

想验证自家有没有中招，很简单。浏览器打开 Waveform Bufferbloat Test，看载荷延迟那一项。空载 10 毫秒，满载飙到两三百以上，就是缓冲区膨胀了。

修也不难，路由器刷 OpenWrt，开 SQM 智能队列管理，选 fq_codel 或者 CAKE 算法就行。

你看，一个 1988 年设计得好好的刹车系统，被几毛钱的内存芯片拆了个干净，然后全世界的人在自家客厅里被卡了十几年，最后还是当年那个写刹车的人出来把刹车装回去。

下次游戏卡了别骂运营商。先看看你路由器的内存，是不是太大了。