本文由融云技術(shù)團(tuán)隊分享，有修訂和改動。

1、引言

Electron 憑借其相對更低的研發(fā)成本投入、強(qiáng)大的跨平臺支持、擁有基數(shù)龐大的 Javascript 開發(fā)者受眾等優(yōu)勢，在 PC 端跨平臺桌面開發(fā)領(lǐng)域異軍突起，大受歡迎。

本文分享的是融云基于Electron的IM跨平臺PC端SDK改造過程中所總結(jié)的一些實踐經(jīng)驗，希望對你有用。

* 友情提示：如果您對Electron的基礎(chǔ)概念還不太了解，建議您先從本系列文章的首篇《快速了解新一代跨平臺桌面技術(shù)——Electron》和第2篇《Electron初體驗(快速開始、跨進(jìn)程通信、打包、踩坑等)》開始閱讀，否則可能難以理解本文的有關(guān)內(nèi)容。

學(xué)習(xí)交流：

（本文已同步發(fā)布于：http://www.52im.net/thread-4060-1-1.html）

2、系列文章

本文是系列文章中的第5篇，本系列總目錄如下：

• 《IM跨平臺技術(shù)學(xué)習(xí)(一)：快速了解新一代跨平臺桌面技術(shù)——Electron》
• 《IM跨平臺技術(shù)學(xué)習(xí)(二)：Electron初體驗(快速開始、跨進(jìn)程通信、打包、踩坑等)》
• 《IM跨平臺技術(shù)學(xué)習(xí)(三)：vivo的Electron技術(shù)棧選型、全方位實踐總結(jié)》
• 《IM跨平臺技術(shù)學(xué)習(xí)(四)：蘑菇街基于Electron開發(fā)IM客戶端的技術(shù)實踐》
• 《IM跨平臺技術(shù)學(xué)習(xí)(五)：融云基于Electron的IM跨平臺SDK改造實踐總結(jié)》（* 本文）
• 《IM跨平臺技術(shù)學(xué)習(xí)(六)：網(wǎng)易云信基于Electron的IM消息全文檢索技術(shù)實踐》（稍后發(fā)布.. ）

3、本次改造的技術(shù)目標(biāo)

針對本次改造，我們需要達(dá)到以下4個技術(shù)目標(biāo)：

• 1）需提供與傳統(tǒng)桌面通訊軟件相匹配的能力支持；
• 2）需實現(xiàn)瀏覽器與Electron不同運(yùn)行時代碼的高度復(fù)用；
• 3）便于開發(fā)者構(gòu)建多窗口、多進(jìn)程的復(fù)雜桌面端應(yīng)用；
• 4）需同步適配同一IM端SDK的多個版本。

以下，我們將逐條討論這4個目標(biāo)所有實現(xiàn)的具體技術(shù)內(nèi)容。

4、技術(shù)目標(biāo)1：需提供與傳統(tǒng)桌面通訊軟件相匹配的能力支持

相較于 B/S 架構(gòu)的 Web 網(wǎng)頁應(yīng)用，我們期望能夠在 Electron 環(huán)境下向開發(fā)者提供更為豐富的本地化能力，以及比 Websocket（或Comet）更高效的Socket實時雙工通信通道。

借助這些原本在瀏覽器環(huán)境下不便實現(xiàn)的技術(shù)能力，來整體提高用戶對于桌面端產(chǎn)品的使用體驗，將 Electron 作為一個 C/S 架構(gòu)軟件運(yùn)行平臺的潛力發(fā)揮到最大。（白話就是，我們希望借助Electron這個框架，將原本W(wǎng)eb端的一些雞肋能力，做到像原生富客戶端一樣）

5、技術(shù)目標(biāo)2：瀏覽器與Electron不同運(yùn)行時代碼的高度復(fù)用

由于 Electron 與標(biāo)準(zhǔn) Web 應(yīng)用擁有幾乎相同的技術(shù)生態(tài)，因此多數(shù)產(chǎn)品會要求前端代碼工程兼顧瀏覽器與 Electron。

也就是說，一套代碼既要打包為傳統(tǒng)桌面端應(yīng)用（利用Electron），又可發(fā)布為瀏覽器中運(yùn)行的 Web 網(wǎng)頁應(yīng)用。

基于此，我們提供的 IM SDK 需要在兩種不同的運(yùn)行時環(huán)境下做到差異最小化，避免開發(fā)者編寫冗余的平臺兼容代碼。（白話就是，盡可能在基于Electron的桌面端和純Web網(wǎng)頁端之間重用更多的代碼，不然又得多擼一個全新的Electron端，這得多費勁）

6、技術(shù)目標(biāo)3：便于開發(fā)者構(gòu)建多窗口、多進(jìn)程的復(fù)雜桌面端應(yīng)用

Electron 通過對 IPC 能力的封裝為桌面端應(yīng)用開發(fā)提供了較完善的跨進(jìn)程通訊方案，借助此能力，開發(fā)者構(gòu)建的桌面端應(yīng)用也逐漸趨于復(fù)雜。

比較典型的如桌面端IM產(chǎn)品：通常用一個獨立窗口做基礎(chǔ)的 IM 聊天業(yè)務(wù)，一個窗口做歷史聊天記錄查詢業(yè)務(wù)。

當(dāng)有音視頻會議業(yè)務(wù)場景時，還需要再開一個窗口做會議業(yè)務(wù)。

甚至有開發(fā)者提出了與每個聊天對象都保持一個獨立聊天窗口的需求（產(chǎn)品形態(tài)如 QQ）。

在這類需求下，長連接狀態(tài)維持、消息同步變得異常復(fù)雜，原因在于以下3個方面。

• 1）若每個進(jìn)程窗口都維持獨立長連接，難免會出現(xiàn)某一進(jìn)程連接與其他進(jìn)程連接狀態(tài)不同步。且開發(fā)者需在各進(jìn)程同時維護(hù)連接狀態(tài)，復(fù)雜度較高。同時還會造成服務(wù)的并發(fā)能力下降。
• 2）若僅有單一主窗口進(jìn)行連接維持，其他窗口通過 IPC 能力將主窗口作為連接代理，則需要在主進(jìn)程、各渲染進(jìn)程中維護(hù)復(fù)雜的跨進(jìn)程通訊業(yè)務(wù)代碼，從而推高項目整體的復(fù)雜度。
• 3）目前的 Electron 開發(fā)者絕大多數(shù)來自于 Web 開發(fā)者，既有編程思維是建立在瀏覽器頁面內(nèi)單進(jìn)程單線程的應(yīng)用模型下構(gòu)建起來的，對于處理此類多進(jìn)程模型的產(chǎn)品開發(fā)缺乏相關(guān)的經(jīng)驗積累。

為降低類似需求場景的業(yè)務(wù)實現(xiàn)復(fù)雜度，我們需要在 PaaS 能力層面上解決多進(jìn)程連接共享、多進(jìn)程消息同步問題，讓開發(fā)者在既有編程思維模式下將每個業(yè)務(wù)實現(xiàn)的更為順暢。

7、技術(shù)目標(biāo)4：需同步適配同一IM端SDK的多個版本

我們的既有Web端 IM SDK 存在一個端多個不同版本的情況（主要是為了兼容老用戶，舊版本很難一刀切直接扔掉，只能新老版末同時并存）。

各版本都有不同數(shù)量的客戶積累，且各版本 API 接口設(shè)計迥異，跨版本升級成本較高。

考慮到使用不同版本的客戶未來將業(yè)務(wù)向 Electron 遷移的可能性，我們期望通過架構(gòu)設(shè)計的改進(jìn)來避免既有客戶做過多的集成代碼修改，在確保既有客戶不因版本升級而流失的前提下降低 Web 研發(fā)團(tuán)隊自身的多版本 SDK 維護(hù)成本。

8、本次改造的落地實踐

針對上面章節(jié)中確定的技術(shù)目標(biāo)，我們將從以下3個方向著手落地實踐：

• 1）剝離各版本的共同業(yè)務(wù)與對外差異性 API 定義；
• 2）Electron 與瀏覽器平臺下 IM SDK 的區(qū)分；
• 3）解決多進(jìn)程消息同步、多進(jìn)程連接共享問題。
  以下，我們將逐條分享這3個方面的具體實踐內(nèi)容。

9、落地實踐1：剝離各版本的共同業(yè)務(wù)與對外差異性API定義

我們的 IM SDK 各版本分別為不同的代碼倉庫獨立維護(hù)，互無干系。（白話就是，所有端的IM SDK都是獨立開發(fā)，從頭造輪子）

這導(dǎo)致所有的功能（包括即將開發(fā)的 Electron 桌面解決方案）都可能要在各個版本倉庫上單獨實現(xiàn)，不僅開發(fā)成本高，還會導(dǎo)致實現(xiàn)質(zhì)量無法保證、或代碼實現(xiàn)不統(tǒng)一，同時也推高了產(chǎn)研后續(xù)流程的測試、上線等環(huán)節(jié)的成本。

▲ IM SDK 不同版本獨立維護(hù)

基于前述技術(shù)目標(biāo)4的要求，在既有現(xiàn)狀下繼續(xù)開發(fā)，就意味著需要在兩個版本的基礎(chǔ)上做不同實現(xiàn)，既不符合程序員的代碼審美，也影響團(tuán)隊整體的研發(fā)效率。（白話就是，如果又要從頭造輪子實在太難受）

