移動(dòng)IM開發(fā)那些事
兩年都在做Android IMSDK。今天突然心血來潮躏嚎，想對(duì)現(xiàn)在的IM即時(shí)通訊技術(shù)做個(gè)總結(jié)瘾杭，文章大部分內(nèi)容應(yīng)用其他博客揽祥，請(qǐng)諒解。
IM傳輸層協(xié)議
目前我所知道的IM傳輸時(shí)使用的是UDP桨醋、TCP棚瘟、基于TCP的Http協(xié)議。
UDP
UDP:用戶數(shù)據(jù)報(bào)協(xié)議喜最，是一個(gè)簡(jiǎn)單的面向數(shù)據(jù)報(bào)的運(yùn)輸層協(xié)議偎蘸。UDP不提供可靠性，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報(bào)發(fā)送出去瞬内，但是并不能保證它們能到達(dá)目的地迷雪。由于UDP在傳輸數(shù)據(jù)報(bào)前不用在客戶和服務(wù)器之間建立一個(gè)連接，且沒有超時(shí)重發(fā)等機(jī)制虫蝶，故而傳輸速度很快振乏。
目前使用該協(xié)議的應(yīng)該只有QQ吧。
關(guān)于QQ使用UDP的問題（請(qǐng)見《為什么QQ用的是UDP協(xié)議而不是TCP協(xié)議秉扑？》帖子中的討論）慧邮。個(gè)人不清楚QQ使用UPD作為傳輸層協(xié)議的初衷调限，但猜測(cè)是因?yàn)?0多年前Client 10K問題沒有得到很好解決，一臺(tái)服務(wù)器支撐不了1W個(gè)TCP連接 误澳，騰訊的同時(shí)在線量高耻矮，沒辦法，只有用UDP了忆谓，但UDP又不可靠裆装，故只能在UDP上實(shí)現(xiàn)TCP的超時(shí)／重傳／確認(rèn)等機(jī)制啦。
TCP
TCP是一種面向連接的倡缠、可靠的哨免、基于字節(jié)流的傳輸層通信協(xié)議。
目前大部分IM都是該協(xié)議昙沦。如蘑菇街IM琢唾、陌陌、微信
基于TCP長(zhǎng)連接則能夠更好地支持大批量用戶盾饮，問題是客戶端和服務(wù)器的實(shí)現(xiàn)比較復(fù)雜采桃。
基于TCP的HTTP協(xié)議
該協(xié)議主要用于Web IM。目前大多數(shù)WebIM都使用WebSocket丘损。它的優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單普办，方便開發(fā)上手，問題是流量大徘钥，服務(wù)器負(fù)載較大衔蹲，消息及時(shí)性無法很好地保證，對(duì)大規(guī)模的用戶量支持不夠呈础，比較適合小型的IM系統(tǒng),如小網(wǎng)站的客戶系統(tǒng)舆驶。
參考基于web的IM軟件通信原理分析
IM應(yīng)用層協(xié)議
數(shù)據(jù)格式的選定可以從以下方面進(jìn)行考慮
網(wǎng)絡(luò)數(shù)據(jù)大小——占用帶寬，傳輸效率：雖然對(duì)單個(gè)用戶來說猪落，數(shù)據(jù)量傳輸很小贞远，但是對(duì)于服務(wù)器端要承受眾多的高并發(fā)數(shù)據(jù)傳輸，必須要考慮到數(shù)據(jù)占用帶寬笨忌，盡量不要有冗余數(shù)據(jù)蓝仲，這樣才能夠少占用帶寬，少占用資源官疲，少網(wǎng)絡(luò)IO袱结，提高傳輸效率；
網(wǎng)絡(luò)數(shù)據(jù)安全性——敏感數(shù)據(jù)的網(wǎng)絡(luò)安全：對(duì)于相關(guān)業(yè)務(wù)的部分?jǐn)?shù)據(jù)傳輸都是敏感數(shù)據(jù)途凫，所以必須考慮對(duì)部分傳輸數(shù)據(jù)進(jìn)行加密垢夹；
編碼復(fù)雜度——序列化和反序列化復(fù)雜度，效率维费，數(shù)據(jù)結(jié)構(gòu)的可擴(kuò)展性果元，可維護(hù)性：對(duì)于平臺(tái)相關(guān)業(yè)務(wù)的代碼實(shí)現(xiàn)也需要考慮到數(shù)據(jù)發(fā)送方和數(shù)據(jù)接收方數(shù)據(jù)處理的復(fù)雜度和數(shù)據(jù)結(jié)構(gòu)的可擴(kuò)展性促王，可維護(hù)性，人力成本和實(shí)施復(fù)雜度也必須考慮在內(nèi)而晒；
協(xié)議通用性——大眾規(guī)范：數(shù)據(jù)類型必須是跨平臺(tái)蝇狼，數(shù)據(jù)格式是通用的，大家普遍能接受上手的倡怎；
可以參考：
如何選擇即時(shí)通訊應(yīng)用的數(shù)據(jù)傳輸格式
通過以上方面迅耘，對(duì)下面的幾種數(shù)據(jù)格式進(jìn)行分析：
| 優(yōu)點(diǎn) | 缺點(diǎn) ｜
---- | --- | --- | ---
xmpp協(xié)議： | 基于xml協(xié)議，容易理解监署，使用廣泛颤专，易于擴(kuò)展。 |流量大钠乏，在移動(dòng)終端也耗電栖秕。交互過程復(fù)雜。多被pc時(shí)代的產(chǎn)品使用缓熟，不適合移動(dòng)時(shí)代的IM產(chǎn)品累魔，即使我們基于xmpp進(jìn)行改進(jìn)摔笤，簡(jiǎn)化握手過程够滑，改進(jìn)文件傳輸機(jī)制，但是它的基因決定了如何改進(jìn)吕世，他都不適合移動(dòng)互聯(lián)網(wǎng)時(shí)代的IM產(chǎn)品彰触。
mqtt協(xié)議 | 適配多平臺(tái)，IBM開發(fā)的即時(shí)通信協(xié)議 |協(xié)議簡(jiǎn)單命辖，需要自己擴(kuò)展好友况毅，群組等功能
私有協(xié)議 | 隨心所欲，自己定義尔艇，流量小尔许。 |工作量巨大，擴(kuò)展性差终娃，需要考慮全面味廊。
后續(xù)會(huì)對(duì)XMPP進(jìn)行分析,XMPP至少是一個(gè)時(shí)代。雖然老舊棠耕，但是對(duì)于深入IM研究很有價(jià)值
現(xiàn)在市面上IM的協(xié)議使用私有協(xié)議,方便擴(kuò)展業(yè)務(wù)
私有協(xié)議
私有協(xié)議的數(shù)據(jù)格式一般是基于二進(jìn)制流協(xié)議余佛。常見的二進(jìn)制序列化有Protobuf和MessagePack∏嫌或者你可以自己寫序列化過程（這是個(gè)痛苦的過程~）
建議使用probuf,在實(shí)際使用中較為方便辉巡，并且具有自動(dòng)生成Java,OC,C++代碼功能。
特別注明：
我們團(tuán)隊(duì)在剛開始是使用自定義協(xié)議蕊退，通過讀取字節(jié)流的方式讀取內(nèi)容郊楣。
非常不適合擴(kuò)展,每次新增功能都要改動(dòng)很多憔恳。
現(xiàn)在已經(jīng)切換到protobuf,使用的還是挺溜的，不用關(guān)心如何讀取返回的字節(jié)流
大家可以看下這篇文章強(qiáng)列建議將Protobuf作為你的即時(shí)通訊應(yīng)用數(shù)據(jù)傳輸格式
其他
后續(xù)的計(jì)劃净蚤，會(huì)間歇性的發(fā)布關(guān)于IM的文章
移動(dòng)IM開發(fā)之XMPP MQTT分析
移動(dòng)IM開發(fā)之IM功能定位
移動(dòng)IM開發(fā)之心跳
移動(dòng)IM開發(fā)之登錄優(yōu)化
移動(dòng)IM開發(fā)之消息
移動(dòng)IM開發(fā)之IMSDK競(jìng)品比較
移動(dòng)IM開發(fā)之IM App競(jìng)品對(duì)比
移動(dòng)IM開發(fā)之安全協(xié)議涉及與考慮
IM相關(guān)的文章
即時(shí)通訊網(wǎng) http://www.52im.net/
專注在一滴水上喇嘱，或許能夠得到整片大海
