附錄A
　　談一談網(wǎng)絡(luò)編程學(xué)習(xí)經(jīng)驗(yàn)
　　本文談一談我在學(xué)習(xí)網(wǎng)絡(luò)編程方面的一些個(gè)人經(jīng)驗(yàn)�！熬W(wǎng)絡(luò)編程”這個(gè)術(shù)語的范圍很廣，本文指用Sockets API 開發(fā)基于TCP/IP 的網(wǎng)絡(luò)應(yīng)用程序，具體定義見§A.1.5 “網(wǎng)絡(luò)編程的各種任務(wù)角色”。
　　受限于本人的經(jīng)歷和經(jīng)驗(yàn)，本附錄的適應(yīng)范圍是：
　　o x86-64 Linux 服務(wù)端網(wǎng)絡(luò)編程，直接或間接使用Sockets API。
　　o 公司內(nèi)網(wǎng)。不一定是局域網(wǎng)，但總體位于公司防火墻之內(nèi)，環(huán)境可控。
　　本文可能不適合：
　　o PC 客戶端網(wǎng)絡(luò)編程，程序運(yùn)行在客戶的PC 上，環(huán)境多變且不可控。
　　o Windows 網(wǎng)絡(luò)編程。
　　o 面向公網(wǎng)的服務(wù)程序。
　　o 高性能網(wǎng)絡(luò)服務(wù)器。
　　本文分兩個(gè)部分：
　　1. 網(wǎng)絡(luò)編程的一些“胡思亂想”，以自問自答的形式談?wù)勎覍?duì)這一領(lǐng)域的認(rèn)識(shí)。
　　2. 幾本必看的書，基本上還是W. Richard Stevents 的那幾本。
　　另外，本文沒有特別說明時(shí)均暗指TCP 協(xié)議，“連接”是“TCP 連接”，“服務(wù)
　　端”是“TCP 服務(wù)端”。
　　A.1 網(wǎng)絡(luò)編程的一些“胡思亂想”
　　以下大致列出我對(duì)網(wǎng)絡(luò)編程的一些想法，前后無關(guān)聯(lián)。
　　A.1.1 網(wǎng)絡(luò)編程是什么
　　網(wǎng)絡(luò)編程是什么？是熟練使用Sockets API 嗎？說實(shí)話，在實(shí)際項(xiàng)目里我只用過
　　兩次Sockets API，其他時(shí)候都是使用封裝好的網(wǎng)絡(luò)庫。
　　第一次是2005 年在學(xué)校做一個(gè)羽毛球賽場(chǎng)計(jì)分系統(tǒng)：我用C# 編寫運(yùn)行在PC上的軟件，負(fù)責(zé)比分的顯示；再用C# 寫了運(yùn)行在PDA 上的計(jì)分界面，記分員拿著PDA 記錄比分；這兩部分程序通過TCP 協(xié)議相互通信。這其實(shí)是個(gè)簡單的分布式系統(tǒng)，體育館有幾片場(chǎng)地，每個(gè)場(chǎng)地都有一名拿PDA 的記分員，每個(gè)場(chǎng)地都有兩臺(tái)顯示比分的PC （顯示器是42 寸平板電視，放在場(chǎng)地的對(duì)角，這樣兩邊看臺(tái)的觀眾都能看到比分）。這兩臺(tái)PC 的功能不完全一樣，一臺(tái)只負(fù)責(zé)顯示當(dāng)前比分，另一臺(tái)還要負(fù)責(zé)與PDA 通信，并更新數(shù)據(jù)庫里的比分信息。此外，還有一臺(tái)PC 負(fù)責(zé)周期性地從數(shù)據(jù)庫讀出全部7 片場(chǎng)地的比分，顯示在體育館墻上的大屏幕上。這臺(tái)PC 上還運(yùn)行著一個(gè)程序，負(fù)責(zé)生成比分?jǐn)?shù)據(jù)的靜態(tài)頁面，通過FTP 上傳發(fā)布到某門戶網(wǎng)站的體育頻道。系統(tǒng)中還有一個(gè)錄入賽程（參賽隊(duì)、運(yùn)動(dòng)員、出場(chǎng)順序等）數(shù)據(jù)庫的程序，運(yùn)行在數(shù)據(jù)庫服務(wù)器上。算下來整個(gè)系統(tǒng)有十來個(gè)程序，運(yùn)行在二十多臺(tái)設(shè)備（PC 和PDA）上，還要考慮可靠性，避免single point of failure。
　　這是我第一次寫實(shí)際項(xiàng)目中的網(wǎng)絡(luò)程序，當(dāng)時(shí)寫下來的感覺是像寫命令行與用戶交互的程序：程序在命令行輸出一句提示語，等待客戶輸入一句話，然后處理客戶輸入，再輸出下一句提示語，如此循環(huán)。只不過這里的“客戶”不是人，而是另一個(gè)程序。在建立好TCP 連接之后，雙方的程序都是read/write 循環(huán)（為求簡單，我用的是blocking 讀寫），直到有一方斷開連接。
　　第二次是2010 年編寫muduo 網(wǎng)絡(luò)庫，我再次拿起了Sockets API，寫了一個(gè)基于Reactor 模式的C++ 網(wǎng)絡(luò)庫。寫這個(gè)庫的目的之一就是想讓日常的網(wǎng)絡(luò)編程從Sockets API 的瑣碎細(xì)節(jié)中解脫出來，讓程序員專注于業(yè)務(wù)邏輯，把時(shí)間用在刀刃上。muduo 網(wǎng)絡(luò)庫的示例代碼包含了幾十個(gè)網(wǎng)絡(luò)程序，這些示例程序都沒有直接使用Sockets API。
　　在此之外，無論是實(shí)習(xí)還是工作，雖然我寫的程序都會(huì)通過TCP 協(xié)議與其他程序打交道，但我沒有直接使用過Sockets API。對(duì)于TCP 網(wǎng)絡(luò)編程，我認(rèn)為核心是處理“三個(gè)半事件”，見§6.4.1 “TCP 網(wǎng)絡(luò)編程本質(zhì)論”。程序員的主要工作是在事件處理函數(shù)中實(shí)現(xiàn)業(yè)務(wù)邏輯，而不是和Sockets API“較勁”。
　　這里還是沒有說清楚“網(wǎng)絡(luò)編程”是什么，請(qǐng)繼續(xù)閱讀后文§A.1.5“網(wǎng)絡(luò)編程的各種任務(wù)角色”。
　　A.1.2 學(xué)習(xí)網(wǎng)絡(luò)編程有用嗎
　　以上說的是比較底層的網(wǎng)絡(luò)編程，程序代碼直接面對(duì)從TCP 或UDP 收到的數(shù)據(jù)以及構(gòu)造數(shù)據(jù)包發(fā)出去。在實(shí)際工作中，另一種常見的情況是通過各種client library來與服務(wù)端打交道，或者在現(xiàn)成的框架中填空來實(shí)現(xiàn)server，或者采用更上層的通信方式。比如用libmemcached 與memcached 打交道，使用libpq 來與PostgreSQL 打交道，編寫Servlet 來響應(yīng)HTTP 請(qǐng)求，使用某種RPC 與其他進(jìn)程通信，等等。這些情況都會(huì)發(fā)生網(wǎng)絡(luò)通信，但不一定算作“網(wǎng)絡(luò)編程”。如果你的工作是前面列舉的這些，學(xué)習(xí)TCP/IP 網(wǎng)絡(luò)編程還有用嗎？
　　我認(rèn)為還是有必要學(xué)一學(xué)，至少在troubleshooting 的時(shí)候有用。無論如何，這些library 或framework 都會(huì)調(diào)用底層的Sockets API 來實(shí)現(xiàn)網(wǎng)絡(luò)功能。當(dāng)你的程序遇到一個(gè)線上問題時(shí)，如果你熟悉Sockets API，那么從strace 不難發(fā)現(xiàn)程序卡在哪里，盡管可能你沒有直接調(diào)用這些Sockets API。另外，熟悉TCP/IP 協(xié)議、會(huì)用tcpdump 也非常有助于分析解決線上網(wǎng)絡(luò)服務(wù)問題。
　　A.1.3 在什么平臺(tái)上學(xué)習(xí)網(wǎng)絡(luò)編程
　　對(duì)于服務(wù)端網(wǎng)絡(luò)編程，我建議在Linux 上學(xué)習(xí)。
　　如果在10 年前，這個(gè)問題的答案或許是FreeBSD，因?yàn)镕reeBSD“根正苗紅”，在2000 年那一次互聯(lián)網(wǎng)浪潮中扮演了重要角色，是很多公司首選的免費(fèi)服務(wù)器操作系統(tǒng)。2000 年那會(huì)兒Linux 還遠(yuǎn)未成熟，連epoll 都還沒有實(shí)現(xiàn)。（FreeBSD 在2001年發(fā)布4.1 版，加入了kqueue，從此C10k 不是問題。）
　　10 年后的今天，事情起了一些變化，Linux 成為市場(chǎng)份額最大的服務(wù)器操作系統(tǒng)。在Linux 這種大眾系統(tǒng)上學(xué)網(wǎng)絡(luò)編程，遇到什么問題會(huì)比較容易解決。因?yàn)橛玫娜硕�，你遇到的問題別人多半也遇到過；同樣因?yàn)橛玫娜硕�，如果真的有什么�?nèi)核bug，很快就會(huì)得到修復(fù)，至少有work around 的辦法。如果用別的系統(tǒng)，可能一個(gè)問題發(fā)到論壇上半個(gè)月都不會(huì)有人理。從內(nèi)核源碼的風(fēng)格看，F(xiàn)reeBSD 更干凈整潔，注釋到位，但是無奈它的市場(chǎng)份額遠(yuǎn)不如Linux，學(xué)習(xí)Linux 是更好的技術(shù)投資。
　　A.1.4 可移植性重要嗎
　　寫網(wǎng)絡(luò)程序要不要考慮移植性？要不要跨平臺(tái)？這取決于項(xiàng)目需要，如果貴公司做的程序要賣給其他公司，而對(duì)方可能使用Windows、Linux、FreeBSD、Solaris、AIX、HP-UX 等等操作系統(tǒng)，這時(shí)候當(dāng)然要考慮移植性。如果編寫公司內(nèi)部的服務(wù)器上用的網(wǎng)絡(luò)程序，那么大可只關(guān)注一個(gè)平臺(tái)，比如Linux。因?yàn)榫帉懞途S護(hù)可移植的網(wǎng)絡(luò)程序的代價(jià)相當(dāng)高，平臺(tái)間的差異可能遠(yuǎn)比想象中大，即便是POSIX 系統(tǒng)之間也有不小的差異（比如Linux 沒有SO_NOSIGPIPE 選項(xiàng)，Linux 的pipe(2) 是單向的，而FreeBSD 是雙向的），錯(cuò)誤的返回碼也大不一樣。
　　我就不打算把muduo 往Windows 或其他操作系統(tǒng)移植。如果需要編寫可移植的網(wǎng)絡(luò)程序，我寧愿用libevent、libuv、Java Netty 這樣現(xiàn)成的庫，把“臟活、累活”留給別人。
　　A.1.5 網(wǎng)絡(luò)編程的各種任務(wù)角色
　　計(jì)算機(jī)網(wǎng)絡(luò)是個(gè)big topic，涉及很多人物和角色，既有開發(fā)人員，也有運(yùn)維人員。比方說：公司內(nèi)部兩臺(tái)機(jī)器之間ping 不通，通常由網(wǎng)絡(luò)運(yùn)維人員解決，看看是布線有問題還是路由器設(shè)置不對(duì)；兩臺(tái)機(jī)器能ping 通，但是程序連不上，經(jīng)檢查是本機(jī)防火墻設(shè)置有問題，通常由系統(tǒng)管理員解決；兩臺(tái)機(jī)器能連上，但是丟包很嚴(yán)重，發(fā)現(xiàn)是網(wǎng)卡或者交換機(jī)的網(wǎng)口故障，由硬件維修人員解決；兩臺(tái)機(jī)器的程序能連上，但是偶爾發(fā)過去的請(qǐng)求得不到響應(yīng)，通常是程序bug，應(yīng)該由開發(fā)人員解決。
　　本文主要關(guān)心開發(fā)人員這一角色。下面簡單列出一些我能想到的跟網(wǎng)絡(luò)打交道的編程任務(wù)，其中前三項(xiàng)是面向網(wǎng)絡(luò)本身，后面幾項(xiàng)是在計(jì)算機(jī)網(wǎng)絡(luò)之上構(gòu)建信息系統(tǒng)。
　　1. 開發(fā)網(wǎng)絡(luò)設(shè)備，編寫防火墻、交換機(jī)、路由器的固件（firmware）。
　　2. 開發(fā)或移植網(wǎng)卡的驅(qū)動(dòng)。
　　3. 移植或維護(hù)TCP/IP 協(xié)議棧（特別是在嵌入式系統(tǒng)上）。
　　4. 開發(fā)或維護(hù)標(biāo)準(zhǔn)的網(wǎng)絡(luò)協(xié)議程序，HTTP、FTP、DNS、SMTP、POP3、NFS。
　　5. 開發(fā)標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議的“附加品”，比如HAProxy、squid、varnish 等Web loadbalancer。
　　6. 開發(fā)標(biāo)準(zhǔn)或非標(biāo)準(zhǔn)網(wǎng)絡(luò)服務(wù)的客戶端庫，比如ZooKeeper 客戶端庫、memcached客戶端庫。
　　7. 開發(fā)與公司業(yè)務(wù)直接相關(guān)的網(wǎng)絡(luò)服務(wù)程序，比如即時(shí)聊天軟件的后臺(tái)服務(wù)器、網(wǎng)游服務(wù)器、金融交易系統(tǒng)、互聯(lián)網(wǎng)企業(yè)用的分布式海量存儲(chǔ)、微博發(fā)帖的內(nèi)部廣播通知等等。
　　8. 客戶端程序中涉及網(wǎng)絡(luò)的部分，比如郵件客戶端中與POP3、SMTP 通信的部分，以及網(wǎng)游的客戶端程序中與服務(wù)器通信的部分。
　　本文所指的“網(wǎng)絡(luò)編程”專指第7 項(xiàng)，即在TCP/IP 協(xié)議之上開發(fā)業(yè)務(wù)軟件。換句話說，不是用Sockets API 開發(fā)muduo 這樣的網(wǎng)絡(luò)庫，而是用libevent、muduo、Netty、gevent 這樣現(xiàn)成的庫開發(fā)業(yè)務(wù)軟件，muduo 自帶的十幾個(gè)示例程序是業(yè)務(wù)軟件的代表。
　　A.1.6 面向業(yè)務(wù)的網(wǎng)絡(luò)編程的特點(diǎn)
　　與通用的網(wǎng)絡(luò)服務(wù)器不同，面向公司業(yè)務(wù)的專用網(wǎng)絡(luò)程序有其自身的特點(diǎn)。
　　業(yè)務(wù)邏輯比較復(fù)雜，而且時(shí)常變化  如果寫一個(gè)HTTP 服務(wù)器，在大致實(shí)現(xiàn)HTTP 1.1 標(biāo)準(zhǔn)之后，程序的主體功能一般不會(huì)有太大的變化，程序員會(huì)把時(shí)間放在性能調(diào)優(yōu)和bug 修復(fù)上。而開發(fā)針對(duì)公司業(yè)務(wù)的專用程序時(shí)，功能說明書（spec）很可能不如HTTP 1.1 標(biāo)準(zhǔn)那么細(xì)致明確。更重要的是，程序是快速演化的。以即時(shí)聊天工具的后臺(tái)服務(wù)器為例，可能第一版只支持在線聊天；幾個(gè)月之后發(fā)布第二版，支持離線消息；又過了幾個(gè)月，第三版支持隱身聊天；隨后，第四版支持上傳頭像；如此等等。這要求程序員能快速響應(yīng)新的業(yè)務(wù)需求，公司才能保持競(jìng)爭(zhēng)力。由于業(yè)務(wù)時(shí)常變化（假設(shè)每月一次版本升級(jí)），也會(huì)降低服務(wù)程序連續(xù)運(yùn)行時(shí)間的要求。相反，我們要設(shè)計(jì)一套流程，通過輪流重啟服務(wù)器來完成平滑升級(jí)（§9.2.2）。
　　不一定需要遵循公認(rèn)的通信協(xié)議標(biāo)準(zhǔn)  比方說網(wǎng)游服務(wù)器就沒什么協(xié)議標(biāo)準(zhǔn)，反正客戶端和服務(wù)端都是本公司開發(fā)的，如果發(fā)現(xiàn)目前的協(xié)議設(shè)計(jì)有問題，兩邊一起改就行了。由于可以自己設(shè)計(jì)協(xié)議，因此我們可以繞開一些性能難點(diǎn)，簡化程序結(jié)構(gòu)。比方說，對(duì)于多線程的服務(wù)程序，如果用短連接TCP 協(xié)議，為了優(yōu)化性能通常要精心設(shè)計(jì)accept 新連接的機(jī)制2，避免驚群并減少上下文切換。但是如果改用長連接，用最簡單的單線程accept 就行了。
　　程序結(jié)構(gòu)沒有定論  對(duì)于高并發(fā)大吞吐的標(biāo)準(zhǔn)網(wǎng)絡(luò)服務(wù)，一般采用單線程事件驅(qū)動(dòng)的方式開發(fā)，比如HAProxy、lighttpd 等都是這個(gè)模式。但是對(duì)于專用的業(yè)務(wù)系統(tǒng)，其業(yè)務(wù)邏輯比較復(fù)雜，占用較多的CPU 資源，這種單線程事件驅(qū)動(dòng)方式不見得能發(fā)揮現(xiàn)在多核處理器的優(yōu)勢(shì)。這留給程序員比較大的自由發(fā)揮空間，做好了“橫掃千軍”，做爛了一敗涂地。我認(rèn)為目前one loop per thread 是通用性較高的一種程序結(jié)構(gòu)，能發(fā)揮多核的優(yōu)勢(shì)，見§3.3 和§6.6。
　　性能評(píng)判的標(biāo)準(zhǔn)不同  如果開發(fā)httpd 這樣的通用服務(wù)，必然會(huì)和開源的Nginx、lighttpd 等高性能服務(wù)器比較，程序員要投入相當(dāng)?shù)木�力去�?yōu)化程序，才能在市場(chǎng)上占有一席之地。而面向業(yè)務(wù)的專用網(wǎng)絡(luò)程序不一定是IO bound，也不一定有開源的實(shí)現(xiàn)以供對(duì)比性能，優(yōu)化方向也可能不同。程序員通常更加注重功能的穩(wěn)定性與開發(fā)的便捷性。性能只要一代比一代強(qiáng)即可。
　　網(wǎng)絡(luò)編程起到支撐作用，但不處于主導(dǎo)地位  程序員的主要工作是實(shí)現(xiàn)業(yè)務(wù)邏輯，而不只是實(shí)現(xiàn)網(wǎng)絡(luò)通信協(xié)議。這要求程序員深入理解業(yè)務(wù)。程序的性能瓶頸不一定在網(wǎng)絡(luò)上，瓶頸有可能是CPU、Disk IO、數(shù)據(jù)庫等，這時(shí)優(yōu)化網(wǎng)絡(luò)方面的代碼并不能提高整體性能。只有對(duì)所在的領(lǐng)域有深入的了解，明白各種因素的權(quán)衡（trade-off），才能做出一些有針對(duì)性的優(yōu)化�，F(xiàn)在的機(jī)器上，簡單的并發(fā)長連接echo服務(wù)程序不用特別優(yōu)化就做到十多萬qps，但是如果每個(gè)業(yè)務(wù)請(qǐng)求需要1ms 密集計(jì)算，在8 核機(jī)器上充其量能達(dá)到8 000 qps，優(yōu)化IO 不如去優(yōu)化業(yè)務(wù)計(jì)算（如果投入產(chǎn)出合算的話）。
　　A.1.7 幾個(gè)術(shù)語
　　互聯(lián)網(wǎng)上的很多“口水戰(zhàn)”是由對(duì)同一術(shù)語的不同理解引起的，比如我寫的《多線程服務(wù)器的適用場(chǎng)合》3，就曾經(jīng)被人說是“掛羊頭賣狗肉”，因?yàn)檫@篇文章中舉的master 例子“根本就算不上是個(gè)網(wǎng)絡(luò)服務(wù)器。因?yàn)樗�的瓶頸根本就跟網(wǎng)絡(luò)無關(guān)�！�
　　網(wǎng)絡(luò)服務(wù)器  “網(wǎng)絡(luò)服務(wù)器”這個(gè)術(shù)語確實(shí)含義模糊，到底指硬件還是軟件？到底是服務(wù)于網(wǎng)絡(luò)本身的機(jī)器（交換機(jī)、路由器、防火墻、NAT），還是利用網(wǎng)絡(luò)為其他人或程序提供服務(wù)的機(jī)器（打印服務(wù)器、文件服務(wù)器、郵件服務(wù)器）？每個(gè)人根據(jù)自己熟悉的領(lǐng)域，可能會(huì)有不同的解讀。比方說，或許有人認(rèn)為只有支持高并發(fā)、高吞吐量的才算是網(wǎng)絡(luò)服務(wù)器。
　　為了避免無謂的爭(zhēng)執(zhí)，我只用“網(wǎng)絡(luò)服務(wù)程序”或者“網(wǎng)絡(luò)應(yīng)用程序”這種含義明確的術(shù)語�！伴_發(fā)網(wǎng)絡(luò)服務(wù)程序”通常不會(huì)造成誤解。
　　客戶端？服務(wù)端？   在TCP 網(wǎng)絡(luò)編程中，客戶端和服務(wù)端很容易區(qū)分，主動(dòng)發(fā)起連接的是客戶端，被動(dòng)接受連接的是服務(wù)端。當(dāng)然，這個(gè)“客戶端”本身也可能是個(gè)后臺(tái)服務(wù)程序，HTTP proxy 對(duì)HTTP server 來說就是個(gè)客戶端。
　　客戶端編程？服務(wù)端編程？   但是“服務(wù)端編程”和“客戶端編程”就不那么好區(qū)分了。比如Web crawler，它會(huì)主動(dòng)發(fā)起大量連接，扮演的是HTTP 客戶端的角色，但似乎應(yīng)該歸入“服務(wù)端編程”。又比如寫一個(gè)HTTP proxy，它既會(huì)扮演服務(wù)端--被動(dòng)接受Web browser 發(fā)起的連接，也會(huì)扮演客戶端--主動(dòng)向HTTP server 發(fā)起連接，它究竟算服務(wù)端還是客戶端？我猜大多數(shù)人會(huì)把它歸入服務(wù)端編程。
　　那么究竟如何定義“服務(wù)端編程”？
　　服務(wù)端編程需要處理大量并發(fā)連接？也許是，也許不是。比如云風(fēng)在一篇介紹網(wǎng)游服務(wù)器的博客4 中就談到，網(wǎng)游中用到的“連接服務(wù)器”需要處理大量連接，而“邏輯服務(wù)器”只有一個(gè)外部連接。那么開發(fā)這種網(wǎng)游“邏輯服務(wù)器”算服務(wù)端編程還是客戶端編程呢？又比如機(jī)房的服務(wù)進(jìn)程監(jiān)控軟件，并發(fā)數(shù)跟機(jī)器數(shù)成正比，至多也就是兩三千的并發(fā)連接。（再大規(guī)模就超出本書的范圍了。）
　　我認(rèn)為，“服務(wù)端網(wǎng)絡(luò)編程”指的是編寫沒有用戶界面的長期運(yùn)行的網(wǎng)絡(luò)程序，程序默默地運(yùn)行在一臺(tái)服務(wù)器上，通過網(wǎng)絡(luò)與其他程序打交道，而不必和人打交道。與之對(duì)應(yīng)的是客戶端網(wǎng)絡(luò)程序，要么是短時(shí)間運(yùn)行，比如wget；要么是有用戶界面（無論是字符界面還是圖形界面）。本文主要談服務(wù)端網(wǎng)絡(luò)編程。
　　……