客戶端網絡庫實現真的很簡單嗎？

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

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

---

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

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

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

2. 問：那你是否考慮到這種狀況，你同時或者前後發過去兩個網絡請求，你怎麼肯定你收到回覆是哪一個請求的？

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

   答：那我對每個請求加一個惟一標識，這樣我就能夠分辨出來了。

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

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

5. 問：你有沒有考慮過各類網絡錯誤和異常的監控和處理，好比TCP長鏈接網絡斷開後的自動重連？

6. 問：你有沒有考慮過若是你把網絡層或者網絡數據層和前臺業務和界面混雜在一塊兒後的代碼混亂複雜度？

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

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

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