Java 通訊

前言javascript

通常來講,Web端即時通信技術因受限於瀏覽器的設計限制,一直以來實現起來並不容易,主流的Web端即時通信方案大體有4種:傳統Ajax短輪詢、Comet技術、WebSocket技術、SSE(Server-sent Events)。php

關於這4種技術方式的優缺點,請參考《Web端即時通信技術盤點:短輪詢、Comet、Websocket、SSE》。本文將專門講解Comet技術。 更多資料html

Web端即時通信新手入門貼: 《新手入門貼:詳解Web端即時通信技術的原理》java

Web端即時通信技術盤點請參見: 《Web端即時通信技術盤點:短輪詢、Comet、Websocket、SSE》android

關於Ajax短輪詢: 找這方面的資料沒什麼意義,除非忽悠客戶,不然請考慮其它3種方案便可。web

有關Comet技術的詳細介紹請參見: 《Comet技術詳解:基於HTTP長鏈接的Web端實時通訊技術》 《WEB端即時通信:HTTP長鏈接、長輪詢(long polling)詳解》 《WEB端即時通信:不用WebSocket也同樣能搞定消息的即時性》 《開源Comet服務器iComet:支持百萬併發的Web端即時通信方案》算法

有關WebSocket的詳細介紹請參見: 《WebSocket詳解(一):初步認識WebSocket技術》 《WebSocket詳解(二):技術原理、代碼演示和應用案例》 《WebSocket詳解(三):深刻WebSocket通訊協議細節》 《Socket.IO介紹:支持WebSocket、用於WEB端的即時通信的框架》 《socket.io和websocket 之間是什麼關係?有什麼區別?》數據庫

有關SSE的詳細介紹文章請參見: 《SSE技術詳解:一種全新的HTML5服務器推送事件技術》編程

更多WEB端即時通信文章請見: http://www.52im.net/forum.php?mod=collection&action=view&ctid=15 概述瀏覽器

本文將介紹如何在現有的技術基礎上選擇合適的方案開發一個「服務器推」(Comet技術)的應用,最優的方案仍是取決於應用需求的自己。相對於傳統的 Web 應用, 開發 Comet 應用具備必定的挑戰性。

在WebSocket技術沒有徹底解決瀏覽器兼容問題前,「服務器推」(Comet技術)存在普遍的應用需求,需求推進技術的發展,Comet 技術在Web端即時通信的方案裏幾乎不可或缺。 「服務器推」(Comet技術)的應用範圍

傳統模式的 Web 系統以客戶端發出請求、服務器端響應的方式工做。這種方式並不能知足不少現實應用的需求,譬如:

監控系統:後臺硬件熱插拔、LED、溫度、電壓發生變化; 即時通訊系統:其它用戶登陸、發送信息; 即時報價系統:後臺數據庫內容發生變化。

這些應用都須要服務器能實時地將更新的信息傳送到客戶端,而無須客戶端發出請求。「服務器推」技術在現實應用中有一些解決方案,本文將這些解決方案分爲兩類:一類須要在瀏覽器端安裝插件,基於套接口傳送信息,或是使用 RMI、CORBA 進行遠程調用;而另外一類則無須瀏覽器安裝任何插件、基於 HTTP 長鏈接。

將「服務器推」應用在 Web 程序中,首先考慮的是如何在功能有限的瀏覽器端接收、處理信息:

客戶端如何接收、處理信息,是否須要使用套接口或是使用遠程調用。客戶端呈現給用戶的是 HTML 頁面仍是 Java applet 或 Flash 窗口。若是使用套接口和遠程調用,怎麼和 JavaScript 結合修改 HTML 的顯示。 客戶與服務器端通訊的信息格式,採起怎樣的出錯處理機制。 客戶端是否須要支持不一樣類型的瀏覽器如 IE、Firefox,是否須要同時支持 Windows 和 Linux 平臺。

