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

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

从 TCP 协议说起

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

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

图 1，TCP 三次握手示意（来源 Next generation multiplexed transport over UDP (PDF)） Google QUIC 协议：从 TCP 到 UDP 的 Web 平台图 2，TLS 初始化握手示意（来源 Next generation multiplexed transport over UDP (PDF)）

正因为 TCP 协议连接建立的成本相对较高，可以通过TCP 快速打开（TCP Fast Open）来减少建立连接时的握手次数。但是该技术目前应用较少。
和 TCP 相反，UDP 协议是无连接协议。客户端发出 UDP 数据包后，只能“假设”这个数据包已经被服务端接收。这样的好处是在网络传输层无需对数据包进行确认，但存在的问题就是为了确保数据传输的可靠性，应用层协议需要自己完成包传输情况的确认。
此时，QUIC 协议就登场了。QUIC 协议可以在 1 到 2 个数据包（取决于连接的服务器是新的还是已知的）内，完成连接的创建（包括 TLS）（图 3）。

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

图 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 的地位看起来是这样的：

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

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

QUIC 特性

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

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

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

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

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

图片来源 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）。 Google QUIC 协议：从 TCP 到 UDP 的 Web 平台

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

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

总结

QUIC 协议开创性的使用了 UDP 协议作为底层传输协议，通过各种方式减少了网络延迟。
目前 QUIC 协议已经在运行在最大的网站上，期待 QUIC 协议规范能够成为终稿，并在其他浏览器和服务器中能够实现
原文：https://www.infoq.cn/article/quic-google-protocol-web-platform-from-tcp-to-udp

原创文章，作者：赛福，如若转载，请注明出处：https://www.safecdn.cn/958.html

本站不销售、不代购、不提供任何支持，仅分享网络信息，请自行辨别，请遵纪守法、文明上网。

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

从 TCP 协议说起

QUIC 协议的目的

QUIC 特性

会话重启和并行下载

QUIC 协议实践

总结

相关推荐