[TOC]
QUIC协议
https://www.mobibrw.com/2020/23190
HTTP2.0 也是基于TCP协议的，tcp协议在处理包时是有严格顺序的
TCP协议在收到数据包之后，这部分数据可能是乱序到达的，但是TCP必须将所有数据收集排序整合后给上层使用，如果其中某个包丢失了，就必须等待重传，从而出现某个丢包数据阻塞整个连接的数据使用
于是google的 QUIC协议从TCP切换到UDP
机制一：自定义连接机制。一旦一个元素发生变化时，就需要断开重连，重新连接。UDP以一个64位的随机数作为ID来标识。避免了四元组。
机制二：自定义传输机制。
tcp为了保证可靠性，通过使用序号和应答机制，来解决顺序问题和丢包问题。QUIC也有个序列号，是递增的，任何宇哥序列号的包只发送一次，下次就要加1，那样就计算可以准确了.QUIC既然是面向连接的，也就像TCP一样，是一个数据流，发送的数据在这个数据流里面有个偏移量offset.按照offset拼接，还是能够拼成一个流。
- 机制三： 无阻塞的多路复用
有了自定义的连接和重传机制，就可以解决上面HTTP2.0的多路复用问题。
同HTTP2.0一样，同一条 QUIC连接上可以创建多个stream，来发送多个HTTP请求，但是，QUIC是基于UDP的，一个连接上的多个stream之间没有依赖。这样，假如stream2丢了一个UDP包，后面跟着stream3的一个UDP包，虽然stream2的那个包需要重新传，但是stream3的包无需等待，就可以发给用户。
- 机制四：自定义流量控制
TCP的流量控制是通过滑动窗口协议。接收窗口只会对窗口内最后一个按序到达的字节进行确认。前面的没到，后面的到了也不能ACK,就会导致后面的到了，也有可能超时重传，浪费带宽。
QUIC的ACK是基于offset的，每个offset的包来了，进了缓存，就可以应答，应答后就不会重发，中间的空档会等待到来或者重发，而窗口的起始位置为当前收到的最大offset，从这个offset到当前的stream所能容纳的最大缓存，是真正的窗口的大小，显然，那样更加准确。