Jack Jiang

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

               摘要: 本文由字節跳動技術團隊楊晨曦分享,本文有修訂和改動。1、引言本文將帶你一起初步認識Thrift的序列化協議,包括Binary協議、Compact協議(類似于Protobuf)、JSON協議,希望能為你的通信協議格式選型帶來參考。  技術交流:- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM》- 開源IM框架源碼:https://github.com/JackJ...  閱讀全文

          posted @ 2023-12-28 10:52 Jack Jiang 閱讀(65) | 評論 (0)編輯 收藏

          為了更好地分類閱讀 52im.net 總計1000多篇精編文章,我將在每周三推送新的一期技術文集,本次是第29 期。

          [- 1 -] 談談移動端 IM 開發中登錄請求的優化

          [鏈接] http://www.52im.net/thread-282-1-1.html

          [摘要] 到底是“登陸”還是“登錄”?這是很多處女坐開發者糾結的問題,不過它不是本文本討倫的內容。本文將針對移動端IM的登陸功能給出相應的優化建議。


          [- 2 -] 移動端IM登錄時拉取數據如何作到省流量?

          [鏈接] http://www.52im.net/thread-787-1-1.html

          [摘要] 移動網絡時代,手機的流量是個很昂貴的資源(至少暫時是這樣)。一個典型的移動端IM在登錄后,往往要向服務器同步非常多的數據,如果處理的不好是很費流量的,那么從技術上來講,有沒有節省流量的方法呢?這就是本文要討論的話題。


          [- 3 -] 淺談移動端IM的多點登錄和消息漫游原理

          [鏈接] http://www.52im.net/thread-867-1-1.html

          [摘要] 本文將展開聊聊移動端IM“多點登陸”與“消息漫游”的原理。


          [- 4 -] 完全自已開發的IM該如何設計“失敗重試”機制?

          [鏈接] http://www.52im.net/thread-280-1-1.html

          [摘要] 如何設計好這個失敗重試的機制,使得客戶端能做好失敗重試,服務器有能夠排除這種重復消息,但是排重處理不太復雜?


          [- 5 -] 通俗易懂:基于集群的移動端IM接入層負載均衡方案分享

          [鏈接] http://www.52im.net/thread-802-1-1.html

          [摘要] 本文將以基于TCP數據傳輸協議的移動端IM為例,通過循序漸進地方式,分享如何構建一個基于分布式集群的移動端IM接入層的設計和實現。


          [- -] 微信對網絡影響的技術試驗及分析(論文全文)

          [鏈接] http://www.52im.net/thread-195-1-1.html

          [摘要] 本文來自論文《微信對網絡影響的技術試驗及分析》,文中研究了微信對現今移動網絡的影響,對于即時通訊開發人員來說,文中的某些數據和研究結果,對于實現類似的技術,有一定的參考和借鑒意義。即時通訊網(52im.net)現全文收錄之。


          [- 7 -] 即時通訊系統的原理、技術和應用(技術論文)

          [鏈接] http://www.52im.net/thread-218-1-1.html

          [摘要] 首先,介紹即時通信的概念、特點和技術原理,較為全面地剖析了實現即時通信系統涉及的關鍵技術,包括即時通信傳輸協議、相關安全技術和音/視頻編解碼技術等;其次,簡要概述了即時通信系統在我校的應用情況;最后,說明當前即時通信工具存在的問題及其發展趨勢。


          [- 8 -] 開源IM工程“蘑菇街TeamTalk”的現狀:一場有始無終的開源秀

          [鏈接] http://www.52im.net/thread-447-1-1.html

          [摘要] 本文將簡要介紹TeamTalk開源的過去和現在,為打算研究和采用TeamTalk的同行提供一定程度的參考。文中所涉及內容如有不妥,還請各位看官見諒。


          [- -]  QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)

          [鏈接] http://www.52im.net/thread-1208-1-1.html

          [摘要] 實際在生產環境下,群消息的發送都會想盡辦法進行壓縮,并開展各種改善性能的處理辦法,而不是像上述舉例里的直接擴散寫(即2000人群里,一條消息被簡單地復制為2000條一對一的消息投遞)。具體有哪些優先策略?本文或許可以帶給你一些啟發。


          [- 10 -] QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)

          [鏈接] http://www.52im.net/thread-1212-1-1.html

          [摘要] 關于壓縮圖片在諸如即時通訊應用場景下的好處,我們就不再贅述,不言自明。本篇將承接上篇《QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)》,繼續討論圖片的尺寸壓縮和常用的幾種尺寸壓縮算法。


          [- 11 -] 騰訊原創分享(一):如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率

          [鏈接] http://www.52im.net/thread-675-1-1.html

          [摘要] 本文內容是由騰訊TMQ專項測試團隊針對手機QQ圖片上傳速度和成功率問題,在各種復雜移動網絡環境下的優化實踐總結和整理而成。文章雖是針對手機QQ圖片上傳這一特定業務功能,但內容中大量涉及復雜移動網絡環境下無線網絡的特性、特點以及相關第一手測試數據,都是非常珍貴的,尤其值得移動端IM開發、消息推送這種深度依賴移動網絡的應用開發者借鑒和參考。


          [- 12 -] 騰訊原創分享(二):如何大幅壓縮移動網絡下APP的流量消耗(上篇)

          [鏈接] http://www.52im.net/thread-696-1-1.html

          [摘要] 本文將給讀者們一個一年多以前為公司的某產品成功優化網絡流量的案例。速度、成功率與流量正好是 Apps 網絡優化的幾大重點,希望本文我們分享的思路能夠給諸位正在開展或將來會開展此類工作的讀者們一些啟發。


          [- 13 -] 騰訊原創分享(三):如何大幅壓縮移動網絡下APP的流量消耗(下篇)

          [鏈接] http://www.52im.net/thread-697-1-1.html

          [摘要] 本篇中將詳細介紹我們的具體分析方法和實踐優化思路,以及在優化過程中總結出來的法則等。


          [- 14 -] 如約而至:微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源

          [鏈接] http://www.52im.net/thread-684-1-1.html

          [摘要] 本文正文內容引用了微信開發團隊的資料。


          [- 15 -] 基于社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的?

          [鏈接] http://www.52im.net/thread-1191-1-1.html

          [摘要] 研究Yelp的極致圖片壓縮技術,或許能給即時通訊開發者同行帶來一定的借鑒意義,而這也是此文的意義所在。


          [- 16 -] 騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)

          [鏈接] http://www.52im.net/thread-1559-1-1.html

          [摘要] 本次文章跟大家分享如何在保障質量(指的是圖片質量、音視頻質量)前提下所做的帶寬和網絡流量壓縮,進而達到運營成本的優化。


          [- 17 -] 騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)

          [鏈接] http://www.52im.net/thread-1560-1-1.html

          [摘要] 本文接上篇《騰訊技術分享:騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)》,繼續騰訊公司分享如何在保障質量(指的是圖片質量、音視頻質量)前提下所做的帶寬和網絡流量壓縮,進而達到運營成本的優化。


          [- 18 -] 為什么說即時通訊社交APP創業就是一個坑?

          [鏈接] http://www.52im.net/thread-1619-1-1.html

          [摘要] 所以今天,我將盡量試著以用戶的眼光,去描述這樣一種現實:什么拳打QQ、腳踩微信,自嗨式的創業就像浮云一樣......


          ??52im社區本周新文:《IM通訊協議專題學習(十):初識 Thrift 序列化協議》,歡迎閱讀!??

          我是Jack Jiang,我為自已帶鹽!https://github.com/JackJiang2011/MobileIMSDK/

          posted @ 2023-12-27 15:23 Jack Jiang 閱讀(62) | 評論 (0)編輯 收藏

          本文由冰河分享,作者博客 binghe.gitcode.host,原題“這套分布式IM即時通訊系統如何寫到簡歷上?我給你整理好了!”,本文有修訂和改動。

          1、引言

          分布式IM即時通訊系統本質上就是對線上聊天和用戶的管理。

          針對聊天本身來說,最核心的需求就是:發送文字、圖片、文件、語音、視頻、消息緩存、消息存儲、消息未讀、已讀、撤回,離線消息、歷史消息、單聊、群聊,多端同步,以及其他一些需求。

          對用戶管理來說,存在的需求包含:添加好友、查看好友列表、刪除好友、查看好友信息、創建群聊、加入群聊、查看群成員信息、退出群聊、修改群昵稱、拉人進群、踢人出群、解散群聊、填寫群公告、修改群備注以及其他用戶相關的需求等。

          為了更好的理解分布式IM即時通訊系統的設計,我站在架構師的角度,在充分了解系統需求、業務流程和技術流程后,從全局視角為系統設定方案目標,對技術方案進行選型,對系統進行總體架構設計和分層架構設計,并梳理清楚發送消息的交互鏈路、單聊和群聊的交互鏈路。希望對你有幫助。

           
          技術交流:

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

          2、方案目標

          在進行技術選型與總體架構設計之前,需要明確一個事項,就是系統無論采用哪種方案,采用哪種架構設計都需要明確這種方案的業務目標、技術目標和架構目標,并在研發過程中不斷評估系統的總體性能表現,發現系統瓶頸并不斷進行優化。

          總體上,我們搭建和開發的分布式IM即時通訊系統,需要滿足如下方案目標。

          具體是:

          • 1)業務目標:滿足需求設計篇章中的各類需求場景;
          • 2)技術目標:支持無限擴容,百萬用戶同時在線聊天;
          • 3)架構目標:高并發、高性能、高可用、可監控、可預警、可伸縮,支持無限擴展。

          3、技術選型

          在技術選型上,除了采用SpringBoot等基礎框架外,也會采用容器化方案。

          同時,考慮到為了盡量降低技術門檻,在整個分布式IM即時通訊系統的技術選型中,主要采用市面上比較流行的技術框架和方案。

          具體選型如下所示:

          • 1)開發框架:SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo;
          • 2)緩存:Redis分布式緩存+Guava本地緩存;
          • 3)數據庫:MySQL、TiDB、HBase;
          • 4)流量網關:OpenResty+Lua;
          • 5)業務網關:SpringCloud Gateway + Sentinel;
          • 6)持久層框架:MyBatis、Mybatis-Plus;
          • 7)服務配置、服務注冊與發現:Nacos;
          • 8)消息中間件:RocketMQ;
          • 9)網絡通信Netty
          • 10)文件存儲:Minio;
          • 11)日志可視化治理:ELK;
          • 12)容器化管理:Swarm、Portainer;
          • 13)監控:Prometheus、Grafana;
          • 14)前端:Vue;
          • 15)單元測試:Junit;
          • 16)基準測試:JMH;
          • 17)壓力測試:JMeter。

          4、初步架構設計

          對于IM即時通訊系統來說,涵蓋了即時通訊后端服務、大后端平臺、SDK接入服務、OpenAI接入服務、大前端UI,我相信不少小伙伴多多少少能夠畫出IM即時通訊系統的架構圖,大致如下圖所示。

           

          其實,這種這種架構設計也比較常見,在這種架構設計中,Kong/Openresty/Nginx只做負載均衡和反向代理,研發人員更多的是關注業務層和基礎層的開發,流量比較小時,這種架構設計一般不會有什么問題。但是一旦流量比較大,用戶調用后端平臺的接口發送消息時,即時通訊SDK同步調用即時通訊服務的接口就會出現性能問題。

          因為每個終端同時只能與一個IM即時通訊服務實例建立連接,如果大量的用戶終端恰好都與一個IM即時通訊服務建立連接,那即時通訊SDK頻繁同步調用同一個IM即時通訊服務的接口就會出現性能瓶頸。此時,出現性能瓶頸時,不僅僅會影響到IM即時通訊服務,也會對后端平臺接收請求的業務造成一定的影響。

          5、架構設計優化

          既然上節圖中所示的架構設計存在性能瓶頸,那我們如何進行優化呢?

          為此我們在前圖基礎上進行了優化,優化后的架構如下圖所示。

          對比兩圖可以看出,在屏蔽掉技術實現細節的前提下,我們將對業務的校驗和流量管控進行前置化,放大Kong/OpenResty/Nginx的職責,使得這些軟件不僅具備反向代理和負載均衡的功能,還能實現限流、黑白名單、流量管控、業務校驗等功能。

          也就是說,在這種架構模式下,我們充分發揮了整個分布式IM即時通訊系統的入口職責,充分利用Kong/OpenResty/Nginx的高并發、高吞吐量的能力,盡量將大部分無效請求擋在整個系統之外。例如,用戶在沒登錄系統的前提下,就嘗試調用發送消息、添加好友、添加群組等等接口。這樣會大大減輕后臺平臺的業務壓力。

          除了在Kong/OpenResty/Nginx中實現限流、黑白名單、流量管控、業務校驗等功能外,我們還引入了業務網關集群,實現限流、降級、熔斷、流控、校驗、鑒權等功能,進一步保證下游系統的穩定性和安全。

          為了解決大量用戶終端恰好連接到同一個IM即時通訊服務實例,IM即時通訊SDK頻繁調用同一個IM即時通訊服務實例的接口造成的性能問題。我們在IM即時通訊服務SDK與IM即時通訊服務之間引入了RocketMQ集群。

          IM即時通訊服務集群中的每一個IM即時通訊服務實例在集群中都有一個唯一的ID,并且每個IM即時通訊服務實例在啟動后,只會監聽RocketMQ中與自身ID相關的Topic。這樣每個IM即時通訊服務只會收到與自身ID相關的Topic中的消息,不會接收所有的消息。

          當用戶登錄系統后,就會與IM即時通訊服務建立長連接,并且會以用戶ID和終端為Key,以IM即時通訊服務的ID為value,將其存儲到分布式緩存中。同時,會以用戶ID和終端為Key,以用戶終端與IM即時通訊服務建立的長連接為value,將其存儲到IM即時通訊服務本地內存中。

          當用戶調用后端平臺的接口發消息時,會帶上目標用戶的ID,并且在IM即時通訊SDK中會指定用戶登錄的終端設備,最終會通過IM即時通訊SDK向RocketMQ發送消息。

          此時IM即時通訊SDK會根據目標用戶ID和終端從分布式緩存中獲取目標用戶連接的IM即時通訊服務的ID,并向此ID相關的Topic發送消息。此時與目標用戶建立長連接的IM即時通訊服務就會接收到RocketMQ中的消息,隨后根據用戶ID和終端從本地緩存中獲取到與用戶終端建立的長連接,并基于此長連接向用戶推送消息。

          另外,在實際實現中,為了避免大量用戶同時只連接IM即時通訊服務集群中的某一個服務實例,會對用戶連接的IP、瀏覽器指紋、手機設備等做Hash和取模運算,使其盡量均勻分布到集群中的每一個服務實例上。

          那么問題來了,這種架構設計還有進一步優化的空間嗎?

          6、容器化架構設計

          為進一步增強分布式IM即時通訊系統的性能、可用性和彈性伸縮能力,我們可以對分布式IM即時通訊系統進行容器化架構設計,如下圖所示。

          可以看到,我們對分布式IM即時通訊系統的架構設計進行了進一步優化,采用了容器化架構設計。在原有架構的基礎上,我們進行了如下改進和優化。

          1)基礎支撐服務:基礎支撐服務會由各種基礎中間件、數據存儲服務、以及監控服務實現,包含:MySQL數據庫、TiDB數據庫、HBase、Redis緩存、RocketMQ消息隊列、Prometheus監控和Portainer容器管理等基礎中間件實現,基礎支撐服務會對整個分布式IM即時通訊系統提供最基礎的數據、傳輸、監控和容器管理等服務。

          2)容器化:在容器化層面,會通過Docker、Swarm和Portainer實現,其中,會基于Swarm和Portainer對容器化進行管理。

          3)其他基礎性功能實現:除了上述分層架構外,對于建設分布式IM即時通訊系統來說,還要考慮異常監控、服務注冊與發現、可視化、服務降級與兜底數據、服務限流、服務容災、容量規劃與擴縮容和全鏈路壓測等。

          7、DDD分層業務架構設計

          在分布式IM即時通訊系統中,不管是大后端平臺,還是IM即時通訊服務,我們都會對業務層的代碼采用分層業務架構。

          這里,可以借鑒DDD的分層架構思想,將代碼總體上分成展示層、應用層、領域層和基礎設施層四個層次。

          但是,考慮到分布式IM即時通訊系統的特殊性,又不會嚴格按照DDD的原則來設計代碼分層,具體按照如下圖所示。

          可以看到,分布式IM即時通訊系統會借鑒DDD的設計思想,但是不會完全按照DDD的方式進行設計。

          1)展示層:展示層,也叫做用戶UI層,是DDD設計的最上層,對外提供API接口,接收客戶端請求,解析參數,返回結果數據,并對異常進行處理。

          2)應用層:應用層,也叫做Application層,應用層主要處理容易變化的業務場景,可對相關的事件、調度和其他聚合操作進行相關的處理。

          3)領域層:領域層,也叫做Domain層,領域層可以說是DDD設計的精髓所在,它是將業務系統中相對不變的部分抽象出來封裝成領域模型。在分布式IM即時通訊系統的設計中,領域層基本不會依賴其他層,也不會依賴基礎設施層,這里是與DDD設計存在區別的地方。

          4)基礎設施層:基礎設施層,也叫做Infrastructure層,基礎設施層會對其他各層提供通用的基礎能力,在分布式IM即時通訊系統中,就包括了緩存、通用工具類、消息、系統的持久化機制等。

          8、總體IM消息交互鏈路

          在分布式IM即時通訊系統中,我們忽略掉其他一些細節信息,重點關注下發送消息的交互鏈路邏輯。不管是單聊還是群聊,最終都需要通過IM即時通訊服務將消息推送給用戶的終端。此時發送消息的流程如下圖所示。

          可以看到:用戶在分布式IM即時通訊系統發送消息時,不管是單聊還是群聊,最終的消息都會推送到用戶登錄的終端設備上。假設此時用戶A給用戶B發送消息,或者用戶A和用戶B在同一個群組,用戶A向群組發送消息,用戶B接收消息的主要流程如下。

          具體是:

          • 1)用戶A調用后端平臺的接口向用戶B發送消息,并且發送的消息中會帶有用戶B的ID以及終端信息;
          • 2)后端平臺將消息緩存起來,并且會將消息異步寫入消息庫;
          • 3)后端平臺從Redis中獲取用戶B連接的IM即時通訊服務的ID;
          • 4)后端平臺獲取到用戶B連接的IM即時通訊服務的ID后,會向RocketMQ中用戶B連接的IM即時通訊服務ID對應的Topic發送消息;
          • 5)IM即時通訊服務會監聽自身服務ID對應的RocketMQ中Topic的消息,此時,用戶B連接的IM即時通訊服務會接收到消息;
          • 6)IM即時通訊服務接收到消息后,會根據用戶B的ID以及終端信息從緩存中獲取用戶B與IM即時通訊服務建立的連接,并且通過這個連接向用戶B推送消息。

          要實現如上發送消息的流程,前提是要滿足如下條件:

          • 1)后端平臺滿足分布式條件,可隨時橫向擴展;
          • 2)IM即時通訊服務滿足分布式條件,可隨時橫向擴展;
          • 3)每個啟動的IM即時通訊服務實例在集群中都有一個唯一的ID;
          • 4)每個IM即時通訊服務,都只監聽自身ID對應的RocketMQ中Topic的消息;
          • 5)用戶登錄分布式IM即時通訊系統后,會與IM即時通訊服務建立長連接,并且會根據用戶ID和所在的終端緩存長連接,同時會根據用戶ID和所在的終端將連接的IM即時通訊服務的ID緩存到Redis;
          • 6)用戶發送消息時,會根據目標用戶的ID和終端從Redis中獲取IM即時通訊服務的ID,進而向當前IM即時通訊服務的ID對應的RocketMQ的Topic發送消息;
          • 7)對應的IM即時通訊服務監聽并接收到RocketMQ消息后,會根據目標用戶的ID和終端從緩存中獲取到用戶的連接信息,向目標用戶推送消息。

          9、IM單聊交互鏈路

          單聊就是在分布式IM即時通訊系統中,一個用戶直接與另外一個用戶聊天,也就是一對一的聊天。在這種場景下,很有可能單聊的兩個用戶中,出現用戶不在線的情況。

          例如:用戶A給用戶B發送消息時,用戶B可能不在線。

          此時,我們就需要將用戶A向用戶B發送的消息存儲起來。

          其實,在我們實現的分布式IM即時通訊系統中,無論把用戶B是否在線,都會存儲消息記錄。當用戶B登錄系統后,將消息同步給用戶B,如下圖所示。

          可以看到,用戶A向用戶B發送消息時:

          • 1)如果用戶B在線,就可以按照發送消息的交互鏈路向用戶B發送消息了;
          • 2)如果用戶B不在線,此時就無法向用戶B正常推送消息。當用戶B登錄分布式IM即時通訊系統后,就會調用后端平臺的接口拉取所有未讀消息,并通過用戶B在線流程向用戶B推送消息。

          10、IM群聊交互鏈路

          群聊就是在分布式IM即時通訊系統中,多個用戶在同一個群組中進行聊天。

          此時在發送消息時,我們可以通過群組ID找出群內所有在線的用戶,將消息即時發送給在線的用戶。

          那些未在線的用戶就按照單聊未在線的用戶進行處理,如下圖所示。

          可以看到,群聊的交互鏈路流程如下所示:

          • 1)用戶調用后端平臺的接口向群組發送消息;
          • 2)后端平臺將消息緩存并異步寫入消息庫;
          • 3)由于是向群組發送消息,群里有多個用戶,此時就會從Redis中獲取所有用戶連接的IM即時通訊服務ID列表;
          • 4)對用戶按照服務ID分組,將相同服務ID下的用戶分在同一個邏輯分組里,方便后續推送消息,并且會記錄未在線的用戶列表;
          • 5)循環向每個服務ID對應的RocketMQ中的Topic發送消息;
          • 6)廣播處理未在線用戶的未讀消息ID;
          • 7)IM即時通訊服務會監聽自身服務ID對應的Topic,會隨時接收推送到自身服務的消息;
          • 8)當IM即時通訊服務接收到消息后,此時用戶掉線,或者用戶不在線,向用戶推送消息就會失敗,或者未查詢到用戶與IM即時通訊服務建立的連接,就不會向用戶推送消息;
          • 9)當用戶登錄分布式IM即時通訊系統后,會從后端平臺拉取歷史(離線)消息,并通過用戶在線的流程,向用戶推送消息;

          好了,看到這里,你明白如何設計一個高度可擴展的分布式IM即時通訊系統了嗎?

          11、相關資料

          [1] 淺談IM系統的架構設計

          [2] 簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端

          [3] 一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)

          [4] 一套原創分布式即時通訊(IM)系統理論架構方案

          [5] 移動端IM中大規模群消息的推送如何保證效率、實時性?

          [6] 一套億級用戶的IM架構技術干貨(上篇):整體架構、服務拆分等

          [7] 一套億級用戶的IM架構技術干貨(下篇):可靠性、有序性、弱網優化等

          [8] 從新手到專家:如何設計一套億級消息量的分布式IM系統

          [9] 企業微信的IM架構設計揭秘:消息模型、萬人群、已讀回執、消息撤回等

          [10] 融云技術分享:全面揭秘億級IM消息的可靠投遞機制

          [11] 阿里IM技術分享(三):閑魚億級IM消息系統的架構演進之路

          [12] 基于實踐:一套百萬消息量小規模IM系統技術要點總結

          [13] 跟著源碼學IM(十):基于Netty,搭建高性能IM集群(含技術思路+源碼)

          [14] 一套十萬級TPS的IM綜合消息系統的架構實踐與思考

          [15] 得物從0到1自研客服IM系統的技術實踐之路

          [16] 海量用戶IM聊天室的架構設計與實踐

          [17] 史上最通俗Netty入門長文:基本介紹、環境搭建、動手實戰

          [18] 新手入門:目前為止最透徹的的Netty高性能原理和框架架構解析

          [19] 寫給初學者:Java高性能NIO框架Netty的學習方法和進階策略

          [20] 手把手教你用Netty實現網絡通信程序的心跳機制、斷線重連機制

          [21] 史上最強Java NIO入門:擔心從入門到放棄的,請讀這篇!

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

          posted @ 2023-12-21 11:29 Jack Jiang 閱讀(139) | 評論 (0)編輯 收藏

          為了更好地分類閱讀 52im.net 總計1000多篇精編文章,我將在每周三推送新的一期技術文集,本次是第28 期。

          [- 1 -] 新手入門一篇就夠:從零開發移動端IM

          [鏈接] http://www.52im.net/thread-464-1-1.html

          [摘要] 本文將以新手的視角引導你閱讀相關文章,便于你從零開發一個移動端IM做好方方面面的知識準備:包括但不限于網絡編程基礎、通信協議的選型、IM的架構設計等等。文筆有限,如有不妥之處還請批評指正,希望對你有用。

          [- 2 -] 移動端IM開發者必讀(一):通俗易懂,理解移動網絡的“弱”和“慢”

          [鏈接] http://www.52im.net/thread-1587-1-1.html

          [摘要] 本文的目的,就是希望以通俗易懂的語言,幫助移動端IM開發者更好地理解移動網絡的各種特性,使得開發出的功能能更好地適應移動網絡,給用戶帶來更好的使用體驗。

          [- 3 -] 移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結

          [鏈接] http://www.52im.net/thread-1588-1-1.html

          [摘要] 本文將針對上篇中提到的特性,結合我們的實踐經驗,總結了四個方法來追求極致的“爽快”:快鏈路、輕往復、強監控、多異步,從理論講到實踐、從技術講到產品,理論聯系實際,舉一反三,希望給您帶來啟發。

          [- 4 -] 從客戶端的角度來談談移動端IM的消息可靠性和送達機制

          [鏈接] http://www.52im.net/thread-1470-1-1.html

          [摘要] 這篇文章和大家聊下從移動端客戶端的角度所關注的IM消息可靠性和送達機制

          [- 5 -] 現代移動端網絡短連接的優化手段總結:請求速度、弱網適應、安全保障

          [鏈接] http://www.52im.net/thread-1413-1-1.html

          [摘要] 本文整理的有關內容,對于移動端即時通訊IM應用來說,同樣具有啟發意義

          [- 6 -] 騰訊技術分享:社交網絡圖片的帶寬壓縮技術演進之路

          [鏈接] http://www.52im.net/thread-1391-1-1.html

          [摘要] 為了進一步降低運營帶寬成本,減小用戶訪問流量及提升頁面加載速度,社交網絡 CDN運維緊跟行業圖片優化趨勢,創新引入WebP、SharpP、自適應分辨率、Guetzli等圖像壓縮技術到現網,經過三年多的多部門聯合攻關,已逐漸形成一套覆蓋全圖片類型(JPEG、JPG、PNG、WebP、GIF)多場景的圖片壓縮運營體系,適用于各類型終端,每年節約外網帶寬幾百G。

          [- 7 -] 小白必讀:閑話HTTP短連接中的Session和Token

          [鏈接] http://www.52im.net/thread-1686-1-1.html

          [摘要] 本文的寫作目的是以最白話地方式,通俗易懂的為你講清HTTP協議中的Session和Token等概念,希望讀完全文,您仍能滿懷信心,繼續義無反顧地跳入程序員這個職業深坑 ^_^。更深入的技術細節,請閱讀《IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token》。

          [- 8 -] IM開發基礎知識補課:正確理解前置HTTP SSO單點登錄接口的原理

          [鏈接] http://www.52im.net/thread-1351-1-1.html

          [摘要] 針對上述主流移動IM系統中“長”、“短”連接的分工方式,其中最為重要也是用戶最先接觸到的——就是基于Http的SSO單點登陸接口(有的系統里可能并不叫SSO接口,本文討論的是其廣義:即實現身份認證功能的http接口),那么這個SSO接口工作原理是什么?可以怎么來實現?有無最佳實踐建議?

          [- -]  移動端IM中大規模群消息的推送如何保證效率、實時性?

          [鏈接] http://www.52im.net/thread-1221-1-1.html

          [摘要] 實際在生產環境下,群消息的發送都會想盡辦法進行壓縮,并開展各種改善性能的處理辦法,而不是像上述舉例里的直接擴散寫(即2000人群里,一條消息被簡單地復制為2000條一對一的消息投遞)。具體有哪些優先策略?本文或許可以帶給你一些啟發。

          [- 10 -] 移動端IM開發需要面對的技術問題

          [鏈接] http://www.52im.net/thread-133-1-1.html

          [摘要] 這兩年多一直從事網易云信 iOS 端 IM SDK的開發,期間不斷有兄弟部門的同事和合作伙伴過來問各種技術細節,干脆統一介紹下一個IM APP的方方面面,包括技術選型(包括通訊方式,網絡連接方式,協議選擇)和常見問題。

          [- 11 -] 開發IM是自己設計協議用字節流好還是字符流好?

          [鏈接] http://www.52im.net/thread-150-1-1.html

          [摘要] 自己設計協議的話,協議用字節流好還是字符流好? 各有什么優缺點?

          [- 12 -] 請問有人知道語音留言聊天的主流實現方式嗎?

          [鏈接] http://www.52im.net/thread-175-1-1.html

          [摘要] 請問有人知道語音聊天的主流實現方式嗎?就是類似微信那種,按住說話,錄一段,發送那種。這語音文件錄好之后是直接轉成二進制發送。還是說當成一個文件上傳到服務器,然后發送一個消息給對方,對方收到后下載?

          [- 13 -] IM消息送達保證機制實現(一):保證在線實時消息的可靠投遞

          [鏈接] http://www.52im.net/thread-294-1-1.html

          [摘要] 本文將要討論的是即時IM應用中極其重要但也不被用戶感知的消息送達保證機制(即QoS機制),文中將給出目前主流的參考實現思路。

          [- 14 -] IM消息送達保證機制實現(二):保證離線消息的可靠投遞

          [鏈接] http://www.52im.net/thread-594-1-1.html

          [摘要] 實時在線投遞針對的是消息收發雙方都在線的情況(如當發送方用戶A發送消息給接收方用戶B時,用戶B是在線的),那如果消息的接收方用戶B不在線,系統是如何保證消息的可達性的呢?這就是本文要討論的問題。

          [- 15 -] 如何保證IM實時消息的“時序性”與“一致性”?

          [鏈接] http://www.52im.net/thread-714-1-1.html

          [摘要] 實時消息時序和一致性是分布式系統架構設計中非常難的問題(尤其IM應用這種以消息為中心的應用形態),困難在哪?有什么常見優化實踐?這就是本文要討論的內容。

          [- 16 -] 一個低成本確保IM消息時序的方法探討

          [鏈接] http://www.52im.net/thread-866-1-1.html

          [摘要] IM類系統中,都需要考慮消息時序問題,如果后發送的消息先顯示,可能嚴重擾亂聊天消息所要表達的意義。

          [- 17 -] IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”?

          [鏈接] http://www.52im.net/thread-715-1-1.html

          [摘要] “用戶在線狀態的一致性”(單聊好友在線狀態、群聊用戶在線狀態)是IM應用領域比較難解決的一個技術問題,如何精準實時的獲得好友、群友的在線狀態,是今天將要探討的話題。

          [- 18 -] IM群聊消息如此復雜,如何保證不丟不重?

          [鏈接] http://www.52im.net/thread-753-1-1.html

          [摘要] 由于“消息風暴擴散系數”的存在(概念詳見《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”?》),群消息的復雜度要遠高于一對一的單聊消息。群消息的實時性、可達性、離線消息是今天將要討論的核心話題。

          ??52im社區本周新文:《一套分布式IM即時通訊系統的技術選型和架構設計》,歡迎閱讀!??

          我是Jack Jiang,我為自已帶鹽!https://github.com/JackJiang2011/MobileIMSDK/

          posted @ 2023-12-21 10:30 Jack Jiang 閱讀(63) | 評論 (0)編輯 收藏

          本文由NetworkFox分享,來源于華三通信,原題“什么是國密算法?”,本文有修訂和改動。

          1、引言

          最近幾年經常能聽到IM應用的開發者討論國產信創方面的技術問題,在某些場景下,國密算法是硬性要求,所以學習一下國密算法還是很有必要的。

          國密算法是指由中國國家密碼管理局發布的密碼算法標準,旨在保障國家信息安全。目前,國家密碼管理局已發布了一系列國產商用密碼標準算法,包括SM1(SCB2)、SM2、SM3、SM4、SM7、SM9以及祖沖之密碼算法(ZUC)等。通過在金融、電子政務及安防等領域廣泛應用國密算法,在對敏感數據進行機密性、完整性和可用性保護的同時,減少對外部密碼產品的依賴,提升國家信息安全水平。

          本文將盡量以通俗易懂的文字,為你分享國密算法的種類、技術原理和應用場景等。

           
           
          技術交流:

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

          2、系列文章

          本文是IM通訊安全知識系列文章中的第12篇,此系列總目錄如下:

          即時通訊安全篇(一):正確地理解和使用Android端加密算法

          即時通訊安全篇(二):探討組合加密算法在IM中的應用

          即時通訊安全篇(三):常用加解密算法與通訊安全講解

          即時通訊安全篇(四):實例分析Android中密鑰硬編碼的風險

          即時通訊安全篇(五):對稱加密技術在Android平臺上的應用實踐

          即時通訊安全篇(六):非對稱加密技術的原理與應用實踐

          即時通訊安全篇(七):用JWT技術解決IM系統Socket長連接的身份認證痛點

          即時通訊安全篇(八):如果這樣來理解HTTPS原理,一篇就夠了

          即時通訊安全篇(九):你知道,HTTPS用的是對稱加密還是非對稱加密?

          即時通訊安全篇(十):為什么要用HTTPS?深入淺出,探密短連接的安全性

          即時通訊安全篇(十一):IM聊天系統安全手段之通信連接層加密技術

          即時通訊安全篇(十二):IM聊天系統安全手段之傳輸內容端到端加密技術

          即時通訊安全篇(十三):信創必學,一文讀懂什么是國密算法》(* 本文)

          3、為什么需要國密算法?

          3.1國密算法的產生背景

          在網絡信息傳輸和存儲過程中,數據的保密性和安全性是一項重要的需求。

          傳統的國際標準加密算法雖然安全可靠,但由于無法保證源代碼的安全性,因此存在著源代碼被外部惡意攻擊者滲透或篡改的風險。為了構建安全的行業網絡環境并增強國家行業信息系統的“安全可控”能力,中國積極開展了針對信息安全需求的研究和探索。

          自2007年開始,中國制定了國密算法標準,并于2010年正式發布。

          經過多年的發展、改進和完善,國密算法已成為中國自主研發的密碼算法標準,并在各行業得到廣泛應用。它的誕生不僅顯著提升了中國在密碼技術領域的核心競爭力,還為國家信息安全建設作出了重要貢獻。

          3.2國密算法的特點

          國密算法具備如下特點:

          1)安全性高:國密算法采用了嚴密的密碼學原理和復雜的運算方式,具有較高的安全性。它在加密、數字簽名和哈希等功能上都能提供可靠的保護,抵抗了各種傳統和現代密碼攻擊手段。

          2)高效性與靈活性:國密算法在保證安全性的同時,注重算法的效率。它的加密速度和運行效率相對較高,同時也能適應不同的密碼長度和密鑰長度,以滿足不同場景的需求。

          3)標準化廣泛:國密算法已被國家標準化機構認可和采用。它符合國際密碼學標準的基本要求,具備與國際算法相媲美的能力。同時,國密算法也在國內推廣和應用廣泛,成為中國信息安全領域的基礎核心算法之一。

          4)自主創新:國密算法是中國自主研發的密碼算法,所以對于算法的實現和推廣都具有獨立的掌控能力。這意味著中國可以更好地保護自己的國家信息安全,減少對外依賴,提高自主抵抗能力。

          5)面向多領域應用:國密算法不僅局限于某個特定領域的應用,它適用于金融業、電子商務、通信、物聯網、區塊鏈等不同領域的信息安全保護。它的廣泛應用范圍使得國密算法可以滿足不同行業的安全需求。

          4、國密算法應用概述

          國密算法包括SM1(SCB2)、SM2、SM3、SM4、SM7、SM9以及祖沖之密碼算法(ZUC)等。

          其中:

          • 1)SM1、SM4、SM7、祖沖之密碼(ZUC)屬于對稱算法;
          • 2)SM2、SM9屬于非對稱算法;
          • 3)SM3屬于雜湊算法。

          下文將主要介紹國密算法中的常用算法SM1、SM2、SM3和SM4的實現和應用。

          5、SM1算法的原理和應用場景

          SM1算法是國密算法中的一種對稱加密算法,其特點是加解密使用相同密鑰。利用SM1對稱加密算法加解密數據的過程。

          SM1算法未公開,僅以IP核(Intellectual Property Core,一種預先做好的集成電路功能模塊)的形式存在于芯片中。

          SM1算法主要用于小數據量的加密保護,因此被廣泛用于研制智能IC卡、智能密碼鑰匙、門禁卡、加密卡等安全產品。

          6、SM2算法的實現和應用場景

          6.1概述

          SM2算法是基于ECC(Elliptic Curve Cryptography)橢圓曲線的非對稱加密算法,包括了SM2-1橢圓曲線數字簽名算法、SM2-2橢圓曲線密鑰交換協議和SM2-3橢圓曲線公鑰加密算法,分別用于實現數字簽名、密鑰協商和數據加密等功能。

          SM2算法在許多領域都有廣泛的應用。

          在電子商務領域:SM2算法被用于保護用戶個人信息的安全傳輸,確保用戶在網上交易過程中的隱私和財產的安全。

          在互聯網金融領域:SM2算法被用于數字支付、電子銀行等場景,實現用戶身份認證和交易的安全性。

          此外,SM2算法還適用于物聯網領域,保護物聯網設備之間的通信安全,確保數據的可靠傳輸。

          6.2數據加密

          在非對稱加密算法中,可對外公布的密鑰稱為“公鑰”,只有持有者所知的密鑰稱為“私鑰”。發送者使用接收者的公鑰來加密消息,接收者用自己的私鑰解密和讀取該消息。

          利用SM2非對稱加密算法加解密數據的過程:

          6.3密鑰協商

          由于橢圓曲線的計算復雜性高,破解難度大,因此SM2算法在密鑰協商技術領域也起著關鍵作用。

          利用SM2算法進行密鑰協商的過程:

          • 1)會話雙方生成自己的私鑰(隨機數);
          • 2)會話雙方由私鑰、ECC橢圓曲線參數G各自計算出公鑰;
          • 3)會話雙方將自己的公鑰傳遞給對方,傳遞過程公開。由于橢圓曲線的計算復雜性高,破解難度大,因此攻擊者難以通過公鑰和橢圓曲線參數G反推出私鑰;
          • 4) 雙方將自己的私鑰與對方的公鑰進行運算,最終得到相同的會話密鑰,該會話密鑰可作為共享密鑰用于對稱加密(例如SM4算法)通信。

          6.4數字簽名

          數字簽名是一種用于驗證信息完整性、真實性和來源的技術手段。它通常用于確保數據在傳輸或存儲過程中沒有被篡改,并且可以追溯到特定的發送方。

          發送方使用自己的私鑰對消息進行加密,生成數字簽名。接收方使用發送方的公鑰對簽名進行解密和驗證,以驗證消息的完整性和真實性。

          在數字簽名應用中,SM2算法通常與SM3摘要算法一起使用。

          7、SM3算法的實現和應用場景

          SM3雜湊(Hashing)算法是國密算法中的一種摘要算法。

          SM3算法通過哈希函數將任意長度的消息壓縮成固定長度的摘要。摘要具有唯一性,即不同信息生成的摘要不同,且無法由摘要恢復出原始信息,更無法偽造信息獲得相同摘要,因此SM3算法被廣泛用于實現數字簽名、數據完整性檢測及消息驗證等功能。

          基于SM3算法的特點,在信息安全領域,SM3算法被用于保護密碼學協議、數字證書和電子簽名等數據的完整性。在區塊鏈領域,SM3算法被用于加密貨幣的區塊生成和鏈上交易的校驗,確保區塊鏈的安全性。

          此外,SM3算法還可以應用于密碼學隨機數的生成和偽隨機序列的校驗等領域,增加了數據的安全性和可靠性。

          利用SM2算法和SM3算法對用戶數據進行數字簽名認證及完整性校驗的過程:

          • 1) 用戶A發送的數據A經過SM3哈希算法運算生成摘要A。
          • 2) 摘要A經過用戶A的私鑰加密生成數字簽名。
          • 3) 用戶A的明文數據和數字簽名經加密算法(SM1/SM2/SM4)加密成密文后發送給用戶B。加密算法以非對稱加密算法SM2為例,即加解密使用不同密鑰。
          • 4)密文到達用戶B處,經加密算法(SM1/SM2/SM4)解密后,還原成明文數據和數字簽名。
          • 5)用戶B使用用戶A的公鑰解密數據包中的數字簽名:
          •      解密成功,數據來源合法,得到摘要A;
          •      解密失敗,數據來源非用戶A,丟棄本次數據。
          • 6)收到的數據包中的明文數據經過SM3哈希運算生成摘要A’。對比摘要A和摘要A’:
          •      摘要A’=摘要A,數據完整;
          •      摘要A’≠摘要A,數據被篡改,丟棄本次數據。

          8、SM4算法的實現和應用

          8.1概述

          與SM1算法分類相同,SM4算法同樣為分組對稱加密算法,但SM4算法實現公開。

          分組加密算法是將明文數據按固定長度進行分組,用同一密鑰逐組加密,密文解密時同樣使用相同密鑰逐組解密。

          SM4算法實現簡單,因此加解密速度較快,消耗資源少,主要用于大數據量的加密和解密,例如靜態儲存或數據信號傳輸通道中數據的加解密。

          在網絡安全領域,SM4算法被用于保護網絡傳輸和存儲的敏感數據,如銀行卡信息、密碼等。在物聯網領域,SM4算法被用于物聯網設備之間的通信和數據加密,確保物聯網數據的隱私安全。

          此外,SM4算法還可以應用于區塊鏈領域,保護加密貨幣的交易安全等領域,為相關系統和數據的安全提供了保障。

          SM4算法支持ECB、CBC、CFB等多種分組模式,下文將介紹ECB和CBC兩種基礎模式。

          8.2加解密模式:ECB模式

          SM4算法基于ECB模式對數據加解密的過程:

          • 1)發送端將明文按固定長度分組,對每個明文分組分別使用相同的密鑰進行加密生成密文分組。完整的密文由所有密文分組按序排列組合而成;
          • 2)接收端將密文按固定長度分組,對每個密文分組分別使用相同的密鑰進行解密生成明文分組。所有明文分組按序排列組合而成完整的明文數據。

          ECB模式實現簡單,各段數據間互不影響,有利于并行運算,但相同的明文塊會被加密成相同的密文塊,不能提供嚴格的數據保密性。

          8.3加解密模式:CBC模式

          SM4算法基于CBC模式對明文加密的過程:

          • 1)將明文按固定長度分組;
          • 2)明文分組1與初始向量IV進行異或運算,異或運算的結果經密鑰加密后得到密文分組1;
          • 3)剩余的明文分組依次與前一個密文分組進行異或運算后再加密,得到對應的密文分組;
          • 4)完整的密文由所有密文分組按序排列組合而成。

          SM4算法基于CBC模式對密文解密的過程:

          • 1)將密文按固定長度分組后,對密文分組進行倒序處理;
          • 2)對密文分組n先使用密鑰進行解密,密文分組n解密后的數據與密文分組n-1進行邏輯逆運算,得到明文分組n;
          • 3) 同理,剩余的密文分組解密后再與前一個密文分組進行邏輯逆運算,得到對應的明文分組;
          • 4)最后,密文分組1用密鑰解密后的數據是與初始向量進行邏輯逆運算,然后得到明文分組1;
          • 5)完整的明文由所有明文分組按序排列組合而成。

          CBC模式安全性高于ECB,但明文塊不能并行計算,且誤差會傳遞下去。

          9、國密算法與國際標準算法的對比

          國密算法和國際標準算法都是現代密碼學中常用的加密算法,但在技術和優劣方面存在一些區別。

          常見國密算法與國際標準算法各參數性能的對比如下:

           

          10、國密算法的典型應用場景有哪些?

          10.1AD-WAN縱向IP/MPLS組網

          國密算法可以與AD-WAN技術結合,應用于IP/MPLS縱向網場景。

          通過AD-WAN智能運維平臺,實現國密配置一鍵下發,在網絡中構建國密數據加密通道,實現基于國密的端到端的IPsec隧道保護。

          國密算法在端到端的IPsec隧道中的工作原理如下:

          1)在IKE密鑰協商階段,使用IKE協議進行密鑰協商過程中,采用SM2算法生成會話密鑰。

          2)在身份認證階段,本端使用SM2和SM3算法生成身份信息的數字簽名,并使用SM1或SM4算法和會話密鑰對身份信息和數字簽名進行加密;對端收到加密的身份信息后,使用相同的會話密鑰解密,然后通過SM2和SM3算法進行身份認證。

          3)在數據傳輸階段,本端使用SM2和SM3算法生成用戶數據的數字簽名,并使用SM1或SM4算法以及會話密鑰對用戶數據和數字簽名進行加密;對端收到加密的用戶數據后,使用相同的會話密鑰解密,然后通過SM2和SM3算法進行數據完整性檢查。

          10.24G/5G VPDN業務組網

          4G/5G VPDN(Virtual Private Dialup Network,虛擬專有撥號網絡)業務是在4G/5G無線網絡中采用撥號方式實現的一種虛擬專有網絡業務。它利用L2TP技術為客戶構建與互聯網隔離的隧道,以滿足客戶分支和總部內網通信的需求。VPDN組網同時支持將L2TP和IPsec技術結合,通過L2TP完成用戶認證確保接入安全,并利用IPsec保障通信數據安全。

          1)4G/5G VPDN組網中分支網關由4G/5G路由設備擔任,通過撥號接入運營商網絡。

          2)運營商對4G/5G路由設備的APN(Access Point Name,接入點名稱)、賬戶、SIM/USIM卡信息進行認證。

          3)4G/5G路由設備認證通過后被運營商判斷是VPDN用戶,同時由運營商AAA服務器向LAC(L2TP Access Concentrator,L2TP訪問集中器)設備下發L2TP隧道屬性,LAC設備將基于下發的L2TP隧道屬性信息向該VPDN用戶所屬總部的LNS(L2TP Network Server,L2TP網絡服務器)設備發起隧道建立請求。

          4)L2TP隧道建立后,LAC設備會通過此隧道向LNS設備透傳用戶的認證信息。LNS設備向總部內網的AAA服務器發起對VPDN用戶的二次認證,認證通過后為VPDN用戶分配一個企業內網IP地址。分支終端用戶和總部可以開始通信。

          5)分支網關與總部網關設備上均安裝有國密板卡,通過IPsec協商建立起端到端的IPsec隧道,使用國密算法對傳輸的數據報文進行加密保護和數據完整性檢查。

          6)經IPsec加密后的數據報文在LAC設備處進行L2TP封裝后,通過L2TP隧道傳輸到LNS。

          7)LNS收到數據報文后首先對L2TP報文進行解封裝,然后經過IPsec解密還原出數據報文,根據報文目的IP地址轉發報文。

          11、相關文章

          [1] 常用加解密算法與通訊安全講解

          [2] 非對稱加密技術的原理與應用實踐

          [3] IM聊天系統安全手段之通信連接層加密技術

          [4] IM聊天系統安全手段之傳輸內容端到端加密技術

          [5] 通俗易懂:一篇掌握即時通訊的消息傳輸安全原理

          [6] 基于Netty的IM聊天加密技術學習:一文理清常見的加密概念、術語等

          [7] 理論聯系實際:一套典型的IM通信協議設計詳解(含安全層設計)

          [8] 微信新一代通信安全解決方案:基于TLS1.3的MMTLS詳解

          [9] 手把手教你為基于Netty的IM生成自簽名SSL/TLS證書


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

          posted @ 2023-12-14 11:06 Jack Jiang 閱讀(74) | 評論 (0)編輯 收藏

          ​為了更好地分類閱讀 52im.net 總計1000多篇精編文章,我將在每周三推送新的一期技術文集,本次是第27 期。

          [- 1 -] 專訪微信視頻技術負責人:微信實時視頻聊天技術的演進

          [鏈接] http://www.52im.net/thread-1201-1-1.html

          [摘要] 本次專訪是對谷沉沉老師在即將到來的 2017ArchSummit 全球架構師峰會上,以《數億微信視頻通話背后的視頻技術二三事》為題發表演講的一次預熱。


          [- 2 -] 騰訊音視頻實驗室:使用AI黑科技實現超低碼率的高清實時視頻聊天

          [鏈接] http://www.52im.net/thread-1308-1-1.html

          [摘要] 騰訊音視頻實驗室和優圖實驗室X-lab的戴宇榮老師的團隊聯合開發的基于神經網絡的實時視頻超分辨率技術,在極小的神經網絡模型大小的條件下,在手機實時視頻通話上實現了基于機器學習的超分辨率技術,起到了主觀上提升一檔分辨率的效果。此技術即將應用在手機QQ 7.3.5的iOS版本上的實時視頻聊天。


          [- 3 -] 微信團隊分享:微信每日億次實時音視頻聊天背后的技術解密

          [鏈接] http://www.52im.net/thread-1311-1-1.html

          [摘要] 本文將為大家介紹微信實時音視頻聊天在不同發展階段的各個關鍵視頻技術環節采用的方案,同時分享在實時音視頻聊天中的視頻編碼器研發的方法和經驗。


          [- 4 -]福利貼:最全實時音視頻開發要用到的開源工程匯總

          [鏈接] http://www.52im.net/thread-1395-1-1.html

          [摘要] 本文匯總了一些能幫助到正在學習或進行實時音視頻開發的同行們的開源工程,這些工程分為幾類:音視頻編解碼類、視頻前后處理、服務端類等,希望能加速您的學習或研究過程。


          [- 5 -] 實時音視頻聊天中超低延遲架構的思考與技術實踐

          [鏈接] http://www.52im.net/thread-1465-1-1.html

          [摘要] 從直播在線上抓娃娃,不斷變化的是玩法的創新,始終不變的是對超低延遲的苛求。實時架構是超低延遲的基石,如何在信源編碼、信道編碼和實時傳輸整個鏈條來構建實時架構?在實時架構的基礎之上,如果通過優化采集、編碼、傳輸、解碼和渲染中的關鍵環節來降低延遲?本文將會介紹即構在這方面的思考與實踐。


          [- 6 -] 理解實時音視頻聊天中的延時問題一篇就夠

          [鏈接] http://www.52im.net/thread-1553-1-1.html

          [摘要] 音視頻實時通訊的應用場景已經隨處可見,從“吃雞”的語音對講、直播連麥、直播答題組隊開黑,再到銀行視頻開戶等。對于開發者來講,除了關注如何能快速實現不同應用場景重點額音視頻通訊,另一個更需要關注的可能就是“低延時”。但是,到底實時音視頻傳輸延時應該如何“低”,才能滿足你的應用場景呢?


          [- 7 -] 寫給小白的實時音視頻技術入門提綱

          [鏈接] http://www.52im.net/thread-1620-1-1.html

          [摘要] 本文是由一篇演講稿整理出來的文章,目標讀者是對實時音視頻開發感興趣但是又不知道如何下手的初學者們,對大家有所幫助。


          [- 8 -] 微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等

          [鏈接] http://www.52im.net/thread-1746-1-1.html

          [摘要] 騰訊多媒體內核中心高級研究員時永方接受了LiveVideoStack的郵件采訪,談及了個人成長中的關鍵時刻,學習多媒體開發的三點核心,以及在5G和高清時代下,微信多媒體團隊面臨的挑戰。


          [- 9 -]  騰訊技術分享:微信小程序音視頻技術背后的故事

          [鏈接] http://www.52im.net/thread-1799-1-1.html

          [摘要] 本文來自騰訊視頻云終端技術總監rexchang(常青)的技術分享,講述的是微信小程序中音視頻技術構思、設計和實現等方方面的內容,希望能為你的音視頻技術實踐帶來啟發。


          [- 10 -] 微信多媒體團隊梁俊斌訪談:聊一聊我所了解的音視頻技術

          [鏈接] http://www.52im.net/thread-1828-1-1.html

          [摘要] 從華為2012實驗室到騰訊,過去十余年梁俊斌一直專注在音頻技術。他告訴LiveVideoStack:音頻技術還有許多難點需要解決,而作為技術人也延展到應用場景,關注用戶需求。本文整理了本次訪談的主要內容,僅供參閱。


          [- 11 -] 新浪微博技術分享:微博短視頻服務的優化實踐之路

          [鏈接] http://www.52im.net/thread-1843-1-1.html

          [摘要] 本文的短視頻技術跟IM的單聊、群聊、朋友圈里的小視頻是類似的東西,文中針對短視頻的相關優化實踐可以為您的IM小視頻開發提供一定的參考和借鑒意義,希望對您有用。


          [- 12 -] 以網游服務端的網絡接入層設計為例,理解實時通信的技術挑戰

          [鏈接] http://www.52im.net/thread-1915-1-1.html

          [摘要] 本文將嘗試從開發者角度:梳理開發網游服務端的網絡接入層的過程中面臨的各種技術挑戰,并針對性地提供相應的實時通信網絡接入層解決思路,希望對于即時通訊應用的開發者來說,可以從中得到些許啟發。


          [- 13 -] 騰訊技術分享:微信小程序音視頻與WebRTC互通的技術思路和實踐

          [鏈接] http://www.52im.net/thread-1988-1-1.html

          [摘要] 本文來自騰訊視頻云終端技術總監rexchang(常青)技術分享,內容分別介紹了微信小程序視音視頻和WebRTC的技術特征、差異等,并針對兩者的技術差異分享和總結了微信小程序視音視頻和WebRTC互通的實現思路以及技術方案。希望能帶給你啟發。


          [- 14 -] 愛奇藝技術分享:輕松詼諧,講解視頻編解碼技術的過去、現在和將來

          [鏈接] http://www.52im.net/thread-3028-1-1.html

          [摘要] 本文以輕松幽默的語氣,講解了視頻編解碼的一些基本常識,并以愛奇藝為例,講述了視頻編解碼技術在國內的發展以及未來的一些展望。


          [- 15 -] 零基礎入門:實時音視頻技術基礎知識全面盤點

          [鏈接] http://www.52im.net/thread-3079-1-1.html

          [摘要] 本文是作者自已根據入門實時音視頻的親身經歷,對于基礎知識點的認知總結。雖然很淺顯,但相對小白來說,能稍微系統的了解這些概念就已經是很好的起點了。


          [- 16 -] 實時音視頻面視必備:快速掌握11個視頻技術相關的基礎概念

          [鏈接] http://www.52im.net/thread-3194-1-1.html

          [摘要] 本文將通過通俗的文字,言簡意賅地為你講解實時音視頻技術中跟視頻技術在關的11個非常重要的基礎知識概念,希望能為你日后從事這方面的工作起到拋磚引玉的作用。


          [- 17 -] 實時音視頻開發理論必備:如何省流量?視頻高度壓縮背后的預測技術

          [鏈接] http://www.52im.net/thread-3581-1-1.html

          [摘要] 本文將從視頻編解碼技術的基礎知識入手,引出視頻編解碼技術中非常基礎且重要的預測技術,學習幀內預測和幀間預測的技術原理。


          ??52im社區本周新文:《即時通訊安全篇(十三):信創必學,一文讀懂什么是國密算法》,歡迎閱讀!??

          我是Jack Jiang,我為自已帶鹽!https://github.com/JackJiang2011/MobileIMSDK/

          posted @ 2023-12-13 11:57 Jack Jiang 閱讀(81) | 評論 (0)編輯 收藏

          一、關于RainbowChat-Web

          RainbowChat-Web是一套Web網頁端IM系統,是RainbowChat的姊妹系統(RainbowChat是一套基于開源IM聊天框架 MobileIMSDK (Github地址)  的產品級移動端IM系統)。

          二、v6.0 版更新內容

          此版更新內容更多歷史更新日志):

          • 1)[bug][服務端] - 解決了群成員從首頁“消息”列表中刪除已解散群的item時沒有反應的問題;
          • 2)[新增][服務端] - 安全提升,實現了一套新的token生成、校驗機制(支持對稱加密和非對稱加密兩種模式);
          • 3)[新增][服務端] - 安全提升,啟用了AppKey校驗機制;
          • 4)[新增][前端]    - 優化了http接口、文件上傳接口校驗邏輯,提升安全性;
          • 5)[新增][前端]    - 安全提升,啟用了AppKey校驗機制;
          • 6)[新增][前端]    - 新增發送“群名片”消息功能;
          • 7)[新增][前端]    - 新增了消息轉發功能;
          • 8)[優化][前端]    - 其它細節優化等。

          三、v6.0 版新增特性截圖

          “群名片”功能運行截圖查看演示視頻更多運行截圖):

          “消息轉發”功能(查看演示視頻更多運行截圖):

          posted @ 2023-12-11 12:08 Jack Jiang 閱讀(56) | 評論 (0)編輯 收藏

               摘要: 本文由字節跳動技術團隊高原、湯中峰分享,原題“抖音功耗優化實踐”,本文有修訂和改動。一、引言功耗優化是應用體驗優化的一個重要課題,高功耗會引發用戶的電量焦慮,也會導致糟糕的發熱體驗,從而降低了用戶的使用意愿。而功耗又是涉及整機的長時間多場景的綜合性復雜指標,影響因素很多。不論是功耗的量化拆解,還是異常問題的監控,以及主動的功耗優化對于開發人員來說都是很有挑戰性的。本文結合抖...  閱讀全文

          posted @ 2023-12-07 11:37 Jack Jiang 閱讀(264) | 評論 (0)編輯 收藏

          為了更好地分類閱讀 52im.net 總計1000多篇精編文章,我將在每周三推送新的一期技術文集,本次是第26 期。

          [- 1 -] 實時語音聊天中的音頻處理與編碼壓縮技術簡述

          [鏈接] http://www.52im.net/thread-825-1-1.html

          [摘要] 在視頻或者音頻通話過程中,一方面為了減小原始聲音數據的傳輸碼率,需要進行音頻壓縮,另一方面為了得到更高質量的音質,需要進行音頻處理。如何處理好這兩方面,保證聲音傳播的高真性,是個技術活兒!

          [- 2 -] 網易視頻云技術分享:音頻處理與壓縮技術快速入門

          [鏈接] http://www.52im.net/thread-678-1-1.html

          [摘要] 隨著音頻處理和壓縮技術的不斷發展,效果更好、適用范圍更廣、性能更高的算法和新的技術必將不斷涌現,不斷改善我們的生活。

          [- 3 -] 學習RFC3550:RTP/RTCP實時傳輸協議基礎知識

          [鏈接] http://www.52im.net/thread-590-1-1.html

          [摘要] 本文對這些協議進行初步歸納總結,在分析RFC3550的基礎上,重點分析RTP系列協議,并以報文類型為主線分析RTCP系列協議。

          [- 4 -]基于RTMP數據傳輸協議的實時流媒體技術研究(論文全文)

          [鏈接] http://www.52im.net/thread-273-1-1.html

          [摘要] 本文來自論文《基于 RTMP 協議的流媒體技術的原理與應用》,文中研究了基于 Flash 平臺的流媒體系統中使用的 RTMP 協議的原理和應用,并對網絡上實時流媒體的各種傳輸方式的優缺點進行了分析。

          [- 5 -] 聲網架構師談實時音視頻云的實現難點(視頻采訪)

          [鏈接] http://www.52im.net/thread-399-1-1.html

          [摘要] 孫雨潤,聲網 Agora.io 首席音視頻架構師,負責全球音視頻傳輸技術架構。畢業于中國科學技術大學,原 YY 后臺架構師,主導 Web YY 整體后臺系統架構搭建。曾任職騰訊 QQ 研究員 ,主導 QQ 空間面孔墻等項目;任職微軟 Microsoft 期間,參與高性能計算產品項目。

          [- 6 -] 還在靠“喂喂喂”測試實時語音通話質量?本文教你科學的評測方法!

          [鏈接] http://www.52im.net/thread-507-1-1.html

          [摘要] 實時語音聊天開發,對于一般的開發者來說比較神秘,很多朋友不太清楚如何全面的評估一個音頻引擎。

          [- 7 -] 如何用最簡單的方法測試你的實時音視頻方案

          [鏈接] http://www.52im.net/thread-535-1-1.html

          [摘要] 本文總結了一些有關實時音視頻方案比較值得自測的要點,旨在沒有生產環境反饋和豐富的測試資源情況下,用較低的成本來測試覆蓋盡可能多的真實場景中可能遇到的網絡和設備問題。

          [- 8 -] 簡述實時音視頻聊天中端到端加密(E2EE)的工作原理

          [鏈接] http://www.52im.net/thread-763-1-1.html

          [摘要] 本文著重闡述端到端加密(E2EE),端到端加密是確保數據傳輸安全的可行方法之一。讀完這篇文章,你可以了解這種加密方式的基本原理.

          [- -]  理論聯系實際:實現一個簡單地基于HTML5的實時視頻直播

          [鏈接] http://www.52im.net/thread-875-1-1.html

          [摘要] 本次分享就向大家介紹一下分享一下直播的整個流程和一些技術點,并動手實現一個簡單的Demo。

          [- 10 -] IM實時音視頻聊天時的回聲消除技術詳解

          [鏈接] http://www.52im.net/thread-939-1-1.html

          [摘要] 為了不讓文章讀起來枯燥,本文將盡量通俗易懂地為您講解實時音視頻聊天場景下的回聲消除技術原因希望能帶給你些許啟發。

          [- 11 -] 如何優化傳輸機制來實現實時音視頻的超低延遲?

          [鏈接] http://www.52im.net/thread-1008-1-1.html

          [摘要] 要在語音視頻 SDK 中實現超低延遲,實時的語音視頻傳輸機制是必不可少的,而 FEC 和 ARQ 的智能結合是實時語音視頻傳輸機制的基石。

          [- 12 -] 實時通信RTC技術棧之:視頻編解碼

          [鏈接] http://www.52im.net/thread-1034-1-1.html

          [摘要] 本文是系列文章的第一篇:講述視頻編解碼的一些基本知識。

          [- 13 -] Android直播入門實踐:動手搭建一套簡單的直播系統

          [鏈接] http://www.52im.net/thread-1154-1-1.html

          [摘要] 實時視頻直播是這兩年非常火的技術形態,已經滲透到教育、在線互娛等各種業務場景中。但要搭建一套實時視頻直播系統,并非易事,當然相關的直播技術理論在論壇的其它文章里已經寫的非常詳細,本文不再展開。

          [- 14 -] 網易云信實時視頻直播在TCP數據傳輸層的一些優化思路

          [鏈接] http://www.52im.net/thread-1254-1-1.html

          [摘要] 網易云信的實時視頻直播目前使用了TCP進行傳輸,且基于此,從編碼動態適配、發送隊列調整、協議優化、socket等做了全流程的優化,確保在限帶寬、丟包、時延、抖動,無論單項還是復雜網絡,都有非常不錯的實際體驗。

          [- 15 -] 實時音視頻聊天技術分享:面向不可靠網絡的抗丟包編解碼器

          [鏈接] http://www.52im.net/thread-1281-1-1.html

          [摘要] 編解碼器面向直播和網絡通信是不一樣的,我今天想說的是面向不可靠傳輸網絡的抗丟包編解碼器。

          [- 16 -] P2P技術如何將實時視頻直播帶寬降低75%?

          [鏈接] http://www.52im.net/thread-1289-1-1.html

          [摘要] 那整個系統是怎么設計的?使用了哪些技術來達成目標?接下來我來重點分享一下架構設計和技術細節。

          ??52im社區本周新文:《抖音技術分享:抖音Android端手機功耗問題的全面分析和詳細優化實踐》,歡迎閱讀!??

          我是Jack Jiang,我為自已帶鹽!https://github.com/JackJiang2011/MobileIMSDK/

          posted @ 2023-12-06 12:22 Jack Jiang 閱讀(79) | 評論 (0)編輯 收藏

               摘要: 本文由竹子愛熊貓分享,原題“(十一)Netty實戰篇:基于Netty框架打造一款高性能的IM即時通訊程序”,本文有修訂和改動。1、引言關于Netty網絡框架的內容,前面已經講了兩個章節,但總歸來說難以真正掌握,畢竟只是對其中一個個組件進行講解,很難讓諸位將其串起來形成一條線,所以本章中則會結合實戰案例,對Netty進行更深層次的學習與掌握,實戰案例也并不難,一個非常樸素的I...  閱讀全文

          posted @ 2023-11-30 12:28 Jack Jiang 閱讀(99) | 評論 (0)編輯 收藏

          僅列出標題
          共50頁: First 上一頁 7 8 9 10 11 12 13 14 15 下一頁 Last 
          Jack Jiang的 Mail: jb2011@163.com, 聯系QQ: 413980957, 微信: hellojackjiang
          主站蜘蛛池模板: 泰兴市| 苏尼特右旗| 师宗县| 洛隆县| 花垣县| 叙永县| 阿拉尔市| 芜湖县| 九江县| 花莲市| 云龙县| 稷山县| 普定县| 龙州县| 南木林县| 忻州市| 托克逊县| 永康市| 蒙山县| 郧西县| 广东省| 杭锦后旗| 夏津县| 鄂伦春自治旗| 堆龙德庆县| 犍为县| 宜州市| 淮南市| 洛浦县| 井冈山市| 宝应县| 江北区| 多伦县| 廉江市| 申扎县| 三都| 文水县| 嵩明县| 鸡泽县| 绥棱县| 宝清县|