支持QUIC和 HTTP/3 的NGINX技术预览版上线
396 次浏览
发表于 2021-10-22 09:53

作者: Liam Crilly

发布时间:2020 年 6 月 10 日


注记QUIC的协议规范已经在2021527日定稿,欲了解NGINX最新针对 QUIC  HTTP/3 产品路线,点击阅读原文阅读我们的最新英文博客文章。


很高兴宣布NGINX支持 QUIC+HTTP/3的预览版本正式发布。该预览版实现了IETF QUIC 草案规范,并由独立的发分支维护,与稳定分支及主线分支隔离。经过几个月的初步开发,该版本已可进行互操作性测试,并接受意见反馈和代码贡献了。

官方同时提供了一个基于NGINX QUIC+HTTP/3实现的演示站点:https://quic.nginx.org/


HTTP/3 的前世今生

当今世界瞬息万变,但超文本传输协议 (HTTP) 却在过去二十多年里始终未曾改变。HTTP/1.1 标准发布于 1999 年,现已成为 Web 应用和 API 普遍使用的传输协议。在协议发布后的21 年里,虽然应用和服务都发生了翻天覆地的变化,但协议本身仍未有变。

有的读者可能会问,“不是已推出了 HTTP/2 吗?”。这个问题问得好。HTTP/2 标准发布于 2015 年,目前已经有 45% 的面向互联网的网站采用了 HTTP/2。然而,此统计数据掩盖了这样一个事实,即 HTTP 在公共互联网与在“最后一英里(运行时基础架构)上的使用有很大不同。

事实上,HTTP/2 很少被端到端地部署到现代互联网基础架构中。HTTP/2 的目的是解决公共互联网中最突出的一些问题,例如延迟过长且难以预测,以及一旦一个 HTTP 请求出现问题,后续请求就都可能会出现延迟

然而,在应用运行环境内部(例如公有云或私有数据中心),网络延迟低且可靠性高,基于文本传输的HTTP/1.1在可检测方面比基于流的HTTP/2更好,因此HTTP/2并不占优势。

HTTP/2 非常适用于客户端到运行时基础架构的“边缘”环境,其很大程度改善了浏览器和移动设备的用户体验。此时,HTTP/2请求通常会被代理到使用 HTTP/1.1 的内部运行时环境中。边缘很可能是 CDN 提供商,或是负责入口流量处理的反向代理负载均衡器。



两大 HTTP 版本的典型混合部署


既然这种混合使用 HTTP/2 和 HTTP/1.1 来交付网站和应用的方法效果很好,那么为什么要提出去开发另一新协议 HTTP/3 呢?

HTTP/2 的主要创新在于使用 TCP 作为底层传输时,利用单个连接的多路复用方式处理HTTP请求。然而,TCP 本身固有的局限性,限制了网站和应用的性能及用户体验。

TCP 标准首次发布于 1981 年,作为通用传输协议取得了巨大成功。但是,当您通过同一连接多路复用多个独立请求时,它们都会受限于该连接的可靠性。只要有一个请求的数据包丢失,所有多路复用请求都会延迟,直到检测到丢失的数据包,然后重新传输。

HTTP/3 基于 QUIC 传输协议,该协议专门用于支持多路复用连接,并摆脱了对单个 TCP 连接的依赖。QUIC 使用 UDP 作为在客户端和服务器之间的数据包底层传输机制,并为HTTP 请求提供可靠连接。值得注意的是,QUIC 还将 TLS作为内置组件,而不是像 HTTP/1.1 和 HTTP/2 那样作为附加层。



HTTP 传输栈简要概述


QUIC 的目标是为 HTTP/3 提供高性能、高可靠性、高安全性的传输协议(尽管 QUIC 也适用于非 HTTP 流量)。从语义上讲,HTTP/3 本身与 HTTP/2 非常相似。然而,在没有明确的 HTTP 版本指定时,网站地址https://www.example.com可能同时支持HTTP/1.1、HTTP/2 和 HTTP/3版本中的一个或多个,此时客户端(或Web 浏览器)如何知道使用哪个 HTTP 版本?

版本识别问题最初随着 HTTP/2 的发布而出现,为了解决这个问题,开发人员使用 TLS 握手机制来检测客户端和服务器能否通过 HTTP/2 通信。这样,客户端早在连接建立之前就知道如何与服务器对话。然而,QUIC 使用 UDP(代替 TCP)作为底层传输协议也产生了新的问题,即客户端如何知道初始请求应该建立哪种类型的连接,TCP 还是 UDP?

解决方法是让客户端为初始 HTTP 请求建立 TCP 连接。支持 HTTP/3 的服务器返回信息会包含 Alt-Svc Header,同时Alt-Svc还可指定监听 HTTP/3 流量的 UDP 端口。此外,浏览器还会记住哪些站点支持 QUIC,以减少频繁使用 Alt-Svc 方式探测QUIC协议支持与否带来的开销。


NGINX QUIC+HTTP/3 预览版

今天我们正式推出了支持QUIC 和 HTTP/3的NGINX初始版本 — http_v3_module。该版本为技术预览版,仅供实验使用,不适用于生产环境。在撰写本文时,QUIC 标准尚未定稿,此初始版本根据当前草案的子集实现。

经过数月的设计和开发,http_v3_module 现在已经可以进行互操作性测试了。我们也非常欢迎大家提供反馈意见并贡献代码。请注意,NGINX 开源主线开发分支(以及任何版本的 NGINX Plus)暂不提供 http_v3_module,它仍然是实验版本,并位于专门的开发分支中:https://hg.nginx.org/nginx-quic

另请注意,此 QUIC+HTTP/3 实现是全新的,与 Cloudflare quiche 项目提供的补丁无关。

对于熟悉 NGINX 配置的人来说,QUIC+HTTP/3 的启用过程非常简单。

server {
listen 443 ssl; # TCP listener for HTTP/1.1
listen 443 http3 reuseport; # UDP listener for QUIC+HTTP/3

ssl_protocols TLSv1.3; # QUIC requires TLS 1.3
ssl_certificate ssl/www.example.com.crt;
ssl_certificate_key ssl/www.example.com.key;

add_header Alt-Svc 'h3=":443"'; # Advertise that HTTP/3 is available
add_header QUIC-Status $quic; # Sent when QUIC was used
}


有关从 nginx-quic 源码库构建 NGINX 的更多信息和推荐配置,请参阅README。此外,http_v3_module 的演示站点请参见 https://quic.nginx.org/

您也可以通过访问该网站检查您的浏览器是否支持 QUIC,并将 HTTP/3 互操作性与自己构建的 nginx-quic 进行比较。由于 QUIC 标准尚未定稿,您可能需要使用常用浏览器的开发版本或最新版本启用 QUIC 连接。

感谢试用 nginx-quic,期待您的反馈:

 如果您有任何意见或建议,请在下方的评论区告诉我们,或发送到 NGINX 邮件列表

 如果您遇到错误或异常行为,或者需要故障定位帮助,请将您的消息发送到 NGINX 邮件列表(NGINX 研发团队会予以密切关注)。


发表评论
发表者

NGINX官方账号

NGINX官方账号

  • 63

    文章

  • 3

    关注

  • 136

    粉丝

活动推荐
版权所有©F5 Networks,Inc.保留所有权利。京ICP备16013763号-5