作者簡介：謝友鵬，目前在螞蟻金服-支付寶-網(wǎng)絡技術(shù)部任職技術(shù)專家，先后在華為和支付寶從事網(wǎng)絡和云相關(guān)開發(fā)。涉及領域vpn、sdwan、全球網(wǎng)絡加速、區(qū)塊鏈網(wǎng)絡加速、cdn靜態(tài)緩存等。長期研究nginx、apache traffic server、frp等代理項目和基于k8s的云原生項目。不定期更新個人微信公眾號--網(wǎng)絡技術(shù)修煉。關(guān)注領域：網(wǎng)絡、云、linux高性能服務端。

1999年Dan Kegel在發(fā)表的論文中提出了The C10K problem，這篇論文對傳統(tǒng)服務器架構(gòu)處理大規(guī)模并發(fā)連接時的挑戰(zhàn)進行了詳細描述，并提出了一些解決方案和優(yōu)化技術(shù)。這里的C指的是Concurrent(并發(fā))的縮寫，C10K問題是指怎么在單臺服務器上并發(fā)一萬個請求。如果你分析過性能問題一定會注意到，性能極限通常受到一個或多個資源的限制，比如內(nèi)存、文件句柄個數(shù)、網(wǎng)絡帶寬、CPU等。這里討論的前提是機器的物理資源和系統(tǒng)配置能夠滿足一萬個請求。在這個前提下，網(wǎng)絡并發(fā)主要關(guān)注兩個方面：一是應用程序和操作系統(tǒng)內(nèi)核之間如何進行IO事件通知，二是應用程序進程或線程的分配方式。

I/O模型

阻塞vs非阻塞、同步vs異步

你可能經(jīng)?？吹侥衬稠椖坑玫耐椒亲枞Ｐ汀⒛衬稠椖坑玫漠惒椒亲枞Ｐ?，所以在正式討論I/O模型前，還是先對齊一下關(guān)于阻塞、非阻塞以及同步、異步的概念吧。

阻塞、非阻塞指的是系統(tǒng)調(diào)用時“等待數(shù)據(jù)準備好”這個動作。比如read時候，如果內(nèi)核判定數(shù)據(jù)還沒準備好：

內(nèi)核讓應用進程一直等待，直到數(shù)據(jù)準備好才通知應用進程就是阻塞；

內(nèi)核立即通知應用程序說數(shù)據(jù)沒準備好，你先干別的吧，就是非阻塞。

同步、異步指的是“內(nèi)核空間與用戶空間復制數(shù)據(jù)”這個動作。比如read時候，如果內(nèi)核判定數(shù)據(jù)還沒準備，過一段時間數(shù)據(jù)來了：

內(nèi)核通知應用進程你來讀取數(shù)據(jù)吧，應用程序再次系統(tǒng)調(diào)用將數(shù)據(jù)讀走就是同步；

內(nèi)核將數(shù)據(jù)拷貝到用戶空間后再通知應用進程，數(shù)據(jù)已經(jīng)拷貝好了直接用吧，就是異步。

I/O模型詳解

Stevens在《UNIX 網(wǎng)絡編程 卷1》一書的6.2章節(jié)介紹了五種 I/O 模型。以下模型以UDP接收報文為例來說明這五種I/O 的工作方式。

阻塞式I/O

該模型使用最簡，用戶進程調(diào)用讀取數(shù)據(jù)系統(tǒng)后就一直等待，直到內(nèi)核數(shù)據(jù)準備好，并將數(shù)據(jù)從內(nèi)核空間拷貝到用戶空間后，調(diào)用結(jié)束。這種模型效率顯然的低下，因為這種模型會導致兩種可能結(jié)果：

為每個請求分配一個進程或線程，那么高并發(fā)意味著內(nèi)核要調(diào)度的進程或線程數(shù)量很龐大，調(diào)度、上下文切換等開銷會使系統(tǒng)性能降低。

固定數(shù)量的進程或線程處理請求，那么這些進程或線程全被被占用后，新請求就只能等了。

該模型低效的根本原因在于阻塞，內(nèi)核數(shù)據(jù)沒有準備好的時候，用戶態(tài)進程明明可以干其他活的，現(xiàn)在只能白白等待。