來看看更傳統的基於客戶端套接口的「服務器推」技術

1Flash XMLSocket

若是 Web 應用的用戶接受應用只有在安裝了 Flash 播放器才能正常運行, 那麼使用 Flash 的 XMLSocket 也是一個可行的方案。

這種方案實現的基礎是:

Flash 提供了 XMLSocket 類。 JavaScript 和 Flash 的緊密結合:在 JavaScript 能夠直接調用 Flash 程序提供的接口。

具體實現方法:在 HTML 頁面中內嵌入一個使用了 XMLSocket 類的 Flash 程序。JavaScript 經過調用此 Flash 程序提供的套接口接口與服務器端的套接口進行通訊。JavaScript 在收到服務器端以 XML 格式傳送的信息後能夠很容易地控制 HTML 頁面的內容顯示。

關於如何去構建充當了 JavaScript 與 Flash XMLSocket 橋樑的 Flash 程序,以及如何在 JavaScript 裏調用 Flash 提供的接口,咱們能夠參考 AFLAX(Asynchronous Flash and XML)項目提供的 Socket Demo 以及 SocketJS(請參見 參考資源)。

Javascript 與 Flash 的緊密結合,極大加強了客戶端的處理能力。從 Flash 播放器 V7.0.19 開始,已經取消了 XMLSocket 的端口必須大於 1023 的限制。Linux 平臺也支持 Flash XMLSocket 方案。但此方案的缺點在於:

客戶端必須安裝 Flash 播放器; 由於 XMLSocket 沒有 HTTP 隧道功能,XMLSocket 類不能自動穿過防火牆; 由於是使用套接口,須要設置一個通訊端口,防火牆、代理服務器也可能對非 HTTP 通道端口進行限制。

不過這種方案在一些網絡聊天室,網絡互動遊戲中已獲得普遍使用。

2Java Applet 套接口

在客戶端使用 Java Applet,經過 java.net.Socket 或 java.net.DatagramSocket 或 java.net.MulticastSocket 創建與服務器端的套接口鏈接,從而實現「服務器推」。

這種方案最大的不足在於 Java applet 在收到服務器端返回的信息後,沒法經過 JavaScript 去更新 HTML 頁面的內容。 基於 HTTP 長鏈接的「服務器推」技術:Comet技術

1Comet 簡介

瀏覽器做爲 Web 應用的前臺,自身的處理功能比較有限。瀏覽器的發展須要客戶端升級軟件,同時因爲客戶端瀏覽器軟件的多樣性,在某種意義上,也影響了瀏覽器新技術的推廣。在 Web 應用中,瀏覽器的主要工做是發送請求、解析服務器返回的信息以不一樣的風格顯示。AJAX 是瀏覽器技術發展的成果,經過在瀏覽器端發送異步請求,提升了單用戶操做的響應性。但 Web 本質上是一個多用戶的系統,對任何用戶來講,能夠認爲服務器是另一個用戶。現有 AJAX 技術的發展並不能解決在一個多用戶的 Web 應用中,將更新的信息實時傳送給客戶端,從而用戶可能在「過期」的信息下進行操做。而 AJAX 的應用又使後臺數據更新更加頻繁成爲可能。

圖 1. 傳統的 Web 應用模型與基於 AJAX 的模型之比較: Comet技術詳解:基於HTTP長鏈接的Web端實時通訊技術_1.jpg

