在高頻交易系統中，networking 是整個交易鏈路中最敏感的效能元件之一。從 market data 接收、封包解析，到 Order Gateway 發送，每一個微秒甚至奈秒級的延遲都可能影響交易系統的反應速度。因此，如何降低 I/O latency、避免 thread blocking，以及維持穩定的 tail latency，是 HFT Networking 設計中的核心問題。

1. 從阻塞到非阻塞 —— 現代 Linux 網路加速器

傳統 Blocking I/O 的主要問題在於，當應用程式呼叫 recv() 或 read() 時，如果 socket buffer 中沒有可用資料，thread 可能進入等待狀態。這個過程不僅會造成 CPU 資源閒置，也可能引入 scheduler、context switch 與 cache pollution 等額外成本。在一般 web server 中，這些成本通常可以接受；但對 HFT 系統而言，即使是數微秒的額外 latency，也可能需要被仔細分析。

Non-Blocking I/O 的設計理念則完全不同。透過設定 socket 為 non-blocking mode，應用程式執行 recv() 時，若是目前沒有資料可讀系統會立即返回，而不是讓 thread 阻塞。應用程式可以根據返回值決定下一步操作，從而讓 CPU 持續執行其他工作。Linux 環境下常見的相關機制包括 epoll、SO_BUSY_POLL，以及更進階的 io_uring。

2. io_uring —— 新世代的作業系統黑科技

在 io_uring 出現之前，Linux 處理非同步主要靠 epoll。但 epoll 有個瓶頸：每次有資料進出，應用程式都要向作業系統核心發出 system call。這就像進出海關要一直驗證，很消耗 CPU 效能。

io_uring 建立了兩個共享的 ring buffer：Submission Queue 負責發送請求；Completion Queue 負責接收結果。以下兩個特點使得它效能特別好。

• 零系統呼叫：應用程式把一堆 I/O 任務放進佇列後，作業系統核心會自己去拿來做，做完放回結果佇列。整個過程應用程式和內核心有靈犀，幾乎不需要互相中斷，省下了昂貴的切換成本。
• 網路與磁碟通吃：以前的 epoll 只對網路有用，對硬碟檔案讀寫無能為力；io_uring 則完美支援網路與磁碟 I/O。

3. Boost.Asio —— C++ 網路程式設計的常青樹

Asio 是 C++ 網路標準化提案的基石，而 Boost.Asio 是一個歷史悠久且極度成熟的 C++ 函式庫，協助開發者把底層複雜的非同步機制包裝起來。它的核心基於 Proactor 設計模式。當程式向 Asio 發出網路讀取指令後，無須在現場原地等待 block，而是能立即釋放資源去處理其他高優先級的任務。後續的資料處理則交由 Asio 在連線完成時自動觸發，從而大幅提升系統的併發處理能力與資源 busy-waiting 的浪費。

同一套 Asio 程式碼，在 Linux 上它會自動調用 epoll，在 Windows 上會自動調用 IOCP，擁有強大的跨平台能力。其完美支援 C++20 的 Coroutines，讓使用者可以用傳統同步程式碼的直覺方式，寫出高效能的非同步程式。

4. 非同步與低延遲 —— 高頻交易系統的硬核優化指南

在高頻交易場景中，Non-Blocking I/O 並不等於低延遲。傳統的 epoll_wait 事件通知機制，因涉及執行緒喚醒與排程干預，容易產生無法容忍的延遲抖動。為了追求極致穩定，HFT 系統通常採取以下優化策略。

• 核心技術：捨棄傳統機制，改用 busy polling 持續監控 socket。或導入 kernel bypass 技術，讓應用程式直接跨過 Linux 網路堆疊從網卡讀取資料。
• 硬體與記憶體最佳化：搭配 CPU 核心綁定、NUMA 感知記憶體配置、Hugepage 與 lock-free 資料結構，極小化上下文切換與系統呼叫。
• 整體架構：從網卡接收、解析、策略執行到下單網關，建立全鏈路的低延遲管道。嚴密監控吞吐量、平均延遲、尾端延遲與丟包率。

高頻交易網路並非單純的 API 選擇，而是從硬體、作業系統到應用層的整體架構優化，旨在高負載下維持可預期且高度穩定的端到端低延遲。一個典型的低延遲 HFT Networking pipeline 可以抽象成：
NIC → RX Queue → Non-Blocking Receive → Packet Parsing → Market Data Handler → Strategy → Order Gateway → TX Queue → NIC