如果說答案是性能，那么肯定有人會(huì)滿不在乎。覺得性能不夠的話， 只要加機(jī)器就可以了。 然而更少的機(jī)器，意味著更低的能耗，更少的硬件投入，更少的人力資源投入去維護(hù)機(jī)器?？偠灾?，更低的成本。

肯定會(huì)有人說，C++的開發(fā)速度太慢了。然而這并不是絕對(duì)的。C++也可以做到非?？焖俚拈_發(fā)。有句俗語(yǔ) “腳本一時(shí)爽，重構(gòu)火葬場(chǎng)” 說的正是腳本語(yǔ)言開發(fā)的項(xiàng)目進(jìn)入維護(hù)階段后無(wú)窮的災(zāi)難。而 C++ 經(jīng)過了幾十年的發(fā)展, 擁有龐大的工具鏈. 不管是動(dòng)態(tài)分析還是靜態(tài)分析都有大量的工具, 能極大的幫助程序員減少錯(cuò)誤. c++得益于精良的設(shè)計(jì)，嚴(yán)格的檢查，越是大型的工程，越是能降低開發(fā)成本。

但這并不意味著C++就不適合小型項(xiàng)目了。小型的項(xiàng)目，也可以快速開發(fā)。因?yàn)?C++11 開始，已經(jīng) 感覺像是全新的語(yǔ)言了，可以完全以腳本的形式去使用，獲得接近甚至超越腳本語(yǔ)言的開發(fā)速度，同時(shí)得益于編譯優(yōu)化，獲得不俗的運(yùn)行時(shí)性能。 C++正是魚和熊掌得兼的語(yǔ)言。

為什么要用asio這個(gè)庫(kù)？

事實(shí)上如果使用C++開發(fā)服務(wù)端程序，你有多得數(shù)不清的選擇。什么 ACE 啦，libuv 啦，libevent 啦，libev 啦，甚至可以直接使用 epoll/iocp 這樣的系統(tǒng)API。 為什么要用 asio 呢？

那些年我們用過的網(wǎng)絡(luò)庫(kù)

在計(jì)算機(jī)史前文明時(shí)代, 曾經(jīng)有個(gè)世界難題, 叫 “c10k problem”. 這個(gè)是繼 y2k problem 后的又一個(gè)重大攻關(guān)項(xiàng)目. 全世界的文藝青年都想拿下解決這個(gè)問題的榮譽(yù), 正可謂八仙過海, 各顯神通.

那一年, NPTL 還沒有研究出來. 還不能創(chuàng)建成千上萬(wàn)個(gè)線程

那一年, windows 還在藍(lán)屏中掙扎, 無(wú)暇顧及網(wǎng)絡(luò).

然而, 曙光還是有的. 異步的出現(xiàn)帶給了人以希望. 古老的UNIX早就想到了, 提供了 select() 系統(tǒng)調(diào)用供人驅(qū)使. 然而問題還是有的, select 只能支持 1024 個(gè)文件描述符, windows 上的 select 更是劣質(zhì)到只能使用64個(gè). 就算通過修改定義強(qiáng)迫接受一萬(wàn)個(gè)文件描述符, 也沒有解決實(shí)際的問題. select 實(shí)在是太慢了.

在這種背景下, IBM 老大哥帶領(lǐng)著MS老弟先搞了 IOCP . 然而開源的人有開源的做法, 在 NIH 綜合癥的影響下, BSD 的人敢為天下所不齒, 發(fā)明了 Kqueue. 同樣在 NIH 綜合癥影響下, Linux 的一群 M* 的猴子搗鼓出了 epoll.

分裂, 讓人頭疼.

然而, 他們都聲稱自己的新接口對(duì) select 有質(zhì)的提升, 是破解 c10k 問題的不二法寶. 你用也得用, 不用也得用. 為了讓自己編寫的網(wǎng)絡(luò)程序能跨平臺(tái), 程序員開始了對(duì)3大各自為陣的法寶的膜拜學(xué)習(xí).

除了需要應(yīng)對(duì)多套互不兼容的 API , 異步本身也需要更高級(jí)的抽象, 把程序員從編寫異步代碼的地獄模式里拯救出來. 于是程序員們急需一個(gè)上天入地?zé)o所不能的法寶的法寶, 把這3家法寶給統(tǒng)御起來.

