在学习 QUIC 协定的路上，有很多的博客把 QUIC 的协定讲的很透彻，然而对于一些入门的细节并没有讲的很分明，导致在学习 QUIC 的时候，存在肯定的艰难。在这篇文章里，我将补充一些有利于老手了解 QUIC 协定的知识点。
名词解释
RTT
round trip times，在发送真正的 payload 之前，C/S 单方须要沟通的轮数。例如 TLS 协定须要 2 轮沟通后客户端能力发送 payload，所以 TLS (1.1,1.2) 是 2 -RTT 协定。
0-RTT 和 1 -RTT
0-RTT 示意 Client 在首次与 Server 握手的时候就曾经发送了数据流，1-RTT 示意 Client 须要与 Server 进行一来一回的握手通信之后，能力发送数据流。
一般来说在不启用 0 -RTT 个性的时候，都是按 1 -RTT 进行通信的，并且首次握手都是 1 -RTT，只有 Client 缓存了 Token 之后，才可能启用 0 -RTT，在首包中进行传输。
TCP 耗费 1.5RTT
彻底弄懂 TCP 协定：从三次握手说起
如图所示，三次握手过程为 1.5RTT，残缺的一来一回示意一个 RTT，第三次握手并没有返回过程。
TLS1.3
TLS1.3 在首次握手时，须要耗费一个 RTT 建设连贯，服务器会发送一个 NST(New-Session-Ticket) 的报文给客户端，该报文中记录 PSK 的值、名字和有效期等信息，单方下一次建设连贯时，能够应用该 PSK 值作为初始密钥资料。
当连贯断开重连时，TLS1.3 客户端缓存的 PSK 能够间接作为认证信息，在握手的时候间接对 Application Data 进行加密传输，存储在握手报文的 Early Data 中，实现 0 -RTT 的成果。
包空间, 包号和帧
server -> Sending coalesced packet (2 parts, 1252 bytes) for connection f265b7253becdfa903e3ad19c55b52
2022/11/18 14:40:23 server Long Header{Type: Initial, DestConnectionID: (empty), SrcConnectionID: 1d86dead, Token: (empty), PacketNumber: 0, PacketNumberLen: 2, Length: 117, Version: v1}
2022/11/18 14:40:23 server -> &wire.AckFrame{LargestAcked: 0, LowestAcked: 0, DelayTime: 0s}
2022/11/18 14:40:23 server -> &wire.CryptoFrame{Offset: 0, Data length: 90, Offset + Data length: 90} 包空间为：Initial
包号为：PacketNumber: 0
帧为：AckFrame ACK 帧，CryptoFrame 加密帧
独自的包号空间
QUIC 为每个加密级别应用独自的包号空间，除了 0-RTT 和所有代的 1-RTT 密钥应用雷同的包号空间。独自的包号空间确保一个加密级别上发送的包的确认不会导致不同加密级别上发送的包的虚伪重传。拥塞管制和往返工夫 (RTT) 测量是跨包号空间对立的。
枯燥递增的包号
TCP 将发送端的传输程序与接收端的交付程序合并在一起，这会导致携带雷同序列号的雷同数据的重传，从而导致“重传歧义”。QUIC 将两者离开：QUIC 应用包号来批示传输程序，并且所有的应用程序数据都在一个或多个流中发送，交付程序由 STREAM 帧中编码的流偏移确定。
QUIC 的包号在包号空间内严格递增，并间接编码传输程序。较高的包号示意该数据包是较晚发送的，而较低的包号示意该数据包发送的较早。当检测到蕴含 ACK 诱发帧的包失落时，QUIC 会将必要的帧从新打包进具备新包号的新数据包中，则当收到 ACK 时，这种做法能够打消该 ACK 在确认哪个数据包的歧义性。因而，能够进行更准确的 RTT 测量，很容易查看到虚伪重传，并且能够仅仅基于包号来对立利用诸如疾速重传这样的机制。
这个设计点大大简化了 QUIC 的失落检测机制。大多数 TCP 机制都会隐式地尝试依据 TCP 序列号推断传输程序 – 这是一项比拟艰巨的工作，特地是当 TCP 工夫戳不可用时。
帧
一个 quic 包中能够蕴含多个帧，不同类型的音讯，对应不同的帧，例如 ACKFrame，StreamFrame，DatagramFrame.
ALPN
RFC 7301 : Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
容许客户端在连贯建设期间提供多个利用协定。客户端蕴含的传输参数对客户端提供的所有利用协定失效。利用协定能够指定传输参数值，例如初始流控下限。然而，利用协定对传输参数值设置限度，可能导致因为限度抵触使得客户端不能提供多种利用协定反对。
通信形式
晓得了 QUIC 的优缺点，以及协定细节之后，具体 QUIC 到底怎么通信的，如何保障可靠性呢？目前 QUIC 的具体通信实现有两种形式：
Stream 流
QUIC Stream 数据流是 QUIC 次要数据传输的载体，牢靠传输是其须要保障的基本功能。也是 QUIC 最早反对实现的通信形式，用来提供一种有序牢靠的数据传输方式，大多数的 QUIC 通信都是基于这种形式进行通信。
Datagram
RFC 9221
RFC 9221
- 同一 QUIC 连贯外面能够同时蕴含牢靠 Stream 传输和不牢靠数据传输，它们能够共享一次握手信息，别离能够作用于 TLS 和 DTLS，可升高握手提早。
- QUIC 在握手上比 DTLS 更加精准，它对每个握手数据包加上了超时重传定时器，可能疾速感知握手包的失落和复原。
- QUIC Datagram 的不牢靠传输也能够被 ACK，这是一个选项，如果有 ACK，能够让应用程序感知到 QUIC Datagram 的胜利接管。
- QUIC Datagram 也实用于 QUIC 的 CC。
这些个性可能让实时音视频流、在线游戏和实时网络服务等利用的传输失去极大的效率晋升。
官网材料对于 Datagram 的形容，与 Stream 的最大区别在于，Datagram 是不牢靠的数据传输，实用于实时音视频流、在线游戏和实时网络服务等业务，应该是这类业务能够就义数据的可靠性，以晋升数据的传输效率。相对来说 Stream 为了保护数据的可靠性传输，减少了缓存等机制，存在性能损耗，对吞吐量也有肯定的影响，如果业务的确不关注严格的可靠性，容许局部数据失落，比方可能视频播放中掉帧，只有不重大，那么对于效率的晋升就是能够承受的。
举荐的学习材料
大神翻译的中文 QUIC 协定文档: 能够说是十分全面的 QUIC 常识手册，能够在这里找到你想找到的简直所有的 QUIC 协定细节。
QUIC 0-RTT 实现简析及一种分布式的 0 -RTT 实现计划：把 QUIC 的协定通信过程讲的很分明
跟坚哥学 QUIC 系列：加密和传输握手: yomo 开源我的项目的贡献者，yomo 是一个基于 quic 实现的流式通信框架
一些开源我的项目
quic-go : Golang 实现的比拟成熟的 QUIC 实现。
yomo : 一个流式通信框架，这家公司还做了一个私有云服务，用来解决长距离，低延时的通信传输问题。
xquic: 是一个遵循 IETF 规范的 QUIC 和 HTTP/ 3 的客户端和服务端实现 , 阿里开源的，然而目前次要是阿里本人的手淘业务在用，还在踊跃开发中。
版权申明: 本文为 InfoQ 作者【黄继承】的原创文章。
原文链接:【https://xie.infoq.cn/article/…】。
本文恪守【CC-BY 4.0】协定，转载请保留原文出处及本版权申明。