非阻塞式 I/O

這種模型通過非阻塞的方式與內(nèi)核打交道，如果內(nèi)核中數(shù)據(jù)還未準備好，就立刻返回給用戶進程，用戶進程就可以先干別的事情，過一段再進行讀數(shù)據(jù)的系統(tǒng)調(diào)用，直到內(nèi)核數(shù)據(jù)準備好，并將數(shù)據(jù)拷貝到用戶空間。相比于阻塞的模型，這種非阻塞+主動輪詢的模型避免了用戶進程白白等待內(nèi)核準備數(shù)據(jù)的時間，所以效率有所提升，但是因為每次輪詢都是系統(tǒng)調(diào)用，所以上下文切換變多了，因此性能也不高。

I/O 復用

既然不停主動查詢內(nèi)核數(shù)據(jù)是否準備好這件事會引起系統(tǒng)性能下降，那能不能通過注冊+通知的方式呢？這就是大名鼎鼎的I/O復用模型。該模型允許用戶態(tài)通過一個進程將所有相關(guān)的讀寫事件(使用select、poll或epoll)注冊到內(nèi)核，然后內(nèi)核會主動通知用戶態(tài)進程，一旦任意一個或多個請求的讀寫數(shù)據(jù)準備好。這種方式在單個進程或線程中同時處理多個I/O通道的就緒狀態(tài)被稱為I/O多路復用。使用I/O多路復用既不會阻塞處理請求的進程，也不會因為輪詢內(nèi)核數(shù)據(jù)是否準備好而導致過多的系統(tǒng)調(diào)用，因此具有高效的特點。然而，需要注意的是，一旦內(nèi)核通知應用進程數(shù)據(jù)準備就緒，仍然需要通過系統(tǒng)調(diào)用觸發(fā)數(shù)據(jù)的讀取過程。

Linux內(nèi)核對這種模型的支持非常完善，因此許多高性能服務器在Linux環(huán)境中廣泛采用這種模式。

信號驅(qū)動式 I/O

I/O復用模型中是用一個進程(select、poll或epoll)阻塞或輪詢所有請求的數(shù)據(jù)是否準備好，從而讓所有請求進程的處理都不會阻塞。信號驅(qū)動式則沒有這個復用的I/O進程，每個請求進程自己去內(nèi)核注冊，然后等數(shù)據(jù)準備好內(nèi)核通知應用進程去處理。這種模型應用套接字處理的實踐場景為基于UDP的NTP服務，幾乎沒有在TCP上的應用，因為對于TCP來說信號產(chǎn)生過于頻繁，而且并沒有告訴應用程序發(fā)生了什么事件，比如下面條件均會導致TCP套接字產(chǎn)生SIGIO信號：

監(jiān)聽套接字某個連接請求已經(jīng)完成；

某個斷鏈請求已經(jīng)發(fā)起；

某個斷鏈請求已經(jīng)完成；

某個半連接已經(jīng)關(guān)閉；

數(shù)據(jù)到達套接字；

數(shù)據(jù)已經(jīng)從套接字發(fā)出；

發(fā)生某個異步錯誤。

異步 I/O

前面幾種方式，無論是阻塞還是非阻塞，從內(nèi)核空間到用戶空間復制數(shù)據(jù)的動作都是在內(nèi)核通知用戶進程后，用戶進程再通過系統(tǒng)調(diào)用觸發(fā)完成的，因此都屬于同步操作。而異步I/O模型則不同，它允許用戶態(tài)進程通過系統(tǒng)調(diào)用讀取數(shù)據(jù)后，即使內(nèi)核數(shù)據(jù)未準備好，也會立即返回給用戶進程，告知數(shù)據(jù)未準備好，讓用戶進程可以執(zhí)行其他操作。當數(shù)據(jù)準備好后，內(nèi)核會將數(shù)據(jù)從內(nèi)核空間拷貝到用戶態(tài)，并直接回調(diào)用戶進程，將數(shù)據(jù)送到用戶進程手中。這種模型不僅具備非阻塞特性，還能進一步減少系統(tǒng)調(diào)用的次數(shù)，因此在理論上相對于其他模型更加高效。需要注意的是，這種模型需要操作系統(tǒng)內(nèi)核的支持。

