本章主要列舉服務器程序的各種網絡模型，示例程序以及性能對比后面再寫。
一、分類依據。服務器的網絡模型分類主要依據以下幾點
（1）是否阻塞方式處理請求，是否多路復用，使用哪種多路復用函數
（2）是否多線程，多線程間如何組織
（3）是否多進程，多進程的切入點一般都是accept函數前
二、分類。首先根據是否多路復用分為三大類：
（1）阻塞式模型
（2）多路復用模型
（3）實時信號模型
三、詳細分類。1、阻塞式模型根據是否多線程分四類：
（1）單線程處理。實現可以參見
http://m.shnenglu.com/CppExplore/archive/2008/03/14/44509.html后面的示例代碼。
（2）一個請求一個線程。主線程阻塞在accept處，新連接到來，實時生成線程處理新連接。受限于進程的線程數，以及實時創建線程的開銷，過多線程后上下文切換的開銷，該模型也就是有學習上價值。
（3）預派生一定數量線程，并且所有線程阻塞在accept處。
該模型與下面的（5）類似與線程的領導者/追隨者模型。
傳統的看法認為多進程（linux上線程仍然是進程方式）同時阻塞在accept處，當新連接到來時會有“驚群”現象發生，即所有都被激活，之后有一個獲取連接描述符返回，其它再次轉為睡眠。linux從2.2.9版本開始就不再存在這個問題，只會有一個被激活，其它平臺依舊可能有這個問題，甚至是不支持所有進程直接在accept阻塞。
（4）預派生一定數量線程，并且所有線程阻塞在accept前的線程鎖處。
一次只有一個線程能阻塞在accept處。避免不支持所有線程直接阻塞在accept，并且避免驚群問題。特別是當前linux2.6的線程庫下，模型（4）沒有存在的價值了。另有文件鎖方式，不具有通用性，并且效率也不高，不再單獨列舉。
（5）主線程處理accept，預派生多個線程（線程池）處理連接。
類似與線程的半同步/半異步模型。
主線程的accept返回后，將clientfd放入預派生線程的線程消息隊列，線程池讀取線程消息隊列處理clientfd。主線程只處理accept，可以快速返回繼續調用accept，可以避免連接爆發情況的拒絕連接問題，另加大線程消息隊列的長度，可以有效減少線程消息隊列處的系統調用次數。
（6）預派生多線程阻塞在accept處，每個線程又有預派生線程專門處理連接。
（3）和（4）/（5）的復合體。
經測試，（5）中的accept線程處理能力非常強，遠遠大于業務線程，并發10000的連接數也毫無影響，因此該模型沒有實際意義。
總結：就前五模型而言，性能最好的是模型（5）。模型（3）/(4)可以一定程度上改善模型（1）的處理性能，處理爆發繁忙的連接，仍然不理想。。阻塞式模型因為讀的阻塞性，容易受到攻擊，一個死連接（建立連接但是不發送數據的連接）就可以導致業務線程死掉。因此內部服務器的交互可以采用這類模型，對外的服務不適合。優先（5），然后是（4），然后是（1），其它不考慮。
2、多路復用模型根據多路復用點、是否多線程分類：以下各個模型依據選用select/poll/epoll又都細分為3類。下面個別術語采用select中的，僅為說明。
（1）accept函數在多路復用函數之前，主線程在accept處阻塞，多個從線程在多路復用函數處阻塞。主線程和從線程通過管道通訊，主線程通過管道依次將連接的clientfd寫入對應從線程管道，從線程把管道的讀端pipefd作為fd_set的第一個描述符，如pipefd可讀，則讀數據，根據預定義格式分解出clientfd放入fd_set，如果clientfd可讀，則read之后處理業務。
此方法可以避免select的fd_set上限限制，具體機器上select可以支持多少個描述符，可以通過打印sizeof(fd_set)查看，我機器上是512字節，則支持512×8＝4096個。為了支持多余4096的連接數，此模型下就可以創建多個從線程分別多路復用，主線程accept后平均放入（順序循環）各個線程的管道中。創建5個從線程以其對應管道，就可以支持2w的連接，足夠了。另一方面相對與單線程的select，單一連接可讀的時候，還可以減少循環掃描fd_set的次數。單線程下要掃描所有fd_set（如果再最后），該模型下，只需要掃描所在線程的fd_set就可。
（2）accept函數在多路復用函數之前，與（1）的差別在于，主線程不直接與從線程通過管道通訊，而是將獲取的fd放入另一緩存線程的線程消息隊列，緩存線程讀消息隊列，然后通過管道與從線程通訊。
目的在主線程中減少系統調用，加快accept的處理，避免連接爆發情況下的拒絕連接。
（3）多路復用函數在accept之前。多路復用函數返回，如果可讀的是serverfd，則accept，其它則read，后處理業務，這是多路復用通用的模型，也是經典的reactor模型。
（4）連接在單獨線程中處理。
以上（1）（2）（3）都可以在檢測到cliendfd可讀的時候，把描述符寫入另一線程（也可以是線程池）的線程消息隊列，另一線程（或線程池）負責read，后處理業務。（5）業務線程獨立，下面的網絡層讀取結束后通知業務線程。以上（1）（2）（3）（4）中都可以將業務線程（可以是線程池）獨立，事先告之（1）、（2）、（3）、（4）中read所在線程（上面1、2、4都可以是線程池），需要讀取的字符串結束標志或者需要讀取的字符串個數，讀取結束，則將clientfd/buffer指針放入業務線程的線程消息隊列，業務線程讀取消息隊列處理業務。這也就是經典的proactor模擬。
總結：模型（1）是拓展select處理能力不錯選擇；模型（2）是模型（1）在爆發連接下的調整版本；模型（3）是經典的reactor，epoll在該模型下性能就已經很好，而select/poll仍然存在爆發連接的拒絕連接情況；模型（4）（5）則是方便業務處理，對模型（3）進行多線程調整的版本。帶有復雜業務處理的情況下推薦模型（5）。根據測試顯示，使用epoll的時候，模型（1）（2）相對（3）沒有明顯的性能優勢，（1）由于主線程兩次的系統調用，反而性能下降。
3、實時信號模型：使用fcntl的F_SETSIG操作，把描述符可讀的信號由不可靠的SIGIO(SYSTEM V)或者SIGPOLL(BSD)換成可靠信號。即可成為替代多路復用的方式。優于select/poll，特別是在大量死連接存在的情況下，但不及epoll。
四、多進程的參與的方式（1）fork模型。fork后所有進程直接在accept阻塞。以上主線程在accept阻塞的都可以在accept前fork為多進程。同樣面臨驚群問題。
（2）fork模型。fork后所有進程阻塞在accept前的線程鎖處。同線程中一樣避免不支持所有進程直接阻塞在accept或者驚群問題，所有進程阻塞在共享內存上實現的線程互斥鎖。
（3）業務和網絡層分離為不同進程模型。這個模型可能是受unix簡單哲學的影響，一個進程完成一件事情，復雜的事情通過多個進程結合管道完成。我見過進程方式的商業協議棧實現。自己暫時還沒有寫該模型的示例程序測試對比性能。
（4）均衡負載模型。起多個進程綁定到不同的服務端口，前端部署lvs等均衡負載系統，暴露一個網絡地址，后端映射到不同的進程，實現可擴展的多進程方案。
總結：個人認為（1）（2）沒什么意義。（3）暫不評價。（4）則是均衡負載方案，和以上所有方案不沖突。
以上模型的代碼示例以及性能對比后面給出。