1、前言
對於有過網絡編程經驗的開發者來說，使用何種數據傳輸層協議來實現數據的通信，是個非常基礎的問題，它涉及到你的第一行代碼該如何編寫。
從PC時代的IM開始，IM開發者就在爲數據傳輸協議的選型爭論不休（比如：《爲什麼QQ用的是UDP協議而不是TCP協議？》這樣的問題，隔一段時間就能在社區裏看到）。到了移動互聯網時代，鑑於移動網絡的不可靠性等特點，再加上手機的省電策略、流量壓縮等，爲這個問題的回答增了更多的不確定因素。
對於有選擇困難證的人來說，基於以上因素，加上UDP和TCP協議的本質差異，這樣的選擇確實很糾結。本文將從作者的實踐總結，給出自已的觀點，如有異議還請理性回覆，不爲找噴，僅供參考。
說明：本文引用了DDPush的技術資料，感謝原作者。 （本文同步發佈於：http://www.52im.net/thread-33-1-1.html）
2、學習交流
- 即時通訊開發交流羣：
215891622 [推薦]
- 移動端IM開發推薦文章：《新手入門一篇就夠：從零開發移動端IM》
3、參考資料
《爲什麼QQ用的是UDP協議而不是TCP協議？》
《UDP中一個包的大小最大能多大》
《基於TCP協議的移動端IM仍然需要心跳保活機制》
《NAT詳解：基本原理、穿越技術(P2P打洞)、端口老化等》
《計算機網絡通訊協議關係圖（中文珍藏版）》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《微信對網絡影響的技術試驗及分析（論文全文）》
4、UDP vs TCP
TCP還是UDP？長連接如何實現？如何實現心跳機制？心跳的間隔如何確定？這些問題都是討論移動端IM、消息推送等類似話題時，幾乎一定被問到的問題。這裏嘗試正本清源一下。
5、互聯網、移動互聯網網絡環境
在分析到底應該使用UDP還是TCP之前，有必要先討論一下互聯網與移動互聯網的網絡環境特點。
互聯網的網絡基礎建設，經過十幾年長期的發展，已經較爲穩定和成熟，PC終端、操作系統的能力也達到了較高的水平。
而移動互聯網，由於涉及到無線電話網絡基站、2G、3G和4G技術的不斷髮展，其穩定性、帶寬、資源分配等各方面雖日趨完善，但當前終究還有不少問題的存在。另外，由於移動互聯網其“移動”的本質，加上智能終端設備（智能手機、平板電腦）的發展較晚，目前還在不斷演變的情況，與互聯網相比，移動互聯網還是低速、不穩定、終端能力稍弱的情況。而且由於其“移動”本質，短時間內很難達到互聯網的質量。
所以，在互聯網的環境裏面，網絡應用程序由於網絡設施、操作系統的成熟，開發使用起來比較容易，資源也較爲充足。而移動互聯網還是要“斤斤計較”。
6、智能終端電池續航能力，系統休眠
智能終端設備的電池續航能力始終是技術瓶頸。在連續使用的情況下，絕大部分智能設備電池無法支持兩個小時以上。所以在沒有外部電源的情況，智能終端設備必須頻繁、長時間休眠，這將極大地影響兩種網絡環境下的網絡應用場景。
7、IPv4資源、端口資源
這個話題往往被很多人忽略，但它有着至關重要的影響。雖然大部分人都很清楚IP地址的緊缺導致的動態IP分配的必然，卻忽略了由於IP地址不足引起的端口資源不足。
由於需要動態分配IP地址（這裏不僅僅指互聯網入口的IP，還包括局域網內部的IP），路由器的工作原理都是經過端口映射，把內部網絡（包括PC、手機、平板、Wifi、2G、3G、4G）IP與端口映射成外部IP（通常是公網IP）和對應的端口，並維持這個映射關係，才能正常地修改、轉發報文信息，保證內部各個ip、端口與外部的各個ip、端口的通信。
然而，單個IP地址的端口資源是有限的，理論上限是65535個端口。對於普通寬帶路由器來說，這個已經很充足了。但是！對於大型的網絡服務、網絡主幹接入點等來說，如果IP資源不足，每個IP幾萬個端口的資源很快會耗盡，從而影響正常通訊。
8、端口映射老化時間
正因爲如此，所有的路由器都會爲每個端口映射關係設置老化時間，如果老化時間倒數到0，則端口映射關係失效，該端口被釋放給其他連接使用。如果端口全部耗盡，則無法再新建內部與外部的網絡連接。
端口映射老化時間，比很多人想象中的要短很多。一般的家用寬帶路由器，老化時間一般是兩三分鐘；在有線寬帶運營商接入部分，老化時間可能少於兩分鐘。在無線電話網絡運營商接入部分（例如GPRS連接），老化時間甚至不超過一分鐘！
也就是說，任何一個網絡通訊（不管是TCP或UDP），如果幾分鐘之內沒有網絡報文傳輸，其佔用的IP地址端口將被路由器回收。這個時候該次通信必將終止，不管TCP還是UDP，神馬都是浮雲。
更殘酷的事實是，互聯網可認爲是由無數個路由器連接而成的，一個網絡通信往往需要通過n個路由器，每個路由器都會爲一次通信建立自己的端口映射。只要其中一個路由器回收其端口，則整個通訊中斷。
這也是很多人疑惑爲什麼TCP的KeepAlive參數無法保證長連接的原因。TCP的KeepAlive默認是兩個小時（而且該參數還是TCP的可選實現，不是必然實現），在路由器端口映射老化時間的影響下，必然無法發揮其作用。實際上，該參數在單一的局域網內纔可能被使用上，還要依賴具體的操作系統。
由於路由器端口映射的存在，加上智能終端頻繁、長時間的休眠，TCP長連接的實用性在移動互聯網情況下極大地打了折扣。
也因爲如此，移動端IM、推送系統必須實現所謂的心跳包機制，以保持端口映射關係的老化時間不會減少到0而被回收，從而避免連接中斷。
9、服務端承載能力
不管是UDP還是TCP，最終都是應用服務端的設備去提供服務的。而TCP由於提供了安全可靠的流服務，其對計算機、網絡資源的消耗是遠遠大於UDP協議的。對於配置較好的主流服務器，配備大量的內存（數十G至上百G內存），與高速的磁盤、網卡，是能同時支持數百萬個TCP連接的。不過這裏需要較專業的服務器設置，需要調整不少系統參數，再加上服務程序的配合。另外，TCP連接的建立、維持與釋放，都是需要較昂貴的計算、網絡資源的。
終端在線服務，若是一個較爲簡單的服務，未必使用上TCP衆多的高級功能，但承受TCP的昂貴成本，未必值得。如果能用UDP來提供服務，單服務器的承載能力，是可以去到TCP服務的數十倍，甚至上百倍的增長。這也是爲什麼DNS這種併發數巨大的服務器提供UDP接口的原因。
另外，上百萬TCP連接的網絡服務，其編程的難度、程序複雜度、調試難度、服務器運維成本、網絡成本等都遠遠高於UDP。
而UDP編程，與上百萬個終端通訊的難度與成本則低很多。如果提供的網絡服務不是基於流的服務，也允許一定的失敗機率（例如P2P），則UDP往往是更適合的方式。
10、高級應用網絡通訊要求
不過，移動端IM系統、推送系統一方面提供終端在線服務，另外一方面也需要考慮內容信息的完整性和安全性。畢竟信息的丟失，或者通訊的被竊聽，都是難以接受的。而TCP不管在網絡層的可靠性控制，還是在應用層的安全支持（例如HTTPS），都爲應用提供無法替代的強大功能和便利。
11、結論
綜合以上所述，其實答案也呼之欲出。
現在的移動端IM、推送系統，既面對移動互聯網的不確定性，又面對智能終端頻繁的系統休眠、網絡切換，還要考慮服務端的承載成本，對於在線服務而言UDP是比TCP更適合的方式。但是由於數據完整性、安全性的需要，又不應完全放棄TCP的可靠與安全。
所以，個人認爲，更恰當的方式應該是：兩種通信協議同時使用，各有側重。UDP用於保持大量終端的在線與控制，應用與業務則通過TCP去實現。這個和FTP服務控制與數據分離，採取不同的連接，有異曲同工之處。
事實上，這個也是即時通訊巨頭QQ所採用的方式。早期的時候，QQ還是主要使用TCP協議，而後來就轉向了採用UDP的方式來保持在線，TCP的方式來上傳和下載數據。現在，UDP是QQ的默認工作方式，表現良好。相信這個也被沿用到了微信上。
簡單的考證：登錄PC版QQ，關閉多餘的QQ窗口只留下主窗口，並將其最小化。幾分鐘過後，查看系統網絡連接，會發現QQ進程已不保有任何TCP連接，但有UDP網絡活動。這時在發送聊天信息，或者打開其他窗口和功能，將發現QQ進程會啓用TCP連接。
（本文同步發佈於：http://www.52im.net/thread-33-1-1.html）
作者：Jack Jiang (點擊作者姓名進入Github)
出處：http://www.52im.net/space-uid-1.html
交流：歡迎加入即時通訊開發交流羣 215891622
討論：http://www.52im.net/
Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】和【輕量級移動端即時通訊框架MobileIMSDK】的作者，可前往下載交流。
本博文 歡迎轉載，轉載請註明出處（也可前往 我的52im.net 找到我）。