如果視頻直播的端到端延遲必須嚴格控制在 500 毫秒以內(nèi)，使之具備和視頻連麥相同的低延遲體驗，現(xiàn)在的 CDN 加速技術(shù)還能起作用嗎？首先數(shù)據(jù)不能有cache，TCP 的延遲累積必須消除，甚至 RTMP 協(xié)議也要切換到 WebRTC 的技術(shù)架構(gòu)。移動互聯(lián)網(wǎng)的實時視頻應用領(lǐng)域正在快速演變中的一切，我們先姑且稱之為網(wǎng)絡(luò)延遲革命吧。

運營商們對上述網(wǎng)絡(luò)延遲革命顯然是敏感的，正著力推動 SDN/NFV 的建設(shè)：三層解耦，網(wǎng)絡(luò)云化和發(fā)展 ONAP 已經(jīng)成為行業(yè)的共識。那么隨著 underlay 網(wǎng)絡(luò)服務能力的提升是否會極大的消弱 underlay 的網(wǎng)絡(luò)加速技術(shù)的依賴呢？答案是肯定的。但是實際的情況卻是，我們目前還無法完全依賴運營商網(wǎng)絡(luò)來開發(fā)一款完全免費的全球?qū)崟r音視頻通話類應用。比如說，如果想開展類似 QQ 微信音視頻聊天那樣的業(yè)務，還必須依靠 underlay 網(wǎng)絡(luò)中轉(zhuǎn)加速技術(shù)來解決 NAT 穿透失敗和“四跨”的問題。這里所述“四跨”是指跨國、跨運營商、跨地域、跨時段的網(wǎng)絡(luò)傳輸質(zhì)量存在波動的問題。

本文討論的 SD-RTN(Software Defined Real-time Network) 就是一種上述的underlay 網(wǎng)絡(luò)中轉(zhuǎn)加速技術(shù)。相比 CDN 而言，SD-RTN 提供的是以 UDP 協(xié)議為主的，端到端網(wǎng)絡(luò)延遲為毫秒級的實時數(shù)據(jù)傳輸云服務。SD-RTN 是一種可承載任何點到點實時數(shù)據(jù)傳輸需求的業(yè)務架構(gòu)：只要調(diào)用開放的 API，無論是實時視頻（會議、教育、直播、社交、監(jiān)控、VR）、文件傳輸（短視頻、辦公）還是高速數(shù)據(jù)同步（游戲、AI、IOT、物聯(lián)網(wǎng)）都可以很方便的接入 SD-RTN的實時數(shù)據(jù)傳輸云服務。

所謂融合 SD-RTN 則是指不以獨占的方式租用 POP 節(jié)點和購買托管服務器，而是在已經(jīng)虛擬化的網(wǎng)絡(luò)和和服務器基礎(chǔ)之上，以共享方式搭建的 SD-RTN。融合 SD-RTN 是一個完全彈性的中轉(zhuǎn)加速網(wǎng)絡(luò)，可以很好的解決網(wǎng)絡(luò)節(jié)點資源投入和業(yè)務發(fā)展速度之間的矛盾。畢竟不是每個公司的業(yè)務量都足夠大，可以支撐大量購買服務器和租用 BGP 線路的高額成本。

融合 SD-RTN 利用了共享節(jié)點組網(wǎng)，所以必須彈性的利用網(wǎng)絡(luò)節(jié)點資源，不能對已有的其他業(yè)務造成強烈沖擊。為此我們引入了兩個技術(shù)理念：

1、自動擁塞規(guī)避的端到端動態(tài)路由算法；

2、用 99%可靠的節(jié)點構(gòu)建 99.9%穩(wěn)定的網(wǎng)絡(luò)。

端到端動態(tài)路由算法要求服務器的數(shù)據(jù)中轉(zhuǎn)模塊對網(wǎng)絡(luò)節(jié)點的可用空閑帶寬具備實時檢測能力和瞬時路徑切換能力，而且這種路徑切換必須是業(yè)務無感知的。為此，我們開發(fā)了完善的 QoE 機制：包括丟包、延遲和抖動實時統(tǒng)計，多路徑熱備份等。而用 99%可靠的節(jié)點構(gòu)建 99.9%穩(wěn)定的網(wǎng)絡(luò)，就意味著融合 SD-RTN 的拓撲結(jié)構(gòu)必須是實時更新，高度自愈的。所以我們利用 QoE 機制，并增加了全網(wǎng)測速功能，讓每個網(wǎng)絡(luò)節(jié)點都擁有一個實時計算的，可動態(tài)更新的拓撲樹結(jié)構(gòu)。

融合 SD-RTN 作為通用的點到點實時數(shù)據(jù)傳輸云平臺，集中體現(xiàn)在具備以下技術(shù)特點：1、共享節(jié)點；2、協(xié)議優(yōu)化；3、接近接入；4、動態(tài)路由；5、云端QoE；6、通用架構(gòu)。首先共享節(jié)點，不再贅述。其次協(xié)議優(yōu)化是指同時支持UDP/TCP 協(xié)議接入，并且針對 TCP 接入的情況下，SD-RTN 內(nèi)部可自動轉(zhuǎn)換成QUIC 協(xié)議來減少延遲累積的產(chǎn)生。就近接入是指利用全球 IP 經(jīng)驗庫和實測數(shù)據(jù)來分配最佳中轉(zhuǎn)接入點，如果遇到運營商的 underlay 網(wǎng)絡(luò)傳輸質(zhì)量足夠好的時候，則盡量避免引入多跳數(shù)據(jù)中轉(zhuǎn)。動態(tài)路由指的是端到端傳輸路徑實時可切換，并且對具體業(yè)務而言是完全無感知的。云端 QoE 不僅為數(shù)據(jù)的可靠傳輸提供了完善的機制，也是實現(xiàn)共享節(jié)點組網(wǎng)的基礎(chǔ)。而且云端 QoE 必須是靈活可配置的，針對丟包、延遲和抖動敏感度不同的業(yè)務類型，自動編排傳輸路徑質(zhì)量計算的權(quán)重。通用架構(gòu)是指用 S2S(server to server)、C2S(client to server)和 C2C(client to client)三種 API 接入流程來涵蓋了所有的業(yè)務場景的實時數(shù)據(jù)傳輸云服務。

上述通用架構(gòu)的 S2S 接入流程，主要針對的是服務器之間的實時數(shù)據(jù)同步。其特點是兩端都有公網(wǎng) IP，可以調(diào)用 API 通知 SD-RTN 的接入點向指定的 IP 和端口發(fā)送數(shù)據(jù)。而 C2S 接入流程是目前最為廣泛的應用場景，特點是一端是服務器，另一端是位于在 NAT 后面使用私有 IP 的終端。此終端接入 SD-RTN 必須使用經(jīng)過 NAT 映射之后的公網(wǎng) IP，并且在創(chuàng)建完會話后需要主動向 SD-RTN 的接入點發(fā)一個數(shù)據(jù)包，這樣才能建立起完整的 TCP/UDP 雙向數(shù)據(jù)通道。最后 C2C接入流程針對的是終端間的直連場景，比如社交中的雙人音視頻聊天。在 C2C 接入流程中，SD-RTN 中的 API 服務器實際承擔了 NAT 穿透 stun 打洞服務器的角色，SD-RTN 的接入點則是 TURN 服務器的角色。