QUIC 协议的优势包括：

• 快速建立连接：将传输层和加密层的握手合并，减少了连接建立的延迟。QUIC 建连时间大约为 0~1RTT，相比 HTTPS 的 3RTT 建连，具有极大的优势。客户端第一次建连的握手协商需 1RTT，而已建连的客户端重新建连可以使用之前协商好的缓存信息来恢复 TLS 连接，仅需 0RTT 时间。
• 可扩展性强：拥有 32 位的版本协商扩展位，有较多空间部署新版本，厂商也可以利用这些空间定义自己的专属版本。能够在应用层实现，可更快地进行更新，服务可以快速演进，新特性每天都能得到部署。
• 降低对丢包的敏感度：使用类似 HTTP/2 的多路复用模式，可以同时支持多个数据流。如果一个数据流发送错误导致丢包，其他数据流会继续发送数据包，不会阻塞传输，解决了 TCP 的队头阻塞问题。
• 切换网络时的性能提升：支持连接迁移，用一个 connection ID 标识连接，当源的 IP 或端口发生变化时，只要 connection ID 一致，连接都可以保持，不会发生切断重连，实现无缝连接。比如在移动端使用时，当网络环境发生变化（如从 Wi-Fi 切换到移动数据网络），QUIC 可以在不中断连接的情况下继续传输数据，避免了因网络切换而导致的延迟和数据丢失。
• 提升的安全性和隐私保护：在传输层中内置了加密功能，从而验证整个负载（包括 header），默认支持安全的 TLS，意味着端到端完全安全。
• 细致的流量控制：从不同粒度进行流量控制，即基于连接的流量控制与基于流的流量控制。
• 更快的特性迭代速度：在用户态实现，支持新特性的快速演进，能支持可插拔的拥塞控制算法，不仅能够在现有的成熟拥塞控制算法（如 cubic、bbr 等）之间进行轻易切换，而且还能快速部署验证基于 AI 的拥塞控制算法（例如基于强化学习的拥塞控制算法）。
• 多路径传输提高带宽利用率：多路径 QUIC（MPQUIC）可以让一个 QUIC 连接同时利用多条链路来进行数据传输，从而最大化可用带宽的利用率，也提高了连接的容错能力（其中一条链路出现故障不会影响传输）。
• 按需进行一定的扩展：除了与 QUIC 本身特性密切相关的标准外，还有许多关于 QUIC 的扩展特性的标准或草案，为 QUIC 自身特性注入新的血液，也为 QUIC 的应用带来了更广阔的想象。

QUIC 协议的劣势主要有：

• 在网络质量较好的链路上表现可能不如 TCP：在高带宽、低时延和低丢包率的网络中，QUIC 的性能有时还不如 TCP。同等流量下，QUIC 的 CPU 消耗高于使用了 SSL 的 TCP，尽管经过了优化，QUIC 的 CPU 消耗率仍比 TCP/SSL 要高不少。这主要是因为 QUIC 底层使用 UDP 进行传输，而内核中设计的 UDP 收发包机制存在一定问题，影响了 QUIC 报文的传输性能；QUIC 内部利用 TLS 对报文进行了加密，复杂的加密过程对 CPU 的性能损耗较大；QUIC 把包括 ACK 在内的所有报文先收上来放到用户层后再进行处理，导致了额外的用户级和内核级的上下文切换以及数据从内核转移至用户的额外拷贝；国内不少运营商会对 UDP 流量进行限速处理，UDP 五元组变化频繁也会给某些状态设备造成压力。
• 对流量管理和分析不太友好：由于使用了 TLS1.3 作为安全性保证以及 UDP 作为底层传输协议，这让 Wireshark、Zeek 等抓包及网络安全分析工具无法获取到 QUIC 报文携带的关键信息，会给想要过滤 QUIC 流量的用户造成一定影响。不过，目前较新版本的 Wireshark 已经支持通过导入密钥日志文件来抓取 QUIC 报文并进行解密，QUIC 协议也自带了 qlog 这一机制（目前还处于草案阶段）来方便使用者进行调试并观察 QUIC 报文交互过程。
• 迁移 APP 面临巨大挑战：将 APP 从 HTTP/2 迁移到 HTTP/3（或者从 TCP 迁移到 UDP）需要将整个应用层实现和传输层实现转移到 UDP，并在服务端和客户端构建全新的解决方案，对于资源相对有限的小厂商而言挑战较大。
• QUIC 包含 TCP 回退：基于 QUIC 的 APP 必须设计成能够回退到 TCP，以防万一，这意味着开发者要同时开发和维护两个不同的版本，负担较重。
• 不具备某些 TCP 特性：例如不支持成块传输（chunked transfer，即将视频切片分割为小块的能力），限制了用于基于 QUIC 的视频传输的协议数量。
• 可能需要更高的 CPU 使用率：QUIC 所需的 HTTP/3 在客户端和服务端可能占用了更多的 CPU 资源。不过，谷歌认为 QUIC 有助于延长电池寿命。随着该协议进入主流技术栈，这一问题预计不会有太大影响。
• 采用受限：几乎每个浏览器都接受使用 QUIC 进行简单的网页浏览，但除了 chromium，没有浏览器将它设置为默认选项。在流媒体领域，除了谷歌和 facebook（现更名为 meta）之外，少有公司使用 QUIC。只有少数 CDN 提供商支持 QUIC，且一些只是验证了 QUIC 的实现，并未为大规模部署做好准备。这就带来了问题：如果推出使用 multi-CDN 并基于 QUIC 的新服务，那么只有部分访问能使用 QUIC，因为难以向用户证明它对用户体验的显著影响。
• 网络防火墙可能拦截：网络防火墙无法解密 QUIC 流量来检查数据包，所以潜在的恶意流量可能没有被标准安全功能检测出来而进入网络。一些安全厂商通常会在端口 80（web 服务器）和 443（TSL）拦截 QUIC 数据包（认为它们包含恶意软件），迫使客户端回退使用 HTTP/2 和 TCP 协议。但这种操作通常不会显著影响内容用户体验，因为正确实现的流媒体服务会默认回退到 TCP+TLS。不过这可能会阻止率先部署 QUIC 的想法，只有解决这一挑战，QUIC 才能被各大企业广泛接受。