移動端IM開發須要面對的技術問題

時間 2019-11-18

標籤移動開發須要面對技術問題欄目無線简体版

原文原文鏈接

一、前言

這兩年多一直從事網易雲信 iOS 端 IM SDK的開發，期間不斷有兄弟部門的同事和合做夥伴過來問各類技術細節，乾脆統一介紹下一個IM APP的方方面面，包括技術選型（包括通信方式，網絡鏈接方式，協議選擇）和常見問題。（原文連接：http://www.52im.net/thread-133-1-1.html）php

分享者：項望烽，畢業於浙江大學，目前是網易雲信 iOS 端研發負責人。 html

二、學習交流

- 即時通信開發交流羣： 215891622 [推薦]android

- 移動端IM開發推薦文章：《新手入門一篇就夠：從零開發移動端IM》算法

三、P2P仍是服務器中轉？

IM通信方式無非兩種選擇：設備直連(P2P)和經過服務器中轉。編程

3.1 P2P方式

P2P多見於局域網內聊天工具，典型的應用有:飛鴿傳書、天網Maze(你懂的)等。這類軟件在啓動後通常作兩件事情：緩存

進行UDP廣播:發送本身信息和接受同局域網內其餘端信息；
開啓TCP監聽:等待其餘端進行鏈接。

詳細的流程能夠參考飛鴿傳書源碼。可是這種方式在有種種限制和不便:一方面它只適合在線的點對點消息傳輸，對離線，羣組等業務支持不夠。另外一方面因爲 NAT 的存在，使得不一樣局域網內機器互聯難度大大上升，在某些網絡類型(對稱NAT)下沒法創建鏈接。

安全

3.2 服務器中轉方式

幾乎全部互聯網IM產品都採用服務器中轉這種方式進行消息傳輸，相對於P2P的方式，它有以下的優勢:服務器

可以支持更多P2P沒法支持或支持很差的業務，如離線消息，羣組，聊天室服務；
方便業務邏輯的拓展和新舊版本的兼容。

固然它也有本身的問題:服務器架構複雜，併發要求高。微信

四、該選擇什麼樣的網絡通信技術？

IM主流網絡通信技術有兩種:網絡

基於TCP的長鏈接；
基於HTTP短鏈接PULL的方式。

後者常見於WEB IM系統(固然如今不少WEB IM都是基於WebSocket實現)，它的優勢是實現簡單，方便開發上手，問題是流量大，服務器負載較大，消息及時性沒法很好地保證，對大規模的用戶量支持不夠，比較適合小型的IM系統,如小網站的客戶系統。

基於TCP長鏈接則可以更好地支持大批量用戶，問題是客戶端和服務器的實現比較複雜。固然也還有一些變種，以下行使用MQTT進行服務器通知/消息的下發，上行使用HTTP短鏈接進行指令和消息的上傳。這種方式可以保證下行消息/指令的及時性，可是在弱網絡下上行慢的問題仍是比較嚴重。早期的來往就是基於這種方式。

五、協議如何制定？

IM協議選擇原則通常是：易於拓展，方便覆蓋各類業務邏輯，同時又比較節約流量。後一點的需求在移動端IM上尤爲重要。常見的協議有：XMPP、SIP、MQTT、私有協議。（更多關於即時通信應用的協議選擇，請參見《如何選擇即時通信應用的數據傳輸格式》：http://www.52im.net/thread-276-1-1.html）

5.1 XMPP

優勢：協議開源，可拓展性強，在各個端(包括服務器)有各類語言的實現，開發者接入方便；
缺點：缺點也是很多，XML表現力弱、有太多冗餘信息、流量大，實際使用時有大量天坑。

5.2 SIP

SIP協議多用於VOIP相關的模塊，是一種文本協議，因爲我並無實際用過，因此不作評論，但從它是文本協議這一點幾乎能夠判定它的流量不會小。

5.3 MQTT

優勢：協議簡單，流量少；
缺點：它並非一個專門爲IM設計的協議，多使用於推送。

5.4 私有協議

市面上幾乎全部主流IM APP都是是使用私有協議，一個被良好設計的私有協議優勢很是明顯。

優勢：高效，節約流量(通常使用二進制協議)，安全性高，難以破解；
缺點：在開發初期沒有現有樣列能夠參考，對於設計者的要求比較高。

5.5 結論

一個好的協議須要知足以下條件:高效，簡潔，可讀性好，節約流量，易於拓展，同時又可以匹配當前團隊的技術堆棧。基於如上原則，咱們能夠得出: 若是團隊小，團隊技術在IM上積累不夠能夠考慮使用XMPP或者MQTT+HTTP短鏈接的實現。反之能夠考慮本身設計和實現私有協議。

六、該如何設計私有通訊協議？

6.1 序列化與反序列化

