2016-02-18 16:43
5676人閱讀收藏
舉報
it（300）
目錄(?)
[+]
移動im技術選型要點
1、協議選型
2、im 伺服器選型
3、協議和im伺服器改造
4、移動im常見問題以及一些解決方案
5、一些第三方服務
一、常用的im協議
二、im 伺服器的選擇
經過這幾天在網上的調研， 發現目前比較流行的幾個im 伺服器 也就是 openfire、tigase, ejabberd:
備註:
詳解zoosk千萬使用者實時通訊背後的開源技術
三、xmpp協議的問題及改進
1、登入握手部分改進
xmpp quickstart
2、心跳改進
原先xmpp使用的ping/pong 40+位元組， 改進為單向 white space ping, 4位元組。
備註: 心跳單向四個位元組，在xmpp協議下，估計應該是極限了吧。在私有協議協議下，一來一往兩個位元組足夠。
4、presense
5、muc 聊天室
四、基於openfire 伺服器的改進
1、傳送訊息回執
在server端維護乙個訊息佇列， 當收到client傳送會的訊息回執時， 將這個訊息刪掉
2、效能改進
不要使用內建的資料庫, 對於vcard或者好友列表資訊 可以考慮放到redis
3、如果是訊息量很大的話, 訊息儲存可以使用kafka（和資料庫集群之間存定時拉取關係），分布式鎖基於zookeeper，前端lvs做負載均衡。
五、移動im的那些坑點
1、長連線
android 平台 維護client 到server的長連線
im或推送，建立長連線是必須的，可以節省tcp來回建立的開銷，但斷線之後，是否需要即刻重連，尤其是處於地鐵、wifi邊緣地帶，可能會造成重連風暴，需要新增稍加延遲連線機制。
2、心跳包 ggsn
維護移動網ggsn
3、訊息回執處理ack
流動網路很容易丟包， 傳送、接受應加入回執處理
4、語音、的收發優化
大資料拆分成多個包, 乙個包大概10位元組
六、第三方的im服務
2、leancloud 2013 年 9 月發布以來，已經吸引了近萬移動應用和開發者加入。
七、結論
如果說基於現有的im伺服器搭建的話， 個人覺得 從imserver效能以及後期維護和招人成本上來看， 應該是 tigase > openfire > ejabberd
八、寫在最後
移動IM開源框架對比
移動im技術選型要點 1 協議選型 2 im 伺服器選型 3 協議和im伺服器改造 4 移動im常見問題以及一些解決方案 5 一些第三方服務 一 常用的im協議 二 im 伺服器的選擇 經過這幾天在網上的調研，發現目前比較流行的幾個im 伺服器 也就是 openfire tigase,ejabber...
IM系統框架
今天聽喬斌講了公司im系統的整體框架以及各部分的特點，還有一歇需要注意的問題，趁著熱乎總結紀錄一下。首先分幾大模組，也可以理解為幾層 entry,logic,router,das。entry是接入層，負責管理成千上萬的連線，主要處理高併發，用到了epoll，並將接收到的資料報加入乙個任務佇列，交給下...
開源 Bro Snort suricata對比
場景 前兩者的缺點就是它的優點 缺點 學習有一定的門檻。支援snort suricata的裝置不能與網路上其他支援snort的裝置通訊，也不能集中管理它們。對於小型企業來說，它們可能工作得很好，但對於中型或大型網路，它們可以帶來更多的工作，而帶來更少的價值。規則分析 bro提供了一些關鍵的高階特性 ...