## HTTP/3原理 ### 1. **HTTP/3的来源** 由于TCP和UDP两者在运输层存在一定差异，TCP的传递效率与UDP相比有天然劣势，于是Google基于UDP开发出了新的协议QUIC(Quick UDP Internet Connections)，希望取代TCP提高传输效率，后经过协商将QUIC协议更名为HTTP/3。 ### 2. **QUIC概述** TCP、UDP是我们所熟悉的传输层协议，UDP比TCP相比效率更高但并不具备传输可靠性。而QUIC便是看中UDP传输效率这一特性，并结合了TCP、TLS、HTTP/2的优势，加以优化。 于是在QUIC上层的应用层所运行的HTTP协议也就被称为HTTP/3。 **HTTP over QUIC is HTTP/3**  ## HTTP/3新特性 ### 1. **零RTT建立连接** 如下图，传统HTTP/2(所有HTTP/2的浏览器均基于HTTPS)传输数据前需要三次RTT，即使将第一次TLS握手的对称秘钥缓存也需要两次RTT才能传递数据。  对于HTTP/3而言，仅仅需要一次RTT即可传递数据，如果将其缓存，就可将RTT减少至零。 其核心就是DH秘钥交换算法。 * 客户端向服务端请求数据。 * 服务端生成g、p、a三个随机数，用三个随机数生成A。将a保留后，将g、p、A(Server Config)传递到客户端。 * 客户端生成随机数b，将b保留后，用g、p、b三个随机数生成B。 * 客户端再使用A、b、p生成秘钥K，用K**加密HTTP数据**并与B一同发送到服务端。 * 服务端再使用B、a、p得到相同秘钥K，并解密HTTP数据。  **至此即可完成一次RTT对连接的建立，当缓存Server Config后零RTT即可进行数据传递。** ### 2. **连接迁移** 传统连接通过源IP、源端口、目的IP、目的端口进行连接，当网络发生更换后连接再次建立时延较长。 HTTP/3使用Connection ID对连接保持，只要Connection ID不改变，连接仍可维持。  ### 3. **队头阻塞/多路复用** * TCP作为面向连接的协议，对每次请求序等到ACK才可继续连接，一旦中间连接丢失将会产生队头阻塞。 * HTTP/1.1中提出Pipelining的方式，单个TCP连接可多次发送请求，但依旧会有中间请求丢失产生阻塞的问题。  * HTTP/2中将请求粒度减小，通过Frame的方式进行请求的发送。但在TCP层Frame组合得到Stream进行传输，一旦出现Stream中的Frame丢失，其后方的Stream都将会被阻塞。  * 对于HTTP/2而言，浏览器会默认采取TLS方式传输，TLS基于Record组织数据，每个Record包含16K，其中有12个TCP的包，一旦其中一个TCP包出现问题将会导致整个Record无法解密。这也是网络环境较差时HTTP/2的传输速度比HTTP/1.1更慢的原因。  * HTTP/3基于UDP的传输，不保证连接可靠性，也就没有对头阻塞的后果。同样传输单元与加密单元为Packet，在TLS下也可避免对头阻塞的问题。 ### 4. **拥塞控制** * 热拔插：TCP对于拥塞控制在于传输层，QUIC可在应用层操作改变拥塞控制方法。 * 前向纠错(FEC)：将数据切割成包后可对每个包进行异或运算，将运算结果随数据发送。一旦丢失数据可据此推算。(带宽换时间) * 单调递增的Packet Number：TCP在超时重传后的两次ACK接受情况并不支持的很好。导致RTT和RTO的计算有所偏差。HTTP/3对此进行改进，一旦重传后的Packet N会递增。  * ACK Delay HTTP/3在计算RTT时健壮的考虑了服务端的ACK处理时延。  * 更多地ACK块 一般每次请求都会对应一个ACK，但这样也会浪费(下载场景只需返回数据即可)。 于是可设计成每次返回3个ACK block。在HTTP/3将其扩充成最多可携带256 个ACK block。 ### 5. **流量控制** TCP使用滑动窗口的方式对发送方的流量进行控制。而对接收方并无限制。在QUIC中便补齐了这一短板。 QUIC中接收方从单挑Stream和整条连接两个角度动态调整接受的窗口大小。 ## 参考资料 [HTTP3](https://juejin.cn/post/6844904182340648967)