比较孤陋寡闻，只知道QUIC
| TCP | QUIC | |
|---|---|---|
| 握手延迟 | TCP需要三次握手+TLS握手 | 三次握手+TLS握手放在一起，实现0RTT |
| 头阻塞问题 | TCP丢失保文，会影响所有的应用数据包 | 基于UDP封装传输层Stream，Stream内部保序，Stream之间不存在相互影响 |
| 传输控制 | Seq二义性(重传)、SACK限制、RTT计算不准 | 吸取了TCP的问题，重新设计 |
| 连接迁移 | 五元祖实现连接标识 | 以一个 64 位的随机数作为 ID 来标识 |
| 实现层级 | 在传输层上实现 | 在应用层上实现 |
QUIC 流程简述
握手过程
连接机制
一条 TCP 连接是由五元组标识的，分别是源 IP、源端口、目的 IP、目的端口、协议号
而QUIC 自己的逻辑里面维护连接的机制，不再以五元组标识，而是以一个 64 位的随机数作为 ID 来标识，而且 UDP 是无连接的，所以当 IP 或者端口变化的时候，只要 ID 不变，就不需要重新建立连接
重传机制
TCP 为了保证可靠性，通过使用序号和应答机制，来解决顺序问题和丢包问题
在 TCP 里面存在超时的采样存在不准确的问题
- 发送一个包，发现没有返回，于是再发送，过一阵返回一个 ACK
- ACK的返回，让客户端知道这个包收到了。但是这个往返时间是在ACK的时间减去第一个包时间，还是减去第二个包时间？
QUIC 也有个序列号，是递增的。任何一个序列号的包只发送一次，下次就要加一了。但为了保证包内容的一致性，会存在一个offset的概念，offset是唯一的，如果某个offset对应的包没有就重发，通过这个offset拼接成一个完整的数据流
多路复用机制
HTTP 2.0 的多路复用问题
- HTTP/1.1可以使用多个TCP连接，但对连接数依然有限制，一次请求要等到连接中其他请求完成后才能开始(Pipeline机制也没能解决好这个问题)，所以没有空闲连接的时候请求被阻塞，这是应用层的阻塞
- HTTP/2底层使用了一个TCP连接，上层虚拟了stream，HTTP请求跟stream打交道，无需等待前面的请求完成，这确实解决了应用层的队首阻塞问题
- 传输层的队首阻塞，TCP的应答是严格有序的，如果前面的包没到，即使后面的到了也不能应答，这样可能会导致后面的包被重传，窗口被“阻塞”在队首，这就是传输层的队首阻塞。 不管是HTTP/1.1还是HTTP/2
QUIC 连接上可以创建多个 stream，来发送多个 HTTP 请求。但是，QUIC 是基于 UDP 的，一个连接上的多个 stream 之间没有依赖
流量控制
QUIC 的流量控制也是通过 window_update，来告诉对端它可以接受的字节数
QUIC 的 ACK 是基于 offset 的，每个 offset 的包来了，进了缓存，就可以应答，应答后就不会重发，中间的空档会等待到来或者重发即可，而窗口的起始位置为当前收到的最大 offset，从这个 offset 到当前的 stream 所能容纳的最大缓存
参考资料
- QUIC协议详解 - LightningStar - 博客园
- QUIC 协议原理浅解
- QUIC 0-RTT实现简析及一种分布式的0-RTT实现方案-腾讯云开发者社区-腾讯云
- Xiaojian Hong：跟坚哥学QUIC系列：加密和传输握手