移動互聯網相對於有線網絡最大特色是:帶寬低，延遲高，丟包率高和穩定性差，流量費用高。因此在私有協議的序列化上通常使用二進制協議，而不是文本協議。

常見的二進制序列化庫有protobuf和MessagePack，固然你也能夠本身實現本身的二進制協議序列化和反序列的過程，好比蘑菇街的TeamTalk。可是前面兩者不管是可拓展性仍是可讀性都完爆TeamTalk(TeamTalk連Variant都不支持，一個int傳輸時固定佔用4個字節)，因此大部分狀況下仍是不推薦本身去實現二進制協議的序列化和反序列化過程。

6.2 協議格式設計

基於TCP的應用層協議通常都分爲包頭和包體(如HTTP)，IM協議也不例外。包頭通常用於表示每一個請求/反饋的公共部分，如包長，請求類型，返回碼等。而包頭則填充不一樣請求/反饋對應的信息。

一個最簡單的包頭能夠定義爲：

 
         struct 
         PackHeader 
        
         { 
        
         int32_t     length_;     
         //包長度 
        
         int32_t     serial_;     
         //包序列號 
        
         int32_t     command_;    
         //包請求類型 
        
         int32_t     code_;       
         //返回碼 
        
         };

以心跳包爲例，假設當前的serial爲1，心跳包的command爲10，那麼使用MessagePack作序列化時:length=4，serial=1，command=10，code=0，每一個字段各佔一個字節，包體爲空，僅須要4個字節。

固然這是最簡單的一個例子，面對真正的業務邏輯時，包體裏面會須要塞入更多地信息，這個須要開發根據本身的業務邏輯總結公共部分,如爲了兼容加入的協議版本號,爲了負載均衡加入的模塊id等。

七、其餘不可忽視的問題

上面的內容就是一個IM系統大體的選型過程：服務方式，網絡通信協議，數據通訊協議選擇、協議設計。可是實際開發過程當中還有大量的問題須要處理。

7.1 協議加密

爲了保證協議不容易被破解，市面上幾乎全部主流IM都會對協議進行加密傳輸。常見的流程和HTTPS加密類似:創建鏈接後，客戶端和服務器進行進行協商，最終客戶端得到一個當前Sessino的祕鑰，後續的數據傳輸都經過這個祕鑰進行加解密。通常出於效率的考慮都會採用流式加密，如RC4。而前期協商過程則推薦使用RSA等非對稱加密以增長破解難度。

7.2 快速鏈接（即掉線重連機制）

對iOS APP而言，由於沒有真後臺的存在，APP每次啓動基本都須要一次重連登陸(短期內切換除外)，因此如何快速重連、重登就很是重要。
常見優化思路以下:

本地緩存服務器IP並按期刷新。移動網絡調優能夠參考《iOS端移動網絡調優的8條建議》；
合併部分請求。如加密和登陸操做能夠合併爲同一個操做，這樣就能夠減小一次沒必要要的網絡請求來回的時間；
簡化登陸後的同步請求，部分同步請求能夠推遲到UI操做時進行，如羣成員信息刷新。

7.3 鏈接保持（即心跳機制）

通常APP實現鏈接保持的方式無非是採用應用層的心跳，經過心跳包的超時和其餘條件(網絡切換)來執行重連操做。那麼問題來了:爲何要使用應用層心跳和如何設計應用層心跳。衆所周知TCP協議是有KEEPALIVE這個設置選項，設置爲KEEPALIVE後，客戶端每隔N秒(默認是7200s)會向服務器發送一個發送心跳包。

但實際操做中咱們更多的是使用應用層心跳。緣由以下:

KEEPALIVE對服務器負載壓力比較大(服務器大大是這麼說的...)；
socks代理對KEEPALIVE並不支持；
部分複雜狀況下KEEPALIVE會失效，如路由器掛掉，網線(移動端沒有網線...)直接被拔除。

移動端在實際操做時爲了節約流量和電量通常會在心跳包上作一些小優化：

精簡心跳包，保證一個心跳包大小在10字節以內；
心跳包只在空閒時發送；
根據APP先後臺狀態調整心跳包間隔 (主要是安卓)。

7.4 消息可達（即QoS機制）

在移動網絡下，丟包，網絡重連等狀況很是之多，爲了保證消息的可達，通常須要作消息回執和重發機制。參考易信，每條消息會最多會有3次重發，超時時間爲15秒，同時在發送以前會檢測當前鏈接狀態，若是當前鏈接並無正確創建，緩存消息且定時檢查(每隔2秒檢查一次，檢查15次)。因此一條消息在最差的狀況下會有2分鐘左右的重試時間，以保證消息的可達。

由於重發的存在，接受端偶爾會收到重複消息，這種狀況下就須要接收端進行去重。通用的作法是每條消息都戴上本身惟一的message id(通常是uuid)。