為什麼電腦的「工作區塊」不斷變動？
長久以來，電腦執行的「工作」疆界一直在變動，從作業系統的核心（Kernel）內部，逐漸轉移到特定應用程式的使用者行程（User Process）中。網路處理也不例外，過去大部分的協定「工作」都發生在核心層級。然而，網路功能究竟該在使用者行程中處理到什麼程度，至今仍是個開放性的問題。
核心與使用者行程的效率之爭
使用者行程必須透過系統呼叫（System Calls）將工作委派給核心，這會觸發中斷（Interrupts）。在中斷期間，作業系統會暫停正在運行的程式來處理其他任務。 問題來了：這些中斷會帶來顯著的開銷（Overhead），特別是對於多執行緒（multi-threaded）程式，會因為同步化成本而影響整體執行速度。
真的有關係嗎？ 從某方面來說，或許不影響，因為大多數終端系統的 CPU 容量充裕，99% 的時間都處於閒置狀態。但從另一個角度看，它至關重要！為了追求效率、安全性、以及最佳的能源消耗，我們必須在對的地方高效地完成工作。
這就導致了工作區塊劃分的界線正在移動：
有些努力主要在精簡核心，移除多餘程式碼。
有些「反向」努力則試圖將使用者空間（User-space）的工作移回核心，以減少資料移動和瓶頸。
智慧網卡與「離線處理」的興起
一個典型的案例就是越來越智慧的「線路卡（Line Cards）」。這些網卡配備了大量的記憶體和高速的 FPGA（Field Programmable Gate Array）處理器，專門用於處理進出網路的資料。
這種做法通常被稱為「離線處理（Offline Processing）」：也就是將處理工作放在線路卡上，而不是佔用主機的 CPU 資源。
佇列作為指標：打破系統呼叫的瓶頸
隨著高速韌體「程式碼上卡」（code-on-card）的趨勢發展，一種新的資料傳輸方式也應運而生：將完整的資料佇列（queues of data）以指標（pointers）的形式傳遞。
與其傳輸小塊資料並不斷遭遇核心系統呼叫帶來的阻塞，現在可以單次呼叫，指向一個包含「待辦事項」或一組重複 read() 操作的向量（vector）。這種機制可以直接從線路卡取得資料佇列，大幅避免了整理（marshalling）和移動資料的成本。
Firefox 的實戰：極速 UDP 輸入/輸出 (I/O)
Mozilla 的 Firefox 瀏覽器，透過 Rust 程式語言實作了快速的 User Datagram Protocol (UDP) 輸入/輸出 (I/O)，為我們展示了這項技術的實際應用與對系統呼叫成本的影響。
從 TCP 到 QUIC 的典範轉移
過去：我們生活在一個以 TCP 為主的世界，HTTP、HTTPS、TLS 都建立在 TCP/IP 通訊端（sockets）之上。
現在：我們正處於一個「QUIC 盛行」的時代。QUIC 已經有效地成為新的 TCP，並且功能遠超 TCP。
QUIC 的核心優勢：
多重資料流並存：允許在單一連線中並存多種資料流狀態。
連線靈活性：由於協定實作了會話標記（session markers），即使終端發生變化，它也能敏捷地接續會話。
安全性與支援：由 TLS 良好保護，並獲得 NGINX、Caddy 等現代網頁伺服器的強力支援。
關鍵點：QUIC 協定本身是運行在 UDP 上的。UDP 是在 IP 堆疊同一層級中較不可靠的資料包協定，它本身不提供可靠性、流量或壅塞控制，這些功能都是由 QUIC 協定層疊加在 UDP 之上完成的。
Firefox 如何實現速度飛躍？
Firefox 實作了一種改進的 UDP I/O 方法，它利用了新的核心模型：
合併（coalesced）讀寫。
指向資料的高效向量。
利用板載（on-card）處理的介面。
結果是：Firefox 現在使用最快、成本最低的方法來傳輸您的 QUIC 網路會話資料。
結語：追上領先者的步伐
這是一個重大的成就！QUIC 最初是由 Google 開發並推向 IETF 標準化流程，使得 Chrome 在某種程度上擁有「先發優勢」。但 Firefox 憑藉這項高效能的實作，再次站上了與 Chrome 同級服務的行列。網路效率與創新的界線，正不斷被推向新的高峰！
本文為作者個人想法，不代表TWNIC之立場，若對此內容有興趣，請參閱原文：https://blog.apnic.net/2025/11/28/fast-udp-i-o-for-firefox-in-rust/