「服務器推」是一種很早就存在的技術,之前在實現上主要是經過客戶端的套接口,或是服務器端的遠程調用。由於瀏覽器技術的發展比較緩慢,沒有爲「服務器推」的實現提供很好的支持,在純瀏覽器的應用中很難有一個完善的方案去實現「服務器推」並用於商業程序。最近幾年,由於 AJAX 技術的普及,以及把 IFrame 嵌在「htmlfile「的 ActiveX 組件中能夠解決 IE 的加載顯示問題,一些受歡迎的應用如 meebo,gmail+gtalk 在實現中使用了這些新技術;同時「服務器推」在現實應用中確實存在不少需求。由於這些緣由,基於純瀏覽器的「服務器推」技術開始受到較多關注,Alex Russell(Dojo Toolkit 的項目 Lead)稱這種基於 HTTP 長鏈接、無須在瀏覽器端安裝插件的「服務器推」技術爲「Comet」。目前已經出現了一些成熟的 Comet 應用以及各類開源框架;一些 Web 服務器如 Jetty 也在爲支持大量併發的長鏈接進行了不少改進。關於 Comet 技術最新的發展情況請參考關於 Comet 的 wiki。

下面將介紹兩種 Comet 應用的實現模型。

2Comet技術實現模型1:基於 AJAX 的長輪詢(long-polling)方式

如 圖 1 所示,AJAX 的出現使得 JavaScript 能夠調用 XMLHttpRequest 對象發出 HTTP 請求,JavaScript 響應處理函數根據服務器返回的信息對 HTML 頁面的顯示進行更新。使用 AJAX 實現「服務器推」與傳統的 AJAX 應用不一樣之處在於:

服務器端會阻塞請求直到有數據傳遞或超時才返回。 客戶端 JavaScript 響應處理函數會在處理完服務器返回的信息後,再次發出請求,從新創建鏈接。 當客戶端處理接收的數據、從新創建鏈接時,服務器端可能有新的數據到達;這些信息會被服務器端保存直到客戶端從新創建鏈接,客戶端會一次把當前服務器端全部的信息取回。

圖 2. 基於長輪詢的服務器推模型: Comet技術詳解:基於HTTP長鏈接的Web端實時通訊技術_2.jpg

一些應用及示例如 「Meebo」, 「Pushlet Chat」 都採用了這種長輪詢的方式。相對於「輪詢」(poll),這種長輪詢方式也能夠稱爲「拉」(pull)。由於這種方案基於 AJAX,具備如下一些優勢:請求異步發出;無須安裝插件;IE、Mozilla FireFox 都支持 AJAX。

在這種長輪詢方式下,客戶端是在 XMLHttpRequest 的 readystate 爲 4(即數據傳輸結束)時調用回調函數,進行信息處理。當 readystate 爲 4 時,數據傳輸結束,鏈接已經關閉。Mozilla Firefox 提供了對 Streaming AJAX 的支持, 即 readystate 爲 3 時(數據仍在傳輸中),客戶端能夠讀取數據,從而無須關閉鏈接,就能讀取處理服務器端返回的信息。IE 在 readystate 爲 3 時,不能讀取服務器返回的數據,目前 IE 不支持基於 Streaming AJAX。

3Comet技術實現模型2:基於 Iframe 及 htmlfile 的流(streaming)方式

iframe 是很早就存在的一種 HTML 標記, 經過在 HTML 頁面裏嵌入一個隱蔵幀,而後將這個隱蔵幀的 SRC 屬性設爲對一個長鏈接的請求,服務器端就能源源不斷地往客戶端輸入數據。

圖 3. 基於流方式的服務器推模型: Comet技術詳解:基於HTTP長鏈接的Web端實時通訊技術_3.jpg

上節提到的 AJAX 方案是在 JavaScript 裏處理 XMLHttpRequest 從服務器取回的數據,而後 Javascript 能夠很方便的去控制 HTML 頁面的顯示。一樣的思路用在 iframe 方案的客戶端,iframe 服務器端並不返回直接顯示在頁面的數據,而是返回對客戶端 Javascript 函數的調用,如「<script type="text/javascript">js_func(「data from server 」)</script>」。服務器端將返回的數據做爲客戶端 JavaScript 函數的參數傳遞;客戶端瀏覽器的 Javascript 引擎在收到服務器返回的 JavaScript 調用時就會去執行代碼。

