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 全球软件开发大会上分享相关话题,欢迎关注。
Q:如何理解 QUIC 协议?与 HTTP/2 相比有什么优势和短板?
黄佳琳:QUIC,是一种基于 UDP 的协议,为了更好地理解,可以用一个公式大致地概括为 TCP+TLS+HTTP2=UDP+QUIC+HTTP2’s API。 从这个公式可以看出来,QUIC 最重要的作用就是替代了 TCP+TLS,我们可以把 QUIC 分成两部分来理解。
底层,由于改用了 UDP,QUIC 需要模仿实现 TCP 的一些功能,诸如连接性、可靠性、拥塞控制、流量控制等,但并非照搬 TCP 的协议,而是做了一些改进,避免队首阻塞;
高层,负责加密,实现 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%,不过浏览器的支持度我是持乐观态度的,随着时间推移,相信支持率会逐步上升。
Q:可否介绍下你们应用 QUIC 协议的一些基本情况?
黄佳琳:目前主要在 PC 上使用,QQ 空间黄钻页面和游戏应用页面都已全量使用,QQ 空间首页也在灰度开启中。数据上相比 HTTP/2 有一定提升,页面 onload 提升了 10%。
Q:什么样的场景下使用 QUIC,什么样的场景下使用 HTTP/2,什么样的场景下使用 HTTP/1?
黄佳琳:目前 QQ 空间的 Web 业务主要分 PC 端和移动端两种场景,PC 端主要用 HTTP/2+QUIC,这两个加起来占比已经接近 90%,移动端主要用 HTTP/2,主要是移动端支持 QUIC 的目前还比较少,支持 HTTP2 的占比在 80% 左右。其他不支持 QUIC 或 HTTP2 的就降级使用 HTTP/1,总之,支持新协议的都优先使用新协议。
Q:为什么当初你们要考虑使用 QUIC 协议?当时的背景是什么?
黄佳琳:知道 QUIC 协议其实也是从我们开始使用 HTTP/2 的时候开始的,在研究 HTTP/2 的时候,我看了一本书,叫《Web 性能权威指南》,里面有一章是专门介绍 HTTP/2 协议的,分析得很详细,其中有一句话是这么写的(我特地去翻了一下摘抄出来),“对 HTTP 2.0 而言,TCP 很可能就是下一个性能瓶颈”。看到这句话的时候我在想,TCP 是下一个性能瓶颈,那还能怎么办呢?难不成还能用 UDP 协议?在好奇心驱使之下我搜索了一下,还真有用 UDP 的,那就是 QUIC 协议。真正在生产环境中投入使用其实是另一个契机,就是腾讯的安全云网关团队在 server 端支持了 QUIC 协议,这才使得 QUIC 协议真正落地使用。
Q:在已有的系统和体系里,你们是如何落地 QUIC 协议的?
黄佳琳:在已有的架构里落地 QUIC,我们考虑的是如何对业务更透明,接入更方便。我们现有的架构,在用户端和真实服务器中间有一层统一接入层。我们的 QUIC 是在接入层统一实现的,接入层与用户端之间任意使用 QUIC、HTTP/2、HTTP/1,而接入层与真实服务器之间还是使用 HTTP 1.1 进行转发,这样对于我们的后端机器只需要保持处理 HTTP 1.1 的请求即可。
Q:在生产环境中使用了这么长时间 QUIC 协议,有做过复盘吗?可以给大家分享一些你们觉得落地 QUIC 协议过程中需要注意的关键点吗?
黄佳琳:确实有一些需要注意的关键点,我觉得用 QUIC 协议有一个潜在的问题就是运营商的一些不可控因素。在分析 QUIC 数据的过程中注意到,QUIC 有时候比 HTTP/2 还要慢得多,用 iperf 等测速工具测试发现,UDP 的带宽要比 TCP 小得多,换一下网络环境之后,QUIC 又比 HTTP/2 快了。除了限速之外,有时候用 UDP 会出现丢包严重的问题,这也影响了 QUIC 的性能。但是这一类问题,作为 web 端来说很难发现和避免。我们现在也只是做了一些简单的检测手段,例如对于同一个用户来说,记录他分别使用 HTTP/2 和 QUIC 两种不同协议来加载页面的速度,如果 QUIC 明显慢于 HTTP/2 的话,这个用户下次访问不会再使用 QUIC。不过这种检测方法也会存在一些误判,还需要不断地调整。
原文来自:前端之巅
声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com
支持识别各类商场、超市及药店的购物小票,包括店名、单号、总金额、消费时间、明细商品名称、单价、数量、金额等信息,可用于商品售卖信息统计、购物中心用户积分兑换及企业内部报销等场景
涉农贷款地址识别,支持对私和对公两种方式。输入地址的行政区划越完整,识别准确度越高。
根据给定的手机号、姓名、身份证、人像图片核验是否一致
通过企业关键词查询企业涉讼详情,如裁判文书、开庭公告、执行公告、失信公告、案件流程等等。
IP反查域名是通过IP查询相关联的域名信息的功能,它提供IP地址历史上绑定过的域名信息。