為更好地達(dá)成技術(shù)目標(biāo)4，團(tuán)隊決定優(yōu)先通過重構(gòu)將既有業(yè)務(wù)分層，即各個版本所必須的業(yè)務(wù)代碼抽象下沉為 IM Engine 包，并為各個版本 IM SDK 分別實現(xiàn)不同的API Layer以便與既有線上版本接口對齊，這樣既可以降低團(tuán)隊的研發(fā)成本，也可以滿足既有線上客戶后續(xù)的升級需求。

▲ 重構(gòu)代碼實現(xiàn)業(yè)務(wù)分層

完成業(yè)務(wù)分層后，對于 IM SDK 有依賴的其他產(chǎn)品如 RTC SDK，也都可以擺脫對 IM SDK 接口的依賴而直接調(diào)用 Engine 層接口，業(yè)務(wù)層在拓展 RTC 業(yè)務(wù)時，也就無需再考慮 IM SDK 的版本問題。

▲ 業(yè)務(wù)分層后的結(jié)構(gòu)將保證拓展性

做分層的另一個考慮還為了達(dá)成技術(shù)目標(biāo)2，將與業(yè)務(wù)層的交互限制在 API 層，在 Engine 中處理 Electron 與瀏覽器兩種運(yùn)行時下的代碼差異，業(yè)務(wù)層只需關(guān)心 IM SDK 的接口調(diào)用而無需關(guān)心底層差異，確保業(yè)務(wù)層在兩種運(yùn)行時下只需要維護(hù)極少甚至無需維護(hù)兼容代碼，便于業(yè)務(wù)層更專注于業(yè)務(wù)開發(fā)。

10、落地實踐2：Electron 與瀏覽器平臺下 IM SDK 的區(qū)分

在將 Engine 與業(yè)務(wù)層隔離后（見上一節(jié)），需要考慮 Engine 在不同的運(yùn)行時下的關(guān)鍵能力差異，并依據(jù)能力差異落實 Engine 的底層設(shè)計。

Electron 環(huán)境下的連接、消息存儲等能力由 c++ 模塊編寫提供（即后面提到的 CppProto.node）：

在瀏覽器與 Electron 平臺下，從連接管理、到消息收發(fā)等實現(xiàn)方式迥異，團(tuán)隊需要對 Engine 包繼續(xù)分層，通過 AEngine 抽象類來定義 IM Engine 的能力接口，并抽象 APIContext 類用來管理 AEngine 的能力調(diào)用。

考慮到純 Web 應(yīng)用構(gòu)建尺寸問題，Electron 的能力實現(xiàn)代碼不應(yīng)被打包到標(biāo)準(zhǔn) Web 頁面內(nèi)，因此還需要將 Electron 平臺下的實現(xiàn)代碼單獨抽離出來作為一個獨立包（即ElectronSolution），作為可選模塊由開發(fā)者選擇安裝使用。

▲ Electron相關(guān)的代碼抽離為可選模塊

如上圖所示，CppEngine 在 ElectronSolution 包中定義，其需要由開發(fā)者在 Electron 應(yīng)用創(chuàng)建 BrowserWindow 實例時通過 webPreferences.preload 配置屬性向渲染進(jìn)程窗口預(yù)掛載。

APIContext 在初始化 AEngine 實例時，優(yōu)先檢測 CppEngine 是否已定義。當(dāng)發(fā)現(xiàn)有 CppEngine 定義時，則初始化 CppEngine 提供更豐富的本地化能力，否則初始化 JSEngine。

就像下面的代碼的展現(xiàn)的邏輯：

const engine: AEngine = typeofCppEngine !== 'undefined'

  ? newCppEngine()

  : newJSEngine()

11、落地實踐3：解決多進(jìn)程消息同步、多進(jìn)程連接共享問題

ElectronSolution 包截止目前的設(shè)計中，所有代碼都運(yùn)行在渲染進(jìn)程內(nèi)。

這意味著每個進(jìn)程彼此獨立，都在維護(hù)獨立的進(jìn)程狀態(tài)，無法滿足目標(biāo) 3 中多進(jìn)程狀態(tài)同步、連接共享的需求。

為了解決該問題，需要將 CppProto.node 模塊放到主進(jìn)程，在主進(jìn)程中實現(xiàn)連接管理、消息收發(fā)等能力，多個渲染進(jìn)程通過 IPC 通信共享主進(jìn)程狀態(tài)。

▲ 多個渲染進(jìn)程通過 IPC 通信共享主進(jìn)程狀態(tài)

為了達(dá)成技術(shù)目標(biāo)3的要求，ElectronSolution 需要拆分為兩個子包，即Main 與 Renderer。

具體就是：

• 1）Main 包運(yùn)行在主進(jìn)程內(nèi)，負(fù)責(zé)維持 CppProto.node 模塊的調(diào)用，實現(xiàn)底層連接管理、消息管理等功能，同時通過 Electron 提供的 ipcMain 與各渲染進(jìn)程維持通信；
• 2）Renderer 包中定義 CppEngine 類，繼承自 Engine 包內(nèi)的 AEngine 抽象類，依然通過 webPreferences.preload 用來作為主進(jìn)程的代理，通過 ipcRenderer 與主進(jìn)程維持通信。

▲ 拆分為Main與Renderer兩個子包

修改完成后，ElectronSolution 包的整體結(jié)構(gòu)基本確定。

以下列出 ElectronSolution 包關(guān)鍵目錄結(jié)構(gòu)供參考：

node_modules/@rongcloud/electron-solution

├── index.js

├── main

│   ├── addon

│   │   ├── binding

│   │   │   └── electron-v{electron-version}-{platform}-{arch}.node

│   │   └── index.js

│   ├── dist

│   │   └── index.js

│   ├── index.js

│   └── package.json

└── renderer

│   ├── dist

│   │   └── index.js

│   ├── index.js

│   └── package.json

└── package.json

基于上述架構(gòu)變動，當(dāng)業(yè)務(wù)層需要在多個渲染進(jìn)程中實現(xiàn) IM 能力時，僅需要關(guān)注在各個進(jìn)程中的 IM SDK 接口調(diào)用，由 ElectronSolution 處理多進(jìn)程之間的狀態(tài)同步問題。

當(dāng)開發(fā)者期望由既有 Web 業(yè)務(wù)向 Electron 平臺遷移時，開發(fā)者也無需修改既有的 Web 業(yè)務(wù)代碼，僅需要增量編寫主進(jìn)程代碼相關(guān)功能實現(xiàn)，將 ElectronSolution 安裝并集成到 Electron 桌面端應(yīng)用中即可。

最終，我們形成了以下這樣的IM SDK整體結(jié)構(gòu)：

12、未來的規(guī)劃

除了上述IM相關(guān)業(yè)務(wù)，后續(xù)我們還打算在Electron平臺下提升RTC的場景能力。

目前，Electron 平臺下由 Chromium 原始提供的 WebRTC 能力對于開發(fā)桌面級音視頻應(yīng)用軟件來說相對薄弱，我們有計劃探索借助 node.js 的拓展能力，提供更為底層的 WebRTC 能力拓展如音效、音質(zhì)、視頻特效等。

13、參考資料

[1] 快速了解新一代跨平臺桌面技術(shù)——Electron

[2] Electron初體驗(快速開始、跨進(jìn)程通信、打包、踩坑等)

[3] WebSocket從入門到精通，半小時就夠！

[4] Comet技術(shù)詳解：基于HTTP長連接的Web端實時通信技術(shù)

[5] 一套海量在線用戶的移動端IM架構(gòu)設(shè)計實踐分享(含詳細(xì)圖文)

[6] Web端即時通訊技術(shù)盤點：短輪詢、Comet、Websocket、SSE

[7] 搞懂現(xiàn)代Web端即時通訊技術(shù)一文就夠：WebSocket、socket.io、SSE

（本文已同步發(fā)布于：http://www.52im.net/thread-4060-1-1.html）

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

第 1 篇

[標(biāo)題] 腦殘式網(wǎng)絡(luò)編程入門(一)：跟著動畫來學(xué)TCP三次握手和四次揮手

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

[摘要]網(wǎng)絡(luò)編程中TCP協(xié)議的三次握手和四次揮手的問題，在面試中是最為常見的知識點之一。本篇文章嘗試使用動畫圖片的方式，來對這個知識點進(jìn)行“腦殘式”講解（哈哈），期望讀者們可以更加簡單、直觀地理解TCP網(wǎng)絡(luò)通信交互的本質(zhì)。

第 2 篇

[標(biāo)題] 腦殘式網(wǎng)絡(luò)編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？

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

[摘要] 套接字socket是大多數(shù)程序員都非常熟悉的概念，它是計算機(jī)網(wǎng)絡(luò)編程的基礎(chǔ)，TCP/UDP收發(fā)消息都靠它。本篇文章依然嘗試使用動畫圖片的方式，來對這個知識點進(jìn)行“腦殘式”講解（哈哈），期望讀者們可以更加簡單、直觀地理解Socket通信的數(shù)據(jù)讀寫本質(zhì)。

第 3 篇

[標(biāo)題] 腦殘式網(wǎng)絡(luò)編程入門(三)：HTTP協(xié)議必知必會的一些知識

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

[摘要]無論是即時通訊應(yīng)用還是傳統(tǒng)的信息系統(tǒng)，Http協(xié)議都是我們最常打交道的網(wǎng)絡(luò)應(yīng)用層協(xié)議之一，它的重要性可能不需要再強(qiáng)調(diào)。但是實際上很多人（包括我自己），雖然每天都會跟http的代碼打交道，但對http了解的并不夠深入。本文就我自己的學(xué)習(xí)心得，分享一下我認(rèn)為需要知道的http常見的相關(guān)知識點。

