前言
Web3.0時代的重要特點:
1、數(shù)據(jù)主權(quán)
用戶將擁有自己的數(shù)據(jù)主權(quán),用戶所創(chuàng)造的數(shù)字內(nèi)容,所有權(quán)和控制權(quán)都歸屬于用戶,用戶所創(chuàng)造的價值可以由用戶自主支配。對于IM業(yè)務,就是用戶的好友列表,聊天消息等數(shù)據(jù)屬于用戶,不屬于任何商業(yè)機構(gòu)。
2、去中心化
這個業(yè)務網(wǎng)絡不被任何人和組織所控制,任何人和組織都可以參與這個網(wǎng)絡,隨時都可以加入和退出,為全網(wǎng)用戶提供服務。用戶不屬于任何組織,組織是服務提供者不是用戶的擁有者。
基于以上Web3.0兩個特點,可以推導出Web3.0對IM的技術需求:
1.、動態(tài)網(wǎng)絡:網(wǎng)絡服務節(jié)點是動態(tài)的,全球任何一個地方的節(jié)點都可以隨時加入和退出網(wǎng)絡,任何節(jié)點的崩潰和退出都不影響網(wǎng)路正常運作。
2.、數(shù)據(jù)安全:用戶數(shù)據(jù)必須是加密的,聊天消息要支持端到端加密安全,服務節(jié)點只做存儲與轉(zhuǎn)發(fā),無法查看聊天消息和好友列表等數(shù)據(jù)內(nèi)容。
這些需求對技術架構(gòu)和實現(xiàn)具有非常大的挑戰(zhàn)。
第2點需求意味著需要支持動態(tài)擴容和索容。大家都知道,傳統(tǒng)web2.0技術是基于中心化的,服務器規(guī)格統(tǒng)一,性能都比較好,服務器之間的網(wǎng)絡延遲極小一般在1毫秒以下,集群出口帶寬可達到千兆甚至萬兆。即使是在這么好的條件下,動態(tài)平滑地擴容和縮容,服務平穩(wěn)運行都不是一件容易的事情。在去中心化環(huán)境中,參與網(wǎng)絡的節(jié)點的性能,配置,可靠性,網(wǎng)絡帶寬等參差不齊,機器隨時都可能關機,網(wǎng)絡隨時都可能斷開,甚至還可能存在一些惡意節(jié)點,發(fā)送惡意數(shù)據(jù)影響網(wǎng)絡正常運行。這些因素都是在設計和實現(xiàn)去中心化IM所要面對和考慮的,當然從另一個角度來看,如果這些問題都能得到解決,解決方案也可能反過來應用到中心化服務架構(gòu)中,增強中心化服務的穩(wěn)定性和魯棒性。
在傳統(tǒng)web2.0技術架構(gòu)中,異地多活是一座高峰,是高可用服務架構(gòu)的極致追求。從某種程度上來說,異地多活已經(jīng)接近去中心化架構(gòu),所以我們先來重溫一下異地多活架構(gòu),看看有哪些方面可以借鑒的。
圖片引用自 《搞懂異地多活,看這篇就夠了》
異地多活的思路和關鍵點:
• 提供一個路由層,對用戶按地域或哈希把用戶分配到某個機房
• 同一個用戶的相關請求,只在一個機房內(nèi)完成所有業(yè)務「閉環(huán)」,不再出現(xiàn)「跨機房」訪問
• 機房之間互為熱備份,每個機房都保存所有用戶全量數(shù)據(jù)
• 當某個機房發(fā)生災難時,備份機房的從庫升級成主庫,并在路由層切換用戶到備份機房
異地多活的思路對于去中心化架構(gòu)是非常具有借鑒意義的,可以把機房看成是一個節(jié)點,當無數(shù)個機房(節(jié)點)組成一個網(wǎng)絡時,異地多活架構(gòu)就泛化成了去中心化架構(gòu)。
當然量變引發(fā)質(zhì)變,當節(jié)點足夠多時,傳統(tǒng)的異地多活技術已經(jīng)不能直接適用于去中心化架構(gòu),必須經(jīng)過改進和改造才能為去中心化架構(gòu)所采用。去中心化架構(gòu)是另一座更高的山峰。
路由網(wǎng)絡
路由網(wǎng)絡的作用類似于異地多活中的路由層,提供了資源和服務發(fā)現(xiàn)(discovery)的服務。比如對于用戶張三,我們需要知道當前服務張三的節(jié)點到底在哪里。一個直觀的方案,是一個一個節(jié)點地問(查找),效率低下。在去中心化架構(gòu)中,常用的路由發(fā)現(xiàn)技術是Gossip協(xié)議和Kademlia網(wǎng)絡。
Gossip協(xié)議
Gossip協(xié)議的靈感來自于“好事不出門壞事傳千里”,“辦公室里的流言蜚語很快就傳遍全公司”。比如張三連接的節(jié)點1隨機向臨近節(jié)點廣播“張三在節(jié)點1上”, 臨近節(jié)點再隨機向它的臨近節(jié)點廣播,即一傳十,十傳百,消息很快傳遍全網(wǎng),所有節(jié)點都知道“張三在節(jié)點1上”。反過來,如果節(jié)點2不知道張三在哪里,它可以向全網(wǎng)詢問“張三在哪里”,在傳播的過程中,如果有節(jié)點指知道張三的地址,立即向節(jié)點2返回張三地址,結(jié)束查詢過程。Gossip不是一個新的東西,大家熟知的redis集群采用了Gossip協(xié)議。
Gossip的優(yōu)點是對網(wǎng)絡的連通性和穩(wěn)定性幾乎沒有任何要求,具有極強的魯棒性。缺點是網(wǎng)絡中的消息太多,而且有重復消息,增加了網(wǎng)絡傳輸壓力和節(jié)點的額外處理負載。
Kademlia網(wǎng)絡
Kademlia是一種分布式哈希表(DHT)技術,被廣泛應用于去中心化產(chǎn)品中,比如大家熟知的以太坊,磁力下載等。Kademlia 把成千上萬個節(jié)點構(gòu)成一個自我組織的網(wǎng)絡,用戶可以使用這個網(wǎng)絡快速查找定位到資源。關于Kademlia技術在網(wǎng)絡上能找到很多相關文章,但大多數(shù)都拘泥于細節(jié)中,這里簡單介紹Kademlia的原理,能解決什么問題,至于詳細原理請自行搜索其他文章。
1. Kademlia網(wǎng)絡是一個索引網(wǎng)絡,解決的是如何快速定位資源位置的問題
2. 每個資源都有唯一的哈希值
3. 每個節(jié)點都有唯一的哈希值
4. Node-900擁有一個資源,資源的哈希值是100
5. Node-900 把資源發(fā)布到與資源哈希值最近的Node-100(距離等于0)
6. Node-100的記錄了一條目錄,“哈希100的資源保存在Node-900上”
7. Node-800 想要訪問資源-100,通過哈希值找到Node-100,再根據(jù)目錄訪問Node-900找到資源
8. 目錄數(shù)據(jù)的高可用與冗余
a. 資源擁有者Node-900發(fā)布到距離資源最近的k個節(jié)點,比如 Node-99(距離為1),Node-100(距離為0),Node-102(距離為2)
b. 同樣地,訪問者訪問距離資源最近的k個節(jié)點獲取目錄
c. 因為網(wǎng)絡節(jié)點不斷地上線下線,距離資源最近的k個節(jié)點集合會不斷變化,所以資源擁有者Node-900 要周期性地發(fā)布資源,比如Node-100下線后,k個節(jié)點集合變成 Node-99(距離為1),Node-102(距離為2),Node-103(距離為3)
9. Kademlia的距離是邏輯距離,不是物理距離,兩個邏輯距離很近的節(jié)點,物理上可能相隔很遠。
消息順序
IM 的核心功能是消息收發(fā)。在中心化架構(gòu)中,所有上行消息通常都會歸攏到一個地方,所以消息先后順序由中心化來保證。但在去中心化架構(gòu)中,上行消息可能是從不同的節(jié)點過來的,接收消息順序可能會亂序。具體例子:
C先收到B的消息,后收到A的消息,導致最終C的聊天記錄和A/B的不一樣。
解決方案:
• 時間戳
每條消息都打上一個時間戳,在接收端根據(jù)時間戳排序。但是去中心化網(wǎng)絡中,節(jié)點間的時鐘不可能完全同步,仍然存在先后順序錯亂的可能性。
• 依賴消息
每條消息都帶有依賴消息Id,表示當前消息排在依賴消息之后。客戶端在收到一條消息后,先檢查其依賴消息是否都已經(jīng)收到并且上屏,如果沒有收到則先暫存消息,直到所有依賴消息上屏。此方案的缺點是增加客戶端處理消息的復雜度。
端到端加密
因為任何人都可以加入去中心化IM網(wǎng)絡,任何節(jié)點都可能接觸到消息,所以為了隱私和安全,消息必須是端到端加密的。常用的端到端加密方案是Diffie–Hellman 密鑰交換協(xié)議(DH),可以使通訊雙方無需預先溝通,在不安全的網(wǎng)絡中即可確定一個“協(xié)商密鑰”,這個密鑰可以在后續(xù)的通訊中作為對稱密鑰來加密消息內(nèi)容,這樣避免了雙方網(wǎng)上協(xié)商密鑰帶來的泄露風險。
從圖中可以看出在網(wǎng)絡上傳輸?shù)氖枪€,真正用來加密的“對稱密鑰S”是計算出來的,并沒有通過網(wǎng)絡傳輸,非常安全。但是如果所有消息都用同一個對稱密鑰S,一旦S被破解得到則所有消息都會被破解。最好的辦法是每條消息都用不同的密鑰,即一消息一密鑰。
• 通過密鑰函數(shù)計算得出消息密鑰
• 密鑰函數(shù)通常為不可逆函數(shù),即知道輸出很難反向計算出輸入,比如大家熟知的哈希函數(shù)就是不可逆函數(shù)
• 密鑰函數(shù)的輸出被分為鏈密鑰和消息密鑰兩部分,鏈密鑰作為下一次密鑰函數(shù)的輸入,消息密鑰用來加密消息
• 重復這個過程,即鏈式反應
鏈式反應生成的密鑰雖然很安全,但帶來一個新的問題,即如何讀取歷史消息。讀取歷史消息通常是從某條消息開始拉去n條消息。從上圖可以看出,要想得到“消息密鑰2”,必須從初始密鑰開始計算2次才能得出,如果要得到“消息密鑰10000”,則要計算10000次才能得出,顯然這樣做的效率非常低下。
推送
推送是IM業(yè)務里比較重要的功能,在app退到后臺或者被殺死,仍然可以通知到客戶。在去中心化IM架構(gòu)中,因為消息是端到端加密的,節(jié)點在給app發(fā)送推送時,只有提醒“您有一條新消息”,不會有消息內(nèi)容。這是在隱私保護與用戶體驗之間的妥協(xié)與平衡。
開源現(xiàn)狀
目前在開源社區(qū)比較接近去中心化IM理念的產(chǎn)品matrix。
matrix的特性:
• 每個用戶都有歸屬于一個Home Server,用戶名格式@user:domain,比如 @Alice:163.com , 跟e-mail郵箱名很類似
• Home Server之間采用聯(lián)邦式協(xié)議,Matrix網(wǎng)絡由分布在世界各地,由不同個人和組織運營的服務器組成,因此Matrix協(xié)議不容易被單個組織壟斷
• 私聊和群聊是端到端加密的,所有聊天內(nèi)容加密存儲、加密傳輸。Home Server無法看到用戶的聊天內(nèi)容
• 默認使用HTTPS+JSON APIs作為傳輸協(xié)議
• 可以通過Bridge與 Telegram, Discord, WhatsApp, Facebook, Hangouts, Signal 互通
• 支持通過WebRTC進行音視頻通話
matrix的缺點:
-用戶ID(地址)成本高,因為 @Alice:matrix.com 帶有域名后綴,如果用戶想擁有永久Id,必須購買域名。如果使用SP的域名,則用戶Id本身并不被用戶所擁有,這跟web3的理念是相違背的。
- matrix是 https + json,優(yōu)點是容易理解,缺點是占用更多帶寬,并且在序列化和反序列化時會消耗更多的cpu。
- Home Server之間是全連接(full mesh)方式,當參與的Home Server比較多時,比如有上千甚至上萬個Home Server時,Server之間的連接消耗會導致性能急劇下降。
總的來說 matrix 更像是一個去中心化的e-mail,距離真正的去中心化還有一些差距。
目前Web3的技術創(chuàng)新和變革也是風起云涌,不斷有新的算法和架構(gòu)出現(xiàn)。環(huán)信作為國內(nèi)IM云服務的開創(chuàng)者,在設計下一代IM技術架構(gòu)時,也在積極借鑒和探索這些前沿技術,為我們的客戶提供穩(wěn)定、可靠、專業(yè)、低成本高質(zhì)量的IM服務,為客戶賦能和創(chuàng)造更多的價值。
(免責聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性,但不保證有關資料的準確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏,概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時,應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明,并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后,將會依法盡快聯(lián)系相關文章源頭核實,溝通刪除相關內(nèi)容或斷開相關鏈接。 )