从双十一的物流大战，看全球通信网络的低延迟优化

双十一刚刚过去，你的快递都收到了吗？好像曾经因流量激增，导致各地中转及收件点爆仓，快递迟迟不到，延迟甚至长达半个月的新闻几乎绝迹。当运输速度恒定，中转站点的多寡、分拣能力的强弱、是否丢包重发，决定了你的快递能否如期到达。

那么，如果 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 版本，都会增加新的日志埋点，用于分析业务、分析网络等，以此进行一些定向或定点区域的优化。

在谈及未来计划时，李淼指出，融云将不计成本，不遗余力地继续加大网络建设力度，为开发者提供更加优质的服务。就研发而言，将持续提升软件本身的处理能力，不断丰富数据收集的手段，同时提升数据预估的准确性。