HTTP3版本和实现验证

HTTP3协议基于Google的 QUIC 协议，由互联网工程任务组（IETF）来制定。目录还是草案，已经进行到第33版。

HTTP3 是基于 QUIC 协议的 http。传输层是UDP+QUIC，应用层仍是HTTP，即request/respose, request里也仍是method, url, headers, body等等，从应用层的角度来看，你的代码无需修改就可以迁移到新的协议版本上来。

检查网站是否支持http3协议：

https://http3check.net/?host=...

curl 工具从7.67以后的版本增加对http3的实验性支持。

curl --http3 https://nghttp2.org:8443/

检查浏览器是否支持http3协议：

https://http3.is

今年10月，Facebook 号称超 75% 的流量已使用 QUIC 和 HTTP/3协议。

http 1.1 与http2 及http3协议的比较

![KGMJJO3%1R`A@PO0AGYK7M.png

与http2一样，http3也采用加密的二进制协议，不一新的是http3是基出UDP协议的。

关于为什么http3会采用UDP协议，带来了哪些好处，可以参考http3详解。 cURL的作者 Daniel Stenberg 对此有很详细的说明。包括协议僵化、TCP队关阻塞、减少延迟、安全等都有说明，且有中文译文，值得一看。

一些相关规范草案：

• 0-RTT
• H3-29
• H3-27
• H3-Q050
• H3-T051
• H3-T050
• H3-Q046
• H3-Q043
• Q046
• Q043

零往返时间恢复 Zero Round Trip Time Resumption (0-RTT)

当有人在浏览器中输入您网站的地址时，幕后发生了很多事情……

1. DNS查找 —— 将您的网站地址转换为IP地址的位置，这是浏览器实际用于请求您的网站的地址。因为一般会通过你的网络供应商（ISP）所提供的 DNS 服务器实现查找，且找到后都会缓存一段时间，这通常相对较快且延迟较低。
2. TCP握手 —— 浏览器将请求发送到已提供的IP地址，尝试与服务器建立连接–这需要1次往返（请求和响应）。
3. TLS握手 —— 建立连接后，浏览器和服务器现在可以决定他们都希望使用哪种加密协议– TLS 1.2和更低版本需要2次往返，而TLS 1.3可以降低到1次往返。
4. 页面提取 —— 现在他们正在使用相同的语言，浏览器请求您网站的内容，然后服务器将其返回-这需要再进行一次往返。

0-RTT 零往返时间恢复, 最早是TLS 1.3 提出和一种恢复连接的机制。即恢复链接时直接使用之前已经交换地的密钥加密应用数据，而无需再经历单独的建立 TCP 连接和 TLS 交换密钥的客户端服务器之前的数据往返。

0-RTT允许在无需任何往返的情况下恢复会话。

这里给一个总结...

• TLS 1.2（及更低版本）

• • 新会话：DNS + 4次往返
  • 续会：DNS + 3次往返

• TLS 1.3

• • 新会话：DNS + 3次往返
  • 续会：DNS + 3次往返

• 具有0-RTT的TLS 1.3

• • 新会话：DNS + 3次往返
  • 续会：DNS + 2次往返

从理论上讲，0-RTT因为使用以前的密钥，确实可以对网站来进行重放攻击。因此，在实施时需要一直保持谨慎，一般仅允许GET请求与0-RTT一起使用。由于GET请求永远不要修改服务器上的任何内容，只能返回结果，这意味着网站风险更小。

H3-29

打开 https://http3.is/ 网站：

普通青年看到的是这样的一个画面：

![D$@13N6`_NY@I7G6606{JC.png

文艺青年用Mac对chrome加参数打开：

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-quic --quic-version=h3-29

则看到了这样的画面：

mp4

同时在开发者工具栏会看到h3-29协议：

如果第一链接时没有显示动画，观察一下服务器的响应头，可以看到：

alt-svc: h3-29=":443";ma=86400,h3-27=":443";ma=86400

这实际是在告诉客户端可以升级到h3协议上。这时再刷新页面，chrome会切换到h3协议上去。这样就实现了新旧协议的过渡升级。