关于QUIC协议的连接、重传、多路复用、流量控制_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 所能容纳的最大缓存，是真正的窗口大小。显然，这样更加准确。