從 圖 3 能夠看到,每次數據傳送不會關閉鏈接,鏈接只會在通訊出現錯誤時,或是鏈接重建時關閉(一些防火牆常被設置爲丟棄過長的鏈接, 服務器端能夠設置一個超時時間, 超時後通知客戶端從新創建鏈接,並關閉原來的鏈接)。

使用 iframe 請求一個長鏈接有一個很明顯的不足之處:IE、Morzilla Firefox 下端的進度欄都會顯示加載沒有完成,並且 IE 上方的圖標會不停的轉動,表示加載正在進行。Google 的天才們使用一個稱爲「htmlfile」的 ActiveX 解決了在 IE 中的加載顯示問題,並將這種方法用到了 gmail+gtalk 產品中。Alex Russell 在 「What else is burried down in the depth's of Google's amazing JavaScript?」文章中介紹了這種方法。Zeitoun 網站提供的 comet-iframe.tar.gz,封裝了一個基於 iframe 和 htmlfile 的 JavaScript comet 對象,支持 IE、Mozilla Firefox 瀏覽器,能夠做爲參考。 使用 Comet 模型開發本身的應用

上面介紹了兩種基於 HTTP 長鏈接的「服務器推」架構,更多描述了客戶端處理長鏈接的技術。對於一個實際的應用而言,系統的穩定性和性能是很是重要的。將 HTTP 長鏈接用於實際應用,不少細節須要考慮。

1不要在同一客戶端同時使用超過兩個的 HTTP 長鏈接

咱們使用 IE 下載文件時會有這樣的體驗,從同一個 Web 服務器下載文件,最多隻能有兩個文件同時被下載。第三個文件的下載會被阻塞,直到前面下載的文件下載完畢。這是由於 HTTP 1.1 規範中規定,客戶端不該該與服務器端創建超過兩個的 HTTP 鏈接, 新的鏈接會被阻塞。而 IE 在實現中嚴格遵照了這種規定。

HTTP 1.1 對兩個長鏈接的限制,會對使用了長鏈接的 Web 應用帶來以下現象:在客戶端若是打開超過兩個的 IE 窗口去訪問同一個使用了長鏈接的 Web 服務器,第三個 IE 窗口的 HTTP 請求被前兩個窗口的長鏈接阻塞。

因此在開發長鏈接的應用時, 必須注意在使用了多個 frame 的頁面中,不要爲每一個 frame 的頁面都創建一個 HTTP 長鏈接,這樣會阻塞其它的 HTTP 請求,在設計上考慮讓多個 frame 的更新共用一個長鏈接。

2服務器端的性能和可擴展性

通常 Web 服務器會爲每一個鏈接建立一個線程,若是在大型的商業應用中使用 Comet,服務器端須要維護大量併發的長鏈接。在這種應用背景下,服務器端須要考慮負載均衡和集羣技術;或是在服務器端爲長鏈接做一些改進。

應用和技術的發展老是帶來新的需求,從而推進新技術的發展。HTTP 1.1 與 1.0 規範有一個很大的不一樣:1.0 規範下服務器在處理完每一個 Get/Post 請求後會關閉套接口鏈接; 而 1.1 規範下服務器會保持這個鏈接,在處理兩個請求的間隔時間裏,這個鏈接處於空閒狀態。 Java 1.4 引入了支持異步 IO 的 java.nio 包。當鏈接處於空閒時,爲這個鏈接分配的線程資源會返還到線程池,能夠供新的鏈接使用;當原來處於空閒的鏈接的客戶發出新的請求,會從線程池裏分配一個線程資源處理這個請求。 這種技術在鏈接處於空閒的機率較高、併發鏈接數目不少的場景下對於下降服務器的資源負載很是有效。

