QQ 空间已在生产环境中使用 QUIC 协议

QUIC（Quick UDP Internet Connections，发音’quick’）是 Google 于 2013 年发布的基于 UDP 的多路传输协议，它的主要目标是为了整合 TCP 协议的可靠性和 UDP 协议的速度和效率，以降低延迟，提高用户体验。

Google 通过大规模的性能分析发现，“相对于 TCP 而言，QUIC 的性能有了真正的进步”，这得益于 QUIC 的以下特性：

• 低延迟链接的建立，这对已建立的链接很有好处。在这种情况下，Google 搜索页面的平均加载时间缩减了 3%。
• 改进拥塞控制和丢包恢复机制，这在糟糕的网络环境中尤为重要。在这种情况下，Google 搜索页面在“最慢的 1% 的连接”中节省了整整 1 秒的时间，并且观看基于 QUIC 的 YouTube 视频时会减少高达 30% 的数据重缓存。

据了解，QQ 空间前端团队通过对 HTTP2 和 QUIC 协议的应用和实践，使得 Web 页面访问速度得到了很大的提升，并且他们针对性地采用了不同的资源加载策略，最大化利用了协议的优势。为了了解 QQ 空间团队的相关实践，InfoQ 记者采访了 QQ 空间高级前端开发工程师黄佳琳。同时，黄佳琳也将会在 10 月 17 日举行的 QCon 全球软件开发大会上分享相关话题，欢迎关注。

InfoQ：如何理解 QUIC 协议？与 HTTP/2 相比有什么优势和短板？

黄佳琳：QUIC，是一种基于 UDP 的协议，为了更好地理解，可以用一个公式大致地概括为 TCP+TLS+HTTP2=UDP+QUIC+HTTP2’s API。 从这个公式可以看出来，QUIC 最重要的作用就是替代了 TCP+TLS，我们可以把 QUIC 分成两部分来理解。

1. 底层，由于改用了 UDP，QUIC 需要模仿实现 TCP 的一些功能，诸如连接性、可靠性、拥塞控制、流量控制等，但并非照搬 TCP 的协议，而是做了一些改进，避免队首阻塞；
2. 高层，负责加密，实现 TLS 的保密功能，同时使用更少的 RTT（0~1 个）便可建立安全的会话。更上一层则是复用了 HTTP2 的一些 API，实现了 HTTP2 所具有的多路复用、头部压缩等特性。

QUIC 的背景其实就是 HTTP2 在传输层仍然遇到了一些问题，没办法有效地利用网络传输，我们需要一个协议用更少的延迟和更少的重传时间消耗去传递请求，减少因包丢失造成的队首阻塞，然而又要保证安全性，QUIC 在这种背景下诞生了。

与 HTTP/2 相比，其实从技术原理可以看出来，最大的区别就是弃用了 TCP 改用了 UDP。优势就是解决了 HTTP/2 在传输层所遇到的一些性能瓶颈，而同时又具有 HTTP/2 的特性。劣势就目前来说，是浏览器支持度较差，从 QQ 空间的数据来看，QUIC 目前手机侧鲜有支持，PC 侧支持率占比在 5% 以内，相比之下，HTTP/2 的支持率已经达到 80%，不过浏览器的支持度我是持乐观态度的，随着时间推移，相信支持率会逐步上升。

InfoQ：可否介绍下你们应用 QUIC 协议的一些基本情况？

黄佳琳：目前主要在 PC 上使用，QQ 空间黄钻页面和游戏应用页面都已全量使用，QQ 空间首页也在灰度开启中。数据上相比 HTTP/2 有一定提升，页面 onload 提升了 10%。

InfoQ：什么样的场景下使用 QUIC，什么样的场景下使用 HTTP/2，什么样的场景下使用 HTTP/1？

黄佳琳：目前 QQ 空间的 Web 业务主要分 PC 端和移动端两种场景，PC 端主要用 HTTP/2+QUIC，这两个加起来占比已经接近 90%，移动端主要用 HTTP/2，主要是移动端支持 QUIC 的目前还比较少，支持 HTTP2 的占比在 80% 左右。其他不支持 QUIC 或 HTTP2 的就降级使用 HTTP/1，总之，支持新协议的都优先使用新协议。

InfoQ：为什么当初你们要考虑使用 QUIC 协议？当时的背景是什么？

黄佳琳：知道 QUIC 协议其实也是从我们开始使用 HTTP/2 的时候开始的，在研究 HTTP/2 的时候，我看了一本书，叫《Web 性能权威指南》，里面有一章是专门介绍 HTTP/2 协议的，分析得很详细，其中有一句话是这么写的（我特地去翻了一下摘抄出来），“对 HTTP 2.0 而言，TCP 很可能就是下一个性能瓶颈”。看到这句话的时候我在想，TCP 是下一个性能瓶颈，那还能怎么办呢？难不成还能用 UDP 协议？在好奇心驱使之下我搜索了一下，还真有用 UDP 的，那就是 QUIC 协议。真正在生产环境中投入使用其实是另一个契机，就是腾讯的安全云网关团队在 server 端支持了 QUIC 协议，这才使得 QUIC 协议真正落地使用。

InfoQ：在已有的系统和体系里，你们是如何落地 QUIC 协议的？

黄佳琳：在已有的架构里落地 QUIC，我们考虑的是如何对业务更透明，接入更方便。我们现有的架构，在用户端和真实服务器中间有一层统一接入层。我们的 QUIC 是在接入层统一实现的，接入层与用户端之间任意使用 QUIC、HTTP/2、HTTP/1，而接入层与真实服务器之间还是使用 HTTP 1.1 进行转发，这样对于我们的后端机器只需要保持处理 HTTP 1.1 的请求即可。

InfoQ：在生产环境中使用了这么长时间 QUIC 协议，有做过复盘吗？可以给大家分享一些你们觉得落地 QUIC 协议过程中需要注意的关键点吗？

黄佳琳：确实有一些需要注意的关键点，我觉得用 QUIC 协议有一个潜在的问题就是运营商的一些不可控因素。在分析 QUIC 数据的过程中注意到，QUIC 有时候比 HTTP/2 还要慢得多，用 iperf 等测速工具测试发现，UDP 的带宽要比 TCP 小得多，换一下网络环境之后，QUIC 又比 HTTP/2 快了。除了限速之外，有时候用 UDP 会出现丢包严重的问题，这也影响了 QUIC 的性能。但是这一类问题，作为 web 端来说很难发现和避免。我们现在也只是做了一些简单的检测手段，例如对于同一个用户来说，记录他分别使用 HTTP/2 和 QUIC 两种不同协议来加载页面的速度，如果 QUIC 明显慢于 HTTP/2 的话，这个用户下次访问不会再使用 QUIC。不过这种检测方法也会存在一些误判，还需要不断地调整。