Core Concepts(核心概念)

首先，提出几个问题:

HTTP/3 是什么？
为什么在 HTTP/2 之后这么快就需要 HTTP/3？
HTTP/3 如何提升 Web 性能？

那 HTTP/3 是什么？为什么需要HTTP/3？

实际上我们并不需要一个新的 HTTP 版本，而是底层传输控制协议 (TCP) 的升级

QUIC 就是用来替代 TCP、SSL/TLS 的传输层协议，运行在 QUIC 之上的 HTTP 协议被称为 HTTP/3

为什么需要 QUIC？

因为 TCP 并没有真正考虑到最大效率

为了确保客户端和服务器都存在，并且能够交换数据
TCP需要"握手"来建立新的连接，这需要耗费一个 RTT(完整的网络往返时间) 才能完成
TCP 将其传输的所有数据视为单个“文件”或字节流，即使实际上它同时传输着多个文件
队头阻塞：如果包含单个文件数据的 TCP 数据包丢失，那么所有其他文件也将延迟，直到这些数据包被恢复
QUIC 连接可以保持更长时间

零 RTT 建立连接

HTTP/2 的连接需要 3 RTT，如果考虑会话复用，即把第一次握手算出来的对称密钥缓存起来，那么也需要 2 RTT；如果 TLS 升级到 1.3，那么 HTTP/2 连接需要 2 RTT，考虑会话复用则需要 1 RTT(TLS 1.3 的握手不再支持静态的 RSA 密钥交换，使用带有前向安全的 Diffie-Hellman 进行全面握手)

HTTP/3 首次连接只需要 1 RTT，后面的连接更是只需 0 RTT，意味着客户端发给服务端的第一个包就带有请求数据

HTTP/1.1 提出了 Pipelining 技术，允许一个 TCP 连接同时发送多个请求

一个 TCP 连接同时传输 10 个请求，

其中第 1、2、3 个请求已被客户端接收，但第 4 个请求丢失，那么后面第 5 - 10 个请求都被阻塞，需要等第 4 个请求处理完毕才能被处理，这样就浪费了带宽资源

HTTP/2 中每个请求都被拆分成多个 Frame 通过一条 TCP 连接同时被传输，这样即使一个请求被阻塞，也不会影响其他的请求

在一条 TCP 连接上同时发送 N 个 Stream，其中 Stream1 已正确送达，Stream2 中的第 2 个 Frame 丢失，

TCP 处理数据时有严格的前后顺序，先发送的 Frame 要先被处理，这样就会要求发送方重新发送第 2 个 Frame，Stream3 和 Stream4 虽然已到达但却不能被处理，那么这时整条连接都被阻塞

那 QUIC 是如何解决队头阻塞问题的呢？

QUIC 的传输单元是 Packet，加密单元也是 Packet，整个加密、传输、解密都基于 Packet，这样就能避免 TLS 的队头阻塞问题
QUIC 基于 UDP，UDP 的数据包在接收端没有处理顺序，即使中间丢失一个包，也不会阻塞整条连接，其他的资源会被正常处理

QUIC 支持连接迁移

TCP 连接基于四元组（源 IP、源端口、目的 IP、目的端口），切换网络时至少会有一个因素发生变化，导致连接发生变化(比如，NAT重新绑定)

当连接发生变化时，如果还使用原来的 TCP 连接，则会导致连接失败，就得等原来的连接超时后重新建立连接

QUIC 连接不以四元组作为标识，而是使用一个 64 位的随机数，这个随机数被称为 Connection ID，这个 CID 是在 QUIC 本身的传输层定义的

所以即使 IP 或者端口发生变化，只要 Connection ID 没有变化，那么连接依然可以维持

QUIC 使用单独的帧来发送元数据

QUIC 具有较短的数据包头，并在数据包有效载荷中使用各种“帧”来传达额外信息。例如，一个 ACK 帧（确认）、一个 NEW_CONNECTION_ID 帧（帮助建立连接迁移）和一个 STREAM 帧（携带数据）

使用帧的作用是，将来定义新的帧类型作为 QUIC 的扩展将非常容易

Performance Improvements(性能表现)

QUIC 和 HTTP/3 具有巨大的 Web 性能潜力，但主要适用于网络速度较慢的用户

拥塞控制

传输协议如何有效地使用网络的全部带宽

TCP 通过使用称为拥塞控制的机制不断尝试发现可用带宽

