相比 HTTP/2 而言 HTTP/3 有以下几点提升：

HTTP/3 使用 stream 进一步扩展了 HTTP/2 的多路复用。在 HTTP/3 模式下，一般传输多少个文件就会产生对应数量的 stream。当这些文件中的其中一个发生丢包时，你只需要重传丢包文件的对应 stream 即可。
HTTP/3 不再是基于 TCP 建立的，而是通过 UDP 建立，在用户空间保证传输的可靠性，相比 TCP，UDP 之上的 QUIC 协议提高了连接建立的速度，降低了延迟。
通过引入 Connection ID，使得 HTTP/3 支持连接迁移以及 NAT 的重绑定。
HTTP/3 含有一个包括验证、加密、数据及负载的 built-in 的 TLS 安全机制。
拥塞控制。TCP 是在内核区实现的，而 HTTP/3 将拥塞控制移出了内核，通过用户空间来实现。这样做的好处就是不再需要等待内核更新可以实现很方便的进行快速迭代。
头部压缩。HTTP/2 使用的 HPACK，HTTP/3 更换成了兼容 HPACK 的 QPACK 压缩方案。QPACK 优化了对乱序发送的支持，也优化了压缩率。

HTTP/3 建立传输用的是 UDP 协议，而在 HTTP/3 出现前 UDP 的通常出现地点是类似《计算机网络》这样的书面理论，即便是实际应用也大多和网络攻击一起出现，这就导致 UDP 的名声不太好。名声差了自然在硬件上的支持也捉襟见肘，大部分互联网服务也就理所当然的对 UDP 的访问进行限制。

HTTP/3 是目前最前沿的互联网标准，它的缺点可以通过不断的改进来完善。相比与 HTTP/3 本身的缺陷问题，作为一项新技术最致命的问题是能否获得足够多的有效支持，从而进行大范围推广。

那么当前的环境已经有迎接 HTTP/3 的能力了么？

HTTP/3 作为互联网的标准革新之一，在支持方面无非两点，一个是服务端，一个是客户端。

先来看一下客户端，大家所熟悉的浏览器 Chrome 以及常用 Curl 命令行工具都已经支持 HTTP/3 特性。在 Chrome 的开发者工具一栏里你可以看到一项显示为“HTTP/2+quic/99”，这就是 Chrome 已经支持 HTTP/3 的证据。毕竟 HTTP/3 的组成离不开 QUIC 协议。

而在 Curl 命令行工具[https://github.com/curl/curl] 的最新版本， 你只需在常规的命令末尾添加“--HTTP/3”即可使用 HTTP/3，如果目标服务器支持，它会自然的返回“HTTP/3 200”。

自 2013 年 QUIC 被正式公开以来，到 2020 年已经发展了差不多7年，目前网上已经有了不少热门开源的项目，除去带头大哥 Google 在完成了对自身搜索引擎的支持，还同时拉上了 Gmail 、YouTube 等站点。但对于国内的绝大部分站点来说，HTTP/3 之路，似乎还停留在东土大唐，即使 Nginx 已经公开声明：“我们已经支持 QUIC 协议“。

虽然目前环境还没有全面迭代到 HTTP/3 ，但是 HTTP/3 的发展是不可阻拦的。