报名参加CloudWeGo黑客松,奖金直推双丰收! 了解详情
写点什么

Google QUIC 协议:从 TCP 到 UDP 的 Web 平台

  • 2016-09-13
  • 本文字数:2983 字

    阅读完需:约 10 分钟

QUIC(Quick UDP Internet Connections)协议是一种全新的基于 UDP 的 web 开发协议。

从 TCP 协议说起

当前,web 平台的数据传输都基于 TCP 协议。TCP 协议在创建连接之前需要进行三次握手(图1),如果需要提高数据交互的安全性,既增加传输层安全协议(TLS),还会增加更多的握手次数(图2)。

图1,TCP 三次握手示意(来源 Next generation multiplexed transport over UDP (PDF)

图 2,TLS 初始化握手示意(来源 Next generation multiplexed transport over UDP (PDF)

正因为 TCP 协议连接建立的成本相对较高,可以通过 TCP 快速打开(TCP Fast Open)来减少建立连接时的握手次数。但是该技术目前应用较少。

和 TCP 相反,UDP 协议是无连接协议。客户端发出 UDP 数据包后,只能“假设”这个数据包已经被服务端接收。这样的好处是在网络传输层无需对数据包进行确认,但存在的问题就是为了确保数据传输的可靠性,应用层协议需要自己完成包传输情况的确认。

此时,QUIC 协议就登场了。QUIC 协议可以在 1 到 2 个数据包(取决于连接的服务器是新的还是已知的)内,完成连接的创建(包括 TLS)(图 3)。

图 3,QUIC 协议握手示意(来源 Next generation multiplexed transport over UDP (PDF)

QUIC 协议的目的

从前文对比可以看出,QUIC 协议的主要目的,是为了整合 TCP 协议的可靠性和 UDP 协议的速度和效率。

QUIC 的维基百科页面介绍了该协议的主要目的:

对于 Google 来说优化 TCP 协议是一个长期目标,QUIC 旨在创建几乎等同于 TCP 的独立连接,但有着低延迟,并对类似 SPDY 的多路复用流协议有更好的支持。 如果 QUIC 协议的特性被证明是有效的,这些特性以后可能会被迁移入后续版本的 TCP 和 TLS 协议(它们都有很长的开发周期)。

值得注意的是,如果 QUIC 的特性被证明是有效的,这些特性以后可能会被迁移到后续版本的 TCP 协议中

TCP 协议的实现是高度管制的。TCP 协议栈通常由操作系统实现,如 Linux、Windows 内核或者其他移动设备操作系统。修改 TCP 协议是一项浩大的工程,因为每种设备、系统的实现都需要更新。

相反的,UDP 协议在操作系统层面实现相对简单,基于 UDP 协议实现新的协议以验证 Google 对于 TCP 协议改进的理论,验证成本相对较低。

QUIC 协议内置了 TLS 栈,实现了自己的传输加密层,而没有使用现有的TLS 1.2。同时QUIC 还包含了部分HTTP/2 的实现,因此QUIC 的地位看起来是这样的:

从图上可以看出,QUIC 底层通过UDP 协议替代了TCP,上层只需要一层用于和远程服务器交互的HTTP/2 API。这是因为QUIC 协议已经包含了多路复用和连接管理,HTTP API 只需要完成HTTP 协议的解析即可。

QUIC 特性

避免前序包阻塞

SPDY 和 HTTP/2 协议现在都支持将页面的多个数据(如图片、js 等)通过一个数据链接进行传输。该特性能够加快页面组件的传输速度,但是对于 TCP 协议来说,这会遇到前序包阻塞的问题。这是由于 TCP 协议在处理包时是有严格顺序的,当其中一个数据包遇到问题,TCP 连接需要等待这个包完成重传之后才能继续进行。因此,即使逻辑上一个 TCP 连接上并行的在进行多路数据传输,其他毫无关联的数据也会因此阻塞。

图片来源 Next generation multiplexed transport over UDP (PDF)

QUIC 协议直接通过底层使用 UDP 协议天然的避免了该问题。由于 UDP 协议没有严格的顺序,当一个数据包遇到问题需要重传时,只会影响该数据包对应的资源,其他独立的资源(如其他 css、js 文件)不会受到影响。

图片来源 Next generation multiplexed transport over UDP (PDF)

减少数据包

前文已经介绍过 QUIC 协议在创建连接握手时,只需要 1 到 2 个数据包即可。这对于拥有高速互联网连接的网络环境下可能没有太大的感觉,因为此时一个数据包的延时大概在 10~50ms 之间。

一般来说延迟在 50ms 之内不会有太大的感觉。但是对于无线网络来说,情况就不太一样了。且不说传统 2G/3G 网络,即使是 4G 网络,客户端和服务器之间的延时也通常在 100ms 以上。传统 TCP+TLS 协议的传输方式,在创建连接时的 4 个数据包和 QUIC 协议的 1 个数据包相比,连接创建上就会多耗时 300ms 以上。

向前纠错

QUIC 协议有一个非常独特的特性,称为向前纠错(Forward Error Correction),每个数据包除了它本身的内容之外,还包括了部分其他数据包的数据,因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。

这类似网络层的 RAID 5!

目前默认的冗余量是 10%,既每发送 10 个数据包,其冗余数据就可以重新构建一个丢失的数据包。

向前纠错牺牲了每个数据包可以发送数据的上限,但是减少了因为丢包导致的数据重传,因为数据重传将会消耗更多的时间(包括确认数据包丢失、请求重传、等待新数据包等步骤的时间消耗)。

会话重启和并行下载

底层协议切换到 UDP 协议之后的另一大好处是,连接不再依赖于来源 IP。

对于 TCP 协议来说,标识一个 TCP 连接需要 4 个参数,既来源 IP、来源端口、目的 IP 和目的端口。其中的任一参数改变,TCP 连接就需要重新创建。

这对于传统网络来说影响不大,因为来源和目的 IP 相对固定。但是在无线网络中,情况就大不相同了。设备在移动过程中,可能会因为网络切换(如从 WIFI 网络切换到 4G 网络环境),导致 TCP 连接需要重新创建。

QUIC 协议使用了 UDP 协议,不再需要这四元组参数。同时 QUIC 协议实现了自己的会话标记方式,称为连接 UUID。当设备网络环境切换时,连接 UUID 不会发生变化,因此无需重新进行握手。

该特性除了可以减少无谓的连接重连之外,还可以充分利用设备的不同网络接口,进行资源的并行下载。因为虽然这些网络接口有不同的 IP,但只要他们能够共享连接 UUID,就能够并行的从服务器下载数据。

QUIC 协议实践

Chrome 浏览器从 2014 年开始已经实验性的支持了 QUIC 协议。可以通过在 Chrome 浏览器中输入chrome://net-internals/#quic查看是否已经支持 QUIC 协议。如果还未支持,可以在chrome://flags/#enable-quic中进行开启。

开始 Chrome 浏览器对 QUIC 协议的支持之后,可以在chrome://net-internals/#quic中查看到当前浏览器的 QUIC 一些连接。当然目前只有 Google 服务才支持 QUIC 协议(如 YouTube、 Google.com)。

(点击放大图像)

关于防火墙

通常系统管理员会关注防火墙的TCP 规则,而忽略UDP 规则。如果要在防火墙之后使用QUIC 协议,除了传统web 服务需要开放的 80/TCP443/TCP之外,针对 QUIC 还需要开放443/UDP的访问。

服务端使用 QUIC 协议

目前支持 QUIC 协议的 web 服务只有 0.9 版本以后的 Caddy 。其他常用 web 服务如 nginx、apache 等都未开始支持。curl 表达了对 QUIC 协议支持的兴趣

QUIC 性能优势

在 2015 年的博文中,Google 分享了一些关于 QUIC 协议实现的结果。

这些优势在诸如 YouTube 的视频服务上更为突出。用户报告通过 QUIC 协议在观看视频的时候可以减少 30% 的重新缓冲时间。

如果 YouTube 收集的报告可靠,可以预见视频服务提供商会更快的采用 QUIC 协议。

总结

QUIC 协议开创性的使用了 UDP 协议作为底层传输协议,通过各种方式减少了网络延迟。

目前 QUIC 协议已经在运行在最大的网站上,期待 QUIC 协议规范能够成为终稿,并在其他浏览器和服务器中能够实现。


感谢刘振涛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-09-13 17:4918380

评论

发布
暂无评论
发现更多内容

12秒内AI在手机上完成作画!谷歌提出扩散模型推理加速新方法

Openlab_cosmoplat

人工智能 机器学习 AI绘画

中国厨房更净一步:一场科技“下凡”带来的方太式浪漫

脑极体

人工智能训练数据集:误区、挑战与应对方法

数据堂

ZincSearch 一款 Elasticsearch 的轻量级替代品

宇宙之一粟

Go 三周年连更 ZincSearch

iOS MachineLearning 系列(8)—— 图片热区分析

珲少

Go 语言中没有枚举类型,但是我们可以这样做

陈明勇

Go golang 枚举 Enum 三周年连更

小程序化数字人:构建智能化的门户解决方案

FinClip

轻量级协作任务管理看板

顿顿顿

敏捷开发 任务管理 敏捷开发管理工具 看板工具 scrum工具

和ChatGPT结对完成VS CODE插件项目分享

Marvin Ma

vscode 插件 插件开发 ChatGPT

场景篇-ChatGPT帮我实现发送公众号推文

Marvin Ma

微信公众号 代码生成 ChatGPT

NCCL源码解析③:机器内拓扑分析

OneFlow

2023 年要避免的 17 个致命的网站设计错误

海拥(haiyong.site)

三周年连更

挑战 30 天学完 Python:Day13 列表推导式和Lambda

MegaQi

挑战30天学完Python 三周年连更

软件测试/测试开发丨面试题之Linux 与 Python 编程篇

测试人

软件测试 面试题 测试开发

eBPF的发展演进---从石器时代到成为神(四)

统信软件

操作系统 Linux Kenel

【源码分析】【seata】at 模式分布式事务 -xid隐式传递

如果晴天

源码分析 分布式事务 seata spring-cloud Seata框架

数据标注,优化模型辅助标注、Label 库管理|ModelWhale 版本更新

ModelWhale

云计算 编程 模型 数据标注 数据门户

场景篇-ChatGPT帮我搭建博客网站并自动写博客!

Marvin Ma

博客 ChatGPT

在oracle apex中的Dialog的做法(第一部门):

back_wang

oracle dialog oracle ebs ebs

华为阅读联手20余家头部内容平台,共建数字化阅读

最新动态

性能大PK count(*)、count(1)和count(列)

架构精进之路

MySQL 数据库 后端 innodb 三周年连更

ChatGPT 在 Python WEB 的Prompt项目分享

Marvin Ma

Python 开发 ChatGPT

Django笔记十八之save函数的继承操作和指定字段更新等实例方法

Hunter熊

Python django save auto_increment primary key

Go的内存模型:如何保证并发读写的顺序性?

Jack

副业做得好,搞钱没烦恼:盘点那些靠谱的程序员副业!

禅道项目管理

程序员 副业 技术博客

龙蜥开发者说:亲历从基础设施构建到系统质量保障,龙蜥未来可期 | 第 19 期

OpenAnolis小助手

Linux 开源 sig 龙蜥开发者说 联通数科

Apache Doris 1.2.4 Release 版本正式发布|版本通告

SelectDB

数据库 大数据 数据分析 Doris 联邦查询和分析

2022-04-27:用go语言重写ffmpeg的remuxing.c示例。

福大大架构师每日一题

golang ffmpeg

音视频八股文(7)-- 音频aac adts

福大大架构师每日一题

音视频 流媒体

《爱在黎明破晓前 | 我有话要说》

后台技术汇

三周年连更

Google QUIC协议:从TCP到UDP的Web平台_Google_金灵杰_InfoQ精选文章