雙十一剛剛過去，你的快遞都收到了嗎？好像曾經因流量激增，導致各地中轉及收件點爆倉，快遞遲遲不到，延遲甚至長達半個月的新聞幾乎絕跡。當運輸速度恆定，中轉站點的多寡、分揀能力的強弱、是否丟包重發，決定了你的快遞能否如期到達。【融雲全球網際網路通訊雲】
那麼，如果 IM 訊息是物，音視訊內容是物，那麼全球通訊網就是負責傳輸的物流系統。在物理距離恆定的前提下，對於路由跳數、網路頻寬、網路質量和快取佇列的設計和優化，決定了系統能否做到高質量、低延遲的傳輸。
這是融雲首席架構師李淼在 WICC 廣州“出海分論壇”中分享的話題引子。也因此，李淼關於《全球低延遲通訊網路的設計與優化》的話題分享變得更加具象。
RTC 與 IM 全球網路的設計有所同，有所不同
融雲全球通訊網路分為 RTC 全球網路和 IM 全球通訊絡兩個部分，這是由於 RTC 和 IM 在傳輸中不同的加速特點所決定。
（RTC 網路與 IM 網路）
相同點在於：二者可在資料中心、節點等多項物理設施上進行復用，並且都必須保證高質量、低延遲的傳輸，從而為使用者帶來極佳的場景體驗。
不同點在於：RTC 基於 UTP 協議執行，對於使用者體驗而言，允許有一定的丟包率，但對於延時要求苛刻；而 IM 基於 TCP 協議進行業務承載，在要求訊息不能丟失的同時，需要訊息的集中儲存，不僅能為使用者不線上時儲存離線訊息，還要根據業務型別，進行歷史訊息的儲存。
因此，融雲對於 RTC 的設計，是完全去中心化的分散式通訊網路。好處是在後續進行網路優化時，可以隨意增加媒體節點部署，而不影響使用者的任何使用體驗。
融雲 IM 的網路設計採用的是將資料流量匯入到資料中心的方式，已陸續在國內、北美和新加坡分別設立了資料中心，目前已迭代至基於 Anycast 的一體化加速網。特點在於多協議支援、多資料中心支援，並且，基於 SmartDNS & Anycast 的加速原理可以更高質量地保證在全球範圍內，節點分配的準確度。此外，IM 的許多全球鏈路優化工作，都可以在 RTC 上覆用。
瞭解完以上架構，重點來了：融雲是如何進行延時優化的呢？這需要分別從 RTC 和 IM 兩個方向進行解析。
如何降低 RTC 的網路延時
（RTC 通訊過程）
對於 RTC 而言，能降低延時最好的辦法，就是提高 RTC 節點的覆蓋率，目的在於縮短使用者與邊緣節點的物理距離，也就意味著以更少的跳數完成連線。
融雲對於節點的選擇先是要保證大洲級的全覆蓋，再是對熱門區域進行重點覆蓋。所選節點基於一線 IaaS 廠商的公有云服務搭建，每個節點之間都可通過專線互聯。不但可以提升鏈路傳輸的穩定性，還可以降低 RTC 節點的跳數，甚至可以做到 0 跳或者 1 跳。
優化的難點在於：如何讓使用者選擇到質量最好的節點。通常最直觀的辦法是通過智慧 DNS 解析，但融雲經過驗證發現，準確度率只在 80% 左右。為此，融雲在之後增加了 IP Anycast，它跟 DNS 原理完全不同，可直接通過 IP 的方式來進行分配，這個分配是運營商級的。
在鏈路探測方面，物理距離最近的 IDC 未必就是質量最好的節點，即便採用 smart DNS+IP Anycast，準確度依然無法達到 100%。為此，融雲增加了客戶端的探測能力，在使用者連線時下發 N 個地址。客戶端根據下發地址進行探測，擇優選擇鏈路連線。據日誌分析，準確度達 99.5% 以上。
同雲連線可以通過鏈路優化來保證，那麼跨雲又該怎麼辦呢？
融雲的做法是通過二級級聯，將資料中心之間的流量通過所採購的 SD-WAN 進行匯入匯出。這其中，級聯優化至關重要。
比如，一個北美使用者跟一個國內使用者通訊，融雲會先在北美與香港之間進行專線互聯，然後香港再與國內的節點進行專線互聯。這種通過香港節點進行轉發的方案，能夠在保證質量的前提下，達到低延時的網路優化效果。
但難點在於：故障降級。傳輸過程中，同雲的專線和 SD-WAN 都可能會出現故障。儘管故障的概率極低，但一旦故障發生，就必須有所取捨，為了保證使用者能夠正常接聽互通，只能選擇將整個通訊鏈路進行降級。比如當專線出問題時，會通過二級級聯的方式，進行節點的跳轉，或者直接通過網際網路公網的方式進行資料的轉發。
此外，要降延就要有完善的網路延時監控系統。融雲在客戶端建設了各種標準的 QoS 監測系統，包括資料實時上報和後臺分析。
如何降低 IM 的網路延時
IM 的網路延時優化途徑主要集中於節點間資料轉發和證書計算前置兩個方面。
在節點資料的轉發方面：由於 IM 資料基於 TCP 協議傳輸，但 TCP 的擁塞控制和丟包重傳策略並不友好，因此融雲將部分 TCP 協議替換成 QUIC 協議，也就是說，從物理距離最遠的邊緣節點到路由節點資料的傳輸，融雲都通過 QUIC 進行了優化。
（IM 全球網路的歷程）
通過 QUIC 優化，首先可以避免在邊緣點跟路由節點之間，TCP 的三次握手，直接將 TLS RTT 降為 0；其次是當網路抖動時，QUIC 有更友好的丟包重傳策略，可以做到丟哪個包就補哪個包，而不會像 TCP 那樣，一旦丟包，後續所有的包都要進行重傳。內測表明，這一優化，使整個網路延時降低了 15% 左右。
在證書計算前置方面：融雲採取將 TLS 證書和 SSL 的證書，在邊緣節點上直接進行交換的方式。這樣一來，首先是減少了使用者資料到資料中心之間的整體的 RTT，可將 RTT 直接降到 0。其次，IM 多有小包通訊的場景，例如一個信令包只有 10-20 個位元組，通過在邊緣點上將資料包進行解密，明文傳遞到融雲的路由節點，再進行加密傳到資料中心，大大降低了兩個最遠物理距端點間的資料傳輸量。
需要說明的是，使用者完全無需擔心資料的安全問題。因為融雲的邊緣節點和路由節點全部由融雲控制，均為受信網路。但如果是必須要在公網完成資料傳輸，融雲仍然會通過傳統 TLS 方式來進行資料鏈路加密。
當然，融雲對 IM 的優化策略遠不止於此，更多表現在客戶端及服務端日誌的收集、zero copy、多路複用、IP 直連和 QoS 保證等多個方面。
比如對日誌的收集，融雲每發一個 SDK 版本，都會增加新的日誌埋點，用於分析業務、分析網路等，以此進行一些定向或定點區域的優化。
在談及未來計劃時，李淼指出，融雲將不計成本，不遺餘力地繼續加大網路建設力度，為開發者提供更加優質的服務。就研發而言，將持續提升軟體本身的處理能力，不斷豐富資料收集的手段，同時提升資料預估的準確性。