QUIC协议原理详解

1.QUIC是啥？

1.1 什么是QUIC

QUIC(Quick UDP Internet Connection)是谷歌推出的一套基于UDP的传输协议，它实现了TCP + HTTPS + HTTP/2的功能，目的是保证可靠性的同时降低网络延迟。因为UDP是一个简单传输协议，基于UDP可以摆脱TCP传输确认、重传慢启动等因素，建立安全连接只需要一的个往返时间，它还实现了HTTP/2多路复用、头部压缩等功能。

众所周知UDP比TCP传输速度快，TCP是可靠协议，但是代价是双方确认数据而衍生的一系列消耗。其次TCP是系统内核实现的，如果升级TCP协议，就得让用户升级系统，这个的门槛比较高，而QUIC在UDP基础上由客户端自由发挥，只要有服务器能对接就可以。

1.2 HTTP协议发展

1.2.1 HTTP历史进程

• HTTP 0.9（1991年）只支持get方法不支持请求头；
• HTTP 1.0（1996年）基本成型，支持请求头、富文本、状态码、缓存、连接无法复用；
• HTTP 1.1（1999年）支持连接复用、分块发送、断点续传；
• HTTP 2.0（2015年）二进制分帧传输、多路复用、头部压缩、服务器推送等；
• HTTP 3.0（2018年）QUIC 于2013年实现、2018年正式更名为HTTP3；

1.2.2 HTTP 1.0和HTTP1.1

• 队头阻塞：下个请求必须在前一个请求返回后才能发出，导致带宽无法被充分利用，后续请求被阻塞（HTTP 1.1 尝试使用流水线（Pipelining）技术，但先天 FIFO（先进先出）机制导致当前请求的执行依赖于上一个请求执行的完成，容易引起队头阻塞，并没有从根本上解决问题）
• 协议开销大：header里携带的内容过大，且不能压缩，增加了传输的成本
• 单向请求：只能单向请求，客户端请求什么，服务器返回什么

HTTP 1.0和HTTP 1.1的区别：

HTTP 1.0	HTTP 1.1
仅支持保持短暂的TCP连接（连接无法复用）	默认支持长连接（请求可复用TCP连接）
不支持断点续传	支持断点续传（通过在 Header 设置参数）
前一个请求响应到达之后下一个请求才能发送，存在队头阻塞	优化了缓存控制策略
/	管道化，可以一次发送多个请求，但是响应仍是顺序返回，仍然无法解决队头阻塞的问题
/	新增错误状态码通知
/	请求消息和响应消息都支持Host头域

1.2.3 HTTP2

解决 HTTP1 的一些问题，但是解决不了底层 TCP 协议层面上的队头阻塞问题。

1.二进制传输：二进制格式传输数据解析起来比文本更高效；

2.多路复用：重新定义底层 http 语义映射，允许同一个连接上使用请求和响应双向数据流。同一域名只需占用一个 TCP 连接，通过数据流（Stream）以帧为基本协议单位，避免了因频繁创建连接产生的延迟，减少了内存消耗，提升了使用性能，并行请求，且慢的请求或先发送的请求不会阻塞其他请求的返回；

3.Header压缩&#x