第 4 篇

[標(biāo)題] 腦殘式網(wǎng)絡(luò)編程入門(四)：快速理解HTTP/2的服務(wù)器推送(Server Push)

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

[摘要] 服務(wù)器推送（server push）是 HTTP/2 協(xié)議里面唯一一個需要開發(fā)者自己配置的功能。其他功能都是服務(wù)器和瀏覽器自動實現(xiàn)，不需要開發(fā)者關(guān)心。本文詳細(xì)介紹新一代HTTP/2服務(wù)器推送技術(shù)（server push）的原理和配置方法等。

第 5 篇

[標(biāo)題] 腦殘式網(wǎng)絡(luò)編程入門(五)：每天都在用的Ping命令，它到底是什么？

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

[摘要] Ping命令很簡單，但作為為數(shù)不多的網(wǎng)絡(luò)檢測工具，卻非常有用，是開發(fā)網(wǎng)絡(luò)應(yīng)用時最常用到的命令。雖然“Ping”這個動作這么簡單，但你知道Ping命令背后后的邏輯嗎？這就是本文要告訴你！

第 6 篇

[標(biāo)題] 腦殘式網(wǎng)絡(luò)編程入門(六)：什么是公網(wǎng)IP和內(nèi)網(wǎng)IP？NAT轉(zhuǎn)換又是什么鬼？

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

[摘要] 搞網(wǎng)絡(luò)通信應(yīng)用開發(fā)的程序員，可能會經(jīng)常聽到外網(wǎng)IP（即互聯(lián)網(wǎng)IP地址）和內(nèi)網(wǎng)IP（即局域網(wǎng)IP地址），但他們的區(qū)別是什么？又有什么關(guān)系呢？另外，內(nèi)行都知道，提到外網(wǎng)IP和內(nèi)網(wǎng)IP就不得不提NAT路由轉(zhuǎn)換這種東西，那這又是什么鬼？本文就來簡單講講這些到底都是怎么回事。

第 7 篇

[標(biāo)題] 腦殘式網(wǎng)絡(luò)編程入門(七)：面視必備，史上最通俗計算機(jī)網(wǎng)絡(luò)分層詳解

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

[摘要] 輸入URL，到頁面呈現(xiàn)出來，其中經(jīng)歷了什么？這道面試題的背后，涉及到了很多網(wǎng)絡(luò)原理的知識，我們這篇文章不會全部分享到，而是先把由來和網(wǎng)絡(luò)層次劃分弄清楚，就完成了這篇文章的目的。

第 8 篇

[標(biāo)題] 腦殘式網(wǎng)絡(luò)編程入門(八)：你真的了解127.0.0.1和0.0.0.0的區(qū)別？

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

[摘要] 對于后端程序員來說，127.0.0.1和0.0.0.0這兩個IP地址再熟悉不過了，看起來好像就那么回事，但真正較起真來，這兩個IP地址到底有什么作用以及到底有什么不同？貌似誰可以輕松回答，但張嘴卻又不知從何說起。本文將系統(tǒng)地總結(jié)127.0.0.1和0.0.0.0這兩個IP地址的作用，以及它們之間的區(qū)別，希望能為你解惑。

第 9 篇

[標(biāo)題] 腦殘式網(wǎng)絡(luò)編程入門(九)：面試必考，史上最通俗大小端字節(jié)序詳解

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

[摘要] 程序員在寫應(yīng)用層程序時，一般不需要考慮字節(jié)序問題，因為字節(jié)序跟操作系統(tǒng)和硬件環(huán)境有關(guān)，而我們編寫的程序要么不需要跨平臺（比如只運(yùn)行在windows），要么需要跨平臺時會由Java這種跨平臺語言在虛擬機(jī)層屏蔽掉了。但典型情況，當(dāng)你編寫網(wǎng)絡(luò)通信程序，比如IM聊天應(yīng)用時，就必須要考慮字節(jié)序問題，因為你的數(shù)據(jù)在這樣的場景下要跨機(jī)器、跨網(wǎng)絡(luò)通信，必須解決不同系統(tǒng)、不同平臺的字節(jié)序問題。

第 10 篇

[標(biāo)題] 網(wǎng)絡(luò)編程入門從未如此簡單(一)：假如你來設(shè)計網(wǎng)絡(luò)，會怎么做？

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

[摘要] 本篇主要以通俗易懂的文風(fēng)，引導(dǎo)你理解計算機(jī)網(wǎng)絡(luò)是如何演化成今日的樣子，文中穿插了集線器、交換楊、路由器等設(shè)備的使用背景以及技術(shù)原理，由淺入深，非常適合入門者閱讀。

第 11 篇

[標(biāo)題] 網(wǎng)絡(luò)編程入門從未如此簡單(二)：假如你來設(shè)計TCP協(xié)議，會怎么做？

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

[摘要] 本篇將運(yùn)用通俗易懂的語言，配上細(xì)致精確的圖片動畫，循序漸進(jìn)地引導(dǎo)你理解TCP協(xié)議的主要特性和技術(shù)原理，讓TCP協(xié)議的學(xué)習(xí)不再如此枯燥和生澀，非常適合入門者閱讀。

第 12 篇

[標(biāo)題] 網(wǎng)絡(luò)編程入門從未如此簡單(三)：什么是IPv6？漫畫式圖文，一篇即懂！

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

[摘要] 本篇文章將利用簡潔生動的文字，配上輕松幽默的漫畫，助你從零開始快速建立起對IPv6技術(shù)的直觀理解，非常適合入門者閱讀。

我是Jack Jiang，我為自已帶鹽！

https://github.com/JackJiang2011/MobileIMSDK/

關(guān)于MobileIMSDK

MobileIMSDK 是一套專門為移動端開發(fā)的開源IM即時通訊框架，超輕量級、高度提煉，一套API優(yōu)雅支持UDP 、TCP 、WebSocket 三種協(xié)議，支持iOS、Android、H5、標(biāo)準(zhǔn)Java平臺，服務(wù)端基于Netty編寫。

工程開源地址是：

• 1）Gitee碼云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

關(guān)于RainbowChat

► 詳細(xì)產(chǎn)品介紹：http://www.52im.net/thread-19-1-1.html
► iOS端更新記錄：http://www.52im.net/thread-2735-1-1.html
► 全部運(yùn)行截圖：iOS端全部運(yùn)行截圖 （另：Android端運(yùn)行截圖 點此查看）
► 在線體驗下載：App Store安裝地址 （另：Android端下載體驗 點此查看）

RainbowChat是一套基于開源IM聊天框架 MobileIMSDK 的產(chǎn)品級移動端IM系統(tǒng)。RainbowChat源于真實運(yùn)營的產(chǎn)品，解決了大量的屏幕適配、細(xì)節(jié)優(yōu)化、機(jī)器兼容問題（可自行下載體驗：專業(yè)版下載安裝）。

* RainbowChat可能是市面上提供im即時通訊聊天源碼的，唯一一款同時支持TCP、UDP兩種通信協(xié)議的IM產(chǎn)品（通信層基于開源IM聊天框架  MobileIMSDK 實現(xiàn)）。

v6.0 版更新內(nèi)容

此版更新內(nèi)容【新增“一鍵已讀、搜索”等功能！】（更多歷史更新日志）：

• 1）[新增] 搜索功能（支持好友、群聊、聊天記錄搜索(與微信邏輯一樣)）；
• 2）[新增] “聊天信息”界面中新增“查找聊天記錄”功能；
• 3）[新增] “群聊信息”界面中新增“查找聊天記錄”功能；
• 4）[新增] 首頁消息界面中，增加了“一鍵已讀”功能；
• 5）[bug] 解決了iOS16+“靈動島”手機(jī)下，聊天界面功能面板和輸入法顯示的沖突；
• 6）[優(yōu)化] 優(yōu)化了聊天界面中查看位置、名片消息回來時會自動滾動到最后一行的問題。

此版主要新增功能運(yùn)行截圖（更多截圖點此查看）：

為了更好地分類閱讀總計1000多篇精編文章，我將在每周三推送新的一期技術(shù)文集，本次是第1 期。

第1 篇

