1. 即時通訊協(xié)議對比
業(yè)界上用來做即時通訊的解決方案有：1. 基于http 的輪詢; 2. 基于websocket 長連接; 3. 基于tcp或udp的自定義協(xié)議, 這種若在要在Web端使用, 需要套一層websocket 封裝. 此外早期還有基于Comet 技術(shù)的長連接课舍，基于xmpp 的開源客戶端應用等谷婆。
1.1 即時通訊協(xié)議比較
| 名稱 | 特點 | Web支持 | 模式 |
|---|---|---|---|
| http短輪詢/長輪詢 | 實現(xiàn)簡單; 開銷大蜈彼，耗費服務器性能與帶寬 | 支持 | 請求-響應 |
| Websocket | 連接快媒吗，開銷小 | 支持 | 雙向通訊 |
| xmpp | 協(xié)議沉重，不支持二進制包文 | 不支持 | 雙向通訊 |
| mqtt | 常用于物聯(lián)網(wǎng)場景，協(xié)議簡單 | 不支持 | 發(fā)布-訂閱 |
| socket.io | 在websocket封裝的基礎上實現(xiàn)了連接管理，群組卿操，命名空間等特性。 | 支持 | 發(fā)布-訂閱 |
| 基于tcp自定義協(xié)議 | 連接可靠孙援，開發(fā)難度中等 | 不支持 | - |
| 基于udp自定義協(xié)議 | 連接與發(fā)送數(shù)據(jù)不可靠害淤，開發(fā)難度大 | 不支持 | - |
1.1.1 http短輪詢/長輪詢
一個http的請求有如下的特點:
- 連接必須由客戶端發(fā)起, 服務端被動等待請求, 模式為請求-響應方式.
- 每次請求是無狀態(tài)的，每次請求之間彼此獨立.
- 一個http 請求包括 請求方法+請求資源地址+請求頭部+請求體拓售，見【圖1.1.1 】窥摄，同理一個http 響應包括 相應頭+響應頭部+響應體, 見【圖1.1.2 】
由于http連接必須由客戶端發(fā)起的通訊特點，服務器要往客戶推送消息础淤，必須依賴由客戶端發(fā)起的這條連接崭放。因此在http的協(xié)議上做服務端的消息推送，需要客戶端不斷輪詢鸽凶，服務器有需要發(fā)送的消息時币砂，就在輪詢結(jié)果中返回給客戶端。根據(jù)輪詢類型的不同玻侥，又分為短輪詢和長輪詢决摧。
http短輪詢：
短輪詢的處理如下:
- 客戶端請求服務器，服務器立即返回;
- 客戶端間隔一段時間;
- 客戶端請求服務器凑兰，服務器立即返回;
**http長輪詢: **
短輪詢的處理如下:
- 客戶端請求服務器掌桩，服務器若有數(shù)據(jù)，立即返回姑食，否則阻塞等待;
- 客戶端再次請求服務器波岛，服務器若有數(shù)據(jù)，立即返回音半，否則阻塞等待;
總結(jié): 不管是http短輪詢或http長輪詢则拷，其吞吐量以及響應性都十分不盡人意贡蓖，由于http的請求頭和響應頭的協(xié)議字段帶來的流量損耗，以及服務器被動等待客戶端建立的連接來推送消息帶來延時煌茬，都注定http輪詢的方式這種解決方案用在并發(fā)量吞吐量小斥铺，響應延時容忍度高這種場景。如果用作即時通訊這種專業(yè)化的軟件不那么適合宣旱。
1.1.2 Websocket
WebSocket是一種在單個TCP連接上進行全雙工通信的協(xié)議仅父。WebSocket通信協(xié)議于2011年被IETF定為標準RFC 6455叛薯，并由RFC7936補充規(guī)范浑吟。WebSocket API也被W3C定為標準。
WebSocket使得客戶端和服務器之間的數(shù)據(jù)交換變得更加簡單耗溜，允許服務端主動向客戶端推送數(shù)據(jù)组力。在WebSocket API中，瀏覽器和服務器只需要完成一次握手抖拴，兩者之間就直接可以創(chuàng)建持久性的連接燎字，并進行雙向數(shù)據(jù)傳輸。
WebSocket的定義包括:
WebSocket 是獨立的阿宅、創(chuàng)建在 TCP 上的協(xié)議候衍。
Websocket 通過HTTP/1.1 協(xié)議的101狀態(tài)碼進行握手。
為了創(chuàng)建Websocket連接洒放，需要通過瀏覽器發(fā)出請求蛉鹿，之后服務器進行回應，這個過程通常稱為“握手”（handshaking
WebSocket的出現(xiàn)正是為解決服務器向客戶端推送消息這個問題往湿，在WebSocket出現(xiàn)之前妖异，服務器向客戶端推送消息，只能依賴客戶端輪詢领追，這會導致巨大的資源浪費他膳。
1.1.3 XMPP
可擴展通訊和表示協(xié)議 (XMPP) 可用于服務類實時通訊、表示和需求響應服務中的XML數(shù)據(jù)元流式傳輸绒窑。XMPP以Jabber協(xié)議為基礎棕孙，而Jabber是即時通訊中常用的開放式協(xié)議。
XMPP的出現(xiàn)背景是為了解決ICQ, MSN等桌面聊天應用消息協(xié)議互不相通的局面出現(xiàn)的些膨。當"理想很好散罕，現(xiàn)時很骨感", XMPP在現(xiàn)代越來越不被當做作主流的聊天協(xié)議來使用，甚至一些大廠逐漸棄用了XMPP, 原因有以下幾點:
- 使用XML為載荷的XMPP消息體很大;
- XMPP的協(xié)議貪大求全傀蓉，太過復雜欧漱，使用者門檻很高;
- 雖說XMPP是一個開放的協(xié)議，但實際上遵守協(xié)議的應用很少葬燎，更多是在此基礎上的魔改;
因此XMPP的現(xiàn)狀是雖然有一些歷史的開源組件误甚，開源應用支持快速上手缚甩，但因技術(shù)陳舊，沒人維護等問題窑邦，導致二次開發(fā)擅威，后期維護等都十分困難。
1.1.4 MQTT
MQTT（Message Queuing Telemetry Transport冈钦，消息隊列遙測傳輸協(xié)議）郊丛，是一種基于發(fā)布/訂閱（Publish/Subscribe）模式的輕量級通訊協(xié)議，MQTT 最大的優(yōu)點在于可以以極少的代碼和有限的帶寬瞧筛，為遠程設備提供實時可靠的消息服務厉熟。做為一種低開銷、低帶寬占用的即時通訊協(xié)議较幌， MQTT 在物聯(lián)網(wǎng)揍瑟、小型設備、移動應用等方面有廣泛的應用乍炉。
MQTT 的協(xié)議比較簡單绢片，是低開銷、低帶寬的物聯(lián)網(wǎng)環(huán)境下發(fā)展起來岛琼。若要在Web的應用下使用底循，需要在Websocket之做一層協(xié)議封裝。
1.1.5 socket.io
socket.io 是一個在客戶端槐瑞，服務器之間進行即時通訊的使用庫熙涤，它提供一個低延時，雙向的随珠，基于事件的通訊模式.
socket.io 有如下的特點:
- 它是在Websocket之上構(gòu)建的協(xié)議灭袁，它可以充分利用Websocket 低延時，消耗小的優(yōu)勢;
- 若客戶端不支持Websocket協(xié)議窗看，它會回退成使用HTTP 進行l(wèi)ong-polling來實現(xiàn);
- 它支持廣播茸歧，分組，命名空間显沈，連接管理等豐富的功能软瞎。
與MQTT相比，MQTT與socket.io都是基于發(fā)布/訂閱（Publish/Subscribe）模式的拉讯，但與MQTT不同的是涤浇， socket.io 是基于Web應用發(fā)展起來的，它天然支持Web應用魔慷，它支持websocket 與 long-polling 等多種實現(xiàn)協(xié)議切換只锭，它在處理一些瀏覽器兼容性的問題上更有優(yōu)勢.
與Websocket相比，socket.io 提供了更豐富的功能院尔，它支持廣播蜻展，分組喉誊，命名空間，連接管理等豐富的功能纵顾，而且伍茄，它提供了從客戶端-服務端, 和服務器-客戶端的雙向確認機制，更有效的保證了即時聊天應用消息不遺漏施逾。
1.1.6 基于tcp/udp自定義協(xié)議
一些大的企業(yè)擁有自己的專業(yè)開發(fā)團隊敷矫，通常自己打造一套自己標準的通訊協(xié)議，一方面可以做到"閉源"汉额，阻止競爭者竊取數(shù)據(jù)曹仗；一方面可以根據(jù)自身的業(yè)務情況，不端深入做優(yōu)化闷愤。一般而言整葡，不是專業(yè)做即時通訊的中小企業(yè)都很少打造自己的通訊協(xié)議件余。
1.2 即時通訊協(xié)議選型
在設計"E聊SDK"的過程中讥脐，筆者注意考慮了以下幾點即時通訊的需求:
- 聊天方式支持單聊，群聊啼器，消息類型支持文本旬渠，表情 ，圖片端壳，文件等;
- 首要支持移動端(android, ios, h5), Web端告丢， 其次PC端等多個平臺;
- 開發(fā)難度小，調(diào)試方便损谦，要求API包文可視化;
- 適用于中小項目岖免，支持同時在線: 1000,000 發(fā)消息QPS:100,000
經(jīng)上述幾種即時通訊協(xié)議的仔細比較，考慮到項目需求照捡，最終筆者選擇了socket.io + http 的方案颅湘。socket.io 的用途是作為服務器向客戶端下發(fā)消息，而客戶端向服務器請求API的方式仍選擇傳統(tǒng)的HTTP 方式栗精，如[圖3]闯参，這樣的好處有以下幾點:
- http 的開發(fā)方式與調(diào)試工具已十分成熟，像Chrome 的F12調(diào)試窗, curl 工具, java后端的servlet debug等都十分好用悲立， 使用http 請求的方式方便開發(fā)人員開發(fā)鹿寨，調(diào)試，大大提交業(yè)務開發(fā)效率;
- 服務器使用socket.io 的通道向客戶端下發(fā)即時消息.當socket.io 連接起來后(底層使用websocket), 可以得益于websocket 全雙工薪夕，低延時的優(yōu)勢脚草。
- socket.io 的基于訂閱-發(fā)布模式，協(xié)議上自帶連接管理原献，自動重連等功能, 接入使用簡單馏慨，可以達到開箱即用涩蜘，降低研發(fā)人員使用門檻；
- socket.io 誕生于Web環(huán)境熏纯，支持websocket, xhr-polling 多種底層實現(xiàn)方式同诫，在傳統(tǒng)Web, 現(xiàn)代h5 已得到良好的驗證。移動互聯(lián)網(wǎng)發(fā)展至今樟澜，開發(fā)原生應用因開發(fā)成本误窖，推廣費用等因素不再是"剛需"，對于原生應用的開發(fā)一般使用前端跨平臺的開發(fā)框架來實現(xiàn)秩贰，如ReactNative, uniapp 等霹俺，基于此類流行的跨平臺框架上，socket.io 也有對應的sdk毒费，真正達到"一招通吃"丙唧。
1.3 本章總結(jié)
本章主要介紹了市面上可供即時通訊選型的多種技術(shù)方案，包括http, Websocket, xmpp, mqtt, socket.io 以及自定義的TCP/UDP協(xié)議等觅玻。并在最后介紹了"E聊SDK"的通訊方案選型的考慮想际，以便打造一個現(xiàn)代化即時通訊應用。
