Dave T?ht遺志落地：LibreQoS 2.0把網絡延遲砍

一個開源項目死了核心貢獻者，通常就慢慢涼了。LibreQoS反著來——Dave T?ht 2023年去世后，團隊把他念叨了十年的"延遲負載"理念，全塞進2.0版本里。

從命令行到能看懂的界面

LibreQoS 1.x時代，運營商想調個帶寬策略，得對著配置文件猜謎。2.0直接換了套本地Web界面，拓撲圖、流量熱力、用戶投訴定位，三屏之內能解決八成日常問題。

產品經理出身的我，看到這種改動會條件反射：這是把"網絡運維"從工程師專屬，改成了值班人員也能上手的工具。降低門檻意味著擴大用戶基數，開源項目最缺的就是這個。

但界面只是面子。里子是一套重構的流量調度引擎，把 cake（通用自適應隊列管理）和 eBPF（擴展伯克利包過濾器）的聯動做了重新封裝。用戶不用懂這些縮寫，只需要知道：同樣帶寬，視頻通話少卡一半。

那個總在郵件列表里吵架的人

Dave T?ht沒寫過LibreQoS的核心代碼，但幾乎每個設計決策都有他的影子。他更出名的身份是Bufferbloat項目發起人——2011年就在喊"路由器緩存太大是罪"，比業界共識早了至少五年。

「延遲不是帶寬的副產品，是需要單獨優化的指標」，這是他郵件簽名檔級別的口頭禪。LibreQoS 2.0的實時監控面板里，"Latency Under Load"被放在和吞吐量同等的位置，算是把這句話刻進產品里了。

團隊同時發布了LibreQoS Bufferbloat Test v2，瀏覽器里跑一圈，輸出不是抽象的"網速多少兆"，而是直接告訴你：你的網絡打游戲會不會掉線、開視頻會議會不會變電子音。

誰真的需要這個

家庭用戶用Speedtest測速，運營商用LibreQoS兜底。它的典型部署場景是WISP（無線互聯網服務提供商）和鄉村寬帶——那些沒法鋪光纖、只能靠無線中繼的地方，帶寬本來就緊張，延遲抖動直接決定用戶會不會投訴。

2.0版本把"訂閱者級"的故障排查做深了。以前用戶說"網卡了"，運維只能看到基站整體流量。現在能定位到具體哪個用戶、哪類應用、在哪個時段出現了異常排隊。這種顆粒度，在開源網絡工具里不多見。

項目維護者Robert Chacón在發布說明里寫得很克制：「Dave會希望我們關注實際運行的網絡，而不是爭論抽象概念。」

開源網絡工具的市場很微妙——企業級有商業方案，極客玩家自己刷OpenWrt，LibreQoS卡在中間服務中小運營商。2.0的界面改進和測試工具，看起來是想把"中間層"做厚，讓更多人能參與進來。

最后一個細節：Bufferbloat Test v2的默認測試時長是30秒，剛好覆蓋一局《英雄聯盟》的平均團戰時長。這是湊巧，還是Dave生前某次郵件里提過的數字？