[標(biāo)題] 網(wǎng)絡(luò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）

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

[摘要] 互聯(lián)網(wǎng)的核心是一系列協(xié)議，總稱為"互聯(lián)網(wǎng)協(xié)議"（Internet Protocol Suite）。它們對電腦如何連接和組網(wǎng)，做出了詳盡的規(guī)定。理解了這些協(xié)議，就理解了互聯(lián)網(wǎng)的原理。本篇將帶你從理論上快速理解這些協(xié)議。

第2 篇

[標(biāo)題] 網(wǎng)絡(luò)編程懶人入門(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）

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

[摘要] 接上篇，本篇將以普通人實際上網(wǎng)為例子，通俗易懂地講解網(wǎng)絡(luò)通信協(xié)議到底是什么。本篇帶了有些基礎(chǔ)的計網(wǎng)理論知識，但力求通俗不枯燥。

第3 篇

[標(biāo)題]網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠

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

[摘要] TCP 是互聯(lián)網(wǎng)的核心協(xié)議之一，鑒于它的重要性，本文將單獨介紹它的基礎(chǔ)知識，希望能加深您對TCP協(xié)議的理解。

第4 篇

[標(biāo)題]網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異

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

[摘要] 對于即時通訊開者新手來說，在開始著手編寫IM或消息推送系統(tǒng)的代碼前，最頭疼的問題莫過于到底該選TCP還是UDP作為傳輸層協(xié)議。本文延續(xù)《網(wǎng)絡(luò)編程懶人入門》系列文章的風(fēng)格，通過快速對比分析 TCP 和 UDP 的區(qū)別，來幫助即時通訊初學(xué)者快速了解這些基礎(chǔ)的知識點，從而在IM、消息推送等網(wǎng)絡(luò)通信應(yīng)用場景中能準(zhǔn)確地選擇合適的傳輸層協(xié)議。

第5 篇

[標(biāo)題]網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢

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

[摘要] 隨著網(wǎng)絡(luò)技術(shù)飛速發(fā)展，網(wǎng)速已不再是傳輸?shù)钠款i，UDP協(xié)議以其簡單、傳輸快的優(yōu)勢，在越來越多場景下取代了TCP，如網(wǎng)頁瀏覽、流媒體、實時游戲、物聯(lián)網(wǎng)。本文作為《網(wǎng)絡(luò)編程懶人入門》系列文章的第5篇，將為您快速梳理UDP協(xié)議在某些場景下對比TCP協(xié)議所具有的優(yōu)勢。

第6 篇

[標(biāo)題]網(wǎng)絡(luò)編程懶人入門(六)：史上最通俗的集線器、交換機(jī)、路由器功能原理入門

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

[摘要] 本文旨在簡單地說明集線器、交換機(jī)與路由器的區(qū)別，因而忽略了很多細(xì)節(jié)，三者實際的發(fā)展過程和工作原理并非文中所寫的這么簡單。如果你看完本文能大概了解到三者的異同，本文的目的就達(dá)到了。

第7 篇

[標(biāo)題] 網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議

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

[摘要] 對于移動端即時通訊（尤其IM應(yīng)用）來說，現(xiàn)今主流的數(shù)據(jù)通信總結(jié)下來無外乎就是長連接+短連接的方式，而短連接在應(yīng)用上講就是本文將要介紹的HTTP協(xié)議的應(yīng)用，而正確地理解HTTP協(xié)議對于寫好IM來說，是相當(dāng)有益的（關(guān)于移動端的HTTP具體應(yīng)用情況，可以閱讀《現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應(yīng)、安全保障http://www.52im.net/thread-1413-1-1.html》）。

第8 篇

[標(biāo)題] 網(wǎng)絡(luò)編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接

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

[摘要] TCP 是互聯(lián)網(wǎng)的核心協(xié)議之一，鑒于它的重要性，希望通過閱讀上面介紹的幾篇理論文章，再針對本文的動手實踐，能真正加深您對TCP協(xié)議的理解。

第9 篇

[標(biāo)題] 網(wǎng)絡(luò)編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？

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

[摘要] 標(biāo)題雖然是為了解釋有了 IP 地址，為什么還要用 MAC 地址，但是本文的重點在于理解為什么要有 IP 這樣的東西。本文對讀者的定位是知道 MAC 地址是什么，IP 地址是什么。

第10 篇

[標(biāo)題] 網(wǎng)絡(luò)編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協(xié)議

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

[摘要] 一般的穩(wěn)定網(wǎng)絡(luò)傳輸都是通過TCP，但是在網(wǎng)絡(luò)基建本身就已經(jīng)越來越完善的情況下，TCP設(shè)計本身的問題便暴露了出來，特別是在弱網(wǎng)環(huán)境下，讓我們不得不考慮一些新的可能性。

第11 篇

[標(biāo)題] 網(wǎng)絡(luò)編程懶人入門(十一)：一文讀懂什么是IPv6

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

[摘要] 本文將用淺顯易懂的文字，帶你了解到底什么是IPv6。

第12 篇

[標(biāo)題]網(wǎng)絡(luò)編程懶人入門(十二)：快速讀懂Http/3協(xié)議，一篇就夠！

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

[摘要] 多年來，為了跟上互聯(lián)網(wǎng)的發(fā)展，以及WWW上交換的內(nèi)容種類增加，HTTP進(jìn)行了幾次重大升級，而HTTP/3就是目前的最新版本。本文將從HTTP/3的基本概念、技術(shù)原理、應(yīng)用場景和如何使用它等方面進(jìn)行介紹，確保在有限的篇幅內(nèi)，能讓你通俗地理解它。

第13 篇

[標(biāo)題]網(wǎng)絡(luò)編程懶人入門(十三)：一泡尿的時間，快速搞懂TCP和UDP的區(qū)別

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

[摘要] 不同于其它長篇大論，本文盡量以簡潔精煉的文字，幫你總結(jié)歸納TCP和UDP協(xié)議的主要區(qū)別，方便那些想掌握這方面知識又不愿意耗費太多時間去系統(tǒng)地學(xué)習(xí)網(wǎng)絡(luò)理論基礎(chǔ)的同學(xué)快速理解！

第14 篇

[標(biāo)題]網(wǎng)絡(luò)編程懶人入門(十四)：到底什么是Socket？一文即懂！

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

[摘要] 本系列文章前面那些主要講解的是計算機(jī)網(wǎng)絡(luò)的理論基礎(chǔ)，但對于即時通訊IM這方面的應(yīng)用層開發(fā)者來說，跟計算機(jī)網(wǎng)絡(luò)打道的其實是各種API接口。本篇文章就來聊一下網(wǎng)絡(luò)應(yīng)用程序員最熟悉的Socket這個東西，拋開生澀的計算機(jī)網(wǎng)絡(luò)理論，從應(yīng)用層的角度來理解到底什么是Socket。

我是Jack Jiang，我為自已帶鹽！

https://github.com/JackJiang2011/MobileIMSDK/

關(guān)于MobileIMSDK

MobileIMSDK 是一套專門為移動端開發(fā)的開源IM即時通訊框架，超輕量級、高度提煉，一套API優(yōu)雅支持UDP 、TCP 、WebSocket 三種協(xié)議，支持iOS、Android、H5、標(biāo)準(zhǔn)Java平臺，服務(wù)端基于Netty編寫。

工程開源地址是：

• 1）Gitee碼云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

關(guān)于RainbowChat

► 詳細(xì)產(chǎn)品介紹：http://www.52im.net/thread-19-1-1.html
► iOS端更新記錄：http://www.52im.net/thread-2735-1-1.html
► 全部運(yùn)行截圖：iOS端全部運(yùn)行截圖 （另：Android端運(yùn)行截圖 點此查看）
► 在線體驗下載：App Store安裝地址 （另：Android端下載體驗 點此查看）

RainbowChat是一套基于開源IM聊天框架 MobileIMSDK 的產(chǎn)品級移動端IM系統(tǒng)。RainbowChat源于真實運(yùn)營的產(chǎn)品，解決了大量的屏幕適配、細(xì)節(jié)優(yōu)化、機(jī)器兼容問題（可自行下載體驗：專業(yè)版下載安裝）。

* RainbowChat可能是市面上提供im即時通訊聊天源碼的，唯一一款同時支持TCP、UDP兩種通信協(xié)議的IM產(chǎn)品（通信層基于開源IM聊天框架  MobileIMSDK 實現(xiàn)）。

v5.0 版更新內(nèi)容

此版更新內(nèi)容【新增“掃一掃”等功能】（更多歷史更新日志）：

• 1）[新增] “掃一掃”界面及功能邏輯；
• 2）[新增] “我的二維碼”界面及功能邏輯；
• 3）[新增] “群聊二維碼”界面及功能邏輯；
• 4）[優(yōu)化] 相關(guān)界面中的彈出菜單UI細(xì)節(jié)優(yōu)化。

此版主要新增功能運(yùn)行截圖（更多截圖點此查看）：

本文由融云技術(shù)團(tuán)隊分享，原題“互聯(lián)網(wǎng)通信安全之端到端加密技術(shù)”，內(nèi)容有較多修訂和改動。

1、引言

在上篇《IM聊天系統(tǒng)安全手段之通信連接層加密技術(shù)》中，分享了關(guān)于通信連接層加密的相關(guān)技術(shù)和實踐，包括在傳輸即時通信消息時啟用 TLS 鏈路加密（保證消息在到達(dá)服務(wù)器前無法被竊聽和篡改）、使用 CA 認(rèn)證機(jī)制（杜絕中間人攻擊）等。

本篇將圍繞IM傳輸內(nèi)容的安全問題，以實踐為基礎(chǔ)，為你分享即時通訊應(yīng)用中的“端到端”加密技術(shù)。

學(xué)習(xí)交流：

（本文已同步發(fā)布于：http://www.52im.net/thread-4026-1-1.html）

2、系列文章

本文是IM通訊安全知識系列文章中的第11篇，此系列總目錄如下：

• 《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
• 《即時通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》
• 《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
• 《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風(fēng)險》
• 《即時通訊安全篇（五）：對稱加密技術(shù)在Android平臺上的應(yīng)用實踐》
• 《即時通訊安全篇（六）：非對稱加密技術(shù)的原理與應(yīng)用實踐》
• 《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
• 《即時通訊安全篇（八）：你知道，HTTPS用的是對稱加密還是非對稱加密？》
• 《即時通訊安全篇（九）：為什么要用HTTPS？深入淺出，探密短連接的安全性》
• 《即時通訊安全篇（十）：IM聊天系統(tǒng)安全手段之通信連接層加密技術(shù)》
• 《即時通訊安全篇（十一）：IM聊天系統(tǒng)安全手段之傳輸內(nèi)容端到端加密技術(shù)》（* 本文）

3、為什么需要端到端加密？

上篇中提到的連接層加密技術(shù)，這是提升IM客戶端到服務(wù)器之間數(shù)據(jù)傳輸?shù)陌踩允侄危沁@并不能解決用戶間的通信隱私性以及安全性風(fēng)險。

