《unix網路程式設計》30章詳細介紹了幾種伺服器設計正規化。總結了其中的幾種，記錄一下；
多程序的做法：
1.每次建立乙個新的請求，fork乙個子程序，處理該連線的資料傳輸。
2.預先派生一定數量的子程序，每個子程序都呼叫accept接收連線請求。當乙個請求到來之後會觸發所有程序的accept，但是只有最先的子程序會處理該請求。這就是所說的「驚群」。
3.為了解決「驚群」，在各個子程序的accept前後都用執行緒的互斥鎖來做同步保護。一般來說互斥鎖用於執行緒之間的同步，但是也可用作多個程序之間同步，具體用法參考鏈結。
和多程序的做法相對應，只是執行緒更輕，理論上開銷更小。
1.每次建立乙個新的請求，fork乙個子執行緒，處理該連線的資料傳輸。
2.預先派生一定數量的子執行緒，每個子程序都呼叫accept接收連線請求。當乙個請求到來之後會觸發所有執行緒的accept，但是只有最先的子執行緒會處理該請求。這就是所說的「驚群」。
3.為了解決「驚群」，在各個子執行緒的accept前後都用執行緒的互斥鎖來做同步保護。
一般來說，第一種方法可以對付一般的連線請求量，比如我研究生科研做的每次就我乙個人訪問的，或者我和老師同時訪問的乙個小型伺服器，這樣的足夠了。第三種就比較好了，響應非常迅速，時間上差不多比第一種快了十倍以上，而且第三種編碼也比較簡單。
這本書上還提供了對檔案加鎖，主線程accept傳遞給子執行緒等等辦法，編碼都比較麻煩，效果也一般。
另外之前我的部落格 中提到epoll 的問題。其實那個源**中派生幾個執行緒，每個執行緒都是epoll_wait，這個編碼和在多執行緒中accept非常相似，但是也沒有用到互斥量做執行緒安全。參考鏈結給出了關於該問題的一些描述，「accept 已經不存在驚群問題，但 epoll 上還是存在驚群問題。即，如果多個程序/執行緒阻塞在監聽同乙個 listening socket fd 的 epoll_wait 上，當有乙個新的連線到來時，所有的程序都會被喚醒。」如作者所說，關於此問題nginx給出的解決方案也是加乙個互斥鎖。
（2016-6-2 15:21:01再次更新）
在linux2.6核心中已經解決了accept導致的驚群問題。
在linux3.9核心中提出了要解決epoll_wait驚群問題，而且在核心4.5中，正式得到解決。在這個版本中新增了乙個epollexclusive 標記。核心**根據此標記為會有選擇性的喚醒乙個阻塞在epoll_wait上的程序（執行緒）。但顯然這個版本距離大規模的使用還有很遙遠的距離。參考鏈結：
客戶 伺服器程式設計正規化
本篇從基於tcp ip協議出發，現代流行的應對高併發請求網路服務端設計架構 1.tcp ip 模型 首先回顧一下tcp ip模型，並知道各個層次在作業系統的哪乙個層次 看上圖，osi模型的底下兩層是隨系統提供的裝置驅動程式和網路硬體。通常情況下，除需知道資料鏈路的某些特性外，我們不用關心這兩層的情況...
客戶 伺服器程式設計正規化
unix 網路程式設計第30章讀書筆記，這裡只記錄大致實現方式，具體 實現還請閱讀此書 tcp 迭代伺服器 完全同步方式，完全處理某個客戶的請求之後才專向下乙個客戶，優點是 簡單，並且沒有程序控制所需的時間 tcp 併發伺服器程式，每個客戶乙個子程序 傳統上併發伺服器呼叫fork 派生乙個子程序來處...
Linux C語言 TCP伺服器程式設計
include include include include include include include include include int sockfd 斷開訊號處理函式 void sig handler int signo 伺服器端輸出客戶端的資訊 void out addr stru...