如何選擇即時通訊應用的數據傳輸格式 頂 原

前言

即時通訊應用(包括IM聊天應用、實時消息推送應用等)開發的前期技術選型時,關於數據傳輸格式的選擇,在即時通訊開發者同行的眼裏,是個極富爭議話題。

精略分析一下,大概的原因在於:

  • 可選擇的協議或封裝格式多種多樣:
    可選擇的餘地很大:XMPP、Protobuf、JSON、私有2進制、MQTT、定格化XML、Plain text等等;
  • 同一種格式並不能適用於大多數的場景:
    不同的場景有同的考慮而協議的選擇往 跟這是掛鉤在一起的,比如:移動端IM或推送技術用XMPP這樣的協議時,多數情況下都會被噴;
  • 開發者對所選格式有各自的偏好:
    有的人或團隊對某種或某幾種格式有不一樣的經驗和技術積累,也促成了他們對某種或某幾種協議的偏好。


其實總結以上原因就可以知道,之所以對於即時通訊應用的數據傳輸格式有不同的聲音,根本原因還在於應具體事情具體分析,該選什麼協議由場景決定、由團隊的技術積累決定、甚至由項目的週期和成本決定,這裏不存在唯一解,只有最適合的數據傳輸格式,不存在最好的格式一說。

當然,本文內容中對即時通訊傳輸格式的選擇,是原作者的一家之言,可能存在很大爭議,但如能爲你的即時通訊應用開發的技術選型帶來些許啓發,我相信這才符合作者的本意。(本文同步發佈於:http://www.52im.net/thread-276-1-1.html

學習交流

- 即時通訊開發交流羣: 215891622 [推薦]

更多資料

移動端IM開發,推薦閱讀:《新手入門一篇就夠:從零開發移動端IM》。

數據格式的選型需要考慮的方面

[1] 網絡數據大小:佔用帶寬,傳輸效率

雖然對單個用戶來說,數據量傳輸很小,但是對於服務器端要承受衆多的高併發數據傳輸(尤其現時高併發、大用戶量的IM聊天應用和實時推送服務端等場景),必須要考慮到數據佔用帶寬,儘量不要有冗餘數據,這樣才能夠少佔用帶寬,少佔用資源,少網絡IO,提高傳輸效率。

[2] 網絡數據安全性:敏感數據的網絡安全

對於相關業務的部分數據傳輸都是敏感數據,所以必須考慮對部分傳輸數據進行加密。這通常出現在銀行等數據安全性要求很高的應用行業和場景裏,當然傳統的即時通訊應用裏基於用戶隱私考慮,數據加密也是同樣是個必須考慮的問題。安全性是應用的基礎條件,需求是一樣的,只是加密程度、安全性級別要求有不同而已。

[3] 編碼複雜度

編碼複雜度包括序列化和反序列化複雜度、效率、數據結構的可擴展性和可維護性。

對於平臺相關業務的代碼實現也需要考慮到數據發送方和數據接收方數據處理的複雜度和數據結構的可擴展性,可維護性,人力成本和實施複雜度也必須考慮在內。通常情況下,即時通訊應用(比如IM聊天應用)在開發的前期,爲了方便調試,很多團隊會用簡單的文本協議、JSON等能直觀查看的方式,但後期生產部署後,爲了流量等考慮,可能會轉用Protobuf等更省流量的協議。但總之,協議的定義不可能永遠一成不變,但如果在實現的時候就有這些預見性,相性會大大減輕未來的運營風險。 

[4] 協議通用性、大衆規範

數據類型必須是跨平臺,數據格式是通用的,大家普遍能接受上手的。當然,現在已經邁入移動互聯網時代,多端、多平臺、異構平臺的數據通訊是先決條件,而協議的選擇,通用性也最多隻是應用層有區別。當然,無論如何,異構平臺的一致性,是毫無爭議的必備條件。

不同類別的數據傳輸協議(格式)的比較

[1] 自定義二進制

優點:信息體積小,對應以上”1“              
缺點:編碼複雜度高(自己定義消息格式,自己編寫序列化和反序列化方法,自己進行容錯處理,可擴展性不強,比如添加個字段,就必須改兩端的邏輯處理),對應以上”3“;

[2] 提供序列化和反序列化庫的開源協議

比如 谷歌的protocol buffers, json,  Thrift
優點:是一種流行的通用數據格式,擴展相當方便,序列化和反序列化相當方便(有相應庫),錯誤處理方便(庫支持)。

[3] 文本化協議

比如xml,json
優點:序列化,反序列化容易(庫支持),調試方便,可視化強;
缺點:相對於二進制存儲佔用體積大。

你會選擇哪種格式?

我會選擇JSON(PS: 文中的“我”指原作者),因爲他是“提供序列化和反序列化庫的開源協議還是文本化的協議”,原因如下:

  • 自定義二進制格式的複雜性:
    自定義二進制格式進行傳輸的工作,整個過程在定義消息,write,read的過程過於複雜,還很容易出錯,對於很多數據交互的程序,會花費大量的時間在上面;
  • 自定義二進制格式的擴展性:
    不便於擴展,但json可以很好地解決這種問題;
  • json相比較二進制的數據量也不是問題:
    json的佔用空間稍大,但是我們可以通過網絡數據壓縮來解決,況且json本身也是輕量級的,傳輸效率也很高;
  • 去看《unix編程藝術》吧:
    《第5章--文本化,好協議產生好實踐》、《第6章--透明性:來點兒光》會告訴你使用文本化協議的好處。

結語

文字看完了,原文作者選擇JSON作爲即時通訊應用的數據傳輸格式(協議),到底該怎麼選,相信你也已經找到答案了。(推薦看看另一篇《移動端IM開發需要面對的技術問題》)

相關技術資料分類

[1] 網絡編程基礎資料:
TCP/IP詳解 - 第11章·UDP:用戶數據報協議
TCP/IP詳解 - 第17章·TCP:傳輸控制協議
TCP/IP詳解 - 第18章·TCP連接的建立與終止
TCP/IP詳解 - 第21章·TCP的超時與重傳
理論經典:TCP協議的3次握手與4次揮手過程詳解
理論聯繫實際:Wireshark抓包分析TCP 3次握手、4次揮手過程
計算機網絡通訊協議關係圖(中文珍藏版)
NAT詳解:基本原理、穿越技術(P2P打洞)、端口老化等
UDP中一個包的大小最大能多大?
Java新一代網絡編程模型AIO原理及Linux系統AIO介紹
NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰
NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實戰
>> 更多同類文章 ……

[2] 有關IM/推送的通信格式、協議的選擇:
爲什麼QQ用的是UDP協議而不是TCP協議?
移動端即時通訊協議選擇:UDP還是TCP?
如何選擇即時通訊應用的數據傳輸格式
強列建議將Protobuf作爲你的即時通訊應用數據傳輸格式
移動端IM開發需要面對的技術問題(含通信協議選擇)
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
理論聯繫實際:一套典型的IM通信協議設計詳解
58到家實時消息系統的協議設計等技術實踐分享
>> 更多同類文章 ……

[3] 有關IM/推送的心跳保活處理:
Android進程保活詳解:一篇文章解決你的所有疑問
Android端消息推送總結:實現原理、心跳保活、遇到的問題等
爲何基於TCP協議的移動端IM仍然需要心跳保活機制?
微信團隊原創分享:Android版微信後臺保活實戰分享(進程保活篇)
微信團隊原創分享:Android版微信後臺保活實戰分享(網絡保活篇)
移動端IM實踐:實現Android版微信的智能心跳機制
移動端IM實踐:WhatsApp、Line、微信的心跳策略分析
>> 更多同類文章 ……

[4] 有關WEB端即時通訊開發:
新手入門貼:史上最全Web端即時通訊技術原理詳解
Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE
SSE技術詳解:一種全新的HTML5服務器推送事件技術
Comet技術詳解:基於HTTP長連接的Web端實時通信技術
WebSocket詳解(一):初步認識WebSocket技術
socket.io實現消息推送的一點實踐及思路
>> 更多同類文章 ……

[5] 有關IM架構設計:
淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
一套原創分佈式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM服務器開發之架構選擇
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大後臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
>> 更多同類文章 ……

[6] 有關IM安全的文章:
即時通訊安全篇(一):正確地理解和使用Android端加密算法
即時通訊安全篇(二):探討組合加密算法在IM中的應用
即時通訊安全篇(三):常用加解密算法與通訊安全講解
即時通訊安全篇(四):實例分析Android中密鑰硬編碼的風險
傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示
理論聯繫實際:一套典型的IM通信協議設計詳解(含安全層設計)
微信新一代通信安全解決方案:基於TLS1.3的MMTLS詳解
來自阿里OpenIM:打造安全可靠即時通訊服務的技術實踐分享
>> 更多同類文章 ……

[7] 有關實時音視頻開發:
即時通訊音視頻開發(一):視頻編解碼之理論概述
即時通訊音視頻開發(二):視頻編解碼之數字視頻介紹
即時通訊音視頻開發(三):視頻編解碼之編碼基礎
即時通訊音視頻開發(四):視頻編解碼之預測技術介紹
即時通訊音視頻開發(五):認識主流視頻編碼技術H.264
即時通訊音視頻開發(六):如何開始音頻編解碼技術的學習
即時通訊音視頻開發(七):音頻基礎及編碼原理入門
即時通訊音視頻開發(八):常見的實時語音通訊編碼標準
即時通訊音視頻開發(九):實時語音通訊的迴音及迴音消除概述
即時通訊音視頻開發(十):實時語音通訊的迴音消除技術詳解
即時通訊音視頻開發(十一):實時語音通訊丟包補償技術詳解
即時通訊音視頻開發(十二):多人實時音視頻聊天架構探討
即時通訊音視頻開發(十三):實時視頻編碼H.264的特點與優勢
即時通訊音視頻開發(十四):實時音視頻數據傳輸協議介紹
即時通訊音視頻開發(十五):聊聊P2P與實時音視頻的應用情況
即時通訊音視頻開發(十六):移動端實時音視頻開發的幾個建議
即時通訊音視頻開發(十七):視頻編碼H.264、V8的前世今生
簡述開源實時音視頻技術WebRTC的優缺點
良心分享:WebRTC 零基礎開發者教程(中文)
>> 更多同類文章 ……

[8] IM開發綜合文章:
移動端IM開發需要面對的技術問題
開發IM是自己設計協議用字節流好還是字符流好?
請問有人知道語音留言聊天的主流實現方式嗎?
IM系統中如何保證消息的可靠投遞(即QoS機制)
談談移動端 IM 開發中登錄請求的優化
完全自已開發的IM該如何設計“失敗重試”機制?
微信對網絡影響的技術試驗及分析(論文全文)
即時通訊系統的原理、技術和應用(技術論文)
開源IM工程“蘑菇街TeamTalk”的現狀:一場有始無終的開源秀
>> 更多同類文章 …… 

[9] 開源移動端IM技術框架資料:
開源移動端IM技術框架MobileIMSDK:快速入門
開源移動端IM技術框架MobileIMSDK:常見問題解答
開源移動端IM技術框架MobileIMSDK:壓力測試報告
>> 更多同類文章 ……

[10] 有關推送技術的文章:
iOS的推送服務APNs詳解:設計思路、技術原理及缺陷等
Android端消息推送總結:實現原理、心跳保活、遇到的問題等
掃盲貼:認識MQTT通信協議
一個基於MQTT通信協議的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三種方案的優劣
移動端實時消息推送技術淺析
掃盲貼:淺談iOS和Android後臺實時消息推送的原理和區別
絕對乾貨:基於Netty實現海量接入的推送服務技術要點
移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)
爲何微信、QQ這樣的IM工具不使用GCM服務推送消息?
>> 更多同類文章 ……

[11] 更多即時通訊技術好文分類:

http://www.52im.net/forum.php?mod=collection&op=all

(本文同步發佈於:http://www.52im.net/thread-276-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】的作者,可前往下載交流。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章