1. HTTP 3.0

1.1. 什么是HTTP 3.0标准

2022 年 6 月 6 日，IETF（互联网工程任务组）宣布了 HTTP/3 标准，编号为 RFC 9114。

目前 RFC 9114 HTTP/3 处于 “提案标准 (PROPOSED STANDARD)” 状态，尚未成为正式标准，标准详细内容参见RFC 9114

HTTP/3 即 HTTP-over-QUIC，是采用了 QUIC 进行传输的新 HTTP 协议。
QUIC (Quick UDP Internet Connections) 是 Google 提出来的一个基于 UDP 的传输协议，所以 QUIC 又被叫做快速 UDP 互联网连接。

当 IETF 开始标准化 QUIC 时，它分成了两个层：传输和 HTTP。该传输协议能用于传输其它数据，不限于 HTTP 或类 HTTP 协议。

目前还没有浏览器或服务器提供官方支持，尽管行业和官方机构投入了大量资源，也不能保证它会成为事实上的标准。
然而，在HTTP3快速发展时，这个领域的发展绝对值得关注。

1.2. HTTP协议的演变

1.3. HTTP相关的标准

1.4. 相较于HTTP 2的变化

HTTP 3.0 其实相较于 HTTP 2.0 要比 HTTP 2.0 相较于 HTTP 1.1 的变化来说小很多，最大的提升就在于效率，替换 TCP 协议为 UDP 协议HTTP 3.0 具有更低的延迟，它的效率甚至要比 HTTP 1.1 快 3 倍以上。

优势如下：

• 使用 UDP 协议，不需要三次连接进行握手，而且也会缩短 TLS 建立连接的时间。
• 解决了队头阻塞问题。
• 实现动态可插拔，在应用层实现了拥塞控制算法，可以随时切换。
• 报文头和报文体分别进行认证和加密处理，保障安全性。
• 连接能够平滑迁移。
  

1.5. QUIC 快在哪里？

• HTTP 2.x 协议在传输层是使用了 TCP 进行报文传输，而且 HTTPS 、HTTP/2.0 还采用了 TLS 协议进行加密，这样就会导致三次握手的连接延迟：即 TCP 三次握手（一次）和 TLS 握手（两次），如下图所示。

  • 对于很多短连接场景，这种握手延迟影响较大，而且无法消除。毕竟 RTT （Round Trip Time 往返时延）是人类和效率的终极斗争。
  • HTTP/2.0 虽然解决了队头阻塞问题，但是其建立的连接还是基于 TCP，无法解决请求阻塞问题。
  • TCP 为了保证数据的可靠性，使用了序号+确认号机制来实现，一旦带有 synchronize sequence number 的包发送到服务器，服务器都会在一定时间内进行响应，如果过了这段时间没有响应，客户端就会重传这个包，直到服务器收到数据包并作出响应为止。
  • TCP 一般采用的是自适应重传算法，这个超时时间会根据往返时间 RTT 动态调整的。每次客户端都会使用相同的 syn 来判断超时时间，导致这个 RTT 的结果计算的不太准确
  • TCP 协议的具体实现是由操作系统内核来完成的，应用程序只能使用，不能对内核进行修改
  • TCP 协议头部没有经过加密和认证，所以在传输的过程中很可能被篡改
    

• HTTP 2.x 协议在传输层是使用了 QUIC 进行报文传输, 不需要三次连接进行握手，而且也会缩短 TLS 建立连接的时间，如上图所示：

  • 使用了 UDP 作为传输层协议，这样能够减少三次握手的时间延迟。
  • QUIC 的加密协议采用了 TLS 协议的最新版本 TLS 1.3，相对之前的 TLS 1.1-1.2，TLS1.3 允许客户端无需等待 TLS 握手完成就开始发送应用程序数据的操作，可以支持1 RTT 和 0 RTT，从而达到快速建立连接的效果。
  • UDP 本身没有建立连接这个概念，并且 QUIC 使用的 stream 之间是相互隔离的，不会阻塞其他 stream 数据的处理，所以使用 UDP 并不会造成队头阻塞
  • QUIC 实现可靠性的机制是使用了 Packet Number，这个序列号可以认为是 synchronize sequence number 的替代者，这个序列号也是递增的。与 syn 所不同的是，不管服务器有没有接收到数据包，这个 Packet Number 都会 + 1，而 syn 是只有服务器发送 ack 响应之后，syn 才会 + 1
    • 比如有一个 PN = 10 的数据包在发送的过程中由于某些原因迟迟没到服务器，那么客户端会重传一个 PN = 11 的数据包，经过一段时间后客户端收到 PN = 10 的响应后再回送响应报文，此时的 RTT 就是 PN = 10 这个数据包在网络中的生存时间，这样计算相对比较准确
  • QUIC通过引入stream offset 保证数据的可靠性。
    • 一个 stream 可以传输多个 stream offset，每个 stream offset 其实就是一个 PN 标识的数据，即使某个 PN 标识的数据丢失，PN + 1 后，它重传的仍旧是 PN 所标识的数据，等到所有 PN 标识的数据发送到服务器，就会进行重组，以此来保证数据可靠性。
    • 到达服务器的 stream offset 会按照顺序进行组装，这同时也保证了数据的顺序性。
  • QUIC 协议的一个重要特点就是可插拔性，能够动态更新和升级，QUIC 在应用层实现了拥塞控制算法，不需要操作系统和内核的支持，遇到拥塞控制算法切换时，只需要在服务器重新加载一边即可，不需要停机和重启。
  • QUIC 中的报文头部都是经过认证，报文也经过加密处理。这样只要对 QUIC 的报文有任何修改，接收端都能够及时发现，保证了安全性