率先站出來悳瑟的是 ACE.

悳瑟的 ACE

恰亂世剛過, 天下待定, C++ 委員會(huì)的老人們卻韜光養(yǎng)晦, 不問世事. 所謂亂世出英雄, 英雄出少年, 歐文大學(xué)出了名秀才. 憑借其洋洋灑灑的一片雄文 《Pattern-Oriented Software Architecture》 中舉去了首府學(xué)城, 并為ACE奠定了無(wú)可撼動(dòng)的地位.

ACE 的名字, 也許靈感來自 Adaptive Clubbed Rod, 這也是當(dāng)年一位英雄少年的寶貝. 既是寶貝, 必需如意. 即是后來的葫蘆娃都怕了 “如意寶貝”.

ACE 如意在什么地方呢？如意其一, 支持 IOCP/kqueu/epoll/select/you_name_it 各種接口, 號(hào)曰沒有不能跨的平臺(tái). 如意其二, 支持多種模型。這些模型都在《Pattern-Oriented Software Architecture》有過詳細(xì)敘述. ACE 本身就是這篇論文的實(shí)踐，因?yàn)樗? 紙上得來終覺淺 絕知此事要躬行。 如意其三, 接口和模式排列組合下, 多少種, 竟可不修改代碼而適應(yīng)。

然而 ACE 畢竟嫩了點(diǎn), 沒過幾年就失勢(shì)了. 現(xiàn)在除了一些老程序員還在用, 新生代的程序員已經(jīng)不再使用 ACE 了. 為什么呢? 陳碩在他的博客里說, ACE 過于復(fù)雜，甚至比它試圖封裝的對(duì)象更復(fù)雜, 程序員是指望用你的如意寶貝去駕馭另外那三家寶貝的, 結(jié)果你比他們還難。ACE 犯了早期 C++ 庫(kù)都會(huì)犯的一個(gè)錯(cuò)誤，過度設(shè)計(jì)， 過度java化。所謂 java 化， 就是以對(duì)象代替接口， 以虛函數(shù)代替回調(diào)，以繼承代替組合。以虛類代替模板。對(duì)象間關(guān)系錯(cuò)綜復(fù)雜，牽一發(fā)而動(dòng)全身。除了作者，已經(jīng)無(wú)人能參與 ACE 的開發(fā)了。

與此同時(shí)，C語(yǔ)言的回歸卻在背后悄然進(jìn)行。C語(yǔ)言的復(fù)辟，帶來了幾個(gè)更為糟糕的替代品， libevent 和 libev，以及 乘著nodejs的盛行東風(fēng)而來的 libuv。

原始的 libevent

C語(yǔ)言有著頑強(qiáng)的生命力，當(dāng)然，這并不是因?yàn)镃語(yǔ)言有多好，在后續(xù)的章節(jié)了我們還會(huì)深入的探討C++相對(duì)C的改進(jìn)。C語(yǔ)言的頑強(qiáng)和人天生的懶惰和偏見是有一定關(guān)系的。這種惰性表現(xiàn)為隨遇而安，表現(xiàn)為固執(zhí)己見。 非要拼命的否定C++，固守 C , 對(duì) C 的缺點(diǎn)視而不見，詆毀C++相對(duì)C的改進(jìn)。固守的結(jié)果就是簡(jiǎn)陋原始的 libevent . 然而因?yàn)楸Ｊ攸h巨大的人數(shù)優(yōu)勢(shì)， libevent 應(yīng)其群眾基礎(chǔ)良好而獲得了空前的廣泛使用。

libevent 就如名字所言，是一個(gè)異步事件框架。從 OS 那里獲得事件， 然后派發(fā)。派發(fā)機(jī)制就是“回調(diào)函數(shù)”。異步異步，歸根結(jié)底就是處理從操作系統(tǒng)獲得的事件。iocp也好， epoll也罷，都只是用來獲取事件的接口。libevent 去掉了ACE華而不實(shí)的包裝，保留了異步事件，極大的簡(jiǎn)化了模型。不得不說軟件工程是個(gè)糟糕的發(fā)明，從來都把簡(jiǎn)單問題復(fù)雜化。libevent把簡(jiǎn)單問題簡(jiǎn)單化，讓異步網(wǎng)絡(luò)編程反樸歸真，應(yīng)該來說，本是一個(gè)好庫(kù)。

