Quic 协议——第一部分
一、简介
QUIC 协议最初是由 Google 开发并使用在 Chrome 中的新一代 web 协议。 之后被 IETF 的 QUICWG 工作组接管，目前发布的版本为 24th。
QUIC 协议是一个包含传输层、安全垫片和应用层的复合协议族。QUIC 协议 基于 UDP 协议，在此之上实现了可控有序到达、拥塞控制、流量控制等传输层功能； 提供了对于包和连接的完整性和机密性功能；提供了 http3.0 等的应用层功能。
二、QUIC 协议基本结构
QUIC 协议是基于 UDP 的协议，其最基本包的格式为 UDP 报文（package），由 package number 来提供有序到达的功能。 在一个 QUIC 报文之中，有多个独立功能的 QUIC 帧（frame），每一个帧都 用于实现不同的功能，比如传输帧，错误帧，校验帧等。
在报文和帧的基础之上，QUIC 协议构成了一个双方共享连接状态的有状态协议， 因此有连接 （connection） 的概念。通过 connection id来区别不同的 QUIC 连接。 QUIC 连接具有完整的生命周期（建立、撤销、关闭等）
在连接之上，QUIC协议使用了连接复用的概率，在连接之上建立了多个有状态的流（steam）， 每一个流也是具有独立状态的。每一个流对应了上层的不同应用，比如 id 为 1 的流用于负责 握手协议和密码学参数的协商。
+---------+---------+---------+
| stream1 | stream2 | stream3 |
+---------+---------+---------+
| connection |
+-----------------------------+
| packages (frame1 || frame2 )|
+-----------------------------+
三、 QUIC 协议版本协商
QUIC 报文头部的内容主要有协议的版本 （version） 和connection id 等。 其中 version 协商是建立 QUIC 协议首先需要做的工作。
version 字段长度为 32 bit 长度，因此可以容纳非常多的版本。每个版本的 实现可以不同，但是其版本协商应当与版本无关。
QUIC 协议早期由 Google 维护的时候，主要从 “Q001” 到 “Q025”，转为 IETF 维护后，目前版本为 0xff000024（定稿为 0xff000023）
大致过程为，client 将version 写为0,而后提供可选 version 列表。server 如果接收版本，则确定版本，否则发送重置连接的报文，同时提供可选参数列表。
值得注意的是，QUIC 版本协商没有对报文进行完整性校验，因此可能遭受降级攻击。 为了防止这种攻击，需要在建立加密信道的时候，提供版本协商报文的校验。
本人保留对侵权者及其全家发动因果律武器的权利
版权提醒
如无特殊申明，本站所有文章均是本人原创。转载请务必附上原文链接：https://www.elliot98.top/post/lab/quic-1/。
如有其它需要，请邮件联系！版权所有，违者必究！