设计网站公司 露 联湖南岚鸿,摄影网址,成都网络营销品牌代理机构,邳州网站建设QUIC结构
QUIC协议模型如下图所示#xff0c;其放弃了TCP∕IP网络中使用五元组(源IP,源端口,目的IP,目的端口,协议标识符)来唯一标识一条连接的方式,而使用一个全局唯一的随机生成的ID(即Connection ID) 来标识一条连接。 由低向上分层讨论QUIC协议#xff1a;
•UDP层:在U…QUIC结构
QUIC协议模型如下图所示其放弃了TCP∕IP网络中使用五元组(源IP,源端口,目的IP,目的端口,协议标识符)来唯一标识一条连接的方式,而使用一个全局唯一的随机生成的ID(即Connection ID) 来标识一条连接。 由低向上分层讨论QUIC协议
•UDP层:在UDP层传输的是UDP报文此处关注的是UDP报文荷载内容是什么以及如何高效发送UDP报文
•Connection层:Connection通过Connection ID来确认唯一连接connection对packet进行可靠传输和安全传输
•Stream层:在相应的Connection中Stream通过Stream ID进行唯一流确认并对stream frame进行传输管理。
Quic协议相关术语
数据包PacketQUIC 协议中一个完整可处理的单元可以封装在UDP 数据报datagram中。多个QUIC 数据包packets可以封装在一个UDP 数据报datagram中。帧FrameQUIC 数据包packet的有效载荷payload。端点Endpoint在QUIC 连接中生成、接收和处理 QUIC 数据包packets的终端。QUIC中只有两端点endpoints客户端client和服务端server。客户端Client: 创建QUIC 连接的端点。服务端Server: 接收QUIC 连接的端点。地址Address未经限定使用时表示网络路径一端的IP 版本、IP地址和 UDP 端口号的元组。连接IDConnection ID 用于标识端点 QUIC 连接的一种标识符。每个端点endpoint为其对端peer选择一个或多个连接 ID将其包含在发送到该端点的数据包packets中。这个值对peer 不透明。流StreamQUIC 连接中有序字节的单向unidirectional或双向bidirectional通道。一个QUIC 连接可以同时携带多个流。应用程序Application使用QUIC 发送或者接收数据的实体。
UDP层
UDP荷载大小
•荷载大小受限于3个对象QUIC协议规定路径MTU终端接受能力
1、QUIC不能运行在不支持1200字节的单个UDP传输网络路径上 QUIC规定initial包大小不得小于1200如果数据本身不足1200比如initial ack)那么需要用padding方式至少填充到1200字节
2、QUIC不希望出现IP层分片现象本要求意味着udp交给IP层的数据不会大于1个MTU假设mtu为1500ipv4场景下udp的荷载上限为1472字节1500-20-8ipv6下udp荷载上限为14521500-40-8)。QUIC建议使用PMTUD以及DPLPMTUD进行mtu探测。在实战中我们建议设置IPv6的MTU为1280大于这个值某些网络会存在丢包现象。
3、终端能接受 transport paraments的max_udp_payload_size(0x03)的是终端接受单个udp包大小的能力发送端应当遵从这一约定。
UDP荷载内容
UDP荷载内容即为QUIC协议中的packet。协议规定如果不超过荷载大小的限制那么多个packet可以组成一个UDP报文发出去。在QUIC实现中如果每个UDP报文只包含一个QUIC packet会更容易出现乱序问题。
高效发UDP包
和tcp不同QUIC需要在应用层就完成UDP数据组装且每个udp报文不大于1个mtu如果不加以优化比如每个包直接用sendto/sendmsg发送势必会造成大量的系统调用影响吞吐
1、通过sendmmsg接口进行优化sendmmsg可以将用户态的多个UDP QUIC包通过一次系统调用发到内核态。内核态对于每个UDP QUIC包独立作为UDP包发出去
2、在1.解决了系统调用次数问题开启GSO可以进步一分包延迟到发给网卡驱动前一刻可以进一步提高吞吐降低CPU消耗。
Connection层
上节说到1个udp报文里传输的其实是一个或多个QIUC协议打包的packet。所以在Connection这一层面其实是以packet为单位进行管理的。一个packet到来终端需要解析出目标Connection ID(DCID)字段并将该packet交给找到对应的QIUC connection。一个packet是由header加payload两部分组成。
Connection ID
相较于TCP/IP使用五元组标识一条连接QIUC在Connection层采用客户端随机产生的64位随机数作为Connection ID标识连接这样IP或者端口发生变化时只要ID 不变这条连接依然维持可以做到连接平滑迁移。
连接建立时使用UDP端口号来识别指定机器上的特定server而一旦建立连接通过其connection ID关联。 上图左边是HTTPS的一次完全握手的建连过程需要3 个 RTT。就算是Session Resumption也需要至少 2个 RTT。而 QUIC 由于建立在UDP 的基础上同时又实现了 0RTT的安全握手所以在大部分情况下只需要0 个 RTT就能实现数据发送在实现前向加密的基础上并且 0RTT 的成功率相比TLS 的 Sesison Ticket要高很多。QUIC握手handshake合并了加密和传输参数的协商只需要1-RTT 即可完成握手提升了建立连接到交换应用程序数据的速度。第二次连接时可以通过第一次连接时获取到的预共享密钥pre-shared secret立即发送数据0-RTT。
安全传输
QUIC的安全传输依赖TLS1.3而boring ssl是众多quic实现的依赖库。协议对Packet的头部以及荷载均进行了保护包括packet number)。TLS1.3提供了0-RTT的能力在提供数据保护的同时能在第一时间服务端收到第一个请求报文时就将Response Header发给客户端。大大降低了HTTP业务中的首包时间。为了支持0-RTT客户端需要保存PSK信息以及部分transport parament信息。
安全传输也经常会涉及到性能问题在目前主流的服务端AESG由于cpu提供了硬件加速所以性能表现最好。CHACHA20则需要更多的CPU资源。在短视频业务上出于对首帧的要求通常直接使用明文传输。
Transport ParamenterTP)协商是在安全传输的握手阶段完成除了协议规定的TP外用户也可以扩展私有TP内容这一特性带来了很大的便利比如客户端可以利用tp告知服务端进行明文传输。
可靠传输
QUIC协议是需要像TCP能够进行可靠传输所以QUIC单独有一个rfc描述了丢包检测和拥塞控制的话题
丢包检测
TCP 为了保证可靠性使用了基于字节序号的 Sequence Number 及 Ack 来确认消息的有序到达。
QUIC 同样是一个可靠的协议它使用 Packet Number 代替了 TCP 的 sequence number并且每个 Packet Number 都严格递增。而 TCP 重传 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不变也正是由于这个特性引入了 TCP 重传的歧义问题。
在普通的TCP里面如果发送方收到三个重复的ACK就会触发快速重传如果太久没收到ACK就会触发超时重传而QUIC使用NACK (Negative Acknowledgement) 可以直接告知发送方哪些包丢了不用等到超时重传。TCP有一个SACK的选项也具备NACK的功能QUIC的NACK有一个区别它每次重传的报文序号都是新的。
但是单纯依靠严格递增的 Packet Number 肯定是无法保证数据的顺序性和可靠性。QUIC 又引入了一个 Stream Offset 的概念即一个 Stream 可以经过多个 Packet 传输Packet Number 严格递增没有依赖。但是 Packet 里的 Payload 如果是 Stream 的话就需要依靠 Stream 的 Offset 来保证应用数据的顺序。
拥塞控制QUIC针对TCP协议中的一些缺陷专门做了优化。QUIC 重新实现了TCP 协议的Cubic算法进行拥塞控制并在此基础上做了不少改进。热插拔tcp的拥塞控制需要内核态实现而QUIC在用户态实现因此QUIC 修改拥塞控制策略只需要在应用层操作并且QUIC 会根据不同的网络环境、用户来动态选择拥塞控制算法。前向纠错 FECQUIC 使用前向纠错(FECForward Error Correction)技术增加协议的容错性。一段数据被切分为10 个包后依次对每个包进行异或运算运算结果会作为 FEC 包与数据包一起被传输当出现丢包时可根据剩余的包和FEC包推算出丢的包。
单调递增的Packet Number TCP 为了保证可靠性使用Sequence Number 和 ACK确认消息是否有序到达但这样的设计存在缺陷。超时发生后客户端发起重传随后接收到了ACK确认但因为原始请求和重传请求所返回的ACK 消息一样所以客户端无法分辨此 ACK 对应的是原始请求还是重传请求。如果客户端认为是原始请求的ACK但实际上是左图的情形则计算的采样 RTT 偏大如果客户端认为是重传请求的ACK但实际上是右图的情形又会导致采样 RTT 偏小。采样 RTT 会影响超时重传时间Retransmission TimeOut的 计算。 QUIC解决了上面的歧义问题。与采用Sequence Number 标记不同的是其使用的Packet Number标记严格单调递增如果 Packet N 丢失了那么重传时 Packet 的标识不会是 N而是比 N 大的数字比如NM这样发送方接收到确认消息时就能方便地知道 ACK 对应的是原始请求还是重传请求。
Connection层
更大的ACK block
一般来说接收方收到发送方的消息后都应该发送一个 ACK回复表示收到了数据。但每收到一个数据就返回一个ACK 回复太麻烦所以一般不会立即回复而是接收到多个数据后再回复TCP SACK 最多提供 3个 ACK block。但有些场景下比如下载只需要服务器返回数据就好但按照 TCP 的设计每收到 3 个数据包就要返回一个ACK。而QUIC 最多可以捎带 256 个ACK block。在丢包率比较严重的网络下更多的 ACK block 可以减少返回包的量提升网络效率。
流量控制
TCP 会对每个 TCP 连接进行流量控制,通过滑动窗口进行实现。
QUIC 的流量控制有两个级别连接级别和Stream级别用于表达接收端的接受能力。 单条 Stream的流量控制如上图所示。Stream 还没传输数据时接收窗口flow control receive window就是最大接收窗口flow control receive window随着接收方接收到数据后接收窗口不断缩小。在接收到的数据中有的数据已被处理而有的数据还没来得及被处理。蓝色块表示已处理数据黄色块表示未处理数据这部分数据的到来使得Stream的接收窗口缩小。
随着数据不断被处理接收方就有能力处理更多数据。当满足(flow control receive offset - consumed bytes) (max receive window / 2) 时接收方会发送WINDOW_UPDATE frame 告诉发送方你可以再多发送些数据过来。这时flow control receive offset就会偏移接收窗口增大发送方可以发送更多数据到接收方。
由于QUIC协议允许多路复用因此Stream 级别的控制对防止接收端接收过多数据作用有限更需要借助 Connection 级别的流量控制。
针对stream
可用窗口数 最大窗口数 – 接收到的最大偏移数
针对connection
可用窗口数 stream1可用窗口数 … streamN可用窗口数
QUIC 的流量控制和TCP 有点区别TCP为了保证可靠性窗口左边沿向右滑动时的长度取决于已经确认的字节数。如果中间出现丢包就算接收到了更大序号的Segment窗口起始changdu也无法超过这个序列号。 QUIC 不同就算此前有些 packet 没有接收到它的滑动窗口也只取决于接收到的最大偏移字节数。
Stream层
Stream是一个抽象的概念用以表示一个有序传输的数据流而这些数据其实就是由Stream Frame排列构成。QUIC 使用帧frames进行端到端的通信。一个或多个帧frame被组装成一个 QUIC 包packet。在一个quic connection上可以同时传输多条流QUIC通过对多路传输的支持,解决了TCP中的队头阻塞问题。 在QUIC协议中有序的概念仅维护在单个stream中stream之间和packet都不要求有序假设某个packet丢失只会影响包含在这个包里的stream其他stream仍然可以从后续乱序到达的packet中提取到自己所需帧交给应用层。
Stream头部
可以创建两种类型的流双向流bidirectional streams允许客户端和服务端互相发送数据。单向流unidirectional streams允许单个端点endpoint发送数据。一个基于信用的方案credit-based scheme用于限制流的创建并限制可发送的数据量。stream的不同类型定义在HTTP3中得到了充分的利用。
Stream荷载
Stream的荷载即为一系列Stream Frame通过Stream Frame头部的Stream ID来确认单个流。在TCP里如果一个segment传递丢失那么后续segment乱序到达也不会被应用层使用只到丢失的segment重传成功为止因此TCP实现的HTTP2的多路复用能力受到制约。在QUIC协议中有序的概念仅维护在单个stream中stream之间和packet都不要求有序假设某个packet丢失只会影响包含在这个包里的stream其他stream仍然可以从后续乱序到达的packet中提取到自己所需要的数据交给应用层。
Quic相关开源库
gQUICiQUICchromiumquic-client/server-demo模块封装了支持HTTPS的QUIC实现MsQuicMsQuic是IETF quic协议的Microsoft实现。它是跨平台的用C语言编写设计成一个通用的QUIC库。chromiumnet/quic模块封装QUIC在更底层模仿TCP Socket操作在chrome75版本后被弃用本次quic模块基于74-75版本的模块实现。quic-go使用Go语言来重写的QUIC协议实现库从github上面看其对于iQUIC和gQUIC这两个分支流派都提供了支持。quiche目前谷歌使用的QUIC开源代码库将QUIC从chromium独立出来提供QUIC协议的支持与iQUIC兼容。QuicwgIETF quic实现工作小组