然而 libevent 因?yàn)樵O(shè)計(jì)缺陷，例如使用全局變量，定時(shí)器無(wú)法處理時(shí)間跳變，諸如此類的設(shè)計(jì)缺陷導(dǎo)致了 libev 的出現(xiàn)。 libev 就是為了克服libevent的缺陷而誕生的。然而，libev 就一定好了嗎？

禁錮的 libev

libev 帶著對(duì) libevent 的怨氣出世了。 吸收了 libevent 的所有缺點(diǎn)， 雖然承諾過改進(jìn)。然而 libev 如何改進(jìn)的了呢？ libev 已經(jīng)夠原始了，向下改進(jìn)還不如讓人直接使用系統(tǒng)的 api, 向上改進(jìn)，一是會(huì)導(dǎo)致和libevent的重疊，二是很快就碰到了 C 語(yǔ)言強(qiáng)加的禁錮。

C 語(yǔ)言因其語(yǔ)法簡(jiǎn)陋簡(jiǎn)潔而著稱。然而，缺乏必要的抽象能力，導(dǎo)致 C 語(yǔ)言編寫異步程序，就如同安迪拿著小錘子琢開肖生克監(jiān)獄的墻壁一樣。能，但是要耗費(fèi)巨大的精力和時(shí)間。 編寫異步程序， 最需要的2個(gè)抽象能力， 其一為協(xié)程，其二是函數(shù)對(duì)象，包括匿名函數(shù)對(duì)象， 也就是lambda。 C統(tǒng)統(tǒng)沒有。函數(shù)對(duì)象是實(shí)現(xiàn)閉包比不可少的，如果沒有函數(shù)對(duì)象， 就只能通過攜帶 void 指針的形式迂回完整，繁瑣不說，還特別容易出錯(cuò)。程序里也到處充滿了類型強(qiáng)轉(zhuǎn)。到處是臨時(shí)定義的類型，就為了傳給 void 使用。

盡管C 有那么多缺點(diǎn)，然而 libev 還未來得及被C的缺點(diǎn)拖累，因?yàn)樗恢С?IOCP. 于是 libuv 就出來給 libev 擦屁股了。 支持了 iocp 后的 libuv 就真的只有 C 本身的缺點(diǎn)了嗎？

混亂的 libuv

libuv 可以說是 C 語(yǔ)言的異步庫(kù)所能達(dá)到的最高高度了。完完全全的觸碰到了C語(yǔ)言的自身瓶頸，好在 libuv 只是 nodejs 的底層庫(kù)，上層軟件轉(zhuǎn)移到 javascript 語(yǔ)言而逃避了 C 的禁錮。

真的是這樣的嗎？ libuv 自身還有什么缺點(diǎn)呢？

開源社區(qū)avplayer的大拿jackarain曾經(jīng)說過，一個(gè)網(wǎng)絡(luò)庫(kù)好不好，就看他有沒有正確的處理 TCP 關(guān)閉， read write 實(shí)現(xiàn)的ui不對(duì)。 libuv 很遺憾的是，不合格。libuv 的 uv_write 沒有返回值，允許空回調(diào)。也就是忽略write錯(cuò)誤。 網(wǎng)絡(luò)出錯(cuò)的情況下， libuv 的用戶只能稀里糊涂的知道出錯(cuò)了， 至于錯(cuò)在哪？數(shù)據(jù)到底有沒有發(fā)出去了? 一概不知道。 把數(shù)據(jù)交給 uv_write 后，就是一筆糊涂賬了，大概 TCP 不可靠的說法就是從這里傳出來的吧。

ASIO 騰空出世

在地球最大的島上，另一位少年開始拜讀 ACE 的大作。那時(shí)候，沒有 libuv 沒有 libev 更沒有 libevent . 有的只是 ACE. 然而這個(gè)南方小國(guó)的少年沒有跟風(fēng)陷入 ACE 崇拜，他以敏銳的目光察覺到了 ACE 的弊病。 ACE 哪里做的不好？又哪里是值得借鑒的？

