[開發前准備]
在進行linux服務器開發之前，必須很清楚地了解所開發的對象需要考慮的相關問題
比如：
功能架構：提供服務的模塊體系結構
穩定性：服務器的出core率，內存泄露情況
性能：請求與返回的速度與正確性
負載能力：能同時訪問的最大數量和頻度
根據不同服務器對象的環境和應用，服務器開發的對應手段相差甚遠。比如就客戶端連接時間較短卻又比較頻繁的服務器（例如HTTP服務器）而言，
在可選的服務器結構中，預先派生進/線程的結構就要比並發式結構高效
總之，在開發服務器之前，必須進行完整的服務器開發需求分析，否則一旦你的服務器開發完成而因為效率或者其他某項事物不能滿足你的客戶，那么很有可能失敗！
[服務器讓我明白了這件事情]
服務器一般在后台運行，與客戶端的交互通過請求和返回兩種方式進行通信。
以epoll為例，一個epoll開發的服務器程序，等待着一百萬的客戶端用戶的請求，輪詢觀察某個時刻是否有客戶端發來的請求；排隊依次處理發來的請求，並將結果返回給
客戶端應用程序。
涉及到幾個技術問題：
第一，客戶端訪問進入epoll輪詢隊列的優先級是否需要控制。比如甲是我們的vip白金用戶，那么，我始終先處理甲發來的請求，不然白金用戶要生氣的。
第二，極大可能程度上優化處理請求的速度，這是服務器設計的核心業務。
第三，如果客戶端請求了這樣一個事情：我需要看這一百年來某企業所有的信息，那么我想這個信息量是很大的，也就是現在很熱門的大數據大文件傳輸問題，如何快速
將服務端的這些結果傳給客戶端，在帶寬允許的情況下當然越快越好！這里會有很多處理措施，當然你可以打成一個包直接扔過去，但是這樣是愚蠢的，像蝸牛背着一個
重殼在挪動，用戶可等不了這么久；聰明的做法當然很多，根據你的實際需要，比如，你可以壓縮，你可以分批，等等。
等等，其實服務器的整個開發，每個細節都決定了你的服務器的成敗優劣。在開發linux服務器的項目后，我個人決定，一個讓你的服務器變得強大的很重要的因素是——
——你不願意放棄任何一個可以挺高性能的因素，即使是快0.01ms或者少傳1bt的數據！
[流行的服務器模型]
1 PPC/TPC 模型
這兩種模型思想類似，就是讓每一個到來的連接一邊自己做事去，別再來煩我 。只是 PPC 是為它開了一個進程，而 TPC 開了一個線程。可是別煩我是有代價的，
它要時間和空間啊，連接多了之后，那么多的進程 / 線程切換，這開銷就上來了；因此這類模型能接受的最大連接數都不會高，一般在幾百個左右。
2 select 模型
2.1. 最大並發數限制，因為一個進程所打開的 FD （文件描述符）是有限制的 由 FD_SETSIZE 設置，默認值是 1024/2048 ，因此 Select 模型的最大並發數就被相應限制了。
自己改改這個 FD_SETSIZE ？想法雖好，可是先看看下面吧 …
2.2. 效率問題， select 每次調用都會線性掃描全部的 FD 集合，這樣效率就會呈現線性下降，把 FD_SETSIZE 改大的后果就是，大家都慢慢來，什么？都超時了？？！！
2.3. 內核 / 用戶空間 內存拷貝問題，如何讓內核把 FD 消息通知給用戶空間呢？在這個問題上 select 采取了內存拷貝方法。
3 poll 模型
基本上效率和 select 是相同的， select 缺點的 2 和 3 它都沒有改掉。
4 Epoll 模型
把其他模型逐個批判了一下，再來看看 Epoll 的改進之處吧，其實把 select 的缺點反過來那就是 Epoll 的優點了。
3.1. Epoll 沒有最大並發連接的限制，上限是最大可以打開文件的數目，這個數字一般遠大於 2048, 一般來說這個數目和系統內存關系很大 ，
具體數目可以 cat /proc/sys/fs/file-max 察看。
3.2. 效率提升， Epoll 最大的優點就在於它只管你“活躍”的連接 ，而跟連接總數無關，因此在實際的網絡環境中， Epoll 的效率就會遠遠高於 select 和 poll 。
3.3. 內存拷貝， Epoll 在這點上使用了“共享內存 ”，這個內存拷貝也省略了。
等等。
在開發你的服務器之前，應根據自己的業務需求和實際情況，恰當地選擇服務器的模型，這對這個服務器的功能效率都是具有很重要的意義的。