socket模型：
1、阻塞模型
???一個單進程accept阻塞，接收到客戶端請求后，read消息，處理write返回，然后循環繼續accept。
???這種模型最最簡單，不實際，沒什么實際用途，對于新手教學還行。

2、多進程(線程)模型
???主進程循環accept阻塞，接收到客戶端請求后，fork子進程處理，子進程read阻塞，接收客戶端消息并響應。
???這種模型是我使用到最多的，簡單實用，但是當客戶端請求超多時，fork子進程多，系統資源消耗大，效果不理想；當然這種與多線程同理。

3、進程池(線程池)
???主進程產生固定多的子進程，并定時監控子進程狀態，初始子進程都為空閑狀態。子進程在accept到客戶端請求，通知主進程我很忙，然后處理請求，請求處理完成后，通知主進程我很閑。主進程主要監控子進程是否僵死或退出，維護進程池固定數量的進程來處理消息。
???這種模型，可能每個人的實現方式不一樣，這是我接觸到的。優點是：不會產生超多的進程(線程)以至于過多消耗資源，在請求數量不多的情況下，效果還好；缺點是：因為是‘池’都有限制，當遠遠超過進程池限制的進程數，效果并不理想。

4、連接池
???這種實現方式我第一次聽說，在網上查了好久也沒有頭緒。在我的理解里，socket都是客戶端向服務端發請求建立socket連接，因為客戶端不同這種連接怎么重用？請高手指點一二，主要講清原理即可。

5、select事件模型
???這種實現方式是主進程將socket監聽連接和client請求連接一起FD_SET到一個內核隊列中，內核一直檢查這個隊列的哪個socket描述符有讀或寫或異常的響應則通知用戶進程。用戶進程檢測到socket監聽連接有響應，則accept與客戶端建立連接，并把新的client請求連接FD_SET到內核隊列中；如果檢測到client請求連接有響應，則fork子進程，read客戶端消息，處理并響應消息。
???這種模型，select會捕獲到你設置的某個socket描述符有可讀可寫或異常的事件，但是程序員需要自己檢查自己設置的所有描述符，以確認是哪個描述符有事件發生。優點：占用資源少，不會消耗太多的cpu；缺點是select的效率和FD_SET到內核隊列中的描述符的個數有關，當需要檢測的描述符過多時，就要花費過多的時間去檢測所有的描述符是否有時間發生，而且可以FD_SET的描述符內核也有限制，當客戶端請求成千上萬時，select便無能為力。

6、epoll事件模型
???這種模型我剛開始接觸，目前還沒有完全使用或練習過。但是實現方式卻是目前最好的一種模型，對設置監測的socket描述符同時設置回調函數，當內核監測到socket描述符有事件發生，則會主動觸發回調函數。
???這種模型，優點：可以接收任意多的連接，高效率，低消耗，穩定易使用；缺點：因為各系統提供的接口有很大的差異，可移植性差。