1、QUIC连接
a single conversation between two QUIC endpoints.
QUIC连接的建立将版本协商、加密、传输握手交织在一起,以减少连接建立延迟。
由于NAT重新绑定或移动性,QUIC连接建立后,该连接可能会迁移到其中一个端点的其他不同到ip或端口,最终连接会被其中一个端点终止。
2、版本协商
QUIC的连接建立始于版本协商,因为端点之间的所有通信,包括数据包和帧格式,取决于在版本上达成一致的两个端点。
QUIC连接从客户端发送握手数据包开始。所有从客户端发送到服务器的初始数据包必须设置VERSION Flag,并且必须指定协议的版本。
当服务器收到一个来自客户端的带有为某个连接设置的VERSION Flag的数据包,且这个连接尚未被建立时,服务器会将客户端版本与自己支持的版本进行对比。
若服务器支持
则服务器在连接的生存期内必须使用此协议版本,服务器发送的所有后续数据包必须使得VERSION Flag关闭。
若服务器不支持
则服务器必须向客户端发送版本协商数据包。这个数据包将设置VERSION Flag打开,并将包括服务器的支持版本集。在随后收到具有不可接受版本的相同连接ID的数据包,服务器必须继续以版本协商响应包。客户端收到版本协商响应包后,找到并选择一个可接受的协议版本。若找到,客户端必须使用新的版本协议重发所有包,并且重发的数据包务必使用新的数据包编号。这些包必须继续设置VERSION标志,并且必须包括新的协商协议版本。客户端在所有包中都必须包含版本号,直到收到来自服务器的带有VERSION Flag关闭的包(指示版本协商成功结束),此后客户端发送的VERSION Flag关闭。一旦服务器从客户端收到VERSION Flag关闭的数据包,则忽略随后接收到的VERSION标记包。
版本协商数据包是未加密和交换时没有身份验证的。为了避免降级攻击,客户端需要在版本中验证其记录的服务器版本列表协商数据包,服务器需要验证其记录客户最初建议的版本。因此,客户端和服务器必须稍后在相应的信息中包含此信息加密握手数据。
3、加密和传输握手
QUIC依靠组合加密和传输握手来最大程度地减少连接建立延迟。QUIC提供专用流(Stream ID 1)用于执行组合连接和握手。客户端发给服务器的第一个QUIC包必须包含握手信息作为Stream ID 1上的数据。加密握手协议封装并交付QUIC的握手传输到加密流上的对等方。
3.1 运输参数和选项
在建立连接期间,握手必须协商各种运输参数。握手的传输部分负责交换和协商QUIC的参数。并非所有参数都经过协商,有些是参数仅向一个方向发送。这些参数和选项已编码并移交给加密握手协议以传输给另一端。参数形式为键值对。
(1)必需运输参数
SFCW: Stream Flow Control Window
CFCW: Connection Flow Control Window
MSPC: Maximum number of incoming streams per connection.
(2)可选运输参数
TCID: Indicates support for truncated Connection IDs
COPT: Connection Options are a repeated tag field
3.2 源地址所有权证明
传输协议通常使用往返时间来验证客户的地址所有权,来保护免受恶意客户的攻击欺骗其源地址。QUIC使用一个cookie(STK source address token)来消除了这种往返延迟。
在一个新连接上,QUIC服务器发送一个STK,对客户端透明并由客户端存储。在后续连接中,客户端在传输握手中回显(echo)这个STK,作为IP所有权的证明。
QUIC服务器还使用STK存储服务器指定的连接无状态拒绝的ID,以验证传入连接包含正确的连接ID。
QUIC服务器可以在STK中另外存储其他数据,例如测量到的带宽和测量到客户端的最小RTT帮助服务器更好地引导来自服务器的后续连接同一位客户。服务器可以在连接中发送更新的STK消息更新存储在STK客户端中的服务器状态。
3.3 加密握手协议功能特性
(1)加密握手协议必须保证每个连接的最终的协商密钥互不相同
(2)传输协商:加密握手协议必须提供一个让传输组件交换传输参数和源地址tokens的机制。为了避免降级攻击,发送和接收的传输参数必须在握手成功完成之前进行验证。
(3)0-RTT的连接建立:QUIC的关键功能
(4)源地址欺骗防御:由于QUIC处理源地址验证,加密协议不应施加单独的源地址验证机制。
(5)服务器配置更新:QUIC服务器可以在连接中刷新源地址令牌(STK),以更新存储在客户端STK的信息,并延长客户端可以建立0-RTT连接的时间。
(6)证书压缩:QUIC的早期经验表明压缩在握手期间交换的证书对于减少延迟很有价值。这还有助于减少当服务器发送大量证书时的放大攻击足迹。加密协议应该压缩证书和任何其他信息以最小化握手期间发送的数据包数。
(7)用于QUIC握手中的[客户端最初在其第一包中提出的版本]和[服务器的版本协商包的版本列表]必须被加密握手协议进行密码验证
4、连接迁移
QUIC连接由其64位连接ID标识。
5、连接终止