移動 IM 學習筆記[轉]

轉: http://ruby-china.org/topics/22530

最近在看移動IM相關的資料， 而後發現網上有不少的資料，因此在學習過程當中，整理了一些筆記， 供那些 想了解 移動IM的童鞋一些參考。

移動IM技術選型要點

一、協議選型
二、IM 服務器選型
三、協議和IM服務器改造
四、移動IM常見問題以及一些解決方案 
五、一些第三方服務

1、經常使用的IM協議

 

2、IM 服務器的選擇

通過這幾天在網上的調研， 發現目前比較流行的幾個IM 服務器 也就是 Openfire、Tigase, Ejabberd:

 

備註: 
詳解Zoosk千萬用戶實時通訊背後的開源技術

3、XMPP協議的問題及改進

一、登陸握手部分改進

Xmpp QuickStart

二、心跳改進

原先Xmpp使用的Ping/Pong 40+字節， 改進爲單向 white space ping, 4字節。

備註: 心跳單向四個字節，在Xmpp協議下，估計應該是極限了吧。在私有協議協議下，一來一往兩個字節足夠。

三、文件傳輸
- Xmpp 的文件傳輸採用的點對點的傳輸; 改進爲http 上傳到server

- 語音、視頻壓縮上傳

- 圖片默認下載縮略圖

四、Presense

移動互聯網環境下，無論用戶是否在線， 都會假設 用戶永遠在線。

這是由於移動網絡環境致使， 好比從wifi 切換到 3G、處於地鐵、WIFI邊緣地帶等， 若是還採用PC端 相似QQ那種方式， 極可能會形成重連風暴。

五、Muc 聊天室

Muc 是聊天室協議，在業務層面進行改進， 發送消息時 發送給全部用戶，無論他在不在線

4、基於Openfire 服務器的改進

一、發送消息回執

在server端維護一個消息隊列， 當收到client發送會的消息回執時， 將這個消息刪掉

二、性能改進

不要使用內置的數據庫, 對於Vcard或者好友列表信息 能夠考慮放到Redis

三、若是是消息量很大的話, 消息存儲可使用Kafka（和數據庫集羣之間存定時拉取關係），分佈式鎖基於Zookeeper，前端LVS作負載均衡。

5、移動IM的那些坑點

一、長鏈接

android 平臺 維護client 到server的長鏈接

IM或推送，創建長鏈接是必須的，能夠節省TCP來回建立的開銷，但斷線以後，是否須要即刻重連，尤爲是處於地鐵、WIFI邊緣地帶，可能會形成重連風暴，須要添加稍加延遲鏈接機制。

二、心跳包 GGSN

維護移動網GGSN

三、消息回執處理Ack

移動網絡很容易丟包， 發送、接受應加入回執處理

四、語音、圖片的收發優化

大數據拆分紅多個包, 一個包大概10字節

6、第三方的IM服務

一、環信(我的感受選他不錯), 大概是從2013年4月創立， 到目前爲止號稱 有6000萬註冊用戶， 有1000+ app使用

 

二、leancloud 2013 年 9 月發佈以來，已經吸引了近萬移動應用和開發者加入。

 

7、結論

若是說本身搭建一套IM框架的:
- 基本能用須要3個月
- 作的比較好須要9月到1年時間
- 作的像微信同樣，那麼須要2年時間

若是說基於現有的IM服務器搭建的話， 我的以爲 從IMserver性能以及後期維護和招人成本上來看， 應該是 Tigase > Openfire > Ejabberd

8、寫在最後

若是你也對IM感興趣的話，能夠看一看 環信的一個講座, 對應的ppt。

固然了， 因爲我本人接觸IM 這塊也不過久， 因此確定會有一些遺漏， 歡迎你們提意見呀...

---純文章的搬運工！