因為在將數(shù)據(jù)傳輸?shù)椒?wù)器之后，所有有權(quán)訪問此服務(wù)器的人，包括員工、供應(yīng)商及其他有關(guān)人員（甚至黑客），都有可能讀取到用戶的數(shù)據(jù)。

有鑒于此，端到端加密技術(shù)在即時通訊IM領(lǐng)域被廣泛應(yīng)用，包括WhatsApp、Signal、Telegram 等國外即時通信軟件中都有使用。

PS：有關(guān)端到端加密的基礎(chǔ)知識，可以從這兩篇里得到，建議詳讀：

• 《移動端安全通信的利器——端到端加密（E2EE）技術(shù)詳解》
• 《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》

4、端到端加密的技術(shù)設(shè)計思路

4.1 簡化版思路

說到端到端加密，我們首先想到的解決方案是：在發(fā)送端發(fā)送消息前對整個消息進(jìn)行加密，接收端接收到消息后進(jìn)行解密。

如上這樣：消息中轉(zhuǎn)服務(wù)器就無法獲取我們的消息內(nèi)容了。

事實上：這確實是端到端加密中消息收發(fā)的簡化版解決方案，只是我們在實際應(yīng)用中要更加復(fù)雜，效果也更加安全。

4.2 如何安全地傳遞用于消息加解密的密鑰

對于端到端加密，我們需要先解決的前置安全問題是：如何安全地傳遞用于消息加解密的密鑰。

答案是：用非對稱加密的方式傳輸密鑰（與 SSL / TLS 中安全交換密鑰的方式類似）。

非對稱加密傳輸對稱加密密鑰的算法，一般歸結(jié)兩種方式：

• 1）一種是以 RSA、ECC 等為主（公鑰加密私鑰解密的方式，本質(zhì)是加解密的算法）；
• 2）另一種是以 DH、ECDH 為主的生成共享密鑰的方式（本質(zhì)是通過計算協(xié)商一個共同的密鑰而不是加解密算法）。

實際上：大部分即時通信軟件中的端到端加密都采用生成共享密鑰的方式來傳輸會話密鑰。這是為什么呢？

這就涉及到 DH 算法（即 Diffie-Hellman 密鑰交換算法），關(guān)于DH算法的資料，有興趣可以詳讀《Diffie-Hellman密鑰協(xié)商算法》，限于篇幅，這里不專門討論。

Diffie-Hellman 密鑰交換算法的安全性依賴于這樣一個事實：雖然計算以一個素數(shù)為模的指數(shù)相對容易，但計算離散對數(shù)卻很困難。對于大的素數(shù)，計算出離散對數(shù)幾乎是不可能的。

這里簡要描述一下 DH 共享密鑰的過程如下：

（其中“密鑰 S”即為最終的共享密鑰）

4.3 采用共享密鑰的原因

端到端加密采用共享密鑰的方式來傳輸會話密鑰有如下幾個原因：

1）如果采用 RSA、ECC 等公鑰加密私鑰解密的方式傳輸密鑰，需要在創(chuàng)建會話時生成臨時密鑰，并通過對方公鑰加密后傳輸?shù)浇邮斩恕?/p>

這就需要完全保證消息的可靠性，如果該消息在任何一個環(huán)節(jié)中丟失或損壞，則后續(xù)通信都無法進(jìn)行。或者，需要采用更為可靠的傳輸方案，通常做法為需要接收端在線，通過各種確認(rèn)來保證這個可靠性。

而采用共享密鑰的方式則只需要知道對方的公鑰，就可以完成生成共享密鑰，并不一定需要對方在線。

2）如果已經(jīng)生成的臨時對稱密鑰丟失，則需要重新協(xié)商密鑰。而采用共享密鑰的方式則只需要知道對方的公鑰，就可以完成生成共享密鑰，不需要重新協(xié)商。

3）采用公鑰加密私鑰解密的方式至少會比生成共享密鑰方式多一次交換對稱密鑰的通信過程。

4）密鑰協(xié)商方式，不僅僅可以完成兩個點之間的密鑰協(xié)商，還可以延展到多人之間的共同協(xié)商出相同的密鑰，這樣能滿足多人群體溝通的需求。

5、端到端加密的初步實踐方案

我們結(jié)合對于 DH 算法（即 Diffie-Hellman 密鑰交換算法）這種共享密鑰方式的認(rèn)知（即公鑰可隨意公開），先設(shè)計一個簡單的端到端消息加密的過程。

這個過程的邏輯流程如下：

• 1）在客戶端 APP 首次安裝時，基于服務(wù)器公開的兩個全局的參數(shù)，生成自己的 DH 公鑰和私鑰；
• 2）將自己的公鑰上傳證書服務(wù)器，證書服務(wù)器上保存用戶標(biāo)識與其公鑰的關(guān)系。私鑰則保存在客戶端上；
• 3）首次給對方發(fā)送消息或首次接收到對方消息時，便到證書服務(wù)器查詢對方的公鑰；
• 4）根據(jù)對方公鑰和自己的私鑰計算出共享密鑰；
• 5）后續(xù)與對方所有的消息都基于這個密鑰和相同的對稱加解密算法進(jìn)行加密解密操作。

端到端消息加密過程示意：

至此：我們完成了一個簡單的端到端消息加密方案，在這個方案中我們引入了一個第三方的用于存儲用戶公鑰的角色，這個角色的存在可以讓任何一方都不用關(guān)心對方的在線狀態(tài)，隨時給對方發(fā)送加密過消息，而消息轉(zhuǎn)發(fā)服務(wù)器無法解密消息。

接下來，我們針對這個簡單方案存在的各種安全隱患問題，進(jìn)行逐步分析和優(yōu)化。

6、端到端加密實踐方案的進(jìn)一步優(yōu)化和演進(jìn)

6.1 使用HMAC作為消息完整性認(rèn)證算法

在消息傳輸過程中，雙方需要確認(rèn)彼此消息的完整性，簡單的做法就是將消息進(jìn)行 Hash，得到的 Hash 值附加到消息后，隨消息一起發(fā)送；對端接收后，同樣進(jìn)行 Hash，來驗證消息是否被篡改。

關(guān)鍵點在于不同數(shù)據(jù)得到的 Hash 值一定不同，其中帶密鑰的 Hash 值就是 MAC算法。

另外，為了避免使用同樣的 Hash 函數(shù)對相同數(shù)據(jù)進(jìn)行操作總是得出同樣的值，額外加入一個密鑰，這樣使用不同密鑰就可以得出不同的 MAC。當(dāng)然，這個密鑰是兩個對端都知道的。

這樣，我們就得到了基于加密 Hash 的消息完整性認(rèn)證的算法——Hash-based MAC（簡稱HMAC）。

基礎(chǔ)知識1：什么是MAC算法？

全稱Message Authentication Code，即消息認(rèn)證碼（帶密鑰的Hash函數(shù)）。在密碼學(xué)中，MAC是通信實體雙方使用的一種驗證機(jī)制，是保證消息數(shù)據(jù)完整性的一種工具。

MAC算法的安全性依賴于Hash函數(shù)，故也稱帶密鑰的Hash函數(shù)。消息認(rèn)證碼是基于密鑰和消息摘要“hash”所獲得的一個值，可用于數(shù)據(jù)源發(fā)認(rèn)證和完整性校驗。

使用 MAC 驗證消息完整性的具體過程是：

• 1）假設(shè)通信雙方 A 和 B 共享密鑰 K，A用消息認(rèn)證碼算法將 K 和消息 M 計算出消息驗證碼 Mac，然后將 Mac 和 M 一起發(fā)送給 B；
• 2）B 接收到 Mac 和 M 后，利用 M 和 K 計算出新的驗證碼 Mac*，若 Mac*和Mac 相等則驗證成功，證明消息未被篡改。

由于攻擊者沒有密鑰 K，攻擊者修改了消息內(nèi)容后無法計算出相應(yīng)的消息驗證碼，因此 B 就能夠發(fā)現(xiàn)消息完整性遭到破壞。

簡而言之就是：

• 1）發(fā)送者通過MAC算法計算出消息的MAC值，并和消息一起發(fā)給收信者；
• 2）收信者用同樣的MAC算法計算收到的消息的MAC值，并對比兩者。

下圖是原理示意：

基礎(chǔ)知識2：什么是HMAC算法？

HMAC是MAC算法中的一種，其基于加密HASH算法實現(xiàn)。任何加密HASH, 比如MD5、SHA256等，都可以用來實現(xiàn)HMAC算法，其相應(yīng)的算法稱為HMAC-MD5、HMAC-SHA256等。

6.2 使用ECDH算法替換DH算法

DH 算法是以離散對數(shù)的數(shù)學(xué)難題為基礎(chǔ)的，隨著計算機(jī)計算能力逐步增強(qiáng)，我們要不停地使用更大的數(shù)以增加破解難度，目前業(yè)界普遍認(rèn)為至少需要使用 2048 位 DH 算法才具備更好的安全性。

在此我們引入 ECDH 算法替換 DH 算法。ECDH 密鑰協(xié)商算法是 ECC 算法和 DH 密鑰交換原理結(jié)合使用。ECC 是建立在基于橢圓曲線的離散對數(shù)問題上的密碼體制。在相同破解難度下，ECC 具有更小長度的密鑰和更快的正向計算速度優(yōu)勢。

