深入解析 Linux 伺服器網路 I/O 模型：從 Select 到 Epoll 的效能躍升

為什麼 Nginx 效能遠超 Apache？核心在於 I/O 多工模型

在高併發伺服器領域，Nginx 之所以能大幅超越傳統的 Apache，關鍵在於其採用的網路 I/O 模型不同。Apache 早期版本主要依賴 select 模型，而 Nginx 則充分利用了 Linux 2.6+ 核心提供的 epoll（以及 FreeBSD 的 kqueue）機制。這不僅是 API 的差異，更是底層處理邏輯的根本變革。

生動類比：從「傻瓜式守候」到「智能管家」

想像一下大學宿舍等朋友的場景：

• 阻塞 I/O（Blocking I/O）：你只能笨笨地守在樓門口，寸步不離，這期間無法做任何其他事，效率極低。
• Select 模型（傳統多工）：你找來樓管大媽幫忙。但這位大媽記性不好，每次朋友來訪，她都得帶著人逐間房挨個詢問「這裡住的是不是同學甲？」。若同時有大量訪客，大媽忙得團團轉，樓道擠滿人，效率隨連接數線性下降。
• Epoll 模型（現代多工）：升級版大媽備有完整住戶名冊。朋友一到，她查閱名冊立知房間號，直接指路即可，無需親自帶路遍尋。她只關注「有訪客到達」這類活躍事件，閒置連接完全不佔用 CPU。

技術深度剖析：Select 的硬傷與 Epoll 的優勢

Select 的致命限制

• 連接數上限寫死：核心定義 __FD_SETSIZE 通常為 1024，無法突破單進程監控 1024 個以上的檔案描述符（FD）。
• 線性掃描開銷大：每次調用都必須遍歷整個 FD 集合，時間複雜度 O(n)。連接數越多，輪詢越慢。
• 用戶/核心態重複拷貝：每次調用需將 FD 集合從用戶態拷貝到核心態，再拷貝回來，開銷可觀。

Epoll 為何強悍

• 無實際連接數上限：僅受限於系統最大開啟檔案數（/proc/sys/fs/file-max），1GB 記憶體機器輕鬆支撐 10 萬級並發。
• 事件驅動，拒絕輪詢：核心透過回調函數，僅通知就緒的 FD。閒置連接零 CPU 佔用，實現偽非同步 I/O（AIO）。
• 記憶體共享，零拷貝：使用 mmap 將核心態就緒列表映射至用戶態，避免重複拷貝。

場景對比：在高速 LAN 內幾乎所有 Socket 都活躍時，epoll 優勢不明顯，甚至因頻繁 epoll_ctl 略遜於 select。但一旦模擬 WAN 環境（大量 Idle 連接），epoll 效能碾壓 select/poll 數個數量級。

Epoll 兩大觸發模式：LT vs ET

Nginx 預設採用 LT 模式保證穩定，但在特定模組（如 ngx_http_v2_module）中會啟用 ET 以榨乾效能。理解兩者差異，是寫出高性能網路程式的必修課。

總結

從 Select 到 Epoll，是從「輪詢思維」到「事件思維」的範式轉移。Nginx、Redis、Kafka 等現代高性能中間件，皆建立於 epoll/kqueue/IOCP 等作業系統級別的異步通知機制之上。掌握其原理，不僅能指導架構選型，更能在排查疑難效能問題時直搗黃龍。