SD-RTN毫秒级网络加速的技术变革

如果视频直播的端到端延迟必须严格控制在 500 毫秒以内，使之具备和视频连麦相同的低延迟体验，现在的 CDN 加速技术还能起作用吗？首先数据不能有cache，TCP 的延迟累积必须消除，甚至 RTMP 协议也要切换到 WebRTC 的技术架构。移动互联网的实时视频应用领域正在快速演变中的一切，我们先姑且称之为网络延迟革命吧。

运营商们对上述网络延迟革命显然是敏感的，正着力推动 SDN/NFV 的建设：三层解耦，网络云化和发展 ONAP 已经成为行业的共识。那么随着 underlay 网络服务能力的提升是否会极大的消弱 underlay  的网络加速技术的依赖呢？答案是肯定的。但是实际的情况却是，我们目前还无法完全依赖运营商网络来开发一款完全免费的全球实时音视频通话类应用。比如说，如果想开展类似 QQ 微信音视频聊天那样的业务，还必须依靠  underlay  网络中转加速技术来解决 NAT 穿透失败和“四跨”的问题。这里所述“四跨”是指跨国、跨运营商、跨地域、跨时段的网络传输质量存在波动的问题。

本文讨论的 SD-RTN(Software Defined Real-time Network) 就是一种上述的underlay 网络中转加速技术。相比 CDN 而言，SD-RTN 提供的是以 UDP 协议为主的，端到端网络延迟为毫秒级的实时数据传输云服务。SD-RTN 是一种可承载任何点到点实时数据传输需求的业务架构：只要调用开放的 API，无论是实时视频（会议、教育、直播、社交、监控、VR）、文件传输（短视频、办公）还是高速数据同步（游戏、AI、IOT、物联网）都可以很方便的接入 SD-RTN的实时数据传输云服务。

所谓融合 SD-RTN 则是指不以独占的方式租用 POP 节点和购买托管服务器，而是在已经虚拟化的网络和和服务器基础之上，以共享方式搭建的 SD-RTN。融合 SD-RTN 是一个完全弹性的中转加速网络，可以很好的解决网络节点资源投入和业务发展速度之间的矛盾。毕竟不是每个公司的业务量都足够大，可以支撑大量购买服务器和租用 BGP 线路的高额成本。

融合 SD-RTN 利用了共享节点组网，所以必须弹性的利用网络节点资源，不能对已有的其他业务造成强烈冲击。为此我们引入了两个技术理念：

1、自动拥塞规避的端到端动态路由算法；

2、用 99%可靠的节点构建 99.9%稳定的网络。

端到端动态路由算法要求服务器的数据中转模块对网络节点的可用空闲带宽具备实时检测能力和瞬时路径切换能力，而且这种路径切换必须是业务无感知的。为此，我们开发了完善的 QoE 机制：包括丢包、延迟和抖动实时统计，多路径热备份等。而用 99%可靠的节点构建 99.9%稳定的网络，就意味着融合 SD-RTN 的拓扑结构必须是实时更新，高度自愈的。所以我们利用 QoE 机制，并增加了全网测速功能，让每个网络节点都拥有一个实时计算的，可动态更新的拓扑树结构。

融合 SD-RTN 作为通用的点到点实时数据传输云平台，集中体现在具备以下技术特点：1、共享节点；2、协议优化；3、接近接入；4、动态路由；5、云端QoE；6、通用架构。首先共享节点，不再赘述。其次协议优化是指同时支持UDP/TCP 协议接入，并且针对 TCP 接入的情况下，SD-RTN 内部可自动转换成QUIC 协议来减少延迟累积的产生。就近接入是指利用全球 IP 经验库和实测数据来分配最佳中转接入点，如果遇到运营商的 underlay  网络传输质量足够好的时候，则尽量避免引入多跳数据中转。动态路由指的是端到端传输路径实时可切换，并且对具体业务而言是完全无感知的。云端 QoE 不仅为数据的可靠传输提供了完善的机制，也是实现共享节点组网的基础。而且云端 QoE 必须是灵活可配置的，针对丢包、延迟和抖动敏感度不同的业务类型，自动编排传输路径质量计算的权重。通用架构是指用 S2S(server to server)、C2S(client to server)和 C2C(client to client)三种 API 接入流程来涵盖了所有的业务场景的实时数据传输云服务。

上述通用架构的 S2S 接入流程，主要针对的是服务器之间的实时数据同步。其特点是两端都有公网 IP，可以调用 API 通知 SD-RTN 的接入点向指定的 IP 和端口发送数据。而 C2S 接入流程是目前最为广泛的应用场景，特点是一端是服务器，另一端是位于在 NAT 后面使用私有 IP 的终端。此终端接入 SD-RTN 必须使用经过 NAT 映射之后的公网 IP，并且在创建完会话后需要主动向 SD-RTN 的接入点发一个数据包，这样才能建立起完整的 TCP/UDP 双向数据通道。最后 C2C接入流程针对的是终端间的直连场景，比如社交中的双人音视频聊天。在 C2C 接入流程中，SD-RTN 中的 API 服务器实际承担了 NAT 穿透 stun 打洞服务器的角色，SD-RTN 的接入点则是 TURN 服务器的角色。