在《UNIX網(wǎng)絡編程卷1》一書中，截至書稿時，支持POSIX異步I/O的系統(tǒng)相對較少。由于早期Linux內(nèi)核對網(wǎng)絡異步I/O的支持不夠成熟，在Linux環(huán)境下，大多數(shù)高性能網(wǎng)絡服務器選擇采用I/O復用的方式，如epoll。然而，從Linux內(nèi)核5.0版本開始，引入了io_uring異步操作，隨著該技術(shù)的成熟，越來越多的高性能網(wǎng)絡服務器（例如nginx）開始支持使用這種異步I/O方式。

如何簡單理解5種I/O？

下面通過一個例子對比一下5種模型，顧客是應用進程，餐飲人員為內(nèi)核，餐桌為應用進程的數(shù)據(jù)buffer:

阻塞式I/O：交完錢也要在窗口排隊，等師傅做好，將飯端給你，你再端到自己餐桌。

非阻塞式I/O：交完錢你就可以離開窗口玩一會了，窗口有個屏幕，你過一會跑過來看一下自己的飯好了沒，直到飯做好，自己端到自己的餐桌。

I/O復用：好幾個同學都把飯卡交給你，你一個人跑到窗口排隊刷卡，誰的飯好了，你就打電話給誰，讓他自己將飯端到餐桌。

信號驅(qū)動式I/O：你去窗口手機刷卡后就可離開了，飯做好會通過手機通知你，然后自己過去將飯端到餐桌。

異步I/O：去窗口點餐后，告訴服務員你在哪個餐桌就可以離開了，飯做好，服務員會將飯幫你端到餐桌。

進程/線程分配

進程和線程的創(chuàng)建、調(diào)度都需要系統(tǒng)開銷。在高并發(fā)系統(tǒng)中，為每個請求分配一個進程或線程會對性能產(chǎn)生不利影響。為了克服這個問題，高性能的網(wǎng)絡模型通常采用進程池或線程池來管理進程或線程。進程/線程池的設計目的是降低創(chuàng)建和銷毀進程/線程的頻率，并限制系統(tǒng)中總進程/線程的數(shù)量，以減少內(nèi)核調(diào)度的開銷。

常用高性能模式

reactor 模式

《The Design and Implementation of the Reactor》一文詳細介紹了reactor模式的工作方式，簡單來說，reactor模式=I/O復用 + 進程池/線程池。

proactor模式

《Proactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Asynchronous Events》一文詳細介紹了proactor模式的工作方式，簡單來說，proactor模式=異步I/O+ 進程池/線程池。

驚群效應

對于TCP請求來說，最理想的情況是每個事件每次從池中喚醒一個進程或線程去執(zhí)行，這樣既不需要等待又不會引起競爭。用一個進程或線程專門負責處理accept事件，然后將接下來的事件繼續(xù)分發(fā)給其他worker處理是可行的。有一些模型(比如nginx)存在多個進程或線程監(jiān)聽同一個端口的情況，如果不加處理會出現(xiàn)一個accept事件喚醒所有worker進程的情況，即驚群效應。為了應對驚群效應，早期nginx引入了accept_mutex的機制，競爭到鎖的worker才會執(zhí)行accept操作，從而避免所有worker都被喚醒。Linux3.9 版本后提供了reuseport更好的解決了多個進程或線程監(jiān)聽同一個端口引起的驚群問題，簡單說就是內(nèi)核幫你輪詢，而不用在應用層面競爭了。

更快、更強大的網(wǎng)絡模型

欲望是永無止境的，有人提出The C10K problem問題，就有人提出The C10M problem，前文中的討論基本都是圍繞用戶態(tài)進程和內(nèi)核的交互優(yōu)化，既然和內(nèi)核交互容易導致性能瓶頸，那為何不旁路掉內(nèi)核協(xié)議棧呢？所以有了更快的網(wǎng)絡方案，比如DPDK、XDP、甚至硬件加速等。

審核編輯：湯梓紅