可是 AJAX 的應用使請求的出現變得頻繁,而 Comet 則會長時間佔用一個鏈接,上述的服務器模型在新的應用背景下會變得很是低效,線程池裏有限的線程數甚至可能會阻塞新的鏈接。Jetty 6 Web 服務器針對 AJAX、Comet 應用的特色進行了不少創新的改進,請參考文章「AJAX,Comet and Jetty」。

3控制信息與數據信息使用不一樣的 HTTP 鏈接

使用長鏈接時,存在一個很常見的場景:客戶端網頁須要關閉,而服務器端還處在讀取數據的堵塞狀態,客戶端須要及時通知服務器端關閉數據鏈接。服務器在收到關閉請求後首先要從讀取數據的阻塞狀態喚醒,而後釋放爲這個客戶端分配的資源,再關閉鏈接。

因此在設計上,咱們須要使客戶端的控制請求和數據請求使用不一樣的 HTTP 鏈接,才能使控制請求不會被阻塞。

在實現上,若是是基於 iframe 流方式的長鏈接,客戶端頁面須要使用兩個 iframe,一個是控制幀,用於往服務器端發送控制請求,控制請求能很快收到響應,不會被堵塞;一個是顯示幀,用於往服務器端發送長鏈接請求。若是是基於 AJAX 的長輪詢方式,客戶端能夠異步地發出一個 XMLHttpRequest 請求,通知服務器端關閉數據鏈接。

4在客戶和服務器之間保持「心跳」信息

在瀏覽器與服務器之間維持一個長鏈接會爲通訊帶來一些不肯定性:由於數據傳輸是隨機的,客戶端不知道什麼時候服務器纔有數據傳送。服務器端須要確保當客戶端再也不工做時,釋放爲這個客戶端分配的資源,防止內存泄漏。所以須要一種機制使雙方知道你們都在正常運行。在實現上:

服務器端在阻塞讀時會設置一個時限,超時後阻塞讀調用會返回,同時發給客戶端沒有新數據到達的心跳信息。此時若是客戶端已經關閉,服務器往通道寫數據會出現異常,服務器端就會及時釋放爲這個客戶端分配的資源。 若是客戶端使用的是基於 AJAX 的長輪詢方式;服務器端返回數據、關閉鏈接後,通過某個時限沒有收到客戶端的再次請求,會認爲客戶端不能正常工做,會釋放爲這個客戶端分配、維護的資源。 當服務器處理信息出現異常狀況,須要發送錯誤信息通知客戶端,同時釋放資源、關閉鏈接。

Comet開源工程

Pushlet: Pushlet 是一個開源的 Comet 框架,在設計上有不少值得借鑑的地方,對於開發輕量級的 Comet 應用頗有參考價值。使用了觀察者模型。瀏覽器端提供了基於 AJAX 和 iframe 的 JavaScript 庫,服務器端使用 Java Servlet。地址是:http://www.pushlets.com/?cm_mc_uid=72410021035714633836363&cm_mc_sid_50200000=1464236784

iComet: iComet 是一個使用 C++ 語言開發的支持百萬併發鏈接的 comet/push 服務器, 支持百萬級併發鏈接, 內存佔用少, 性能優越. 可用於移動 App 的 Push Server(消息推送服務器), 或者用於 Web Push(Web 服務器推). 用於 Web Push 時, 支持的瀏覽器和操做系統平臺包括: Safari(iOS, Mac), Firefox/Chrome(Windows, Mac), IE6+。詳細請參見:http://www.52im.net/thread-330-1-1.html 全站即時通信技術資料分類

[1] 網絡編程基礎資料: 《TCP/IP詳解 - 第11章·UDP:用戶數據報協議》 《TCP/IP詳解 - 第17章·TCP:傳輸控制協議》 《TCP/IP詳解 - 第18章·TCP鏈接的創建與終止》 《TCP/IP詳解 - 第21章·TCP的超時與重傳》 《理論經典:TCP協議的3次握手與4次揮手過程詳解》 《理論聯繫實際:Wireshark抓包分析TCP 3次握手、4次揮手過程》 《計算機網絡通信協議關係圖(中文珍藏版)》 《NAT詳解:基本原理、穿越技術(P2P打洞)、端口老化等》 《UDP中一個包的大小最大能多大?》 《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》 《NIO框架入門(三):iOS與MINA二、Netty4的跨平臺UDP雙向通訊實戰》 《NIO框架入門(四):Android與MINA二、Netty4的跨平臺UDP雙向通訊實戰》

