最近 IETF （互联网工程任务组），负责开发互联网的协议和架构， 广为人知 那个新闻 完成了 HTTP/3.0 协议的 RFC 的形成 并在标识符 RFC 9114 和 RFC 9204 下发布了相关规范。
HTTP/3.0 规范 收到“建议标准”的状态， 之后工作将开始为 RFC 提供标准草案（Draft Standard）的状态，这实际上意味着协议的完全稳定并考虑到所有的评论。
协议书 HTTP/3 定义了 QUIC 协议的使用 （快速 UDP 互联网连接） 作为 HTTP/2 的传输。 QUIC 是 UDP 协议的插件，支持多连接的多路复用，并提供等同于 TLS/SSL 的加密方法。
该协议由 Google 于 2013 年创建 作为 Web 的 TCP + TLS 的替代方案，解决了 TCP 中连接建立和协商时间过长的问题，并消除了数据传输过程中由于丢包而导致的延迟。
目前， QUIC 和 HTTP/3.0 支持已经在所有浏览器中实现 热门网站。 在服务器端，HTTP/3 的实现可用于 nginx（在单独的分支中并作为单独的模块）、Caddy、IIS 和 LiteSpeed。 Cloudflare 的内容交付网络也支持 HTTP/3。
QUIC的主要特点：
- 高安全性，类似于 TLS（实际上 QUIC 提供了使用 TLS over UDP 的能力）
- 传输完整性控制，防止丢包
- 立即建立连接并确保发送请求和接收响应之间的延迟最小的能力（RTT，往返时间）
- 重传数据包时使用不同的序列号，让您在确定收到的数据包时避免歧义并摆脱超时
- 丢失数据包只会影响与其关联的流的传递，并且不会停止通过当前连接并行传输的流中数据的传递
- 纠错工具，可最大限度地减少由于丢失数据包的重新传输而导致的延迟。 使用特殊的数据包级纠错码来减少需要重新传输丢失的数据包数据的情况。
- 加密块边界与QUIC包边界对齐，减少丢包对后续包内容解码的影响
- 阻止TCP队列没有问题
- 连接识别支持以减少移动客户端的重新连接时间
- 连接用于连接过载控制的高级机制的可能性
- 在每个方向上使用带宽预测技术来确保最佳的数据包转发率，避免数据包丢失的拥塞情况。
- 显着的性能和性能优于 TCP。 对于 YouTube 等视频服务，QUIC 已被证明可以将视频缓冲操作减少 30%。
除此之外，同时还发布了 HTTP/1.1 (RFC 9112) 和 HTTP/2.0 (RFC 9113) 协议规范的更新版本，以及定义 HTTP 请求语义的文档 (RFC 9110). 和 HTTP 缓存控制标头 (RFC 9111)。
的变化 规范 HTTP/1.1，你可以注意到禁令 从单独使用回车符 (CR) 正文以外的内容，即在协议元素中，CR 字符只能与换行符（CRLF）一起使用。
El 改进了分块请求布局算法 以简化带有标题的附加字段和部分的分离。 添加了处理模糊内容的指南，以阻止“HTTP 请求走私”类攻击，这些攻击可能会侵入前端和后端之间流中其他用户请求的内容。
规范的更新 HTTP/2.0 明确定义了对 TLS 1.3 的支持， 不推荐使用的优先级方案和相关的头字段和更新机制 已弃用 HTTP/1.1 连接已弃用。
最后，如果您有兴趣能够了解更多，可以在 以下链接。