tcp队头阻塞是什么？
tcp是按字节有序传输的，如果发送方发送了一连串的报文，中间有个报文没有收到ACK确认，会一直等待超时然后重传报文，发送方的滑动窗口一直不能移动，导致不能发送更多的报文。
这样http请求之间就不是独立的，会互相影响。
http队头阻塞是什么？
多个http请求只能顺序请求，因为http请求和响应没有编号，同时执行多个请求，不按顺序返回响应，客户端无法分辨是哪个响应对应哪个请求，这样如果前面的请求处理较慢，后面的请求都会被阻塞。
http2解决了什么？
- http报文分片
- http header压缩
- 支持服务端推送
- 基于TLS实现安全传输（与https相同）
报文分片
http报文是纯文本的，http2报文是二进制字节流，对报文进行了分片并编号，相当于把tcp的报文分段编号实现搬到应用层。
同一个tcp连接可以同时传输多个http报文分片，实现多路复用，解决http请求对头阻塞问题。
服务端推送
客户端请求一个html，服务端可以把相关的css、png等资源一同返回给客户端，减少客户端请求次数。
QUIC解决了什么？
Quick UDP Internet Connection
基于udp实现，在应用层实现传输可靠性，非常的自由灵活。
主要改进：
- 快速握手
- 避免对头阻塞的多路复用
- 连接迁移
快速握手
在HTTPS协议中，由于TCP和TLS都各需要自3次握手，导致连接建立过程较为复杂和耗时，降低了HTTPS的效率。
QUIC选择UDP来作为其底层协议，就可以将连接建立和密钥协商的过程合二为一，简化操作流程，提高连接效率。
在连接建立成功后， 客户端会缓存起来原始的连接信息等。 在接下来与相同的服务器建立连接的过程中， 客户端能够在不增加额外RTT的情况下建立一个加密的连接，数据要发送的数据可以在握手的包中捎带着发送过去，而不用等待服务器的回复，从而实现0RTT。
所以，所谓QUIC的0RTT是指在建立连接之后，后续发送数据都不需要增加额外的RTT时间，最开始的握手还是需要1RTT的时间消耗的。
多路复用
为什么quic能解决队头阻塞？
- http队头阻塞用http分片解决。
- tcp队头阻塞用udp协议代替，在应用层重新实现可靠传输机制，http请求之间是独立互不影响的。
为什么不修改tcp协议解决队头阻塞？
- tcp在操作系统层面实现，普及比较麻烦。
- 各种网络中间设备（如网关、防火墙、代理服务器）为了效率最优化，保持了约定俗成的潜规则，如某些防火墙只允许特定端口，中间代理会删除报头中不认识的选项字段
连接迁移
一个TCP连接由四元组确定：源ip、源端口号、目标ip、目标端口号。
任何一个元素变化了，tcp就要重新建立连接，例如移动手机在移动网络和WiFi切换，重新建立连接会带来数据传输时延。
而QUIC的连接不依赖于四元组，以一个随机ID作为标识，这样IP或端口发生变化，只要连接ID不变，还是认为是一个连接，应用层感知不到底层tcp连接的变化，这样把影响就降到最低。