共计 2861 个字符，预计需要花费 8 分钟才能阅读完成。
原文作者：汤炜涛
原文链接：分享实录 | NGINX QUIC & HTTP/3 最新进展
转载起源：NGINX 开源社区
NGINX 惟一中文官网社区，尽在 nginx.org.cn
编者按——本文为 NGINX Sprint China 2022 年度线上大会的分享实录，点击文末此处收费观看大会残缺视频回放。
Internet 从未进行过后退的脚步。早在 2015 年 HTTP/2 标准化之前，QUIC 的相干工作就曾经开始了，而在之后 QUIC 成为了 HTTP/3，当然，演变之路并不是那么轻松。现在 QUIC 和 HTTP/3 协定倒退到何种水平？本次分享汤炜涛老师回顾 HTTP 协定的倒退历程。
介绍 QUIC 和 HTTP/3 协定，HTTP/3 协定的长处以及为什么须要 HTTP/3 协定。介绍 NGINX 对 QUIC 和 HTTP/3 协定的反对，解说版本要求和配置办法。
HTTP 协定的倒退
首先简短回顾一下 HTTP 协定倒退历程。HTTP 协定最早诞生在欧洲核子核心，目前咱们把在 HTTP/1.0 正式公布之前的所有协定统称为 HTTP/0.9，最后的 HTTP/0.9 是一个非常简单的协定，仅有 GET 一种办法，直到 HTTP/1.0 才倒退成了大家当初所相熟的 HTTP 协定，当初为止 HTTP/1.0 仍然在宽泛的应用。
HTTP/1.1 以 HTTP/1.0 为根底进行了一些优化，是目前为止互联网应用最多的协定。它最大的优化在于引入了会话机制，当咱们的客户端和服务器之间间断申请多个资源时，并不会像 HTTP/1.0 一样，每申请一个资源就建设一个 TCP 连贯，而是保留一个 TCP 会话连贯，后续的资源都能够用已有的 TCP 连贯来去进行传输，减少了 TCP 连贯的应用效率。
然而如果想一次性并发申请多个资源，在 HTTP/1.1 协定下，为了提高效率通常会一次性并发建设多个 TCP 连贯，这会在效率上有所节约。所以 HTTP/2 最大的变动是退出了连贯复用机制，即当客户端要并发申请多个资源时，能够在一个 TCP 连贯里实现，引入了 Stream 流机制去解决并发传输的问题。另外，HTTP/2 把 TLS 加密变成了强制性。
HTTP/3 最大的改良就是把 HTTP 协定始终在应用的传输层协定，从 TCP 改到了基于 UDP 的 QUIC 协定。
目前 HTTP/1 仍然是支流协定，对于 HTTP/2 来说，已有超过 40% 的网站反对，仅有有余 26% 的网站反对 HTTP/3。
HTTP/2 存在队头阻塞这一个大问题。这个起因后面有说过，HTTP/2 协定引入了连贯复用机制，能够使咱们在一个 TCP 通道里并行申请多个资源，而不像传统的 HTTP/1 协定存在程序性，并且 HTTP/2 把 HTTP/1 的文本格式传输优化为二进制传输，但这样的改良也带来新的问题——队头梗塞。
TCP 是一个牢靠的传速层协定，它须要接收端回复信息之后才会进行后续的数据传输，然而这样就会导致资源传输慢，甚至效率还不如 HTTP/1，因为 HTTP/1 还能够并发多个 TCP 连贯申请多个资源。然而对于 HTTP/2 来说，当所有的资源都放在同一个连贯外面程序传输时，某一个环节出错后，后续的环节也不会进行上来，造成队头梗塞问题。
QUIC 及 HTTP/3 介绍
QUIC 协定是基于 UDP 的传输层协定，它最显著的扭转包含以下几个方面：
把复用移到了传输层
- 简化 HTTP：间接将连贯复用机制搁置在 QUIC 协定内来解决，简化了 HTTP 层面。
应用新的传输层协定
- 解决队头梗塞：应用全新的传输层协定 UDP，解决队头梗塞问题。
- TLS 已被包含(不再是独自一层)：把 TLS 间接嵌入在 QUIC 协定里，而不是独自一层实现。
- 连贯迁徙：在 QUIC 协定里不再依赖于四元组标记连贯，而是应用 Connection ID 标记连贯。只有放弃 Connection ID 不变，即便扭转原地址和源端口仍旧能够放弃原有连贯。
- 在用户空间实现而不是内核：QUIC 协定是在 Linux 的用户空间，而不是内核实现的。这样的益处是咱们能够更加疾速地迭代，不用依赖于内核的一些降级。
HTTP 语义放弃不变
- GET 仍旧是 GETHeaders 也还是 Headers。
尽管目前可能有 40% 的网站反对 HTTP/2，靠近 25% 的网站反对 HTTP/3，然而在理论部署状况中，对于 HTTP/2 和 HTTP/3 的反对，可能并不是实在的 Web 服务器或者应用服务器反对，而是依赖于前端相似 NGINX 这样的一个反向代理，或者是互联网 CDN 这样的技术进行反对，这也使得利用还能够放弃 HTTP/1 的协定不变。
这次要是因为 HTTP/2 和 HTTP/3 所做的改良更多是为了减少互联网传输效率，次要是在互联网应用，而在内网环境个别都会有高速牢靠的一个网络连接，所以并不会应用 HTTP/2 和 HTTP/3 从而减少开发难度。
NGINX 对 QUIC 和 HTTP/3 的反对
- 独自的 QUIC 分支进行开发：目前 NGINX 对 QUIC 的反对是应用了一个独自的分支进行开发，您能够点击 NGINX— QUIC 版本下载进行测试及应用。
- 不同的模块实现：QUIC 和 HTTP/3 的会在不同的模块进行实现。QUIC 的反对会在 core 模块实现，HTTP/3 的反对会在 http_v3_module 模块实现。
- 更多的 TLS 反对：TLS 反对应用 BoringSSL、LibreSSL 或者 OpenSSL 的 quic tls fork。
- 反对连贯迁徙：为了在 NGINX 多过程的架构下反对连贯迁徙，NGINX 研发团队开发了一个 eBPF 我的项目来反对 QUIC 的连贯迁徙。
- 原打算于 2022 年底将 QUIC 分支 Merge 到主线版本。
在配置 HTTP/3 时，除了反向代理节点需反对 QUIC 和 HTTP/3 协定外，还须要解决如何同客户端协商的问题。家喻户晓，从 HTTP/1 降级到 HTTP/2 只须要进行协定降级就能够，然而 HTTP/3 应用了基于 UDP 的 QUIC 协定，所以用户除非应用专属客户端，否则浏览器默认并不会在开始的时候向服务端发动 UDP 连贯申请。
所以要去反对 QUIC 和 HTTP/3 协定，还须要领有一个 HTTP/1 或者 HTTP/2 的服务进行兜底，保障能够先解决客户端默认发过来的基于 TCP 的连贯申请。
服务端再在 Response 中退出相似于 Alt-Svc: h3=”:443″ 的 Header 去告诉客户端反对 HTTP/3 协定以及应用的端口，进而使后续的服务申请能够应用 QUIC 协定。
接下来是具体的 NGINX 配置的状况。肯定要应用 NGINX QUIC 的分支编译，还须要退出 HTTP/3 的 module。目前外围的指令为两条，首先须要减少一个基于 UDP 的 Listener，同时要退出 reuseport 参数来反对连贯迁徙机制。
其次须要在响应里退出一个 Header，使客户端能够及时接管到服务端反对 HTTP/3 协定，明确反对端口，保障客户端能够通过相应的 UDP 端口来发动 QUIC 连贯。
NGINX 惟一中文官网社区，尽在 nginx.org.cn
更多 NGINX 相干的技术干货、互动问答、系列课程、流动资源：
开源社区官网：https://www.nginx.org.cn/
微信公众号：https://mp.weixin.qq.com/s/XVE5