更多同類文章 ……

[2] 有關IM/推送的通訊格式、協議的選擇: 《爲何QQ用的是UDP協議而不是TCP協議?》 《移動端即時通信協議選擇:UDP仍是TCP?》 《如何選擇即時通信應用的數據傳輸格式》 《強列建議將Protobuf做爲你的即時通信應用數據傳輸格式》 《移動端IM開發須要面對的技術問題(含通訊協議選擇)》 《簡述移動端IM開發的那些坑:架構設計、通訊協議和客戶端》 《理論聯繫實際:一套典型的IM通訊協議設計詳解》 《58到家實時消息系統的協議設計等技術實踐分享》

更多同類文章 ……

[3] 有關IM/推送的心跳保活處理: 《Android進程保活詳解:一篇文章解決你的全部疑問》 《Android端消息推送總結:實現原理、心跳保活、遇到的問題等》 《爲什麼基於TCP協議的移動端IM仍然須要心跳保活機制?》 《微信團隊原創分享:Android版微信後臺保活實戰分享(進程保活篇)》 《微信團隊原創分享:Android版微信後臺保活實戰分享(網絡保活篇)》 《移動端IM實踐:實現Android版微信的智能心跳機制》 《移動端IM實踐:WhatsApp、Line、微信的心跳策略分析》

更多同類文章 ……

[4] 有關WEB端即時通信開發: 《新手入門貼:史上最全Web端即時通信技術原理詳解》 《Web端即時通信技術盤點:短輪詢、Comet、Websocket、SSE》 《SSE技術詳解:一種全新的HTML5服務器推送事件技術》 《Comet技術詳解:基於HTTP長鏈接的Web端實時通訊技術》 《WebSocket詳解(一):初步認識WebSocket技術》 《socket.io實現消息推送的一點實踐及思路》

更多同類文章 ……

[5] 有關IM架構設計: 《淺談IM系統的架構設計》 《簡述移動端IM開發的那些坑:架構設計、通訊協議和客戶端》 《一套原創分佈式即時通信(IM)系統理論架構方案》 《從零到卓越:京東客服即時通信系統的技術架構演進歷程》 《蘑菇街即時通信/IM服務器開發之架構選擇》 《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》 《微信技術總監談架構:微信之道——大道至簡(演講全文)》 《如何解讀《微信技術總監談架構:微信之道——大道至簡》》 《快速裂變:見證微信強大後臺架構從0到1的演進歷程(一)》 《17年的實踐:騰訊海量產品的技術方法論》

更多同類文章 ……

[6] 有關IM安全的文章: 《即時通信安全篇(一):正確地理解和使用Android端加密算法》 《即時通信安全篇(二):探討組合加密算法在IM中的應用》 《即時通信安全篇(三):經常使用加解密算法與通信安全講解》 《即時通信安全篇(四):實例分析Android中密鑰硬編碼的風險》 《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》 《理論聯繫實際:一套典型的IM通訊協議設計詳解(含安全層設計)》 《微信新一代通訊安全解決方案:基於TLS1.3的MMTLS詳解》 《來自阿里OpenIM:打造安全可靠即時通信服務的技術實踐分享》

更多同類文章 ……

