雙十一剛剛過去，你的快遞都收到了嗎?好像曾經(jīng)因流量激增，導致各地中轉及收件點爆倉，快遞遲遲不到，延遲甚至長達半個月的新聞幾乎絕跡。當運輸速度恒定，中轉站點的多寡、分揀能力的強弱、是否丟包重發(fā)，決定了你的快遞能否如期到達。

那么，如果 IM 消息是物，音視頻內容是物，那么全球通信網(wǎng)就是負責傳輸?shù)奈锪飨到y(tǒng)。在物理距離恒定的前提下，對于路由跳數(shù)、網(wǎng)絡帶寬、網(wǎng)絡質量和緩存隊列的設計和優(yōu)化，決定了系統(tǒng)能否做到高質量、低延遲的傳輸。

這是融云首席架構師李淼在 WICC 廣州“出海分論壇”中分享的話題引子。也因此，李淼關于《全球低延遲通信網(wǎng)絡的設計與優(yōu)化》的話題分享變得更加具象。

RTC 與 IM 全球網(wǎng)絡的設計有所同，有所不同

融云全球通信網(wǎng)絡分為 RTC 全球網(wǎng)絡和 IM 全球通信絡兩個部分，這是由于 RTC 和 IM 在傳輸中不同的加速特點所決定。

(RTC 網(wǎng)絡與 IM 網(wǎng)絡)

相同點在于：二者可在數(shù)據(jù)中心、節(jié)點等多項物理設施上進行復用，并且都必須保證高質量、低延遲的傳輸，從而為用戶帶來極佳的場景體驗。

不同點在于：RTC 基于 UTP 協(xié)議運行，對于用戶體驗而言，允許有一定的丟包率，但對于延時要求苛刻;而IM 基于 TCP 協(xié)議進行業(yè)務承載，在要求消息不能丟失的同時，需要消息的集中存儲，不僅能為用戶不在線時存儲離線消息，還要根據(jù)業(yè)務類型，進行歷史消息的存儲。

因此，融云對于 RTC 的設計，是完全去中心化的分布式通信網(wǎng)絡。好處是在后續(xù)進行網(wǎng)絡優(yōu)化時，可以隨意增加媒體節(jié)點部署，而不影響用戶的任何使用體驗。

融云 IM 的網(wǎng)絡設計采用的是將數(shù)據(jù)流量導入到數(shù)據(jù)中心的方式，已陸續(xù)在國內、北美和新加坡分別設立了數(shù)據(jù)中心，目前已迭代至基于 Anycast 的一體化加速網(wǎng)。特點在于多協(xié)議支持、多數(shù)據(jù)中心支持，并且，基于 SmartDNS & Anycast 的加速原理可以更高質量地保證在全球范圍內，節(jié)點分配的準確度。此外，IM 的許多全球鏈路優(yōu)化工作，都可以在 RTC 上復用。

了解完以上架構，重點來了：融云是如何進行延時優(yōu)化的呢?這需要分別從 RTC 和 IM 兩個方向進行解析。

如何降低 RTC 的網(wǎng)絡延時

(RTC 通信過程)

對于 RTC 而言，能降低延時最好的辦法，就是提高 RTC 節(jié)點的覆蓋率，目的在于縮短用戶與邊緣節(jié)點的物理距離，也就意味著以更少的跳數(shù)完成連接。

融云對于節(jié)點的選擇先是要保證大洲級的全覆蓋，再是對熱門區(qū)域進行重點覆蓋。所選節(jié)點基于一線 IaaS 廠商的公有云服務搭建，每個節(jié)點之間都可通過專線互聯(lián)。不但可以提升鏈路傳輸?shù)姆€(wěn)定性，還可以降低 RTC 節(jié)點的跳數(shù)，甚至可以做到 0 跳或者 1 跳。

優(yōu)化的難點在于：如何讓用戶選擇到質量最好的節(jié)點。通常最直觀的辦法是通過智能 DNS 解析，但融云經(jīng)過驗證發(fā)現(xiàn)，準確度率只在 80% 左右。為此，融云在之后增加了 IP Anycast，它跟 DNS 原理完全不同，可直接通過 IP 的方式來進行分配，這個分配是運營商級的。

在鏈路探測方面，物理距離最近的 IDC 未必就是質量最好的節(jié)點，即便采用 smart DNS+IP Anycast，準確度依然無法達到 100%。為此，融云增加了客戶端的探測能力，在用戶連接時下發(fā) N 個地址?？蛻舳烁鶕?jù)下發(fā)地址進行探測，擇優(yōu)選擇鏈路連接。據(jù)日志分析，準確度達 99.5% 以上。