少年在給 c++ 委員會(huì)寫的一篇上書中說，Proactor 模型乃最優(yōu)模型。而 Proactor 模型，乃 ACE 提出的 6 個(gè)模型之一。根據(jù) IT 界贏者通吃律，一個(gè)優(yōu)秀的網(wǎng)絡(luò)庫(kù)，只需要支持 Proactor 模型即可。 支持其他次優(yōu)模型都是徒勞的。ACE 試圖全盤通吃，犯了大忌。

少年在一次開發(fā)者大會(huì)的演講上，再次透露，網(wǎng)絡(luò)庫(kù)不宜做成框架，而是要像系統(tǒng)的API那樣，作為一個(gè)樂高積木。ACE 做成了一個(gè)框架，同樣不妥。

你說了那么多 ACE 不好，有本事你弄個(gè)好的?。?批評(píng)者向來都是這么理直氣壯。 正如 ACE 的作者實(shí)踐了 “紙上得來終覺淺 絕知此事要躬行” 一樣，這位勇敢的少年也拿出了 ASIO, “實(shí)踐出真知”，他如是說。

那還是 SARS 病毒肆虐的年代，幾乎沒有人注意到，今后顛覆C++的網(wǎng)絡(luò)世界的 ASIO 悄然出世了。而他的父親，還只是悉尼的學(xué)子。ASIO 并沒有顯赫的家庭背景，然而英雄不問出處，它注定將有不平凡的一生。

俗語(yǔ)有云，三歲看老。在 asio 才三歲的時(shí)候，它父親就將 asio 引薦給了 c++ 委員會(huì)的老人們。上一次他們這么做的時(shí)候，他們接納了 STL。 ASIO 最終被內(nèi)定，然后放入 Boost 鍛煉, 經(jīng)過 Boost 十余的鍛煉，ASIO 終于在 2017 年進(jìn)入了 c++ 標(biāo)準(zhǔn)。

前攝者？為什么是演員

在給 c++ 老人會(huì)的引薦信里，asio 爸爸仔細(xì)闡述了asio的設(shè)計(jì)抉擇回答了圍繞 asio 的設(shè)計(jì)提出的很多問題。 為什么 Proactor 會(huì)是最佳模型？

• 跨平臺(tái) 許多操作系統(tǒng)都有異步API，即便是沒有異步API的Linux, 通過 epoll 也能模擬 Proactor 模式。
• 支持回調(diào)函數(shù)組合 將一系列異步操作進(jìn)行組合，封裝成對(duì)外的一個(gè)異步調(diào)用。這個(gè)只有Proactor能做到，Reactor 做不到。意味著如果asio使用Reactor模式，就對(duì)不起他“庫(kù)” 之名。
• 相比 Reactor 可以實(shí)現(xiàn) Zero-copy
• 和線程解耦 長(zhǎng)時(shí)間執(zhí)行的過程總是有系統(tǒng)異步完成，應(yīng)用程序無(wú)需為此開啟線程

Proactor 也并非全無(wú)缺點(diǎn)，缺點(diǎn)就是內(nèi)存占用比 Reactor 大。Proactor 需要先分配內(nèi)存而后處理IO, 而 Reactor 是先等待 IO 而后分配內(nèi)存。相對(duì)的Proactor卻獲得了Zero-copy好處。因?yàn)閮?nèi)存已經(jīng)分配好了，因此操作系統(tǒng)可以將接受到的網(wǎng)絡(luò)數(shù)據(jù)直接從網(wǎng)絡(luò)接口拷貝到應(yīng)用程序內(nèi)存，而無(wú)需經(jīng)過內(nèi)核中轉(zhuǎn)。 Proactor 模式需要一個(gè) loop ,這個(gè) loop asio 將其封裝為 io_service.他不僅是 asio的核心，更是一切基于asio設(shè)計(jì)的程序的核心。

宇宙級(jí)異步核心

io_service 脫胎于 IO 但不僅用于 IO. Christopher Kohlhoff 在給委員會(huì)的另一份編號(hào) N3747 的信上上說它是 宇宙級(jí)異步模型 Universal Asynchronous Model。在宇宙級(jí)異步模型里，一個(gè)異步操作由三部分構(gòu)成

