关于QUIC协议的连接、重传、多路复用、流量控制

QUIC协议是基于UDP封住的一个协议

QUIC 在自己的逻辑里面维护连接的机制，以一个 64 位的随机数作为 ID 来标识，而且 UDP 是无连接的，所以当 IP 或者端口变化 的时候，只要 ID 不变，就不需要重新建立连接。

QUIC 也有个序列号，是递增的。 任何一个序列号的包只发送一次，下次就要加一了。例如，发送一个 包，序号是 100，发现没有返回;再次发送的时候，序号就是 101 了;如果返回的 ACK 100，就是对第 一个包的响应。如果返回 ACK 101 就是对第二个包的响应，RTT 计算相对准确。

QUIC 定义了一个 offset 概念。 QUIC 既然是面向连接的，也就像 TCP 一样，是一个数据流，发送的数据在这个数据流里面有个 偏移量 offset，可以通过 offset 查看数据发送到了哪里，这样只要这个 offset 的包没有来，就要重发; 如果来了，按照 offset 拼接，还是能够拼成一个流。

同 HTTP 2.0 一样，同一条 QUIC 连接上可以创建多个 stream，来发送多个 HTTP 请求。但QUIC 是基于 UDP 的，一个连接上的多个 stream 之间没有依赖。这样，假如 stream2 丢了一个 UDP 包，后 面跟着 stream3 的一个 UDP 包，虽然 stream2 的那个包需要重传，但是 stream3 的包无需等待，就 可以发给用户。

QUIC 的流量控制也是通过 window_update，来告诉对端它可 以接受的字节数。 但是 QUIC 的窗口是适应自己的多路复用机制的，不但在一个连接上控制窗口，还在 一个连接中的每个 steam 控制窗口。

还记得吗?在 TCP 协议中，接收端的窗口的起始点是下一个要接收并且 ACK 的包，即便后来的包都到 了，放在缓存里面，窗口也不能右移，因为 TCP 的 ACK 机制是基于序列号的累计应答，一旦 ACK 了一 个系列号，就说明前面的都到了，所以只要前面的没到，后面的到了也不能 ACK，就会导致后面的到 了，也有可能超时重传，浪费带宽。

QUIC 的 ACK 是基于 offset 的，每个 offset 的包来了，进了缓存，就可以应答，应答后就不会重发， 中间的空挡会等待到来或者重发即可，而窗口的起始位置为当前收到的最大 offset，从这个 offset 到当 前的 stream 所能容纳的最大缓存，是真正的窗口大小。显然，这样更加准确。