同云連接可以通過鏈路優(yōu)化來保證，那么跨云又該怎么辦呢?

融云的做法是通過二級級聯(lián)，將數(shù)據(jù)中心之間的流量通過所采購的 SD-WAN 進行導入導出。這其中，級聯(lián)優(yōu)化至關重要。

比如，一個北美用戶跟一個國內用戶通信，融云會先在北美與香港之間進行專線互聯(lián)，然后香港再與國內的節(jié)點進行專線互聯(lián)。這種通過香港節(jié)點進行轉發(fā)的方案，能夠在保證質量的前提下，達到低延時的網(wǎng)絡優(yōu)化效果。

但難點在于：故障降級。傳輸過程中，同云的專線和 SD-WAN 都可能會出現(xiàn)故障。盡管故障的概率極低，但一旦故障發(fā)生，就必須有所取舍，為了保證用戶能夠正常接聽互通，只能選擇將整個通訊鏈路進行降級。比如當專線出問題時，會通過二級級聯(lián)的方式，進行節(jié)點的跳轉，或者直接通過互聯(lián)網(wǎng)公網(wǎng)的方式進行數(shù)據(jù)的轉發(fā)。

此外，要降延就要有完善的網(wǎng)絡延時監(jiān)控系統(tǒng)。融云在客戶端建設了各種標準的 QoS 監(jiān)測系統(tǒng)，包括數(shù)據(jù)實時上報和后臺分析。

如何降低 IM 的網(wǎng)絡延時

IM 的網(wǎng)絡延時優(yōu)化途徑主要集中于節(jié)點間數(shù)據(jù)轉發(fā)和證書計算前置兩個方面。

在節(jié)點數(shù)據(jù)的轉發(fā)方面：由于 IM 數(shù)據(jù)基于 TCP 協(xié)議傳輸，但 TCP 的擁塞控制和丟包重傳策略并不友好，因此融云將部分 TCP 協(xié)議替換成 QUIC 協(xié)議，也就是說，從物理距離最遠的邊緣節(jié)點到路由節(jié)點數(shù)據(jù)的傳輸，融云都通過 QUIC 進行了優(yōu)化。

(IM 全球網(wǎng)絡的歷程)

通過QUIC 優(yōu)化，首先可以避免在邊緣點跟路由節(jié)點之間，TCP 的三次握手，直接將 TLS RTT 降為 0;其次是當網(wǎng)絡抖動時，QUIC 有更友好的丟包重傳策略，可以做到丟哪個包就補哪個包，而不會像 TCP 那樣，一旦丟包，后續(xù)所有的包都要進行重傳。內測表明，這一優(yōu)化，使整個網(wǎng)絡延時降低了 15% 左右。

在證書計算前置方面：融云采取將 TLS 證書和 SSL 的證書，在邊緣節(jié)點上直接進行交換的方式。這樣一來，首先是減少了用戶數(shù)據(jù)到數(shù)據(jù)中心之間的整體的 RTT，可將 RTT 直接降到 0。其次，IM 多有小包通訊的場景，例如一個信令包只有 10-20 個字節(jié)，通過在邊緣點上將數(shù)據(jù)包進行解密，明文傳遞到融云的路由節(jié)點，再進行加密傳到數(shù)據(jù)中心，大大降低了兩個最遠物理距端點間的數(shù)據(jù)傳輸量。

需要說明的是，用戶完全無需擔心數(shù)據(jù)的安全問題。因為融云的邊緣節(jié)點和路由節(jié)點全部由融云控制，均為受信網(wǎng)絡。但如果是必須要在公網(wǎng)完成數(shù)據(jù)傳輸，融云仍然會通過傳統(tǒng) TLS 方式來進行數(shù)據(jù)鏈路加密。

當然，融云對 IM 的優(yōu)化策略遠不止于此，更多表現(xiàn)在客戶端及服務端日志的收集、zero copy、多路復用、IP 直連和 QoS 保證等多個方面。

比如對日志的收集，融云每發(fā)一個 SDK 版本，都會增加新的日志埋點，用于分析業(yè)務、分析網(wǎng)絡等，以此進行一些定向或定點區(qū)域的優(yōu)化。

在談及未來計劃時，李淼指出，融云將不計成本，不遺余力地繼續(xù)加大網(wǎng)絡建設力度，為開發(fā)者提供更加優(yōu)質的服務。就研發(fā)而言，將持續(xù)提升軟件本身的處理能力，不斷豐富數(shù)據(jù)收集的手段，同時提升數(shù)據(jù)預估的準確性。

（免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）