QUIC（更新中... ...）

 

本文档只记录我个人认为应该着重进行一下笔记的部分。

RFC

QUIC 基本内容介绍在RFC 9000，加密的实现在9001，丢包检测和拥塞机制在9002。

简介

是由Google开发的一种基于UDP的传输层协议，旨在提高网络传输的性能和安全性。关键要素：UDP 443端口，将TLS 1.3内置在QUIC协议报文中，提升了握手过程的安全性。同时，利用了TLS 1.3的0-RTT和1-RTT连接机制，提升了传输效率。

一些概念

连接、流、帧、报文，他们到底什么样的层级关系？

1-RTT和0-RTT

TLS 1.3的1-RTT（首次连接一定用这个）和0-RTT（主要用于重连）连接机制。

 1-RTT连接建立

• 概念：1-RTT连接是指客户端发送ClientHello后，服务器响应ServerHello，客户端在接收到这个响应后，才可以发送应用数据。这个过程需要一次往返时间（1-RTT）。
• 适用场景：1-RTT适用于首次建立连接或者未能使用0-RTT的情况。
• 安全性：1-RTT提供了完整的握手过程，确保了更高的安全性，适用于对安全性要求较高的应用场景。

 0-RTT连接建立

• 概念：在0-RTT连接中，客户端可以在发送ClientHello消息的同时，开始发送应用数据。这意味着客户端不需要等待服务器的响应就可以开始传输数据，从而显著减少延迟。
• 适用场景：0-RTT通常用于重连场景，而不会用于首次建立连接的场景。前提是客户端之前已经与服务器建立过安全连接，并且服务器支持0-RTT。
• 安全性：尽管0-RTT能减少延迟，但由于初始消息未经过完整的握手过程，因此存在重放攻击的风险。TLS 1.3对0-RTT数据的使用有一定的限制，以降低风险。比如：1）0-RTT仅适用于那些在之前的连接中已经确定的应用数据。这些数据必须是在之前的会话中被接受并理解的内容，服务器不应对新类型的数据进行处理；2）服务器需要确认哪些客户端可以使用0-RTT；3）客户端必须带着session ticket。

QUIC也是有序的，为什么说QUIC在拥塞机制上，可以避免TCP的队头阻塞问题？

TCP拥塞机制：会有队头阻塞的问题，是比较好理解的。就是一个TCP连接，只有一条流，这个流一共有1,2,3,4...100号的数据包，这时候2丢了，那么3,4...100号的数据包，哪怕已经送到了服务器，服务器也不处理，它要等客户端重传了2，才会处理，这就是队头阻塞。当然更坏的情况是，随机丢了不止一个数据包，比如2丢了，15丢了，25丢了等等，那对应的后面都要等等等；

QUIC拥塞机制：不会有队头阻塞，这只是个相对的说法。对于QUIC来说，它一个QUIC连接里，可以传送很多条流（多路复用）。每一个流里面其实也是有序的，后面的先到了，前面的没到，那也一样要队头阻塞。但是QUIC一个连接同时发了很多的流，每个流都出现队头阻塞的概率是很低的，同时，每个流的使命也是独立的。这样的话，总有一些流已经先存在服务器并且有效处理了，就不用像TCP一样，2没到，等2，2到了，处理3,4，发现5又没到，又要等待5到了，才能继续处理7,8。从这个意义上说，避免了队头阻塞。