《tcp/ip協議分析》
c10k
問題（網路服務在處理數以萬計的客戶端連線時，往往出現效率低下甚至完全癱瘓）就向我們做了很詳細的說明。但是客戶端socket程式設計雖然沒有這種併發要求就一定簡單嗎？我認為不是的。請參看我的這篇文章
《客戶端網路庫實現真的很簡單嗎》
。另外網際網路中各種複雜的網路環境也會給我們進行socket程式設計帶來很多困難和挑戰。
阻塞i/o，非阻塞i/o，i/o復用，非同步i/o
。網路上關於這個話題的討論有很多，我說說我的理解吧：
同步/非同步：訪問資料的方式，同步需要主動讀寫資料，在讀寫資料的過程中還是會阻塞。非同步只需要得到i/o操作完成的通知，並不主動讀寫資料，而是由作業系統去完成資料的讀寫。
per connection per thread+blocking i/o：服務端執行緒資源是有限的，而且執行緒的上下文切換是很耗資源的，隨著客戶端併發連線的增多系統資源也會慢慢吃緊。但是在這種模型的基礎上，有些語言內建的
協程（使用者級執行緒）卻可以解決資源問題。比如go routine， erlang actor。前幾天剛發現了乙個基於c語言的協程庫
state thread
也可以用來實現使用者級執行緒。
thread pool+blocking i/o：執行緒池的方式依然會受制於伺服器cpu個數，自然也不會高效的。
non-blocking i/o + i/o multiplexing：網路i/o的多路復用，正是解決c10k問題最基礎的方案。但是還可以進一步優化嗎？
non-blocking i/o + i/o multiplexing + asyc i/o：非常理想、高效的網路模型。windows下是利用完成埠來幫我們實現這個模型，linux下要依賴非同步i/o機制，但是究竟是否好用我沒嘗試過。
《從master-worker模型看團隊管理》。
學之者生用之者死。這是陳碩老師對ace庫的評價，我覺得很形象。對於學院派理想化的東西去學習收益很大，但是使用就不見得適合自己。
boost asio:has a 「near stl」 statusstackoverflow;
poco: 很全面的庫不僅僅有網路庫。
libev:速度更快,bug更少,特性更多,體積更小;
libevent:簡單,強大;
網路資料安全性——敏感資料的網路安全;
編碼複雜度——序列化和反序列化複雜度,效率,資料結構的可擴充套件性,可 維護性;
協議通用性——大眾規範;
tlv結構的二進位制協議
可以以提供序列化和反序列化庫的的角度採用第三方協議:protocol buffers, json, thrift
可以以選擇文字化協議的角度選擇xml,json協議。
《網路傳輸資料格式的選擇》。
《linux多執行緒服務端程式設計》
《構建高效能web站點》
《linux多執行緒服務端程式設計》
高效能tcp網路伺服器
基於tcp協議的遠端過程呼叫框架客戶端實現
yaocoder
我的網路開發之旅 socket程式設計
tcp ip協議分析 c10k 問題 網路服務在處理數以萬計的客戶端連線時，往往出現效率低下甚至完全癱瘓 就向我們做了很詳細的說明。但是客戶端socket程式設計雖然沒有這種併發要求就一定簡單嗎？我認為不是的。請參看我的這篇文章 客戶端網路庫實現真的很簡單嗎 另外網際網路中各種複雜的網路環境也會給我...
我的網路開發之旅 TCP IP協議分析
網路開發那些事 熟悉tcp ip協議 udp協議，有相關的協議開發經驗 熟悉網路程式設計 多執行緒程式設計技術 在公司不敢下電影，浪費大好頻寬！在公司甚至都不敢發某些郵件，鬱悶了吧！我們擷取維基百科上的定義來說明一下他 的 架構清晰 一些資料結構設計的非常巧妙 tcpdump 的 短小精悍，使用方法...
我的移動混合開發之旅
在移動開發這片熱土上，除了原生之外，也有一些公司在嘗試著新技術 新模式，這是混合開發誕生和延續意義以及價值。原生開發和混合開發的優缺點也已經是乙個老生常談的事兒了，在這裡我就簡單來說一下 原生開發優點 靈活 主流 成熟 解決問題成本等優點 混合開發技術 開發效率快，上手難度低，跨平台 一套 可以執行...