基於非同步socket的伺服器框架。已經基本完成，測試結果很滿意。但併發量不算太高，
這種構架本身的結構限制了它的效能。 但一般應用夠了。看了很多iocp的介紹，看的心理癢癢，
也考慮嘗試下。雖然沒有實際寫過一行與iocp有關的**，但從資料分析來看，iocp 就是個快
速的收發器。神話了的東西，其實原理簡單的在我們日常生活中，天天發生。實質就是非同步處理，
告訴a去做什麼，告訴b 去做什麼。。。。關鍵就是要協調好他們的關係。管理的**就是多執行緒，
但不是 connection_per_thread初步考慮 iocp 本身用乙個執行緒(單cpu）作資料收發。然後再啟動
n個邏輯執行緒，用於資料處理。具體啟動幾個邏輯執行緒，要根據實際需要來定。如果是簡單 echo
伺服器，乙個邏輯執行緒就ok了，執行緒少了，系統用於執行緒管理的代價也少。基本原則是執行緒最少化。
收發器(iocp) 與邏輯執行緒間的通訊問題，考慮了很久，初步決定採用 雙緩衝佇列，接收資料一
個佇列，傳送資料乙個佇列。佇列是雙緩衝.例如，在接收資料的時候，iocp執行緒把收到的資料壓入
接收佇列a,邏輯執行緒處理佇列b中的資料，避免」等待「，一切用非同步的思想解決問題。但 佇列切換
還是要作同步處理的。想想也很簡單，關鍵端就完成了。
邏輯執行緒處理具體業務的時候，也要注意不能處於阻塞模式(例如處理乙個複雜的計算，或者乙個耗
時的資料庫查詢。。。)這種情況下，就要開啟乙個新的執行緒。把耗時的操作放到執行緒中執行。執行完成
後，以某種方式通知邏輯執行緒(又是個傷腦筋的事）。
通過前面第乙個伺服器程式的編寫，最大的體會就是 delphi 太害人，提供了太多簡便的東西。但實在
是、不適合於伺服器端開發。delphi本身提供的一些函式，效能問題比較突出，在實際測試中，base64
編碼函式，資料壓縮函式(zlib)都作了優化。優化後的速度有了質的飛躍。為了傳輸資料時候進行加密，
開始考慮過用rsa也有delphi的實現**，沒做測試，就否定了，原因很簡單，速度太慢了。改用aes加
密演算法，找到了網上的一aes 的delphi實現，客戶端使用效果良好，伺服器端也做了必要的速度優化。效
果還是比較滿意。伺服器端開發delphi中的string型別，最好消失掉，但string型別太好用了，小量的應用
還是必須的，否則很多基礎函式都要重新寫。有人會提出疑問，為什麼要少用string型別變數，哈，以後
我高興的時候，會專門講解服務優化的問題。
總之，伺服器要達到高效能，高穩定性，高併發性。。。是不可能完成的任務。萬物相生相剋。
TCP的高併發伺服器模型
單客戶端單程序，統一accept 原型介紹 此併發伺服器模型並不預先分叉程序，而是主程序統一處理客戶端的連線，當客戶端的請求到達時，才臨時fork 程序，由子程序處理客戶端請求。利用socket 函式建立套接字，呼叫bind 函式繫結位址，呼叫listen 函式來監聽佇列長度，然後進入主處理過程，等...
高併發Linux伺服器的常用配置
檢視linux系統級的最大開啟檔案數限制 cat proc sys fs file max linux系統級硬限制，所有使用者級的開啟檔案數限制都不應超過這個數值 修改使用者程序可開啟檔案數限制 fs.file max 999999 程序可以同時開啟的最大控制代碼數 允許將time wait soc...
高併發 Linux 伺服器的常用配置
proc sys fs file max fs.file max 999999 程序可以同時開啟的最大控制代碼數 etc sysctl.conf net.ipv4.tcp tw reuse 1 重用 time wait 狀態的 socket net.ipv4.tcp keepalive time 6...