看完了 W. Richard Stevens 的傳世經典《UNIX 網絡編程》， 能照著例子用 Sockets API 編寫 echo 服務， 卻仍然對稍微復雜一點的網絡編程任務感到無從下手？ 書中示例代碼把業務邏輯和 Sockets 調用混在一起，似乎不利于將來擴展？- 程序在本機測試正常，放到網絡運行上就經常出現數據收不全的情況？
- TCP 協議真的有所謂的“粘包問題”嗎？該如何設計打包拆包的協議？又該如何編碼實現才不會掉到陷阱里？
- 帶外數據（OOB）、信號驅動IO這些高級特性到底有沒有用？
- 網絡協議格式該怎么設計？發送 C struct 會有對齊方面的問題嗎？對方不用 C/C++ 怎么通信？ 將來服務端軟件升級，需要在協議中增加一個字段，現有的客戶端就必須強制升級？
- 要處理幾千上萬的并發連接，似乎書上講的傳統 fork() 模型應付不過來，該用哪種并發模型呢？ 試試 select、poll、epoll 這種 IO 復用模型吧，又感覺非阻塞IO陷阱重重，怎么程序的 CPU 使用率一直是100%？
- 要不改用現成的 libevent 網絡庫吧，怎么查詢一下數據庫就把其他連接上的請求給耽誤了？ 再用個線程池吧。萬一發回響應的時候對方已經斷開連接了怎么辦？會不會串話？
- 讀過《UNIX 環境高級編程》，想用多線程來發揮多核 CPU 的效率， 但對程序該用哪種多線程模型感到一頭霧水？ 有沒有值得推薦的適用面廣的多線程 IO 模型？ 互斥器、條件變量、讀寫鎖、信號量這些底層同步原語哪些該用哪些不該用？ 有沒有更高級的同步設施能簡化開發？ 《UNIX 網絡編程（第二卷）》介紹的那些琳瑯滿目的IPC機制到底用哪個才能兼顧開發效率與可伸縮性？
網絡編程和多線程編程的基礎打得差不多，開始實際做項目了，更多問題撲面而來：- 網上聽人說服務端開發要做到 7x24 運行，為了防止內存碎片連動態內存分配都不能用， 那豈不是連 C++ STL 也一并禁用了？硬件的可靠性高到值得去這么做嗎？
- 傳聞服務端開發主要通過日志來查錯，那么日志里該寫些什么？日志是寫給誰看的？怎樣寫日志才不會影響性能？
- 分布式系統跟單機多進程到底有什么本質區別？心跳協議為什么是必須的，該如何實現？
- C++ 的大型工程該如何管理？庫的接口如何設計才能保證升級的時候不破壞二進制兼容性？
這本《Linux 多線程服務端編程》中，作者憑借多年的工程實踐經驗試圖解答以上疑問。當然，內容還遠不止這些……
本書配套頁面： http://chenshuo.com/book ，將不定期更新。