2. HTTP/3的最佳用例

2.1. 物联网(IoT)

由于其局限性，HTTP可能不是物联网的首选协议，但有些应用程序非常适合基于HTTP的通信。例如，HTTP/3可以解决移动设备从附加传感器收集数据的有损无线连接问题。这也适用于安装在车辆或移动资产上的独立物联网设备。因为HTTP/3有一个健壮的传输层，通过HTTP访问和从这些设备访问更加可靠。

2.2. Microservices

QUIC的优势在于相对较少的握手，可以更快的传递这些请求，并且微服务相对更纯粹，允许真正的单一责任。
HTTP/3在这里的好处不仅在于大数据的吞吐量，而且在于加快每一个微交互。

2.3. Web Virtual Reality (VR)

虽然VR技术还处于起步阶段，但在很多情况下，VR技术在加强协作方面发挥着关键作用。在促进这种丰富的虚拟现实互动方面，WEB交互占据了中心舞台。
VR应用需要更多的带宽来渲染虚拟场景中的复杂细节，因此迁移到HTTP/3会大有收获。

2.4. 实时广告招标

当一个广告被提供给网络浏览器时，它会被实时竞价。页面和用户信息被发送到广告交易所，然后拍卖给出价最高的广告商。所有能够向消费者提供广告的公司都在投标，希望成为给消费者留下这种印象的公司。这是一场对广告服务网络所提供空间的算法竞争。

拥有一个只需要一次确认(一次握手)的连接大大提高了竞价的性能，并允许它加载更有响应性，确保页面加载不被这一系列的竞争延迟。更快的广告加载意味着更快的页面加载。

3. HTTP 3相关的开源项目

• quiche: quiche提供了一个低级编程接口，用于通过QUIC协议发送和接收数据包。它还支持HTTP/3模块，通过它的QUIC协议实现发送HTTP数据包。此外，它为NGINX服务器提供了一个非官方的补丁，用于安装和托管一个能够运行HTTP/3的web服务器，以及Android和iOS移动应用程序的包装器支持。
• Aioquic: Aioquic是QUIC的python实现。它还支持HTTP/3的内置测试服务器和客户端库。Aioquic构建在asyncio模块【Python的标准异步I/O框架】之上。
• Neqo：Neqo是Mozilla使用Rust实现的QUIC和HTTP/3。

4. HTTP3的限制

• 转换到HTTP/3不仅涉及到应用程序层的更改，还涉及到底层传输层的更改。因此，采用HTTP/3比它的前身HTTP/2更具有挑战性，后者只需要在应用层进行更改。新的传输机制的引入对IT基础设施和运维团队产生了一些影响。
• 安全服务的构建通常基于这样一个前提:应用程序流量(大部分是HTTP)将通过TCP传输，TCP是两个协议中关注可靠性、面向连接的协议。UDP的更改可能会对安全基础设施解析和分析应用程序流量的能力产生重大影响，因为UDP是一种基于数据报(包)的协议，可能是不可靠的。
• UDP的另一个问题是，TCP目前是大多数web流量的首选协议，以及由IETF定义的知名服务。对于运行HTTP/3协议的UDP会话时间过长，防火墙的默认包过滤策略可能不支持
• 采用HTTP/3可能太笨重的另一个场景是受限的物联网设备。许多物联网应用部署了具有有限RAM和CPU功率的low form-factor 设备。强制执行这一要求是为了使设备在有限的条件下高效运行，如电池功率、低比特率和有损连接。
• HTTP/3的额外传输层处理，以现有UDP之上的QUIC的形式，增加了整个协议栈的占用空间，它使得HTTP/3足够庞大，不适合那些物联网设备。与之相对的是，这种情况很少，而且存在诸如MQTT这样的专用协议，从而避免了在此类设备上直接支持HTTP的需要。

参考

• HTTP/3 Deep Dive