socket模型

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

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

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

四、鏈接池
   這種實現方式我第一次據說，在網上查了很久也沒有頭緒。在個人理解裏，socket都是客戶端向服務端發請求創建socket鏈接，由於客戶端不一樣這種鏈接怎麼重用？請高手指點一二，主要講清原理便可。

五、select事件模型
   這種實現方式是主進程將socket監聽鏈接和client請求鏈接一塊兒FD_SET到一個內核隊列中，內核一直檢查這個隊列的哪一個socket描述符有讀或寫或異常的響應則通知用戶進程。用戶進程檢測到socket監聽鏈接有響應，則accept與客戶端創建鏈接，並把新的client請求鏈接FD_SET到內核隊列中；若是檢測到client請求鏈接有響應，則fork子進程，read客戶端消息，處理並響應消息。
   這種模型，select會捕獲到你設置的某個socket描述符有可讀可寫或異常的事件，可是程序員須要本身檢查本身設置的全部描述符，以確認是哪一個描述符有事件發生。優勢：佔用資源少，不會消耗太多的cpu；缺點是select的效率和FD_SET到內核隊列中的描述符的個數有關，當須要檢測的描述符過多時，就要花費過多的時間去檢測全部的描述符是否有時間發生，並且能夠FD_SET的描述符內核也有限制，當客戶端請求成千上萬時，select便無能爲力。

六、epoll事件模型
   這種模型我剛開始接觸，目前尚未徹底使用或練習過。可是實現方式倒是目前最好的一種模型，對設置監測的socket描述符同時設置回調函數，當內核監測到socket描述符有事件發生，則會主動觸發回調函數。
   這種模型，優勢：能夠接收任意多的鏈接，高效率，低消耗，穩定易使用；缺點：由於各系統提供的接口有很大的差別，可移植性差。

以上是我瞭解到的socket編程模型，歡迎跟你們討論。同時對於第四種鏈接池的模型，我很不明白，但願有高手能幫我解惑。