《STGW 下一代互联网标准传输协议QUIC大规模运营之路.docx》由会员分享，可在线阅读，更多相关《STGW 下一代互联网标准传输协议QUIC大规模运营之路.docx（24页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、STGW下一代互联网标准传输协议QUIC大规模运营之路wentaomao腾讯TEG后台开发工程师前言QUIC作为互联网下一代标准传输协议可以明显提升业务访问速度提升弱网恳求成功率和改善网络变化场景下的平滑体验。STGW作为公司级的7层接入网关和腾讯云CLB负载平衡器的底层支撑框架每天都为公司内部业务以及腾讯云外部客户提供数万亿次的恳求效劳对恳求处理的性能、传输效率、运营的可靠性都有非常严苛的要求。本文主要介绍STGW大规模运营QUIC经过中的一些经历以及开发工作。QUIC简介QUIC的诞生以及开展在QUIC诞生之前HTTP协议经历了几次重要的晋级HTTP1.0-HTTP1.1增加了长连接支持大
2、大提升了长连接场景下的性能。HTTP-HTTPS增加平安特性对恳求的性能综合来看会有一定的影响。HTTP1.1-HTTP2主要特性是多路复用与头部压缩进步了单连接的并发才能。这些重要变化都是围绕平安与性能展开对HTTP协议的应用以及开展起到了很重要的作用。但是它没有绕开内核TCP的限制导致其协议的开展终究存在瓶颈。GOOGLE在引领业界从HTTP1.1迈向HTTP2GOOGLESPDY协议的标准版后再一次走在了前头在2021年度提出了实验性的QUIC协议首次使用UDP重构了TLS以及TCP协议。QUIC协议不仅仅只应用于HTTPQUIC在设计时除了考虑HTTP外更是设计作为一个通用的传输层协议
3、。在平安性上GOOGLE设计了QUIC加密协议作为握手协议以解决QUIC协议上的平安问题。一般来讲QUIC握手协议QUIC传输层HTTP2就是我们常讲的GQUIC这里指web局部。GQUIC协议的版本不断演化从Q46开场GQUIC协议也不断向IETFQUIC以及HTTP3靠拢。2021年度QUIC的网络草案被正式提交至互联网工程任务组这意味着新的QUIC协议标准将要诞生。在标准QUIC协议起草经过中QUIC协议上的标准HTTP协议作为HTTP3也同时被起草。而作为QUIC的标准握手协议IETF将TLS1.3应用其中。TLS1.3QUICHTTP3这就是我们常讲的IETFQUIC这里指web局部
4、。截止目前QUIC标准的草案已经更新到34版仍没形成正式的RFC。但是QUIC已进入IETF最后征求意见预计标准QUIC/HTTP3协议会很快问世。QUIC的关键特性关于QUIC的原理相关介绍的文章很多这里再列举一下QUIC的重要特性。这些特性是QUIC得以被广泛应用的关键。不同业务可以以根据业务特点利用QUIC的特性去做一些优化。同时这些特性也是我们去提供QUIC效劳的切入点。低连接延时QUIC由于基于UDP无需TCP连接在最好情况下短连接下QUIC可以做到0RTT开启数据传输。而基于TCP的HTTPS即使在最好的TLS1.3的earlydata下仍然需要1RTT开启数据传输。而对于目前线上
5、常见的TLS1.2完全握手的情况那么需要3RTT开启数据传输。对于RTT敏感的业务QUIC可以有效的降低连接建立延迟。可自定义的拥塞控制QUIC的传输控制不再依赖内核的拥塞控制算法而是实如今应用层上这意味着我们根据不同的业务场景实现以及配置不同的拥塞控制算法和参数。GOOGLE提出的BBR拥塞控制算法与CUBIC是思路完全不一样的算法在弱网以及一定丢包场景BBR比CUBIC更不敏感性能也更好。在QUIC下我们可以根据业务随意指定拥塞控制算法以及参数甚至同一个业务的不同连接可以以使用不同的拥塞控制算法。无队头阻塞固然HTTP2实现了多路复用但是因为其基于面向字节流的TCP因此一旦丢包将会影响多路
6、复用下的所有恳求流。QUIC基于UDP在设计上就解决了队头阻塞问题。同时IETF设计了QPACK编码交换HPACK编码在一定程度上也减轻了HTTP恳求头的队头阻塞问题。无队头阻塞使得QUIC相比TCP在弱网以及一定丢包环境上有更强大的性能。连接迁移当用户的地址发生变化时如WIFI切换到4G场景基于TCP的HTTP协议无法保持连接的存活。QUIC基于连接ID唯一识别连接。当源地址发生改变时QUIC仍然可以保证连接存活以及数据正常收发。QUIC协议栈的选择对于协议的实现STGW与CDN业务团队在LEGOSTGW与CDN自研的高性能转发框架上实现过完好的HTTP2协议。同时STGW也在业界最早实现了
7、TLS异步代理计算的方案。对于HTTP1.1/2以及TLS协议有不少工程以及优化经历。QUIC协议栈的自研目前也在按方案展开但尚不成熟。本文就基于开源方案给大众简单介绍一下QUIC协议栈的深度定制以及优化工作。关于QUIC协议栈的实现当前功能广泛协议支持齐全的实现并不多。NGINX官方目前实现了一个实验版本但是该实现很多问题没解决同时其仅支持IETF最新的DRAFT甚至连一个完好的拥塞控制算法也没有实现。CLOUDFLARE的QUIC基于RUST实现性能从公开数据来看并不强。其它的很多实现诸如MSQUIC,NGHTTP3等都只支持IETFQUIC并不支持GQUIC。GOOGLE是QUIC协议的
8、创始者其基于CHROME的QUIC协议栈实现最早功能最齐实现上也最为标准。不管是哪种QUIC协议栈其接入都需要我们对QUIC的根本特性以及概念有较深的理解。比方常见的连接流QUIC连接IDQUIC定时器统一的调度器等等。这些概念与QUIC协议的内容息息相关。下面以CHROMIUMQUIC为例的将QUIC协议栈与高性能转发框架NGINX与LEGO交融的架构图CHROMIUMQUIC接入高性能框架NGINX/LEGOSTGW的工作STGW作为公司级的7层接入网关和腾讯云CLB负载平衡器的底层支撑框架为公司内部业务以及腾讯云外部客户提供数万亿次恳求的效劳对恳求处理的性能、传输效率、运营质量的高可靠性
9、都有非常严苟的要求。为此我们对QUIC协议栈做了大量优化以及深度定制以知足大规模运营以及业务需求。主要的工作有单机与传输性能优化QUIC协议单机性能/本钱优化QUIC将协议栈搬到应用层来从目前一些公开的实现看性能比TCP差不少优化QUIC协议的性能是大规模推广QUIC协议很重要的一环。与高性能转发框架交融当前开源的QUIC协议栈的实现仅仅提供单核支持并仅提供简单的demo。要想大规模应用需要将QUIC协议栈接入到我们使用的高性能网络转发框架中来如NGINX,LEGO等。传输性能拥塞控制定制化可以允许不同业务根据业务特性选择不同的拥塞控制算法。做到平安高比例的0RTT以降低业务的连接延迟。功能特
10、性的定制以及增强怎样让QUIC连接迁移从理论走向应用QUIC的连接ID是QUIC协议的特性但是实际应用中要做到连接迁移并不容易需要充分考虑QUIC包的各个途径。即使在同一台机器上也需要正确转发到对应的核上去。QUIC私有协议的支持QUIC不仅仅用于HTTP作为通用的传输层协议除了支持GQUIC,IETFHTTP3外QUIC的私有协议也需要我们提供应用户。QUIC定制化SDK除了高性能QUIC效劳端外要想使用QUIC需要客户端SDK的支持。对此我们也开发了QUIC的SDK并针对不同的场景做了定制化。知足业务各种定制化需求如有些业务需要QUIC明文传输一些业务需要QUIC回源等。高可用运营日常变更
11、与平滑晋级在配置频繁变更以及模块晋级时我们需要做到对QUIC连接无损。抓包分析工具分析定位为更方便。统计监控QUIC的关键统计指标需做到可视化运营。我们围绕着这些问题展开了QUIC的相关工作力求将QUIC特性QUIC运营QUIC性能QUIC定制化需求等做到最好。QUIC处理性能优化QUIC协议基于UDP将TCP的特性从内核移到了应用层从当前各种QUIC实现来看性能相比TCP差不少。TCP长期以来使用非常广泛这也使得其从协议栈到网卡已经经过了非常多的优化与之相比UDP的优化那么少了很多。除了内核以及硬件外QUIC协议的性能也与实现有关不同的实现版本可能也会有很大的差异。我们对QUIC的性能利用火
12、焰图等各种工具进展了详细分析找出了一些影响QUIC性能的关键点密码相关算法的开销对于小包来讲RSA的计算占比很高对于大包来讲对称加解密也会占到15%左右的比例。UDP收发包的开销十分是对于大文件下载来讲sendmsg占比很高可以到达35%-40%以上。协议栈开销主要受协议栈实现如ACK的处理MTU探测以及发包大小内存管理以及拷贝等。我们基于影响QUIC性能的关键点进展了优化。QUIC的RSA硬件OFFLOAD在小文件恳求场景中RSA的计算在QUIC恳求同HTTPS一样仍然是最消耗CPU的开销。RSA在HTTPS恳求可以利用硬件offload在QUIC握手经过中RSA同样可以利用硬件进展offl
13、oad。使用硬件做RSA卸载一个很重要原因是CPU计算RSA性能较差而专门做加解密的加速卡性能那么很强。一般来讲单块RSA加解密卡的本钱差不多是一台效劳器的5%-7%但是其对RSA签名的操作性能是效劳器的2-3倍左右一台机器插入2块卡就可以带来5倍的RSA性能提升。将QUIC的RSA计算进展硬件卸载在不同的QUIC协议栈上方法并不一样下面介绍一种RSAHOOKASYNCJOB通用的RSA卸载方案。其特点是代码侵入性小不需要额外修改过多quic协议栈或openssl的代码。Openssl1.1.0之后开场支持AsyncJob。Asyncjob机制利用类协程方式切换上下文方式实现异步任务并且提供了
14、一个通知机制通知异步任务的返回结果。AsyncJob里的2个重要函数是async_fibre_makecontextasync_fibre_swapcontext它们利用setjmplongjmpsetcontextmakecontext这些调用保存以及切换当前上下文进而到达状态保存以及代码跳转的才能。使用RSAcallback将握手经过中的RSA进展拦截并在RSA的HOOK函数中本地或远程向加速卡恳求RSA操作。同时使用Asyncjob方式将同步方式异步化进而实现RSA操作的异步卸载。在QUICTLS1.3上RSAHOOKAsyncJob进展RSAoffload。QUIC在进展了RSA的硬件
15、OFFLOAD后对于小包短连接性能得到了很大的提升。以CHROMIUMQUIC为例在1RTT场景QUIC在使用了RSAOFFLOAD后性能为原来的256%0RTT场景QUIC在使用了RSAOFFLOAD后性能为原来的205%。在QUIC协议栈开销更小的实现上这个性能提升会更加明显。QUIC发包的GSO优化在大文件下载中QUIC发包的逻辑占比很大通常在35%-40%以上。因此优化发包逻辑可以提升大文件传输的性能。QUIC大文件恳求火焰图GSO(GenericSegmentationOffload)在内核4.8之后开场支持UDP其原理是让数据跨过IP层链路层在数据分开协议栈进入网卡驱动前进展分段不
16、管是TCP还是UDP都是分段(每个包都附加TCP/UDP头部)这样当一个段丧失不需要发送整个TCP/UDP报文。同时途径上的CPU消耗也会减少。假设网卡硬件本身支持UDP分段那么称为GSOOFFLOAD其将分段工作放在网卡硬件上做可以进一步节省CPU。GSO原理示意图QUIC协议在实现上一般为了不进展MTU分片通常会在发包前就将发送数据进展分段进而无需再进展MTU分片。对于大包来讲QUIC会将每个包控制在1400字节左右然后通过sendmsg发送出去。大文件发送场景这种性能是很低的。假如在sendmsg时发送大包不做分段然后利用内核GSO延迟分段会减少途径的CPU消耗。使用GSO发不同大小包时
17、的吞吐从表中可以看出使用GSO连续20个包进展sendmsg发送相比于1400个包单独发送性能提升了2-3倍。在实际QUIC场景中发包并不是QUIC的全部逻辑。同时并不是每次发包正好都可以凑齐20个连续包。我们对大文件下使用GSO进展QUIC压力测试一样CPU使用情况下吞吐进步了大约在15%-20%。QUIC协议栈的优化QUIC协议栈的性能与QUIC协议栈实现有关。对于一些常见的协议栈实现其优化空间主要有一些实现如CHROMIUM在0RTT以及1RTT恳求中分别多了一次RSA计算这个多余的RSA计算是可以去掉的。优化后0RTT以及1RTT的RSA计算分别为0次以及1次。大文件下载中效劳端会收到
18、并处理大量的ACK。在ACK处理上并不需要接收一个处理一个。可以将一轮中所有的ACK解析后再同时进展处理。一次发包大小尽可能接近MTUQUIC协议本身也提供了MTU探测的特性。尽可能减少协议栈的内存拷贝。下列图是小文件0RTT恳求场景中协议栈优化前以及优化后的性能比照优化前优化后4.4QUIC性能优化小结目前我们将QUIC协议栈无缝接入到了高性能转发模块NGINX与LEGO。在小包恳求上QUIC的性能开销根本可以到达HTTPS的90%以上。假如QUIC使用加速卡做RSAOFFLOAD性能甚至比原生的HTTPS强。在大包恳求上优化过后的QUICCPU性能可以到达HTTPS70%但在大局部机型中大
19、文件恳求通常都是网卡先到达瓶颈。总的来讲QUIC目前的性能问题做大规模部署已经不在是大问题。当然这里面仍然存在优化空间我们也为此做继续的优化之中。QUIC的0RTT优化下列图展示了一个HTTPS恳求与一个QUIC恳求的比照。可以看出一个完全握手的HTTPS恳求在HTTP恳求正式发出时经历了3个RTT。而QUIC恳求可以做到发HTTP恳求之前的0RTT消耗。为什么QUIC可以做到0RTT呢这里分为QUIC握手协议以及IETFQUIC的TLS1.3协议。我们以GQUIC握手为例如下列图用户第一个QUIC包时发送一个没有带serverconfig的clienthello这个时候server回一个RE
20、J的包包含serverconfig等信息。用户后续带上serverconfig继续发clienthello效劳端会回serverhello。此时握手建立成功。QUIC加密握手基于DH的非对称秘钥交换算法进展秘钥交换Serverconfig包含效劳端的算法与公钥等信息客户端利用效劳端的公钥以及自己的公私钥计算协商出连接的对称秘钥。因此第一次恳求客户端在没有保存效劳端serverconfig信息时需要1RTT恳求来完成第一次QUIC恳求。而在后续恳求中客户端可以直接带上之前的serverconfig来完成0RTT恳求。所以这里的关键是怎样提升0RTT的比例。一种典型的场景就是同一个用户在第一次1R
21、TT恳求获取到的serverconfig信息在后续屡次恳求中不管路由到哪台7层STGW效劳器都可以尽可能的处理对应的serverconfig信息。对此我们尝试过很多方案主要有14层通过会话保持将同一个IP尽可能转发到同一个7层STGW效劳器。这样的缺点是1用户的ip可能发生变化2四层基于IP的会话保持以及基于连接ID的会话保持冲突这可能导致0RTT提升的同时连接迁移特性可能无法使用。2类似于HTTPS的分布式sessioncache同一个集群通过远端模块分享serverconfig信息。这需要额外引进新的模块并且会带来一定的延时。3类似于sessionticket支持分布式无状态的server
22、config生成。实际经过中可以根据日期以及参数生成多组SCFG进一步进步可用性以及平安性。关于0RTT的优化目前我们做了不少工作对于一些不敏感的数据传输我们可以做到100%0RTT。QUIC连接迁移实现QUIC连接迁移是QUIC协议一个很重要的特点。QUIC使用连接ID唯一区分连接以应对用户的网络突然发生变化。一种典型的场景是4G与wifi之间的切换之后用户的地址发生变化原始的客户端fd已无法使用。这时只需要在客户端使用QUICSDK重新创立新的fd并继续之前连接的发包即可发出一样连接ID的包出去。用户的QUIC包可能经过中间很多途径最后到达实际的业务效劳器。我们以典型的腾讯业务走网关的场景
23、分析一次QUIC恳求经过外网后会先到四层TGW集群然后转发给七层STGW集群的一台效劳器。到达STGW效劳器后包会到达一个特定的worker进程处理。Worker进展QUIC协议卸载后使用TCP或者UDP转发给详细业务的一个RS。假如用户的QUIC连接在处理经过中突然源地址发生了变化我们怎样继续正确的响应以及维持这个QUIC连接另一个场景是用户的源地址没有发生变化但是7层STGW效劳器需要做配置变更以及晋级这时QUIC连接是否可以维持四层基于QUIC连接ID的会话保持当用户网络地址发生变化时固然源地址变化但是QUIC连接ID仍可保持一致。包经过中间网络后首先会到TGW集群。为了保证用户的地址发
24、生变化时QUIC连接得以维持TGW集群需要做正确的转发。TGW集群对QUIC的会话保持需要考虑GQUIC以及IETFQUIC不同的情况。对于GQUICQ043以下实现起来较为简单因为GQUIC协议里的连接ID由客户产生并在整个连接保持不变。对于IETFQUIC连接ID由客户端以及效劳端协商产生需要考虑longheader包以及shortheader包等不同的场景。下列图为IETF连接ID的协商经过和GQUIC以及IETFQUIC不同类型包的抓包分析。IETF下连接ID的协商经过GQUIC包IETF不同类型包目前TGW集群已经支持QUIC的会话保持根本原理是在同集群不同的TGW效劳器之间同步QU
25、IC连接信息同时可以区分不同QUIC协议将一样QUIC连接ID的包转发到一样的7层STGW效劳器去。七层单机多核的连接迁移当包到达STGW效劳器时由于STGW效劳器多核转发此时还需要将QUIC包转发到同一个进程(或者线程)去处理。当前7层网络框架一般使用多核REUSEPORT模型来提供高性能转发才能。对于QUIC效劳上层不同的进程在同一个UDP端口使用REUSEPORT监听。LINUX内核默认基于4元组hash因此原生情况下不同源地址的包是无法保证到达同一个进程的。EBPF在内核4.19引入BPF_PROG_TYPE_SK_REUSEPORT这个HOOK可以策略性的控制一个包到达后发往到哪一个
26、accept队列。这使得使用EBPF可以实现因为用户源地址变化引起的QUIC连接迁移。详细方法是在EBPF的REUSEPORT钩子处解析QUIC包和连接ID根据QUIC连接ID将包转发到对应的worker去。配置加载以及热晋级连接保持QUIC连接迁移还有一种典型的场景是配置加载以及热晋级当STGW效劳器进程配置变更或进展模块晋级时原生NGINX对TCP是可以保持连接不中断的。但是对于基于UDP的QUIC在未经过优化的情况下我们无法在配置变更以及模块晋级经过中保持包的正常转发。以NGINX的配置以及热晋级变更为例NGINX在配置变更以及热晋级时会产生新的一组worker同时老的worker进入s
27、huttingdown状态而老的连接状态都在老的worker中。此时新老worker共用一组fd。假设老的worker关闭fd监听那么对于老的恳求的连接都会超时。假设老的worker继续监听fd那么存在新老worker惊群读同一个fd的问题这使得任意新老连接的包可能会到任意一个worker对新老连接都存在影响。STGW作为一个平台每天的配置变更需求非常多某些集群甚至到达了几秒一次配置变更。固然我们实现了动态配置加载可以做到绝大局部场景不需要reload程序但是仍然有少局部程序要reload。同时热晋级这种场景也是比拟常见的。假如配置reload或模块晋级就导致存量QUIC连接超时或者中断必然会
28、对业务产生很大影响。NGINX配置变更以及热晋级时worker的收包那么怎样解决这个问题呢基于内核的EBPF方案可以较好的处理4G与WIFI切换的场景但是对于STGW效劳器配置变更以及模块晋级的场景却很难实现。为此STGW使用了基于分享内存的QUIC连接迁移方案使用分享内存管理不同进程的所有连接信息。同时为每个worker设定了一个packetqueue用于接收来自别的进程连接迁移的包的转发。可以讲目前STGW完全支持4G与WIFI互切的QUIC连接迁移场景。同时对于线上大规模运营来讲持续的配置变更以及模块晋级也不会影响QUIC连接的保持。STGW基于分享内存的连接迁移以及连接保持方案连接迁移
29、的应用场景一切重连开销很大的场景可以讲都是QUIC连接迁移的使用场景。例如游戏视频和业务信道传输就是比拟典型的场景。当用户在WIFI网络切换到4G时使用原始的TCP方案在网络切换后会有一个连接重建经过。一般重连后业务会有一些初始化操作这会消耗几个甚至十几个RTT现象就是应用的卡顿或菊花旋转。在使用QUIC连接迁移功能后可以保证在WIFI与4G网络切换经过中连接的正确迁移以及存活无需建立新的连接进而使得业务的流畅度在网络切换时会得到很大提升。灵敏的拥塞算法与TCP重定义TCP拥塞控制算法的目的可以简单概括为充分利用网络带宽、降低网络延时、优化用户体验。然而就目前而言要实现这些目的就难免有权衡以及
30、取舍。LINUX的拥塞控制算法经过很屡次迭代主流都是使用的CUBIC算法。在Linux4.19内核后拥塞控制算法从CUBIC改为了BBR。BBR算法相比之前拥塞控制算法进展了非常重大的改变。BBR通过实时计算带宽以及最小RTT来决定发送速率pacingrate以及窗口大小cwnd。BBR主要致力于1在有一定丢包率的网络链路上充分利用带宽。2降低网络链路上的buffer占用率进而降低延迟。BBR完全摒弃丢包作为拥塞控制的直接反应因素这也导致其对丢包并不是非常敏感。通过测试我们得出在模拟一定概率丢包的网络情况下对QUIC大文件的恳求BBR的下载性能会比CUBIC更好。QUIC将拥塞控制做在了应用层
31、这也使得我们可以灵敏的选择不同的拥塞控制算法。目前我们在QUIC上支持常见的CUBIC,BBR等算法并实现了业务的自主配置根据不同业务针对恳求的不同VIP使用不同的拥塞控制算法。同时我们也支持针对同一个业务不同的用户的RTT动态的选择拥塞控制算法。另外我们也同CDN的拥塞控制算法团队亲密合作以优化拥塞控制算法在不同场景下的业务体验。业务可配的拥塞控制算法除了拥塞控制基于QUIC可以以在传输层针对特定的应用场景去不同的定制化。QUIC将TCP的特性带到了应用层这也使得在传输层上我们有更多的操作可能性。例如参照音视频领域一些常见的用法发送数据时发送冗余数据在一定丢包情况下QUIC传输层可以自动恢复
32、数据而不需要等待数据包的重传以降低音视频的卡顿率。这些基于TCP是很难做到的。业务假如需要重定义TCP的一些功能或者特性来提升业务体验QUIC将会有很大的发挥空间。支持QUIC私有协议STGW作为7层网关提供通用WEB协议卸载以及转发。因此支持QUIC的WEB协议如GQUIC,HTTP/3是我们的根本才能。但是如前面所讲QUIC作为通用传输层协议不仅仅应用于WEB任何私有协议都可以改造到QUIC下。使用QUIC握手协议之后客户端就可以根据自己的业务需求发送GQUIC,HTTP/3等WEB恳求或可以发送任意自己的私有协议。STGW基于NGINX的STREAM模块对其进展深度改造使得任意私有协议都
33、可以跑在QUIC协议之下。这也大大增加了QUIC的应用场景。所以不要觉得不是HTTP协议就用不了QUIC。只要你理解了QUIC的特性并且觉得QUIC的特性可以优化业务体验那么来试试QUIC吧。QUIC定制化SDK由于QUIC尚未标准化当前使用QUIC相对来讲门槛较高。客户端方面由于Google将其阅读器以Chromium工程开源出来其网络协议栈Cronet成为业界QUIC客户端的主要参考对象。但Cronet因为API支持有限代码复杂难以知足个性化需求等不合适直接用在我们的挪动客户端上。同时QUIC作为一个还在高速开展的协议效劳端以及客户端都在快速迭代需要保持严密的跟进。基于上述痛点和QUIC渐
34、渐流行的趋势我们提供比GoogleQUIC更定制化的TQUICSDK。TQUICSDK相比Cronet有体积更加轻量简单易用支持私有协议连接迁移等众多优点。目前TQUICSDK已应用于公司内部多个业务之中。总结本文综合介绍了STGW在大规模应用QUIC协议经过中做的一些优化以及成果。当前我们将QUIC协议栈与高性能网络框架做了深度交融并支持QUICWEB协议QUIC私有协议带外拥塞控制配置等大局部QUIC功能以及特性。知足QUIC大规模部署与运营。我们对QUIC协议栈0RTT1RTT小包高带宽等多场景做了大量的性能优化解决了QUIC严重消耗CPU资源的几个瓶颈。在小包恳求上性能根本可以到达HT
35、TPS的90%。针对RTT敏感的短连接业务我们大大提升了0RTT的比例某些场景可以做到100%0RTT。更全面的连接迁移解决了4层7层多集群、多机器、多进程和进程重启、重加载模块晋级等各种场景下的连接迁移问题。我们提供了定制化的QUICSDK以用于客户端知足定制化QUIC的各种特性。QUIC仍然有很多特性需要充分挖掘如QUIC本身基于UDP没有队头阻塞特性和QPACK编码在HTTP/3的HTTP头部上对队头阻塞的优化等。这些特性在弱网环境下对业务都会有较好的性能提升以及卡顿率降低十分是多路复用场景。目前我们也在结合业务积累更多的实际数据并期望在这块可以有更多的优化。QUIC和相关的HTTP/3等协议即将形成最终的标准我们也在不断跟进QUIC协议的演进。STGW将持续为自研业务以及腾讯云CLB客户提供QUIC的统一接入以及优化帮助业务更好的提升用户体验。期待已久的?有料程序员?系列直播终于来啦第一期嘉宾我们邀请到了专家、畅销书Robin茹炳晟工作娱乐两不误、玩转“研发效能的他将在本次直播中为我们共享他工作15年度的经历沉淀。2月3日本周三晚19:30【腾讯程序员】视频号首播腾讯技术工程