（注：本文所講的網絡協議只針對TCP協議）

背景：開發一個C/S的應用勢必需要服務端和客戶端的適配，包括網絡協議、數據傳輸格式、業務處理的適配。由于服務端承載著大量的客戶端，需要高并發、高性能、高可靠性，在我們的認知里往往認為服務端的網絡模型和架構設計很復雜。但是客戶端嘛，無非就是建立網絡連接，發個請求收個回復如此簡單。所以在工作中經常會出現有些客戶端處理界面和業務的同事對平臺開發者說，你做好服務端的網絡就好，客戶端的網絡我來處理，而且在他們的想法里，這個所謂的客戶端網絡庫只需要很短的時間就可以做完，每每遇到這種情況，我都會問幾個問題勸他們放棄這種想法，由更擅長進行網絡編程的平臺端來提供網絡庫，為什么呢？

---

先看看我常問的幾個問題。

問：你打算怎樣實現客戶端的網絡層？

答：對于TCP協議來說無非就是connect，send，recv唄。

問：那你是否考慮到這種情況，你同時或者先后發過去兩個網絡請求，你怎么確定你收到回復是哪個請求的？

（其實問到這時有些同事就開始不理解了，我會給他們解釋網絡傳輸和服務器處理不是串行的，往往會出現你后發的請求卻先收到回復，客戶端 多線程情況下更為常見。當然也有有辦法的。）

答：那我對每一個請求加一個唯一標識，這樣我就可以分辨出來了。

問：你有沒有考慮過由于connect，send，recv...這些系統API都是阻塞的，如果沒有限制條件，會讓你的一個請求卡住很長時間或者永遠卡住？

問：你有沒有考慮過短連接請求，長連接請求，服務端推送消息如何實現？

問：你有沒有考慮過各種網絡錯誤和異常的監控和處理，比如TCP長連接網絡斷開后的自動重連？

問：你有沒有考慮過如果你把網絡層或者網絡數據層和前臺業務和界面混雜在一起后的代碼混亂復雜度？

問：你對TCP了解多少，僅僅是會用網絡編程的API還是知道TCP還擁有一些諸如TIME_WAIT、TCP_NODELAY...的狀態或特性，你知道經常說的粘包是怎么回事嗎？

往往這些問題問出來一個或者幾個之后一些人就會意識到憑他目前對網絡編程的把控還不足以寫一個生產級別的客戶端網絡庫，其實我曾經也有過類似認為客戶端網絡庫實現很sample的native的想法，但是當我配合著服務端用年計的時間逐漸在測試和生產環境中寫出和完善出一個客戶端網絡庫后才意識到它真的并不簡單。

一切盡在不言中，程序員最好的交流語言就是代碼，希望我的語言不至于很晦澀難懂。感興趣的朋友可以參考我的github上的RPC_Framework這個項目參考一下我的網絡庫的寫法，目前在公司生產環境中我已提供了linux平臺、android平臺、ios平臺、windows平臺的版本。github上的工程減少了一些功能，其中windows的版還未完全完成，希望大家能夠提出寶貴的意見。

總結

以上是生活随笔為你收集整理的客户端网络库实现真的很简单吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。