快速UDP网络连接（英语：Quick UDP Internet Connections，缩写：QUIC）是一种实验性的网络传输协议。由Google开发，在2013年实现。QUIC使用UDP协议，它在两个端点间创建连线，且支持多路复用连线。在设计之初，QUIC希望能够提供基于TLS/DTLS的网络安全保护，减少数据传输及创建连线时的延迟时间，双向控制带宽，以避免网络拥塞。Google希望使用这个协议来取代HTTPS/HTTP协议，使网页传输速度加快，计划将QUIC提交至互联网工程任务小组（IETF），让它成为下一代的正式网络规范。2015年6月，QUIC的网络草案（英语：Internet Draft）被正式提交至互联网工程任务组。2018 年 10 月，互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP（英语：HTTP over QUIC）重命名为HTTP/3以为确立下一代规范做准备。
传输控制协议 (TCP) 旨在提供一个在两个端点之间发送数据流的接口。将数据发送到TCP系统可以确保数据以完全相同的形式传递到另一端，否则连接将提示存在错误。
为此，TCP将数据分解成网络数据包，并在每个数据包中添加少量数据。该附加数据包括用于检测丢失或无序传输的数据包的序列号，以及允许检测数据包数据中的错误的校验和。当任何一个问题出现时，TCP使用自动重复请求(ARQ)来告诉发送者重新发送丢失或损坏的数据包。
在大多数实现中，TCP会将连接上的任何错误视为阻塞，停止进一步传输，直到错误得到解决或连接被视为失败。如果使用单个连接来发送多个数据流，就像在HTTP/2协议中那样，所有这些数据流都会被阻止，尽管其中只有一个可能有问题。例如，如果在下载用于收藏夹图标的GIF图像时出现一个错误，页面的其余部分将等待问题得到解决。
由于TCP系统被设计成看起来像一个“数据管道”，或流，它故意包含很少的对它传输的数据的理解。如果数据有额外的要求，如使用TLS加密，这必须由运行在传输控制协议之上的系统设置，使用传输控制协议与连接另一端的类似软件进行通信。每种设置任务都需要自己的握手过程。这通常需要多次往返请求和响应，直到创建连接。由于长距离通信的固有延迟，这会给整个传输增加大量开销。
QUIC旨在提供几乎等同于TCP连接的可靠性，但延迟大大减少。它主要通过两个理解HTTP流量的行为来实现这一点。
第一个变化是在连接创建期间大大减少开销（英语：Overhead (computing)）。由于大多数HTTP连接都需要TLS，因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。当客户端打开连接时，服务器响应的数据包包括将来的数据包加密所需的数据。这消除了TCP上的先连接并通过附加数据包协商安全协议的需要。其他协议可以以相同的方式进行服务，并将多个步骤组合到一个请求中。然后，这些数据既可用于初始设置中的后续请求，也可用于未来的请求。
QUIC使用UDP协议作为其基础，不包括丢失恢复。相反，每个QUIC流是单独控制的，并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误，协议栈仍然可以独立地继续为其他流提供服务。这在提高易出错链路的性能方面非常有用，因为在大多数情况下TCP协议通知数据包丢失或损坏之前可能会收到大量的正常数据，但是在纠正错误之前其他的正常请求都会等待甚至重发。QUIC在修复单个流时可以自由处理其他数据，也就是说即使一个请求发生了错误也不会影响到其他的请求。
QUIC包括许多其他更普通的更改，这些更改也可以优化整体延迟和吞吐量。例如，每个数据包是单独加密的，因此加密数据时不需要等待部分数据包。在TCP下通常不可能这样做，其中加密记录在字节流中，并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商，但QUIC旨在通过单个握手过程完成这些。
QUIC的另一个目标是提高网络切换期间的性能，例如当移动设备的用户从WiFi热点切换到移动网络时发生的情况。当这发生在TCP上时，一个冗长的过程开始了：每个现有连接一个接一个地超时（英语：Timeout (computing)），然后根据需要重新创建。期间存在较高延迟，因为新连接需要等待旧连接超时后才会创建。为解决此问题，QUIC包含一个连接标识符，该标识符唯一地标识客户端与服务器之间的连接，而无论源IP地址是什么。这样只需发送一个包含此ID的数据包即可重新创建连接，因为即使用户的IP地址发生变化，原始连接ID仍然有效。
QUIC在应用程序空间（英语：Application domain）中实现，而不是在操作系统内核中实现。当数据在应用程序之间移动时，这通常会由于上下文切换而调用额外的开销。但是在QUIC下协议栈旨在由单个应用程序使用，每个应用程序使用QUIC在UDP上托管自己的连接。最终差异可能非常小，因为整个HTTP/2堆栈的大部分已经存在于应用程序（或更常见的库）中。将剩余部分放在这些库中，基本上是纠错，对HTTP/2堆栈的大小或整体复杂性几乎没有影响。
QUIC允许更容易地进行未来更改，因为它不需要更改内核就可以进行更新。QUIC的长期目标之一是添加前向纠错和改进的拥塞控制。
关于从TCP迁移到UDP的一个问题是TCP被广泛采用，并且互联网基础设施中的许多中间设备被调整为UDP速率限制甚至阻止UDP。Google进行了一些探索性实验来描述这一点，发现只有少数连接存在此问题。所以Chromium的网络堆栈同时打开QUIC和传统TCP连接，并在QUIC连接失败时以零延迟回退到TCP连接。
由Google创建并以QUIC的名称提交给IETF的协议与随后在IETF中创建的QUIC完全不同（尽管名称相同）。最初的Google QUIC（也称为gQUIC）严格来说是通过加密UDP发送HTTP/2帧的协议，而IETF创建的QUIC是通用传输协议，也就是说HTTP以外的其他协议（如SMTP、DNS、SSH、Telnet、NTP）也可以使用它。重要的是要注意并记住其差异。自2012年以来，Google在其服务及Chrome中使用的QUIC版本（直到2019年2月）为Google QUIC。随着时间的推移，它正在逐渐变得类似于IETF QUIC（也称为iQUIC）。
BBR 算法主要出发点是，数据包丢失可能并不意味着网络拥塞。例如，一瞬间的无线电干扰，数据包就可能会丢失。Cubic 和其他基于拥塞的算法不区分这种虚假的损失和真正的拥塞，在两种情况下都降低了它们的发送速率。另一方面，BBR不那么容易受到惊吓。
因此，即使面对次优的网络条件，BBR也能提供持续的吞吐量性能。
Google Chrome于2012年开始开发QUIC协议并且于Chromium版本 29 (2013年8月20日释出) 发布。QUIC协议在当前Chrome版本中被默认开启，活跃的会话列表在中可见。
截至2017年，有三种活跃维护中的实现。谷歌的服务器及谷歌发布的原型服务器使用Go语言编写的quic-go及Caddy的试验性QUIC支持。在2017年7月11日，LiteSpeed科技正式在他们的负载均衡（WebADC）及 LiteSpeed 服务器中支持QUIC。截止 17 年 12 月， 97.5%的使用 QUIC 协议的网站在 LiteSpeed 服务器中运行。
另有几种不再维护的社区产品，基于Chromium实现并且减少使用依赖的libquic、提供libquic的Go语言绑定的goquic、打包为Docker镜像的用来转换为普通HTTP请求的反向代理quic-reverse-proxy。
