Quic协议（一)------HTTP3基础之QUIC协议介绍

简述

快速UDP网络连接 ( Quick UDP Internet Connections),基于UDP的多路复用安全传输协议。是由 Google 提出的实验性网络传输协议 ，位于 OSI 模型传输层。 QUIC 旨在解决 TCP 协议的缺陷，并最终替代 TCP 协议， 以减少数据传输，降低连接建立延迟时间，加快网页传输速度。

简单来说QUIC就是UDP之上的快速握手+TLS+HTTP/2（流）

主要特点

• 多流控制设计；

• 低等待延迟；

• 加密性能更优；

• 前向纠错；

• 连接保持；

0-RTT

说到QUIC，就不得不提0-RTT，QUIC的设置之初，就是为了减少http请求过程中握手的消耗。传统的http基于tcp协议，每次创建连接，都需要进行三次握手。对于很多短连接场景，这样的握手延迟影响很大，且无法消除。

stream

应用程序协议通过流（按字节顺序排列）在QUIC连接上交换信息。可以创建两种类型的流：

• 双向流，允许两个端点发送数据；

• 单向流，允许单个端点发送数据。基于信任的方案可以用于限制流的创建并限制可以发送的数据量。

拥塞控制

TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复 。

相比于TCP，QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6]，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。

从拥塞算法本身来看，QUIC 只是按照 TCP 协议重新实现了一遍，关于改进我们后面详细深入了解。

安全性

QUIC默认支持TLS1.3版本，相比于TCP来说，TCP 协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。

QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。这样只要对 QUIC 报文任何修改，接收端都能够及时发现，有效地降低了安全风险。

应用场景

HTTP3
5分钟看懂HTTP3-InfoQ

SDK和支持

C/C++

Name	Version	Roles	Handshake	GitHub
Microsoft's MsQuic	draft-29/v1	client, server	TLS 1.3 RFC	https://github.com/microsoft/msquic
Facebook's mvfst	draft-29	library, client, server	TLS 1.3	https://github.com/facebookincu

Rust

Name	Version	Roles	Handshake	GitHub
Cloudflare's quiche	draft-27, draft-28, draft-29	library, client, server	TLSv1.3 (RFC8446)	https://github.com/cloudflare/quiche
Mozilla/Firefox's Neqo	draft-27 through version 1	library, client, server	TLS 1.3	https://github.com/mozilla/neqo
Quinn	draft-28	library, client, server	TLS 1.3	https://github.com/djc/quinn

Go

Name	Version	Roles	Handshake	GitHub
quic-go	always the current draft	library, client, server	TLS 1.3 RFC	https://github.com/lucas-clemente/quic-go

参考：RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport (rfc-editor.org)

QUIC 开源实现列表（持续更新） - 知乎 (zhihu.com)