陕西网站建设公司找哪家,手机广西网,网站建设需要固定ip地址吗,网站改版怎么弄简介#xff1a; 众所周知#xff0c;QUIC#xff08;Quick UDP Internet Connection#xff09;是谷歌制定的一种互联网传输层协议#xff0c;它基于UDP传输层协议#xff0c;同时兼具TCP、TLS、HTTP/2等协议的可靠性与安全性#xff0c;可以有效减少连接与传输延迟 众所周知QUICQuick UDP Internet Connection是谷歌制定的一种互联网传输层协议它基于UDP传输层协议同时兼具TCP、TLS、HTTP/2等协议的可靠性与安全性可以有效减少连接与传输延迟更好地应对当前传输层与应用层的挑战。目前阿里云CDN线上提供GQUIC版本服务已经有Tbps级别的流量承载并对客户来带了显著的延迟收益。本文将由低向上分层讨论QUIC协议的特点。
众所周知QUICQuick UDP Internet Connection是谷歌制定的一种互联网传输层协议它基于UDP传输层协议同时兼具TCP、TLS、HTTP/2等协议的可靠性与安全性可以有效减少连接与传输延迟更好地应对当前传输层与应用层的挑战。目前阿里云CDN线上提供GQUIC版本服务已经有Tbps级别的流量承载并对客户来带了显著的延迟收益。本文将由低向上分层讨论QUIC协议的特点。
作者黎叔
QUIC协议是一系列协议的集合主要包括
传输协议Transport丢包检测与拥塞控制Recovery)安全传输协议TLS)HTTP3协议HTTP头部压缩协议QPACK)负载均衡协议Load Balance)
本文针对QUIC的系列协议进行科普性简单介绍细节读者仍然需要通读协议原文。本文基于quic的讨论均基于quic-34系列版本。
QUIC协议类似快递公司在收到用户数据后将数据打包传输到对端再进行拆包将用户数据交给了最终目标用户。QUIC是基于UDP协议实现了类似TCP的可靠传输并在此基础上结合HTTP3/QPACK更好地服务互联网上海量的HTTP Request/Response需求。如其名发音QUIC(quick)其目标就是希望比基于TCP的HTTP交互有更好的体验。
QUIC/HTTP3的特点
有序传输用stream的概念确保数据有序。不同的stream或者packet不保证有序到达。报文压缩提高荷载比率比如QUIC引入了variable-length integer encoding。又比如引入QPACK进行头部压缩可靠传输支持丢包检测和重传安全传输TLS 1.3安全协议
分层的协议
QUIC是在UDP的基础上构建类似TCP的可靠传输协议。HTTP3则在QUIC基础上完成HTTP事务。 网络总是分层讨论的在此我们由低向上分层讨论quic协议
UDP层: 在UDP层传输的是UDP报文此处关注的是UDP报文荷载内容是什么以及如何高效发送UDP报文Connection层: Connection通过CID来确认唯一连接connection对packet进行可靠传输和安全传输Stream层: Stream在相应的Connection中通过StreamID进行唯一流确认stream对stream frame进行传输管理HTTP3层HTTP3建立在QUIC Stream的基础上相对于HTTP1.1和HTTP2.0HTTP3提供更有效率的HTTP事务传输。HTTP3中通过QPACK协议进行头部压缩
UDP层
本章节讨论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消耗
3、在2.的基础上现在主流网卡已经支持硬件GSO offload方案可以进一步提高吞吐降低cpu消耗
上面介绍的发送方式事实上可以理解为udp burst发送方式这带来了一个问题拥塞控制需要pacing能力
Connection层
在我们讨论时可知1个udp报文里传输的其实是一个或多个quic协议定义的packet。那么在Connection这一层面其实是以packet为单位进行管理的。一个packet到来终端需要解析出目标ConnectionID(DCID)字段并将该packet交给找到对应的quic connection。一个packet是由header加payload两部分组成。
connection id
不同于tcp的4元组唯一确认一条连接的方式QUIC定义了一个和网络路由无关的ConnectionID来确认唯一连接的。这带来一个好处可以在四元组发生变化时比如nat rebinding或者终端网络切换wifi-4G)依然保持连接。当然虽然连接状态依然保持但由于路径发生变化拥塞控制也需要能够及时调整。
packet头部
IETF的quic header分为两种类型long header, short header。其中long header有分为 initial, 0rtt, handshake, retry四种类型。类型的定义可以直接参考rfc文档此处不再赘述。
quic规定packet number始终为自增的就算某个packet的内容为重传的frame数据其packet number也必须自增这相对于TCP来说带来一个优点能够更加精确的采集到路径的RTT属性。
packet number编解码: packet number是一个0~262 -1的取值范围quic为了节约空间在计算packet number时引入了unacked的概念通过截断只保留有效bit位的方式只用了1-4个字节即可以encode/decode出正确的packet number。rfc文档中有附录详细讲解了enc/dec的过程。
packet头在安全传输中是被保护对象这也意味着在没有ssl信息的情况下无法使用wireshake对packet进行时序分析。中间网络设备也无法向TCP那样获得packet number进行乱序重组。
packet荷载
在对packet进行解密且去除掉packet header后packet的荷载里就都是frame了至少包括1个。
如果packet的荷载里不包括ACK, PADDING, and CONNECTION_CLOSE这种三种类型的帧那么这个packet则被定义为ack-eliciting意味着对端必须对这种packet生成相应的ack通知发送方以确保数据没有丢失。
packet的荷载里frames的类型在多达30种类型每种类型都有自己的应用场景如ACK Frame用于可靠传输Recovery)Crypto用于安全传输TLS握手Stream Frame用于业务数据传递MAX_DATA/DATA_BLOCKED用于流控PING Frame可以用于mtu探测具体描述参考rfc文档。
安全传输
QUIC的安全传输依赖TLS1.3而boringssl是众多quic实现的依赖库。协议对Packet的头部以及荷载均进行了保护包括packet number。TLS1.3 0RTT的能力在提供数据保护的同时能在第一时间服务端收到第一个请求报文时就将Response Header发给客户端。大大降低了HTTP业务中的首包时间。为了支持0RTT客户端需要保存PSK信息以及部分transport parament信息。
安全传输也经常会涉及到性能问题在目前主流的服务端AESG由于cpu提供了硬件加速所以性能表现最好。CHACHA20则需要更多的CPU资源。在短视频业务上出于对首帧的要求通常直接使用明文传输。
Transport ParamenterTP)协商是在安全传输的握手阶段完成除了协议规定的TP外用户也可以扩展私有TP内容这一特性带来了很大的便利比如客户端可以利用tp告知服务端进行明文传输。
可靠传输
QUIC协议是需要像TCP能够进行可靠传输所以QUIC单独有一个rfc描述了丢包检测和拥塞控制的话题
丢包检测协议利用两种方式来判断丢包是否发生一种是基于ack的检测通过time threshold和packet threshold根据已经到达的packet推断在此包之前发出去的包是否丢失。第二种在失去了参考包的情况下那么只能通过PTO的方式来推断包是否丢失。一般来说大量被触发的应该是ACK的检测方式。如果PTO被大量触发会影响发包效率。
拥塞控制QUIC针对TCP协议中的一些缺陷专门做了优化。比如始终递增的packet number丰富的ack rangehost delay计算等。同时tcp的拥塞控制需要内核态实现而QUIC在用户态实现这大大降低了研究高效率的可靠传输协议的门槛。Recovery协议中描述了newReno的实现方式。在GOOGLE chrome中实现了cubic, bbr, bbrv2而mvfst项目则更为丰富包括了ccp, copa协议。
Stream层
stream是一个抽象的概念它表达了一个有序传输的字节流而这些字节其实就是由Stream Frame排在一起构成。在一个quic connection上可以同时传输多条流。
Stream头部
在Quic协议里stream分为单向流或双向流又分为客户端发起或服务端发起。stream的不同类型定义在HTTP3中得到了充分的利用。
Stream荷载
Stream的荷载即为一系列Stream Frame通过Stream Frame头部的Stream ID来确认单个流。 在TCP里如果一个segment传递丢失那么后续segment乱序到达也不会被应用层使用只到丢失的segment重传成功为止因此TCP实现的HTTP2的多路复用能力受到制约。在QUIC协议中有序的概念仅维护在单个stream中stream之间和packet都不要求有序假设某个packet丢失只会影响包含在这个包里的stream其他stream仍然可以从后续乱序到达的packet中提取到自己所需要的数据交给应用层。
HTTP3层
stream分类
在引入HTTP3后stream的单向流类型被扩展成控制流Push流和其他保留类型。其中HTTP3的setting则是在控制流中传输而HTTP数据传输是在客户端发起的双向流中所以读者会发现HTTP数据传输的stream id都是模4等于0的。
在引入QPACK后单向流被进一步扩展了两个类型encoder流decoder流QPACK中动态表的更新则依赖这两个流。
QPACK
QPACK的作用是头部压缩。类似HPACKQPACK定义了静态表动态表用于头部索引。静态表是针对常见的头部协议预先定义的。动态表则是在该QUIC Connection服务HTTP过程中逐渐建立的。QPACK所建立的Encoder/Decoder流是伴随用于HTTP事务的QUIC Connection生命周期。 动态表不是HTTP3能够运行的必须项所以在某些QUIC开源项目中并没有实现复杂的动态表功能。
在QPACK的动态表业务中数据流编码流解码流3种对象共同参与编码流和解码流负责维护动态表变化数据流则解析出头部的索引号去动态表中查询得到最终的头部定义。
其他
Flow Control 流控
QUIC协议引入了flow control的概念用于表达接收端的接受能力。流控分两级Connection级别和Stream级别。发送端发送的数据偏移量不能超过流控的限制如果达到限制那么发送端应该通过 DATA_BLOCKED/STREAM_DATA_BLOCKED来通知接收端。如果为了传输性能接收端应该尽量保持限制足够大比如达到max_data的一半时就及时更新max_data传给发送端。如果接收端不希望太快接受数据也可以利用流控对发送端进行约束。
QUIC版本
QUIC一开始由google主导设计开发在chromium项目中可以看到google quic(GQUIC)版本号被定义为Q039,Q043,Q046,Q050等。
随着IETF版本的QUIC推出ietf quic(IQUIC)也有很多版本如29,30,34(最新版)等不同版本可能是无法互通的比如不同版本安全传输的salt变量规定不一样。所以IQUIC引入了版本协商的功能用于不同的客户端和服务端协商出可以互通的版本。
在实践中还会遇到一个需求要求一个服务能够同时服务GQUIC的不同版本又能服务IQUIC的不同版本。这就要求服务在收取到packet后需要对packet作出判断分析出它属于iquic的还是gquic的然后进行逻辑分流。
QUIC应用及未来展望
目前阿里云CDN线上提供GQUIC版本服务适用的产品包含静态内容分发图片小文件、大文件下载、视音频点播和动态内容分发全站加速。用户只需在CDN、全站加速控制台对域名开启【QUIC协议开关】功能支持QUIC协议的客户端即可通过QUIC协议与阿里云CDN节点通信。
QUIC应用场景
图片小文件明显降低文件下载总耗时提升效率 视频点播提升首屏秒开率降低卡顿率提升用户观看体验 动态请求适用于动态请求提升访问速度如网页登录、交易等交互体验提升 弱网环境在丢包和网络延迟严重的情况下仍可提供可用的服务并优化卡顿率、请求失败率、秒开率、提高连接成功率等传输指标 大并发连接连接可靠性强支持页面资源数较多、并发连接数较多情况下的访问速率提升 加密连接具备安全、可靠的传输性能
关于QUIC协议目前阿里云CDN线上的QUIC已经有了Tbps级别的大流量验证并为客户来带了显著的延迟收益。随着IETF标准的QUIC协议完善阿里云也会尽快推出ietf quic服务我们相信QUIC未来会成为互联网流量的主力成员。
后续阿里云CDN会在“阿里云Edge Plus”公众号中分享更多最新的产品能力、解决方案和技术实践欢迎大家关注与我们一起探讨。
原文链接
本文为阿里云原创内容未经允许不得转载。
