用戶端網絡庫實作真的很簡單嗎？

（注：本文所講的網絡協定隻針對TCP協定）

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

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

問：你打算怎樣實作用戶端的網絡層？

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

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

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

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

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

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

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

問：你有沒有考慮過如果你把網絡層或者網絡資料層和前台業務和界面混雜在一起後的代碼混亂複雜度？

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

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

本文轉自永遠的朋友部落格51CTO部落格，原文連結http://blog.51cto.com/yaocoder/1541271如需轉載請自行聯系原作者

yaocoder