QUIC（Quick UDP Internet Connections）是一种实验性传输层网络协议，提供与TLS/SSL相当的安全性，同时具有更低的连接和传输延迟。QUIC基于UDP，因此拥有极佳的弱网性能，在丢包和网络延迟严重的情况下仍可提供可用的服务。QUIC在应用程序层面就能实现不同的拥塞控制算法，不需要操作系统和内核支持，这相比于传统的TCP协议，拥有了更好的改造灵活性，非常适合在TCP协议优化遇到瓶颈的业务。
一条 TCP 连接由源 IP、源端口、目的 IP、目的端口的四元组标识。其中一个元素发生变化就需要断开重连。在移动互联情况下，当手机信号不稳定或者在 WIFI 和 移动网络之间切换时，都会导致重连，需要再次三次握手，导致一定的时延。基于 UDP 可以在 QUIC 自己的逻辑里面维护连接的机制，不再以四元组标识，而是以一个 64 位的随机数作为 ID 来标识，而且 UDP 是无连接的，当 IP 或者端口变化时，只要 ID 不变，就不需要重新建立连接。
TCP 为了保证可靠性，通过使用序号和应答机制，来解决顺序问题和丢包问题。超时重传机制采用了自适应重传算法，但超时时间存在不准确的问题。QUIC 有个递增的序列号。任何一个序列号的包只发送一次，RTT 计算相对准确。为了识别不同序列号但是内容相同的包，QUIC 定义了 offset。QUIC 像 TCP 一样面向连接，也是一个数据流，发送的数据在这个数据流里面有个偏移量 offset，可以通过 offset 查看数据发送到了哪里，只要这个 offset 的包没有来，就要重发。
同 HTTP 2.0 一样，同一条 QUIC 连接上可以创建多个 stream，来发送多个 HTTP 请求。但是，QUIC 是基于 UDP 的，一个连接上的多个 stream 之间没有依赖。例如 stream2 丢了一个 UDP 包，后面跟着 stream3 的一个 UDP 包，虽然 stream2 丢失的包需要重传，但是 stream3 的包无需等待，就可以发给用户。
TCP 的流量控制是通过滑动窗口来实现的。QUIC 的流量控制也是通过 window_update，来告诉对端它可以接受的字节数。但是 QUIC 的窗口是适应自己的多路复用机制的，不但在一个连接上控制窗口，还在 一个连接中的每个 stream 控制窗口。
在 TCP 协议中，接收端的窗口的起始点是下一个要接收并且之前的都已 ACK 的包，即便后来的包都到了，放在缓存里面，窗口也不能右移，因为 TCP 的 ACK 机制是基于序列号的累计应答。这会导致后面的到了，也有可能超时重传，浪费带宽。
QUIC 的 ACK 是基于 offset 的，每个 offset 的包来了，进了缓存，就可以应答，应答后就不会重发，中间的空挡会等待到来或者重发即可，而窗口的起始位置为当前收到的最大 offset，从这个 offset 到当前的 stream 所能容纳的最大缓存，是真正的窗口大小，这样更加准确。整个连接的窗口，需要对于所有的 stream 的窗口做一个统计。
一些基于目前QUIC实现的第三方库: https://github.com/quicwg/base-drafts/wiki/Implementations