
导语:2018年11月13~14日,由亚太CDN联盟主办的第七届GFIC全球家庭互联网大会在上海举办,蓝汛ChinaCache资深架构师王立鸥先生分享了《QUIC在CDN 超远节点间的互联应用》的技术内容。
导语:2018 年 11 月 13~14 日,由亚太 CDN 联盟主办的第七届 GFIC 全球家庭互联网大会在上海举办,蓝汛 ChinaCache 资深架构师王立鸥先生分享了《QUIC 在 CDN 超远节点间的互联应用》的技术内容。
在 QUIC 的快速发展中,蓝汛 ChinaCache 第一时间关注了 gQUIC 和 IETF 两个不同的分支,并通过实践和比较两个分支异同和自己业务的需求,将 QUIC 应用到了 CDN 系统中。对此,王立鸥从 CDN 的层级架构间通信的要求、QUIC 和传统层级间通信方式的对比、以及在超远场景中的应用进行了总结和分享。
众所周知,传统 CDN 会有多级结构,每一级结构会有不同热度数据。在 CDN 节点之间有大量的通讯数据,这些数据进行分布式存储时的路径对最终 CDN 服务质量有着非常重要的影响。通常来说影响通讯质量的因素通常会受到缓存业务内容的性质、节点间的网络连接和 Client-server 侧的传输架构和机制的影响。这些层级间的数据拉取性能会直接影响到整体 CDN 的下发响应速度。通常可以通过 TCP 优化手段(数据连接池、TCP 优化)、缓存数据分块、高层级向低层次的数据推送、缓存数据预拉取、数据压缩等手段实现超远节点之间的进一步传输。
在这种情况下,QUIC 的优势就展现出来了。QUIC 协议其实是一个快速演进的协议,分为两个版本。我们看的版本一般都叫 gQUIC,另外一个 QUIC 是 IETF QUIC。所谓 gQUIC,是指在 HTTP/2 之后,Google 用 UDP 承载开发的,chrome 支持的协议;而 IETFQUIC,是 IETF 在 gQUIC 成功应用的基础上,作为 QUIC 标准化的版本。
王立鸥进一步演示分析了相同的 gQUIC 版本、不同的实现之间兼容性问题,以及不同的 gQUIC 版本,和实际业务部署环境、使用场景间的兼容性问题。
那么 QUIC 在应用中具体有什么优势呢?王立鸥通过对超远的 CDN 节点 PoP 测试展示,呈现了 QUIC 在安全、性能、吞吐、压缩四个方面的特点。在测试中,一个文件同时用 QUIC 下载,QUIC 的确在一个新建的 TLS 连接过程中非常节约时间。如在 200 多毫秒延时的情况下,这个过程对于一个 HTTP1+TLS 连接过程可能花一秒钟,对于 QUIC 来说可能花三分之一时间就建连成功。由此,可以看出,QUIC 应用效率非常惊人,它既能满足安全传输的要求,也实现了提升传输效率、降低传输成本的需求。
测试验证的环境
最后,王立鸥表示,QUIC 对于业务系统的负担(CPU 占用等)通过不断优化,仍然会高于 TCP/HTTP 的传输方式,但这个负担目前来看是可以接受的。由于 QUIC 现在没有真正事实上标准,在前端应用可能会有更多阻力,但这并不妨碍我们在后端业务中使用 QUIC 这种新技术提高业务实践的效率。
关于 QUIC,您还想了解什么?欢迎大家留言与我们互动。