我們系統(tǒng)上的 ECDH 可以直接采用目前公開的 sepc256kl 和 Curve25519 曲線，而無需服務(wù)再提供公開大數(shù)參數(shù)。

6.3 提升前向安全性

在消息傳輸過程中，如果協(xié)商好的密鑰泄露了，就意味著所有信息都將暴露于風(fēng)險之下。

為了防止這種情況發(fā)生，我們需要每次加密使用的密鑰都與上一次不同，且不可以反向推導(dǎo)得出之前的密鑰。

此處引入一個 Hash 算法：這個 Hash 算法可以通過輸入一個密鑰導(dǎo)出另外一個離散性更大的密鑰，每次發(fā)送消息時都是用上次的消息密鑰進(jìn)行 Hash 運(yùn)算得出本次密鑰，由于 Hash 算法具有單向不可逆的特性，因此就無法通過本次的密鑰推導(dǎo)之前的密鑰。

從感觀上，這就像一個棘輪，棘輪就是一種特殊的齒輪，他只能往一個方向轉(zhuǎn)下去，而不能往回轉(zhuǎn)。

我們先來感性認(rèn)識一下棘輪：

在技術(shù)上，做到"只能往一個方向轉(zhuǎn)下去，而不能往回轉(zhuǎn)"，是達(dá)到前向安全的關(guān)鍵。這就保證了，如果某一輪的密鑰被破解出來，但前面的密鑰是無法計算出來的，也就是前面的消息無法被解密。

6.4 同時保證前向安全和后向安全性

出于極致的安全性要求，我們會同時考慮前向安全和后向安全。如何保證在某次通信中，被破解出來的密鑰，不能破解出之前的消息，而且在一定周期內(nèi)，這個破解出來的密鑰將不會再起作用。

介于此我們再引入另外一個棘輪來保證其向后的安全性。這就是大名鼎鼎的 Signal protocol 中的雙棘輪算法。

Signal protocol 是真正的端到端的通訊加密協(xié)議，號稱是世界上最安全的通訊協(xié)議，任何第三方包括服務(wù)器都無法查看通訊內(nèi)容。

雙棘輪算法包含一個 KDF 棘輪和一個 DH 棘輪。

KDF 全稱（Key derivation function） 密鑰導(dǎo)出函數(shù)，用于從一個原始的密鑰導(dǎo)出一個或多個密鑰。本質(zhì)上就是 Hash 函數(shù)，通常用來將短密碼變成長密碼。另外 KDF 需要加“鹽”（salt），用于防彩虹表，出于 Hash 的特性，這個“鹽”的長度至少要大于 Hash 結(jié)果長度。

KDF (原密鑰，鹽) = 導(dǎo)出密鑰

KDF 棘輪就是運(yùn)用 KDF 算法，設(shè)計出一種密鑰不斷變化的效果，流程如下：

首先：將初始密鑰使用 KDF 算法導(dǎo)出新的密鑰，新密鑰被切成兩部分，前半部分作為下一次 KDF 計算的輸入，后半部分作為消息密鑰。

每迭代一次（也可以說棘輪步進(jìn)一次），就會生成新的消息密鑰。

由于 KDF 算法的單向性，通過這條消息的密鑰無法倒推出上一條消息密鑰，這就保證了密鑰的前向安全。但是如果 KDF 中的鹽被掌握，那么它就可以按照這種算法計算出以后所有的消息密鑰。

為了保證后向安全，就要設(shè)計一種方法，使每次迭代時引入的鹽是隨機(jī)的，從而保證每次的消息密鑰是不可以向后推算的。

由前面介紹的 DH 算法得知：兩對密鑰對可以通過 DH 協(xié)議生成一個安全的協(xié)商密鑰，如果更換其中一個密鑰對，新的協(xié)商密鑰也會變化。

根據(jù)這個方法：我們可以設(shè)計出一個安全更新鹽的方法。我們在證書服務(wù)器增加一個臨時公鑰證書，這個臨時證書是按照接收雙方標(biāo)識構(gòu)建的臨時公鑰對，即每個人的每個單人會話都具備一個臨時公鑰。每進(jìn)行一個消息輪回，就更新一次己方的臨時公鑰，同時根據(jù)另外一方的臨時公鑰和己方的私鑰進(jìn)行協(xié)商，并將協(xié)商出的密鑰作為鹽，使得 KDF 棘輪算法生成的消息密鑰具有后向安全性。

在初始時我們無法預(yù)測出每個人所有的新二人會話：那么我們就可以規(guī)定創(chuàng)建新的二人會話時，發(fā)起方首先生成一個新的臨時 DH 公私鑰對，并向服務(wù)器上傳自己的臨時 DH 公鑰；其次發(fā)送方用接收方公布的長期公鑰與自己的臨時私鑰協(xié)商出密鑰作為消息加密的密鑰，對消息進(jìn)行加密；最后接收方首次接收到消息后用自己的長期公鑰和發(fā)送方的臨時私鑰計算得出消息密鑰，并在首次回復(fù)消息時生成臨時公私鑰，同時上傳臨時公鑰。

問題是：如果接收端不在線，而發(fā)送端每條消息都去更新己方的臨時公鑰證書，就會導(dǎo)致發(fā)出去的這些消息，在接收端上線并收取后無法被正常解密。

為了解決這個問題，我們需要規(guī)定：只有在發(fā)出消息并得到對方回復(fù)后才更新臨時證書，若對方不回復(fù)消息則不去更新臨時證書。接收端能回復(fù)消息就表示其已經(jīng)上線并接收完消息，這樣就可以保證離線消息或者消息亂序也可以被對方正常解析。這種方法就是雙棘輪算法中的另外一個 DH 棘輪。

6.5 更安全的密鑰交換協(xié)議—— X3DH

對比最初的方案，為了滿足消息的前向安全和后向安全，我們增加了雙棘輪算法，在原基礎(chǔ)方案上為每個人增加了一組會話級別臨時 DH 密鑰，每個人都擁有一個長期密鑰和一組臨時密鑰。

但是：由于長期密鑰無法被更換，所以方案依然存在著安全隱患。

因此：Signal protocol 設(shè)計了一種更為復(fù)雜和安全的 DH 密鑰交換過程，稱之為 X3DH（即 DH 協(xié)議的 3 倍擴(kuò)展版）。

在 X3DH 協(xié)議里，每個人都要創(chuàng)建 3 種密鑰對，分別如下：

• 1）身份密鑰對（Identity Key Pair）：一個長期的符合 DH 協(xié)議的密鑰對，用戶注冊時創(chuàng)建，與用戶身份綁定；
• 2）已簽名的預(yù)共享密鑰（Signed Pre Key）：一個中期的符合 DH 協(xié)議的密鑰對，用戶注冊時創(chuàng)建，由身份密鑰簽名，并定期進(jìn)行輪換，此密鑰可能是為了保護(hù)身份密鑰不被泄露；
• 3）一次性預(yù)共享密鑰（One-Time Pre Keys）：一次性使用的 Curve25519 密鑰對隊列，安裝時生成，不足時補(bǔ)充。

所有人都要將這 3 種密鑰對的公鑰上傳到服務(wù)器上，以便其他人發(fā)起會話時使用。

假如 Alice 要給 Bob 發(fā)送消息，首先要和 Bob 確定消息密鑰，流程大致如下：

• 1）Alice 要創(chuàng)建一個臨時密鑰對（ephemeral key），我們設(shè)成 EPK-A，此密鑰對是為了后面棘輪算法準(zhǔn)備，在此處作用不大；
• 2）Alice 從服務(wù)器獲取 Bob 的三種密鑰對的公鑰：身份密鑰對IPK-B、已簽名的預(yù)共享密鑰 SPK-B、一次性預(yù)共享密鑰 OPK-B；
• 3）Alice 開始使用 DH 協(xié)議計算協(xié)商密鑰，要引入?yún)?shù)包括：自己創(chuàng)建的兩個密鑰對的私鑰，以及 Bob 的三個公鑰。然后用類似排列組合的方式，將自己的私鑰與對方的公鑰分別帶入 DH 算法計算。

DH1 = DH(IPK-A, SPK-B)

DH2 = DH(EPK-A, IPK-B)

DH3 = DH(EPK-A, SPK-B)

DH4 = DH(IPK-A, OPK-B)

如圖所示：

然后將計算得到的四個值，前后連接起來，就得到了初始密鑰，如下：

DH = DH1 || DH2 || DH3 || DH4

注：“||”代表連接符，比如 456 || 123 = 456123

但是 DH 這個密鑰太長，不適合作為消息密鑰，所以對這個初始密鑰進(jìn)行一次 KDF 計算，以衍生出固定長度的消息密鑰 S：

S = KDF（DH1 || DH2 || DH3 || DH4）

這一步，Alice 終于計算出了消息密鑰 S。

于是：

• 1）Alice 使用消息密鑰 S 對消息進(jìn)行加密，連同自己的身份公鑰 IPK-A 和臨時公鑰 EPK-A 一同發(fā)給 Bob；
• 2）Bob 收到 Alice 的信息后，取出 Alice 的 2 個公鑰，連同自己的密鑰，使用與 Alice 相同的算法計算消息密鑰 S；
• 3）Bob 和 Alice 使用消息密鑰進(jìn)行加密通訊。

由上可知：X3DH 實際是復(fù)雜版的 DH 協(xié)議。

至此：我們簡單介紹了 Signal Protocol 中最為核心的 X3DH 協(xié)議與雙棘輪算法，基本上可以滿足前向安全和后向安全。當(dāng)然，真實的處理過程會更為復(fù)雜和安全。