• 發(fā)起 按照 asio 的編碼規(guī)范，所有的發(fā)起操作都使用 async_ 前綴，使用 async_動(dòng)詞 的形式作為函數(shù)名。
• 執(zhí)行 異步過程在發(fā)起的時(shí)候被executor執(zhí)行（系統(tǒng)可以是支持 AIO 的內(nèi)核，不支持 AIO 的系統(tǒng)則是 aiso 用戶層模擬）
• 完成并回調(diào) 在發(fā)起 async_* 操作的時(shí)候，總是攜帶一個(gè)回調(diào)的閉包。asio使用閉包作為異步事件完成的處理回調(diào)，沒而不是C式的回調(diào)函數(shù)。asio的宇宙異步模型里，回調(diào)總是在執(zhí)行 io_service::run 的線程里執(zhí)行。asio絕不會(huì)在內(nèi)部線程里調(diào)用回調(diào)。

在回調(diào)里發(fā)起新的異步操作，一輪套一輪。整個(gè)程序就圍繞著 io_service::run 運(yùn)轉(zhuǎn)起來了。 io_service 不僅僅能用于異步 IO ,還可以用來投遞任意閉包。實(shí)現(xiàn)作為線程池的功能。這一通用型異步模型徹底擊敗微軟 PPL 提案，致使微軟轉(zhuǎn)而研究協(xié)程。然而微軟在協(xié)程上同樣面臨 asio 的絞殺。

閉包和協(xié)程

宇宙級(jí) asio 使用閉包作為回調(diào)，而 C 庫(kù)只能使用函數(shù)+void*, ACE 雖然使用的 C++語(yǔ)言，卻不知道閉包為何物，使用的是 虛函數(shù)作為回調(diào)。需要大量的從 ACE 的對(duì)象繼承。以閉包為回調(diào)，asio更是支持了一種叫“無(wú)棧協(xié)程”的強(qiáng)悍武器。 asio的無(wú)棧協(xié)程，僅僅通過庫(kù)的形式，不論是在性能上，還是易用性上，還是簡(jiǎn)潔性上，甚至是B格上，都超過了微軟易于修改語(yǔ)言而得的 await提案。

微軟，乃至 ACE ，并不是不知道閉包，而是在c++里實(shí)現(xiàn)閉包的宇宙級(jí)executor —— 也就是 io_service，需要對(duì)模板技術(shù)的精通。 asio “把困難留給自己，把方便帶給大家”，以地球人無(wú)法理解的方式硬是在 c++98 上實(shí)現(xiàn)了宇宙級(jí)異步核心。 當(dāng)然，如果 c++11 早點(diǎn)出現(xiàn)，如果 c++17 早點(diǎn)出現(xiàn)，實(shí)現(xiàn) asio 的宇宙模型會(huì)更加的簡(jiǎn)單 —— 其實(shí)這也是 c++ 的理念，增加語(yǔ)言特性，只是為了讓語(yǔ)言用起來更簡(jiǎn)單。

緩沖區(qū)

有了閉包的支持，內(nèi)存管理也變得輕輕松松起來。 ASIO 本身并不管理內(nèi)存，所有的IO操作，只提交對(duì)用戶管理的內(nèi)存的引用，稱 Buffers。asio::buffers 引用了用戶提交的內(nèi)存，保持整個(gè) IO 期間，這塊內(nèi)存的有效性是用戶的責(zé)任。然而這并不難！ 因?yàn)榛卣{(diào)是一個(gè)閉包。通過閉包持有內(nèi)存，只要 asio 還未回調(diào)，閉包就在，閉包在，內(nèi)存在。asio 在調(diào)用完回調(diào)后才刪除相應(yīng)的閉包。因此資源管理的責(zé)任可以丟給閉包，而閉包可以通過智能指針精確的控制內(nèi)存。 不是 GC , 勝于 GC 千百倍！益于c++的 RAII機(jī)制，再無(wú)內(nèi)存泄漏之憂！

以上就是c++ 網(wǎng)絡(luò)庫(kù)asio的優(yōu)勢(shì)的詳細(xì)內(nèi)容，更多關(guān)于c++ 網(wǎng)絡(luò)庫(kù)asio的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！