尽管 TCP 的拥塞控制使其稳健，但这也意味着需要一段时间才能达到最佳发送速率，具体取决于 RTT 和实际可用带宽

QUIC 拥塞控制的实现

QUIC 实际上使用与 TCP 非常相似的带宽管理技术。它也从较低的发送速率开始，并随着时间的推移而增长，使用确认（ACK）作为衡量网络容量的关键机制。所以 QUIC 在管理带宽方面没有比 TCP 更聪明，只是 QUIC 比 TCP 更灵活，更容易演进。

官方的 QUIC Recovery RFC 9002 指定了 NewReno 拥塞控制算法的使用

参考
HTTP/3 From A To Z: Core Concepts (Part 1) — Smashing MagazineWhat exactly is HTTP/3? Why was it needed so soon after HTTP/2 (which was only finalized in 2015)? How can or should you use it? And especially, how does this improve web performance? Let’s find out.https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/HTTP/3: Performance Improvements (Part 2) — Smashing Magazinehttps://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/The Road to QUIChttps://blog.cloudflare.com/the-road-to-quic/#onenattobringthemallandinthedarknessbindthem

Dissect HTTP3相关推荐

QUIC/HTTP3 协议简析
从 HTTP 的进化历史讲起,细说使用协议的变迁,了解原因发现问题,解码 QUIC 在 HTTP3 中的支撑作用,共同探讨 HTTP3 的未来. HTTP.HTTP2 和 HTTP3 先和大家来回顾一 ...
HTTP的前世今生（HTTP1.1，HTTPS，SPDY，HTTP2.0，QUIC，HTTP3.0）
本文将从HTTP不断发展的时间线来讲解与其相关的知识点,其中包括HTTP1.1,HTTPS,SPDY,HTTP2.0,QUIC,HTTP3.0等,文章中内容涉及面较广,属于扫盲级别,不会特别深入某个知 ...
QUIC实战(五) 使用nginx quic开发分支部署支持HTTP3 的NGINX
使用nginx + Quiche 部署的支持HTTP3的nginx在实际测试过程中遇到了一些问题,Quiche本身是由go + rust编写的,nginx又是由c++编写的,对于我们来说未知的内容太多 ...
QUIC实战(二) AWS 搭建nginx(http3.0) + upsync + consul(server-client模式) 集群
前面的博客介绍了怎么编译支持http3的nginx,并添加了upsync模块.为了在生产环境验证QUIC,我在aws搭建了一个Nginx + upsync + consul的集群 ,支持动态负载均衡. ...
QUIC实战(一) 通过Quiche部署支持HTTP3 的NGINX
之前研究了下quic相关的特性,不过一直没有去搭建过,最近需要在公司搭建一个quic的生产测试环境,记录一下也方便其他需要搭建环境的开发参考. QUIC的搭建方案有很多,最后我们选择了Quiche.C ...
你们公司还没使用HTTP3？赶紧来补一补，学习一下如何在Nginx上配置HTTP3。
你们公司还没使用HTTP3?赶紧来补一补,学习一下如何在Nginx上配置HTTP3. NGINX最新版本,已提供对 QUIC 和 HTTP/3的支持,本文介绍一下如何安装与配置很高兴能在一个特殊的开 ...
HTTP3快来了，提前学习一下如何在Nginx中支持HTTP3.0/QUIC
HTTP3快来了,提前学习一下如何在Nginx中支持HTTP3.0/QUIC HTTP3.0,也称作HTTP over QUIC.核心是QUIC(读音quick)协议,由Google在2015年提出的 ...
在Nginx中支持HTTP3.0/QUIC
在Nginx中支持HTTP3.0/QUIC HTTP3.0,也称作HTTP over QUIC.核心是QUIC(读音quick)协议,由Google在2015年提出的SPDY v3演化而来的新协议,传 ...
地推HTTP3和QUIC
HTTP/3的目标是通过解决HTTP/2的传输相关问题,在所有形式的设备上提供快速.可靠和安全的Web连接.为此,它使用了一种不同的传输层网络协议,称为QUIC,该协议最初由Google开发的. 感慨 ...
HTTP3 RFC标准正式发布，QUIC会成为传输技术的新一代颠覆者吗？
6月7日早晨(UTC时间Mon, 06 June 2022 20:09),HTTP/3 标准RFC9114 由IETF标准化工作组正式发布,由此QUIC第一代协议族6大基础标准(不变量/传输框架/拥塞 ...

Dissect HTTP3