Jack Jiang

          我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
          posts - 494, comments - 13, trackbacks - 0, articles - 1

          學習交流

          - 即時通訊開發交流群: 215891622 [推薦]

          一、前言

          IM發展至今,已是非常重要的互聯網應用形態之一,尤其移動互聯網時代,它正以無與論比的優勢降低了溝通成本和溝通代價,對各種應用形態產生了深遠影響。

          做為IM開發者或即將成為IM開發者的技術人員,IM的價值和重要性不言自明。但從技術實現來說,IM系統的開發(尤其是移動端IM)還是存在許多技術難點和坑點的。也正因如此,優質的IM開發相關的資料、實踐性成果,對于沒有太多技術儲備的新手來說,尤其難以獲得。

          本文將以新手的視角引導你閱讀相關文章,以便為從零開發一個移動端IM做好方方面面的知識準備:包括但不限于網絡編程基礎、通信協議的選型、IM的架構設計等等。文筆有限,如有不妥之處還請批評指正,希望對你有用。(本文同步發布于:http://www.52im.net/thread-464-1-1.html

          二、讀完本文的收獲 

          [1] 您將獲得

          本文將假設你是毫無技術準備的新手,引導你通過一篇篇精選的文章,了解如何開始從零開發一個移動端IM所需要的各種技術、資料和實踐性代碼。

          [2] 您無法獲得

          鑒于IM技術的復雜性,IM開發相關的技術不是一篇文章所能展現的了,限于篇幅原因本文將不包含任何實踐性代碼、也盡量不對某項技術作深入的展開,相關的實踐性代碼、資料、技術詳解等請依據本文作者準備的文章逐個深入閱讀和學習,而這也恰恰是本文想達到的目的。

          三、題外話

          隨著近兩年IM云服務的發展,很多團隊基于種種原因,直接選擇了短平快的云IM接入APP中。然而,考慮到云IM無論從商業模式還是運營模式上,還需經過多年的沉淀,才可能真正實現客戶與服務商的運營和服務良性循環的雙贏局面。因則,如何選擇云IM服務商,這就是個頭疼的問題了,不過這不是本文將要討論的重點,如果需要,你也可以加入本文提到的討論交流群,與大家一起交流群: 215891622。 

          好了,以下是正文內容。

          四、網絡編程理論準備

          [1] UDP、TCP協議理論

          我們都知道,IM系統的業務本質就是客戶端與客戶端進行消息的實時傳遞,而技術基礎就是基于Socket連接的實時數據讀寫,那么基本的網絡編程理論基礎是作為新手的你必須掌握的知識點。當然,作為IM開發來說,基礎的網絡理論就夠用了,也沒有必要像網絡工程師一樣精通所謂的OSI七層參考模型。

          如果你還不知道什么是UDP、TCP協議,請閱讀以下文章:


          這幾篇文章有助于對UDP、TCP協議建立基本的認識,當然如果時間允許,能全書閱讀網絡編程理論經典《TCP/IP詳解 卷1:協議》則再好不過了。另外,UDP、TCP作為基礎計算機數據傳輸協議,在其之上衍生了很多應用層協議,相關的協議族關系圖可以在此文中找到:《計算機網絡通訊協議關系圖(中文珍藏版)》,可作為您日常的備查手冊使用。

          [2] 深入理解TCP傳輸協議

          透徹理解TCP傳輸協議的連接和斷開過程非常有助于您日后IM算法的優化和實現,這個過程被形象的總結為“3次握手與4次揮手”。

          以下文章有助于您深入理解之:

           

          [3] 深入理解UDP傳輸協議

          相比TCP協議,UDP數據傳輸協議就顯得非常輕量和易于理解,UDP通常被用于需要快速響應的數據傳輸場景下,對應于IM中的應用形態有:P2P通信、實時音視頻等。另外,通常的IM都會被應用于互聯網上(而非局域網),那么了解所謂的NAT路由技術原理等,也將有助于您對P2P打洞、UDP端口老化等概念有一個清楚的認知。

          以下文章有助于您在接下來開發IM的實際應用中提供一定的實踐依據:


          當然,現時的網絡編程,為了解決高性能問題,有很多成型的Socket應用層模式存在,比如:NIO、AIO等,文章《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》簡單介紹了傳統的阻塞式IO、NIO,并著重介紹了最新的AIO技術,如有時間您很有必要予以了解。(更多同類文章:點此進入…

          五、網絡編程基礎實踐

          如果你認真讀完了上一層的文章,是時候寫些代碼,來理論聯系實際理解Socket通信的原理和實踐了。

          有關TCP的Socket通信Demo文章和代碼:


          當然,以是只是隨手找的Demo代碼,網絡上有關TCP數據通信的演示性代碼很容易找到,在此就不過多舉例了。

          本文作者專門編寫的有關跨移動端平臺的UDP Socket通信Demo:

          六、IM到底該用UDP還是TCP協議?

          好了,上面的網絡編程基礎掌握后,就要開始為你的IM進行傳輸協議選型了。說到IM該用UDP還是TCP作為傳輸協議,這是個頗有爭議的話題,各大社區每當此問題的出現必定是大片的不同聲音。

          當然,UDP和TCP各有各的應用場景,作為IM來說,早期的IM因為服務端資源(服務器硬件、網絡帶寬等)比較昂貴且沒有更好的辦法來分擔性能負載,所以很多時候會考慮使用UDP,這其中主要是早期的QQ為代表。

          時至今日,TCP的服務端負載已經有了很好的解決方案,加之服務器資源成本的下降,目前很多IM、消息推送解決方案也都在使用TCP作為傳輸層協議。不過,UDP也并未排除在IM、消息推送的解決方案之外,比如:弱網絡通信(包括跨國的高延遲網絡環境)、物聯網通信、IM中的實時音視頻通信等等場景下,UDP依然是首選項。

          以下文章或許有助于您對傳輸層協議的選型:


          當然,關于IM到底該選擇UDP還是TCP,這是個仁者見仁智者見智的問題,沒有必要過于糾結,請從您的IM整體應用場景、開發代價、部署和運營成本等方面綜合考慮,相信能找到你要的答案。

          七、IM的數據通信格式選型

          IM應用開發的前期技術選型時,關于數據通信格式的選擇,在同行的眼里,是同樣是個極富爭議話題。

          精略分析一下,究其原因,大概在于以下幾點:

          • 可選擇的協議或封裝格式多種多樣:
            可選擇的余地大:XMPP、Protobuf、JSON、私有2進制、MQTT、定格化XML、Plain text等等;
          • 同一種格式并不能適用于大多數的場景:
            不同的場景有同的考慮而協議的選擇往往跟這掛鉤在一起的,如:移動端IM或推送用XMPP協議時,多數情況下都會被噴;
          • 開發者對所選格式有各自的偏好:
            有的人或團隊對某種或某幾種格式有不一樣的經驗和技術積累,也促成了他們對某種或某幾種協議的偏好。


          該選什么樣的數據通信格式,同樣是跟你的應用場景和使用的架構方案相關聯。不過,目前以作者掌握的信息看來,作為需要運行在移動設備的IM,幾乎目前所有主流討論里都不建議使用XMPP協議,具體原因就不在此展開了,下面推薦的文章里會詳細為你解答原因。

          以下文章會對你的IM的數據通信格式選型有所幫助:


          (更多同類文章:點此查看…

          八、移動端IM的心跳保活和后臺消息推送

          [1] 為什么需要心跳保活?

          由于移動網絡的復雜性,心跳保活對于移動端IM來說顯的尤為重要,加之手機省電、省流量策略的設計,如何實現心跳保活則也非常重要,文章《基于TCP協議的移動端IM仍然需要心跳保活機制》或許可以解答你的疑問。

          [2] iOS端的后臺消息推送

          因為iOS平臺的特殊性,iOS應用一旦退到后臺,應用本身是無法用代碼來實現網絡保活的,也就無法自行實現后臺消息推送了。

          以下文章將有助于你理解iOS平臺的后臺消息推送原理:

           

          [3] Android端的心跳保活和后臺消息推送

          鑒于Android平臺眾所周之的分化和互不兼容問題,Android端IM在處理心跳保活和后臺消息推送時,遇到了不少的麻煩。而且,由于Android應用的生命周期管理是由系統控制,因而如何保證您的IM所在進程或后臺服務不被系統殺死,是實現心跳保活和后臺消息推送的實現基礎。

          以下文章可為你的Android端IM的心跳保活和后臺推送方案的設計提供參考:


          (更多同類文章:此進入…

          九、移動端IM系統的架構設計

          IM其本質是一套消息發送與投遞系統,或者說是一套網絡通信系統,歸根結底就是兩個詞:存儲與轉發。但一個成熟的移動端IM系統要想正常運轉,涉及的內容則遠不止這些,而最考驗技術功底的就是服務端架構的設計與實現。

          沒有過IM系統開發經驗的人,可能對以上觀點嗤之以鼻,在此借用TeamTalk的設計者的一段話:“IM服務器開發,從功能抽象的角度看可能非常簡單,可以認為是管理大量的客戶端連接和在不同的客戶端之間傳遞消息,但具體到實現細節就比較復雜了。打個不恰當的比喻,OS的功能抽象也非常簡單,無非是進程間的調度和硬件資源的管理,但要是自己去實現一個,一般人也就只能呵呵了。”

          我們以一個典型方案為例,首先來提煉一下一個IM系統的主要需求:包括賬號、關系鏈、在線狀態顯示、消息交互(文本、圖片、語音)、實時視頻電話......。

          要處理好上述需求,我們通常需要從以下方面進行考量從而設計出合適的架構:

          • 如果采用可靠傳輸協議TCP,需要考慮到負載問題:短連接實現賬號、關系鏈相關業務,長連接實現上線、信息推送;
          • 后臺架構的靈活性、可擴展性:支持分布式部署——把網絡層、業務邏輯層、數據層分離,網絡層和業務層支持負載均衡策略、數據層支持分布式存儲;
          • 客戶端SDK的易用性:把網絡層、數據層分離、業務邏輯層分離。


          另外,一個典型的IM系統架構設計,還有以下性能方面的熱點問題需要設計者重點關注:

          • 編碼角度:采用高效的網絡模型,線程模型,I/O處理模型,合理的數據庫設計和操作語句的優化;
          • 垂直擴展:通過提高單服務器的硬件資源或者網絡資源來提高性能;
          • 水平擴展:通過合理的架構設計和運維方面的負載均衡策略將負載分擔,有效提高性能;后期甚至可以考慮加入數據緩存層,突破IO瓶頸;
          • 系統的高可用性:防止單點故障;
          • 在架構設計時做到業務處理和數據的分離,從而依賴分布式的部署使得在單點故障時能保證系統可用。
          • 對于關鍵獨立節點可以采用雙機熱備技術進行切換。
          • 數據庫數據的安全性可以通過磁盤陣列的冗余配置和主備數據庫來解決。


          鑒于篇幅有限,架構設計方面的內容本文就不深入展開了。

          以下文章將為你的移動端IM的架構設計帶來一定的參考意義:


          (更多同類文章: 點此進入…

          十、移動端IM的通信安全

          IM(尤其移動端IM)的安全性一直是開發者需要優先考慮的基礎問題,如何正確地理解和使用加密技術則顯的尤其重要。IM系統大都采用C/S、B/S、P2P等技術來實現即時通信的功能,軟件編制沒有統一的標準,使得IM系統本身存有多種安全漏洞,加上用戶缺乏安全意識,導致在使用即時通信系統時出現各種安全問題。

          當今的計算機密碼學的主要作用有:加密( Encryption)、認證(Authentication),鑒定(Identification) 。

          加密:防止壞人獲取你的數據。 
          認證:防止壞人修改了你的數據而你卻并沒有發現。 
          鑒權:防止壞人假冒你的身份。

          這些基本概念和加密算法原理就不在此展開敘述了。

          以下文章或許有助于您設計出安全的移動端IM系統:


          (更多同類文章:點此進入…

          十一、有關IM中的實時音視頻技術

          IM應用中的實時音視頻技術,幾乎是IM開發中的最后一道高墻。原因在于:實時音視頻技術 = 音視頻處理技術 + 網絡傳輸技術 的橫向技術應用集合體,而公共互聯網不是為了實時通信設計的。實時音視頻技術上的實現內容主要包括:音視頻的采集、編碼、網絡傳輸、解碼、播放等環節。這么多項并不簡單的技術應用,如果把握不當,將會在在實際開發過程中遇到一個又一個的坑。

          以下文章有助于您從零理解IM的實時音視頻開發的方方面面:


          (更多同類文章: 點此進入…

          十二、移動端IM開發的其它熱點問題

          移動端IM開發中還會遇到上述內容未提及的內容,以下文章或許您用的上:
          移動端IM開發需要面對的技術問題
          開發IM是自己設計協議用字節流好還是字符流好?
          請問有人知道語音留言聊天的主流實現方式嗎?
          IM系統中如何保證消息的可靠投遞(即QoS機制)
          談談移動端 IM 開發中登錄請求的優化
          完全自已開發的IM該如何設計“失敗重試”機制?
          微信對網絡影響的技術試驗及分析(論文全文)
          即時通訊系統的原理、技術和應用(技術論文)
          開源IM工程“蘑菇街TeamTalk”的現狀:一場有始無終的開源秀
          >> 更多同類文章 …… 

          附錄:其它即時通訊文章

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

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

          [3] 更多即時通訊技術好文分類:
          http://www.52im.net/forum.php?mod=collection&op=all

          (本文同步發布于:http://www.52im.net/thread-464-1-1.html

          作者:Jack Jiang (點擊作者姓名進入Github) 
          出處:http://www.52im.net/space-uid-1.html 
          交流:歡迎加入即時通訊開發交流群 215891622 
          討論:http://www.52im.net/ 
          Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。



          作者:Jack Jiang (點擊作者姓名進入Github)
          出處:http://www.52im.net/space-uid-1.html
          交流:歡迎加入即時通訊開發交流群 215891622
          討論:http://www.52im.net/
          Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。
          本博文 歡迎轉載,轉載請注明出處(也可前往 我的52im.net 找到我)。


          只有注冊用戶登錄后才能發表評論。


          網站導航:
          博客園   IT新聞   Chat2DB   C++博客   博問  
           
          Jack Jiang的 Mail: jb2011@163.com, 聯系QQ: 413980957, 微信: hellojackjiang
          主站蜘蛛池模板: 岳普湖县| 大安市| 丁青县| 建昌县| 行唐县| 香港| 色达县| 青铜峡市| 林州市| 合肥市| 贡嘎县| 永吉县| 开封市| 简阳市| 普陀区| 蒙阴县| 陆河县| 宁波市| 阿图什市| 扎鲁特旗| 贞丰县| 咸阳市| 蓬安县| 城口县| 青田县| 郓城县| 望江县| 鞍山市| 张家川| 木兰县| 高雄县| 比如县| 永新县| 金溪县| 灵丘县| 潮安县| 昌吉市| 宜君县| 浑源县| 榆社县| 普宁市|