7、IM群聊的端到端加密方案

在即時通訊場景中，除了二人之間的聊天以外，還有一個重要的場景就是群聊，那么群聊時的多人消息如何做端到端加密呢？

我們再次回到 DH 密鑰協(xié)商算法上的推導(dǎo)過程：顯然，多方情況下依然可以繼續(xù)使用 DH 密鑰協(xié)商算法，這就是群聊中端到端加密的基礎(chǔ)。

而 Signal Protocol 在群組聊天中的設(shè)計與二人聊天又有所不同，由于群聊的保密性要求相對低一些，只采用了 KDF 鏈棘輪+公鑰簽名來進(jìn)行加密通訊以保障加密的前向安全。

群組聊天的加解密通訊流程如下：

• 1）每個群組成員都要首先生成隨機(jī) 32 字節(jié)的 KDF 鏈密鑰(Chain Key)，用于生成消息密鑰，以保障消息密鑰的前向安全性，同時還要生成一個隨機(jī) Curve25519 簽名密鑰對，用于消息簽名；
• 2）每個群組成員用向其它成員單獨加密發(fā)送鏈密鑰(Chain Key)和簽名公鑰。此時每一個成員都擁有群內(nèi)所有成員的鏈密鑰和簽名公鑰；
• 3）當(dāng)一名成員發(fā)送消息時，首先用 KDF 鏈棘輪算法生成的消息密鑰加密消息，然后使用私鑰簽名，再將消息發(fā)給服務(wù)器，由服務(wù)器發(fā)送給其它成員；
• 4）其它成員收到加密消息后，首先使用發(fā)送人的簽名公鑰驗證，驗證成功后，使用相應(yīng)的鏈密鑰生成消息密鑰，并用消息密鑰解密；
• 5）當(dāng)群組成員離開時，所有的群組成員都清除自己鏈密鑰和簽名公鑰并重新生成，再次單獨發(fā)給每一位成員。這樣操作，離開的成員就無法查看群組內(nèi)的消息了。

由上可知：一個人在不同的群組里，會生成不同的鏈密鑰和簽名密鑰對，以保障群組之間的隔離。在每個群組中，每個成員還要存儲其它成員的 KDF 鏈和簽名公鑰，如果群組成員過多，加解密運(yùn)算量非常大，會影響發(fā)送和接收速度，同時密鑰管理數(shù)據(jù)庫也會非常大，讀取效率也會降低。

所以：群組聊天使用 Signal Protocol 協(xié)議，群人數(shù)不宜太多。

8、端到端加密方案的補(bǔ)充說明

上面我們介紹了即時通信中二人聊天和群組聊天的端到端加密全部過程。但是正常情況下端到端消息加密只是加密消息的實際負(fù)載部分（即只加密消息“體”部分），而消息的控制層則不會被加密，因為消息轉(zhuǎn)發(fā)服務(wù)器需要根據(jù)控制信息進(jìn)行消息轉(zhuǎn)發(fā)或路由（否則肯定大大影響IM底層的路由和通信效率，因為需要反復(fù)加密解密）。

為了防止消息被定向分析（分析用戶什么時間向誰發(fā)送了消息，或接收了誰的消息），我們依然需要對整體即時通信的長連接鏈路進(jìn)行加密保護(hù)（這說的就是上篇文章里的通信連接層加密技術(shù)了），防止信息被中間網(wǎng)絡(luò)設(shè)備截獲并分析。而且為了防止密鑰服務(wù)器被中間人攻擊，也需要開啟鏈路加密保護(hù)。

9、參考資料

[1] 移動端安全通信的利器——端到端加密（E2EE）技術(shù)詳解

[2] 簡述實時音視頻聊天中端到端加密（E2EE）的工作原理

[3] HASH、MAC、HMAC學(xué)習(xí)

[4] 一文了解加解密、哈希函數(shù)、MAC、數(shù)字簽名、證書、CA等

[5] 雙棘輪算法：端對端加密安全協(xié)議，原理以及流程詳解

[6] Signal protocol 開源協(xié)議理解

[7] X25519（Curve25519）橢圓曲線參考資料

（本文已同步發(fā)布于：http://www.52im.net/thread-4026-1-1.html）

本文由融云技術(shù)團(tuán)隊分享，原題“互聯(lián)網(wǎng)通信安全之端到端加密技術(shù)”，內(nèi)容有修訂和改動。

1、引言

隨著移動互聯(lián)網(wǎng)的普及，IM即時通訊類應(yīng)用幾乎替代了傳統(tǒng)運(yùn)營商的電話、短信等功能。得益于即時通訊技術(shù)的實時性優(yōu)勢，使得人與人之間的溝通和交流突破了空間、時間等等限制，讓信息的傳遞變的無處不在。

但互聯(lián)網(wǎng)為我們的生活帶來極大便利的同時，用戶的隱私和通信安全問題也隨之而來。

對于IM應(yīng)用開發(fā)者來說，信息溝通的開放性也意味著風(fēng)險性，用戶與網(wǎng)絡(luò)和移動設(shè)備的高度依賴，也為不法之徒提供了可乘之機(jī)。因此，提升即時通訊應(yīng)用的安全性尤其重要。

本篇文章將圍繞IM通信連接層的安全問題及實現(xiàn)方案，聚焦IM網(wǎng)絡(luò)“鏈路安全”，希望能帶給你啟發(fā)。

學(xué)習(xí)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4015-1-1.html）

2、系列文章

本文是IM通訊安全知識系列文章中的第10篇，此系列總目錄如下：

• 《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
• 《即時通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》
• 《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
• 《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風(fēng)險》
• 《即時通訊安全篇（五）：對稱加密技術(shù)在Android平臺上的應(yīng)用實踐》
• 《即時通訊安全篇（六）：非對稱加密技術(shù)的原理與應(yīng)用實踐》
• 《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》
• 《即時通訊安全篇（八）：你知道，HTTPS用的是對稱加密還是非對稱加密？》
• 《即時通訊安全篇（九）：為什么要用HTTPS？深入淺出，探密短連接的安全性》
• 《即時通訊安全篇（十）：IM聊天系統(tǒng)安全手段之通信連接層加密技術(shù)》（* 本文）
• 《即時通訊安全篇（十一）：IM聊天系統(tǒng)安全手段之傳輸內(nèi)容端到端加密技術(shù)》（稍后發(fā)布...）

3、即時通訊面臨的安全問題

1）竊取內(nèi)容：如果在整個即時通訊的通信過程中，其數(shù)據(jù)內(nèi)容是未加密或弱加密的，那么其信息被截獲后就可以直接被讀取出來。

那么，這就會導(dǎo)致用戶數(shù)據(jù)（包括個人隱私數(shù)據(jù)）的泄露，甚至可能危害用戶的財產(chǎn)安全（比如微信這類IM中，紅包、錢包都會涉及財產(chǎn)安全）。如果在辦公場景下，被竊取的還可能是公司商業(yè)機(jī)密，那勢必將會造成更大的經(jīng)濟(jì)損失。

2）篡改內(nèi)容：如果通信內(nèi)容被截獲后，對其進(jìn)行修改再發(fā)送，會破壞信息的正確性和完整性（此消息已非彼消息）。

3）偽造內(nèi)容：如果用戶通信憑證（比如token）被竊取或在通信過程中穿插其他信息，就可能為冒用用戶身份騙取與之通信者的信任創(chuàng)造可能，埋下更大的安全隱患。

4）傳播不法內(nèi)容：基于即時通訊系統(tǒng)的消息推送能力，不法分子除了可能傳播涉黃、涉賭、暴恐或危害國家安全的信息外，還可能傳播計算機(jī)木馬病毒等，可能帶來的危害范圍將進(jìn)一步擴(kuò)大。

4、常用的互聯(lián)網(wǎng)攻擊手段

網(wǎng)絡(luò)通信過程中常見的攻擊手段：

1）移植木馬：過在終端移植木馬，截獲或篡改信息。

2）偽造應(yīng)用：通過偽造 APP 或在 APP 中添加后門等方式，使終端用戶誤以為是正常應(yīng)用進(jìn)行使用，從而達(dá)到其不法目的。

3）網(wǎng)絡(luò)抓包：通過在網(wǎng)絡(luò)設(shè)備上進(jìn)行抓包，獲取用戶通信內(nèi)容。

4）中間人攻擊：通過劫持 DNS 等手段，使用戶通信連接經(jīng)過攻擊者的設(shè)備，從而達(dá)到竊取、篡改等目的。

5）漏洞挖掘：服務(wù)端或終端除了自有的程序以外還包含了各種三方組件或中間件，通過挖掘其上的漏洞，達(dá)到不法目的。

從上圖和手段可知，聊天信息從應(yīng)用經(jīng)過網(wǎng)絡(luò)到達(dá)服務(wù)端，這期間的任何一個環(huán)節(jié)都有可能被人利用。所以，在“危機(jī)四伏”的互聯(lián)網(wǎng)絡(luò)通信中，“安全”必須重視。

5、密碼學(xué)在即時通訊系統(tǒng)中的應(yīng)用

5.1 基本常識

針對前述的安全問題和攻擊手段，將密碼學(xué)應(yīng)用在即時通訊系統(tǒng)連接上，對通信數(shù)據(jù)進(jìn)行加密就變得尤為重要。

密碼學(xué)解決信息安全的三要素（CIA）即：

