Cloudflare、Chrome与Firefox新增HTTP/3支持，HTTP/3有什么特点和优点呢？

Cloudflare、Chrome与Firefox新增HTTP/3支持，网速更快、更可靠

Cloudflare 日前宣布，用户将开始能够通过在其仪表板中启用一个选项来为其域启用HTTP/3支持，当用户使用具有HTTP/3功能的客户端访问Cloudflare托管的网站时，连接将自动升级到新协议。

We are now happy to announce that QUIC and HTTP/3 support is available on the Cloudflare edge network. We’re excited to be joined in this announcement by Google Chrome and Mozilla Firefox, two of the leading browser vendors and partners in our effort to make the web faster and more reliable for all.

现在，我们很高兴地宣布，Cloudflare边缘网络上已提供QUIC和HTTP/3支持。我们很高兴能与两家领先的浏览器供应商和合作伙伴Google Chrome和Mozilla Firefox一起加入此公告，以努力使所有人的网络速度更快、更可靠。

Cloudflare联名Chrome与Firefox一起宣布了该消息。此前，Chrome在Canary版本中已经增加了对HTTP/3的支持，另一边Mozilla也表示，将在今秋晚些时候推出的Firefox Nightly版本中推出对HTTP/3的支持。

虽然Chrome Canary与Firefox Nightly都不适合普通用户使用，但是有经验的用户都可以使用这两个实验版本，这些用户会希望自己抢先测试HTTP/3。

HTTP/3 协议即将标准化。

Google(pbuh) 公司拥有最流行的 web 浏览器(Chrome)和两个最流行的网站（#1 Google.com #2 Youtube.com）。因此谷歌可以控制 web 协议的发展。他们的第一次升级称之为 SPDY (发音"speedy"),这次更新最终成为 HTTP 协议第二版标准，即 HTTP/2 。他们的第二次升级称之为 QUIC（发音"quick"）,将成为 HTTP/3 协议标准。

SPDY (HTTP/2)已经得到了主流web浏览器(Chrome、Firefox、Edge、Safari)和主流web服务器(Apache、Nginx、IIS、CloudFlare)的支持。许多最流行的网站都支持它(即使是非google站点)，尽管您不太可能在网上看到它(使用Wireshark或tcpdump进行嗅探)，因为它总是使用SSL加密的。虽然标准允许HTTP/2在TCP上运行raw，但是所有实现都是SSL上使用它。

这里有一个关于标准很好的一课。在互联网之外，标准通常是法律上的，由政府管理，由所有主要利益相关者在一个房间里讨论，然后使用规则迫使人们采用它。在互联网上，人们首先实现东西，然后如果其他人喜欢它，他们也会开始使用它。标准通常是事实上的，rfc是为已经在互联网上运行良好的内容，记录人们已经在使用的内容。浏览器/服务器采用SPDY并不是因为它是标准化的，而是因为主要的参与者只是简单地开始添加它。同样的情况也发生在QUIC上:它被标准化为HTTP/3的事实是它已经被使用，而不是人们可以开始使用它的标准化里程碑。

QUIC新功能

• 0-RTT

通过使用类似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只需要将之前的缓存传递给服务端验证通过就可以进行传输了。0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。那什么是 0RTT 建连呢？

这里面有两层含义:

1.传输层 0RTT 就能建立连接。

2.加密层 0RTT 就能建立加密连接。

上图左边是 HTTPS 的一次完全握手的建连过程，需要 3 个 RTT。就算是会话复用也需要至少 2 个 RTT。

而 QUIC 呢？由于建立在 UDP 的基础上，同时又实现了 0RTT 的安全握手，所以在大部分情况下，只需要 0 个 RTT 就能实现数据发送，在实现前向加密的基础上，并且 0RTT 的成功率相比 TLS 的会话记录单要高很多。

• 多路复用

虽然 HTTP/2 支持了多路复用，但是 TCP 协议终究是没有这个功能的。QUIC 原生就实现了这个功能，并且传输的单个数据流可以保证有序交付且不会影响其他的数据流，这样的技术就解决了之前 TCP 存在的问题。

同HTTP2.0一样，同一条 QUIC连接上可以创建多个stream，来发送多个HTTP请求，但是，QUIC是基于UDP的，一个连接上的多个stream之间没有依赖。比如下图中stream2丢了一个UDP包，不会影响后面跟着 Stream3 和 Stream4，不存在 TCP 队头阻塞。虽然stream2的那个包需要重新传，但是stream3、stream4的包无需等待，就可以发给用户。

另外QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的，这种方式在多变的移动端网络环境下是很脆弱的。但是 QUIC 是通过 ID 的方式去识别一个连接，不管你网络环境如何变化，只要 ID 不变，就能迅速重连上。

• 加密认证的报文

TCP 协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。

但是 QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。

这样只要对 QUIC 报文任何修改，接收端都能够及时发现，有效地降低了安全风险。

如上图所示，红色部分是 Stream Frame 的报文头部，有认证。绿色部分是报文内容，全部经过加密。

• 向前纠错机制

QUIC协议有一个非常独特的特性，称为向前纠错 (Forward Error Correction，FEC)，每个数据包除了它本身的内容之外，还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。向前纠错牺牲了每个数据包可以发送数据的上限，但是减少了因为丢包导致的数据重传，因为数据重传将会消耗更多的时间（包括确认数据包丢失、请求重传、等待新数据包等步骤的时间消耗）。

假如说这次我要发送三个包，那么协议会算出这三个包的异或值并单独发出一个校验包，也就是总共发出了四个包。当出现其中的非校验包丢包的情况时，可以通过另外三个包计算出丢失的数据包的内容。当然这种技术只能使用在丢失一个包的情况下，如果出现丢失多个包就不能使用纠错机制了，只能使用重传的方式了。