移動IM開發指南1:如何進行技術選型

網易雲信發表於2018-06-14

《移動IM開發指南》系列文章將會介紹一個IM APP的方方面面,包括技術選型、登陸優化等。此外,本文作者會結合他在網易雲信多年iOS IM SDK開發的經驗,深度分析實際開發中的各種常見問題。

推薦閱讀

移動IM開發指南2:心跳指令詳解

移動IM開發指南3:如何優化登入模組

通訊方式選擇

IM通訊方式無非兩種選擇:裝置直連(P2P)和通過伺服器中轉

1. P2P

P2P多見於區域網內聊天工具,典型的應用有:飛鴿傳書等。這類軟體在啟動後一般做兩件事情:

  • 進行UDP廣播:傳送自己資訊和接受同區域網內其他端資訊
  • 開啟TCP監聽:等待其他端進行連線

詳細的流程可以參考飛鴿傳書原始碼。但是這種方式在有種種限制和不便:一方面它只適合線上的點對點訊息傳輸,對離線,群組等業務支援不夠。另一方面由於 NAT 的存在,使得不同區域網內機器互聯難度大大上升,在某些網路型別(對稱NAT)下無法建立連線。

2. 伺服器中轉

幾乎所有網際網路IM產品都採用伺服器中轉這種方式進行訊息傳輸,相對於P2P的方式,它有如下的優點:

  • 能夠支援更多P2P無法支援或支援不好的業務,如離線訊息,群組,聊天室服務
  • 方便業務邏輯的擴充和新舊版本的相容

當然它也有自己的問題:伺服器架構複雜,併發要求高。

網路連線方式

IM主流網路連線方式有兩種:

  • 基於TCP的長連線
  • 基於HTTP短連線PULL的方式

後者常見於WEB IM系統(當然現在很多WEB IM都是基於WebSocket實現),它的優點是實現簡單,方便開發上手,問題是流量大,伺服器負載較大,訊息及時性無法很好地保證,對大規模的使用者量支援不夠,比較適合小型的IM系統,如小網站的客戶系統。

基於TCP長連線則能夠更好地支援大批量使用者,問題是客戶端和伺服器的實現比較複雜。當然也還有一些變種,如下行使用MQTT進行伺服器通知/訊息的下發,上行使用HTTP短連線進行指令和訊息的上傳。這種方式能夠保證下行訊息/指令的及時性,但是在弱網路下上行慢的問題還是比較嚴重。早期的來往就是基於這種方式。

協議選擇

IM協議選擇原則一般是:易於擴充,方便覆蓋各種業務邏輯,同時又比較節約流量。後一點的需求在移動端IM上尤其重要。

常見的協議有:XMPP;SIP;MQTT;私有協議。

  • XMPP協議的優點在於:協議開源,可擴充性強,在各個端(包括伺服器)有各種語言的實現,開發者接入方便。但是缺點也是不少:XML表現力弱,有太多冗餘資訊,流量大,實際使用時有大量天坑。
  • SIP協議多用於VOIP相關的模組,是一種文字協議,由於我並沒有實際用過,所以不做評論,但從它是文字協議這一點幾乎可以斷定它的流量不會小。
  • MQTT的優點是協議簡單,流量少,但是它並不是一個專門為IM設計的協議,多使用於推送。
  • 市面上幾乎所有主流IM APP都是使用私有協議,一個被良好設計的私有協議一般有如下優點:高效,節約流量(一般使用二進位制協議),安全性高,難以破解。缺點則是在開發初期沒有現有樣列可以參考,對於設計者的要求比較高。

一個好的協議需要滿足如下條件:高效,簡潔,可讀性好,節約流量,易於擴充,同時又能夠匹配當前團隊的技術堆疊。基於如上原則,我們可以推出: 如果團隊小,團隊技術在IM上積累不夠可以考慮使用XMPP或者MQTT+HTTP短連線的實現。反之可以考慮自己設計和實現私有協議。

私有協議的設計

  • 序列化選擇

移動網際網路相對於有線網路最大特點是:頻寬低,延遲高,丟包率高和穩定性差,流量費用高。所以在私有協議的序列化上一般使用二進位制協議,而不是文字協議。常見的二進位制序列化庫有protobuf和MessagePack,當然你也可以自己實現自己的二進位制協議序列化和反序列的過程,比如蘑菇街的TeamTalk。但是前面二者無論是可擴充性還是可讀性都完爆TeamTalk(TeamTalk連Variant都不支援,一個int傳輸時固定佔用4個位元組),所以大部分情況下還是不推薦自己去實現二進位制協議的序列化和反序列化過程。

  • 協議格式設計

基於TCP的應用層協議一般都分為包頭和包體(如HTTP),IM協議也不例外。包頭一般用於表示每個請求/反饋的公共部分,如包長,請求型別,返回碼等。 而包頭則填充不同請求/反饋對應的資訊。

一個最簡單的包頭可以定義為

移動IM開發指南1:如何進行技術選型移動IM開發指南1:如何進行技術選型

以心跳包為例,假設當前的serial為1,心跳包的command為10,那麼使用MessagePack做序列化時:length=4,serial=1,command=10,code=0,每個欄位各佔一個位元組,包體為空,僅需要4個位元組。

當然這是最簡單的一個例子,面對真正的業務邏輯時,包體裡面會需要塞入更多地資訊,這個需要開發根據自己的業務邏輯總結公共部分,如為了相容加入的協議版本號,為了負載均衡加入的模組id等。


上面就是IM系統大致的選型過程,包含了通訊方式,連線方式,協議選擇,協議設計。但是實際開發過程中還有大量的問題需要處理。《移動IM開發指南》系列文章第二篇將會為大家解答實際開發中的常見問題。


相關文章