• 1）機(jī)密性（Confidentiality）：保證信息不泄露給未經(jīng)授權(quán)的用戶；
• 2）完整性（Integrity）：保證信息從真實的發(fā)信者傳送到真實的收信者手中，傳送過程中沒有被非法用戶添加、刪除、替換等；
• 3）可用性（Availability）：保證授權(quán)用戶能對數(shù)據(jù)進(jìn)行及時可靠的訪問。

以上表述，好像有點繞口，我們換個通俗一點的表述。。。

密碼學(xué)在網(wǎng)絡(luò)通信中的三大作用就是：

• 1）加密：防止壞人獲取你的數(shù)據(jù)；
• 2）認(rèn)證：防止壞人修改了你的數(shù)據(jù)而你卻并沒有發(fā)現(xiàn)；
• 3）鑒權(quán)：防止壞人假冒你的身份。

除 CIA 外，還有一些屬性也是要求達(dá)到的，如可控性（Controllability）和不可否認(rèn)性（Non-Repudiation）。

5.2 在即時通訊中的應(yīng)用

作為即時通訊中的關(guān)鍵組成，IM即時通訊系統(tǒng)為了實現(xiàn)消息的快速、實時送達(dá)，一般需要客戶端與服務(wù)器端建立一條socket長連接，用以快速地將消息送達(dá)到客戶端。

通常即時通訊客戶端會以 TCP 或 UDP 的方式與服務(wù)器建立連接，同時某些場景下也會使用 HTTP 的方式從服務(wù)器獲取或提交一些信息。

整個過程中所有的數(shù)據(jù)都需進(jìn)行加密處理，簡單的數(shù)據(jù)加密和解密過程可以歸納為：發(fā)送方輸入明文 -> 加密 -> 生成密文 -> 傳輸密文 -> 接收方解密 -> 得到明文。

這其中，會涉及：

• 1）對稱加密算法（詳見《對稱加密技術(shù)在Android平臺上的應(yīng)用實踐》）
• 2）非對稱加密算法（詳見《非對稱加密技術(shù)的原理與應(yīng)用實踐》）；
• 3）信息摘要算法（詳見《常用加解密算法與通訊安全講解》）。

這其中，我國也有一套自有的密碼算法（國密算法）：國密算法，即國家商用密碼算法，是由國家密碼管理局認(rèn)定和公布的密碼算法標(biāo)準(zhǔn)及其應(yīng)用規(guī)范，其中部分密碼算法已經(jīng)成為國際標(biāo)準(zhǔn)。如 SM 商用系列密碼：對稱加密算法 SM4、非對稱加密算法 SM2、信息摘要算法 SM3。

6、通信連接層的會話加密

對于連接層面（鏈路層面）面的加密，應(yīng)最先考慮的是基于 SSL/TLS 協(xié)議進(jìn)行鏈路加密（比如微信的作法：《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》），這是現(xiàn)代網(wǎng)絡(luò)通信安全的基石。

很多人認(rèn)為 SSL/TLS 協(xié)議是附加在 HTTP 協(xié)議上的，是 HTTPS 的一部分（詳見《為什么要用HTTPS？深入淺出，探密短連接的安全性》）。

其實這種理解不完全正確，SSL/TLS 是獨立于應(yīng)用層協(xié)議的，高層協(xié)議可以透明地分布在 SSL/TLS 協(xié)議上面。因此基于socket長連接的IM即時消息通訊協(xié)議也可以構(gòu)建在 SSL/TLS 協(xié)議上面。

SSL/TLS 是獨立于應(yīng)用層協(xié)議：

SSL/TLS 可以被簡單地歸納為：利用基于公私鑰體系的非對稱加密算法，傳輸對稱加解密算法的密鑰，并將后續(xù)通訊的數(shù)據(jù)包基于雙方相同的對稱加解密算法和密鑰進(jìn)行加密并傳輸，從而達(dá)到保證數(shù)據(jù)安全通訊的目的。

非對稱加密算法里面的公鑰和私鑰在數(shù)學(xué)上是相關(guān)的，這樣才能用一個加密、用另一個解密。不過，盡管是相關(guān)的，但以現(xiàn)有的數(shù)學(xué)算法，是沒有辦法從一個密鑰算出另一個密鑰。

另外需要著重強(qiáng)調(diào)的是：在系統(tǒng)中不要使用自簽證書，而要使用具備 CA 認(rèn)證的證書，這樣可以有效的防止中間人攻擊。

7、基于SSL/TLS的通信連接層如何實現(xiàn)會話的快速恢復(fù)

7.1 概述

客戶端和服務(wù)器端建立 SSL/TLS 握手時，需要完成很多步驟：密鑰協(xié)商出會話密鑰、數(shù)字簽名身份驗證、消息驗證碼 MAC 等。

整個握手階段比較耗時的是密鑰協(xié)商，需要密集的 CPU 處理。當(dāng)客戶端和服務(wù)器斷開了本次會話連接，那么它們之前連接時協(xié)商好的會話密鑰就消失了。在下一次客戶端連接服務(wù)器時，便要進(jìn)行一次新的完整的握手階段。

這似乎沒什么問題，但是當(dāng)系統(tǒng)中某一時間段里有大量的連接請求提交時，就會占用大量服務(wù)器資源，導(dǎo)致網(wǎng)絡(luò)延遲增加。

為了解決上面的問題，TLS/SSL 協(xié)議中提供了會話恢復(fù)的方式，允許客戶端和服務(wù)器端在某次關(guān)閉連接后，下一次客戶端訪問時恢復(fù)上一次的會話連接。

會話恢復(fù)有兩種：

• 1）一種是基于 Session ID 的恢復(fù)；
• 2）一種是使用 Session Ticket TLS 擴(kuò)展。

下面來看看兩種方式的優(yōu)劣。

7.2 基于Session ID的SSL/TLS長連接會話恢復(fù)

一次完整的握手階段結(jié)束后，客戶端和服務(wù)器端都保存有這個 Session ID。

在本次會話關(guān)閉，下一次再次連接時：客戶端在 Client Hello 子消息中附帶這個 Session ID 值，服務(wù)器端接收到請求后，將 Session ID 與自己在 Server Cache 中保存的 Session ID 進(jìn)行匹配。

如果匹配成功：服務(wù)器端就會恢復(fù)上一次的 TLS 連接，使用之前協(xié)商過的密鑰，不重新進(jìn)行密鑰協(xié)商，服務(wù)器收到帶 Session ID 的 Client Hello 且匹配成功后，直接發(fā)送 ChangeCipherSpec 子協(xié)議，告訴 TLS 記錄層將連接狀態(tài)切換成可讀和可寫，就完成會話的恢復(fù)。

基于Session ID 會話恢復(fù)原理：

雖然使用 Session ID 進(jìn)行會話恢復(fù)可以減少耗時的步驟，但由于 Session ID 主要保存在服務(wù)器 Server Cache 中，若再次連接請求時由于負(fù)載均衡設(shè)定將請求重定位到了其他服務(wù)器上，此時新的服務(wù)器 Server Cache 中沒有緩存與客戶端匹配的 Session ID，會導(dǎo)致會話無法恢復(fù)無法進(jìn)行，因此不建議選用  Session ID 方式進(jìn)行會話恢復(fù)。

7.3 基于SessionTicket的SSL/TLS長連接會話恢復(fù)

一次完整的握手過程后，服務(wù)器端將本次的會話數(shù)據(jù)（會話標(biāo)識符、證書、密碼套件和主密鑰等）進(jìn)行加密，加密后生成一個 ticket ，并將 ticket 通過 NewSessionTicket 子消息發(fā)送給客戶端，由客戶端來保存，下一次連接時客戶端就將 ticket 一起發(fā)送給服務(wù)器端，待服務(wù)器端解密校驗無誤后，就可以恢復(fù)上一次會話。

基于SessionTicket 會話恢復(fù)原理：

由于加解密都是在服務(wù)端閉環(huán)進(jìn)行，多服務(wù)只需要共享密鑰就可以完成此過程，相較于 Session ID 的方式，可以不依賴 Server Cache，因此 SessionTicket 會話恢復(fù)方式更有利于大型分布式系統(tǒng)使用。

8、本文小結(jié)

本文分享了IM即時通訊的通信連接層安全知識和加密技術(shù)等。

并著重強(qiáng)調(diào)了兩方面內(nèi)容。首先，在IM即時通訊系統(tǒng)中使用具備 CA 認(rèn)證的 SSL/TLS 證書可以保證傳輸安全，防止傳輸過程被監(jiān)聽、防止數(shù)據(jù)被竊取，確認(rèn)連接的真實性。其次，利用 SessionTicket 快速地進(jìn)行會話恢復(fù)可以提高整體系統(tǒng)性能，降低連接延時。

本文的下篇《即時通訊安全篇（十一）：IM聊天系統(tǒng)安全手段之傳輸內(nèi)容端到端加密技術(shù)》，將繼續(xù)分享基于IM傳輸內(nèi)容的端到端加密技術(shù)，敬請關(guān)注。

9、參考資料

[1] TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報協(xié)議

[2] TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議

[3] 網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠

[4] 網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異

[5] 零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實時性？

[6] 對稱加密技術(shù)在Android平臺上的應(yīng)用實踐

[7] 非對稱加密技術(shù)的原理與應(yīng)用實踐

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

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

[10] 為什么要用HTTPS？深入淺出，探密短連接的安全性

[11] 探討組合加密算法在IM中的應(yīng)用

（本文已同步發(fā)布于：http://www.52im.net/thread-4015-1-1.html）