[7] 有關實時音視頻開發: 《即時通信音視頻開發(一):視頻編解碼之理論概述》 《即時通信音視頻開發(二):視頻編解碼之數字視頻介紹》 《即時通信音視頻開發(三):視頻編解碼之編碼基礎》 《即時通信音視頻開發(四):視頻編解碼之預測技術介紹》 《即時通信音視頻開發(五):認識主流視頻編碼技術H.264》 《即時通信音視頻開發(六):如何開始音頻編解碼技術的學習》 《即時通信音視頻開發(七):音頻基礎及編碼原理入門》 《即時通信音視頻開發(八):常見的實時語音通信編碼標準》 《即時通信音視頻開發(九):實時語音通信的迴音及迴音消除概述》 《即時通信音視頻開發(十):實時語音通信的迴音消除技術詳解》 《即時通信音視頻開發(十一):實時語音通信丟包補償技術詳解》 《即時通信音視頻開發(十二):多人實時音視頻聊天架構探討》 《即時通信音視頻開發(十三):實時視頻編碼H.264的特色與優點》 《即時通信音視頻開發(十四):實時音視頻數據傳輸協議介紹》 《即時通信音視頻開發(十五):聊聊P2P與實時音視頻的應用狀況》 《即時通信音視頻開發(十六):移動端實時音視頻開發的幾個建議》 《即時通信音視頻開發(十七):視頻編碼H.26四、V8的前世此生》 《簡述開源實時音視頻技術WebRTC的優缺點》 《良心分享:WebRTC 零基礎開發者教程(中文)》

更多同類文章 ……

[8] IM開發綜合文章: 《移動端IM開發須要面對的技術問題》 《開發IM是本身設計協議用字節流好仍是字符流好?》 《請問有人知道語音留言聊天的主流實現方式嗎?》 《IM系統中如何保證消息的可靠投遞(即QoS機制)》 《談談移動端 IM 開發中登陸請求的優化》 《徹底自已開發的IM該如何設計「失敗重試」機制?》 《微信對網絡影響的技術試驗及分析(論文全文)》 《即時通信系統的原理、技術和應用(技術論文)》 《開源IM工程「蘑菇街TeamTalk」的現狀:一場虎頭蛇尾的開源秀》

更多同類文章 ……

[9] 開源移動端IM技術框架資料: 《開源移動端IM技術框架MobileIMSDK:快速入門》 《開源移動端IM技術框架MobileIMSDK:常見問題解答》 《開源移動端IM技術框架MobileIMSDK:壓力測試報告》 《開源移動端IM技術框架MobileIMSDK:Android版Demo使用幫助》 《開源移動端IM技術框架MobileIMSDK:Java版Demo使用幫助》 《開源移動端IM技術框架MobileIMSDK:iOS版Demo使用幫助》 《開源移動端IM技術框架MobileIMSDK:Android客戶端開發指南》 《開源移動端IM技術框架MobileIMSDK:Java客戶端開發指南》 《開源移動端IM技術框架MobileIMSDK:iOS客戶端開發指南》 《開源移動端IM技術框架MobileIMSDK:Server端開發指南》

更多同類文章 ……

[10] 有關推送技術的文章: 《iOS的推送服務APNs詳解:設計思路、技術原理及缺陷等》 《Android端消息推送總結:實現原理、心跳保活、遇到的問題等》 《掃盲貼:認識MQTT通訊協議》 《一個基於MQTT通訊協議的完整Android推送Demo》 《求教android消息推送:GCM、XMPP、MQTT三種方案的優劣》 《移動端實時消息推送技術淺析》 《掃盲貼:淺談iOS和Android後臺實時消息推送的原理和區別》 《絕對乾貨:基於Netty實現海量接入的推送服務技術要點》 《移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)》 《爲什麼微信、QQ這樣的IM工具不使用GCM服務推送消息?》

更多同類文章 ……

[11] 更多即時通信技術好文分類: http://www.52im.net/forum.php?mod=collection&op=all 即時通信網 - 即時通信開發者社區! 來源:即時通信網 - 即時通信開發者社區!

相關文章
相關標籤/搜索