带你读《2022技术人的百宝黑皮书》——HTTP3 RFC标准正式发布, QUIC会成为传输技术的新一代颠覆者吗?(1)

简介: 带你读《2022技术人的百宝黑皮书》——HTTP3 RFC标准正式发布, QUIC会成为传输技术的新一代颠覆者吗?(1)

HTTP3       RFC标准正式发布, QUIC会成为传输技术的新一代颠覆者吗?

image.png作者:XQUIC项目组

image.png出品:大淘宝技术

 

 

6月7日早晨(UTC时间Mon, 06 June 2022 20:09),HTTP/3 标准RFC9114IETF标准化工作组正式发布,由此QUIC第一代协议族6大基础标准(不变量/传输框架/拥塞控制和恢复/TLS/HTTP3/QPACK压缩)全部完成RFC化,开启一段新的网络时代。在淘宝,我们从18年开始尝试QUIC,到21~22年实现IETF QUIC及HTTP3标准的规模化应用,针对导购和交易核心链路场景拿到15~20%的网络耗时优化收益,同时沉淀自研的标准协议库实现XQUIC,并于年初开源。笔者想借由本文谈一谈对于网络7层模型中传输层的发展方向看法,以及对于底层技术发 展过程中可能碰到的困难及问题提出一点可行的建议。

 

开源仓库:https://github.com/alibaba/xquic

 

什么场景下适合选择QUIC作为TCP的替代品

 

今年我们听到大量的国内外声音,支持QUIC作为TCP的全面替代品,同时也针对QUIC成为网络传输技术新一代的颠覆者,提出支持性的观点。笔者作为XQUIC(一个包含QUIC和HTTP/3标准实现的协议库)项目的发起人和持续建设者,虽然立场相关,但是仍然从客观角度做一下分析。

 

最近一到两年也有很多研发者找到XQUIC项目,希望这个项目能一举解决大家碰到的所有网络问题;笔者的观点 是,这个世界上没有银弹,没有任何技术可以解决所有场景的问题,每一项技术都有它适合的场景和它的局限性。

 

那么到底什么场景下适合使用QUIC呢?答案是公网传输链路下,作为TCP的替代品,确实具备理想的优势。我们 知道公网的特性是链路长(反应在Round-Trip-Time上)、链路复杂性高(反应在各个节点可能存在的丢包/排队 及多流的竞争上)、以及手机端常见的无线信号波动带来的吞吐量抖动(体现在丢包/乱序上),这些问题的解法都是QUIC的强项领域。而在数据中心内部,在链路网络设备可控的情况下,同时追求低性能开销与低成本, TCP/DCTCP仍然表现不错,基于RDMA的一些DC内部解决方案同样也会具备优势。

 

从原理本质上来说,QUIC带来的最大的原理变化是:将传输层从内核态提到用户态,使得传输层可以与应用层进行高度配合,这在过去是无法可想的。这打开了传输层对于应用层传输需求和传输内容理解的天花板,使得传输行为与应用层需求高度匹配具备可行性。有人可能会说这有什么牛逼之处么?我们知道WebRTC在音视频场景下表现

 

 

 

出色,其中一部分关键原因就是其RTP的协议传输设计和工程实践,是充分结合音视频内容的传输需求和特性来设计的。因此具备用户态灵活演进的能力,并且能够贴合应用场景进行传输特性的设计,是非常重要的发展和探索方向。此外它基于UDP的多路复用、以及对Steam/Datagram分别支撑 可靠传输 与 非可靠/半可靠场景的传输能力设计,包括0-RTT降低握手延迟这些基础的协议特性带来的优势,就不再多说。

 

谈谈自研、标准与开源

 

对于任何一项好用的技术来说,能够先应用起来并且服务好业务需求,永远是第一步。对于任何具备深度和一定壁垒的技术(碰巧网络也属于),一般我们都会经历4个发展阶段:

 

image.pngimage.png第一阶段,用好这项技术,首先能用好并切实在业务场景下拿到收益。在当前这个鼓励开源的时代,第一步通过这个领域下已有的开源方案,来验证技术的可行性,并拿到一些初步收益来验证判断和观点,是最快的方式。 第二阶段,原理理解透彻,能够充分理解透彻这项技术的底层原理和机制,并针对业务需求做出调整。在这个阶段往往大家会有两条分叉路径:在已有开源项目上继续修改并发展自己的分支;或筹备自研。在这个阶段是选择前者还是后者,核心依据有2个:一方面 是对这项技术长期发展所能带来的红利,是否可以cover前期的投入;另一方面是,是否具备自研能力。

image.png第三阶段,具备自研能力,如果从2到3的判断能够满足自研的前提,就会走上自研道路。因此我们可以看到绝大部分一线互联网大厂,都会对战略性的技术投入方向进行自研,同样自研也能够带来技术壁垒的积累。这一步也是第四阶段的前置门槛。

image.png第四阶段,引领前沿发展,这个阶段往往又存在两种类型(或两者兼有):通过开源逐步成为事实标准,或者是参与到行业标准的制定当中。

 

笔者个人的观点是,每个阶段都需要投入不同的精力,对应着领域的持续深挖和人才的长期培养与团队建设。选择走到哪个阶段,没有绝对的好与坏,而是应该根据实际的诉求、可持续投入情况 和 发展的观点来判断。

 

另一方面,作为一个技术人,我们也应当充分尊重技术本身的深度,尊重愿意为了走到第三/四阶段,而投入精力、    克服重重困难的技术产品和团队,而非通过一些短期包装和走捷径的方式,避免最终在技术上逐渐空心化,影响技术大环境的发展。如何维护技术环境的一片净土,使得健康的种子能够具备萌芽的条件,这也是技术管理者需要考虑和反思的。

 

带你读《2022技术人的百宝黑皮书》——HTTP3 RFC标准正式发布, QUIC会成为传输技术的新一代颠覆者吗?(2)https://developer.aliyun.com/article/1340579?groupCode=taobaotech

相关文章
|
6天前
|
网络协议 网络安全 网络虚拟化
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算。通过这些术语的详细解释,帮助读者更好地理解和应用网络技术,应对数字化时代的挑战和机遇。
35 3
|
1月前
|
存储 前端开发 NoSQL
拿下奇怪的前端报错(四):1比特丢失导致的音视频播放时长无限增长-浅析http分片传输核心和一个坑点
在一个使用MongoDB GridFS存储文件的项目中,音频和视频文件在大部分设备上播放时长显示为无限,而单独播放则正常。经调查发现,问题源于HTTP Range请求的处理不当,导致最后一个字节未被正确返回。通过调整请求参数,使JavaScript/MongoDB的操作范围与HTTP Range一致,最终解决了这一问题。此案例强调了对HTTP协议深入理解及跨系统集成时注意细节的重要性。
|
3月前
|
存储 算法 数据安全/隐私保护
基于 HTTP Header 传输签名参数
基于 HTTP Header 传输签名参数
83 13
|
3月前
|
移动开发 JavaScript 前端开发
"解锁axios GET请求新姿势!揭秘如何将数组参数华丽变身,让你的HTTP请求在云端翩翩起舞,挑战技术极限!"
【8月更文挑战第20天】二维码在移动应用中无处不在。本文详述了在UniApp H5项目中实现二维码生成与扫描的方法。通过对比插件`uni-app-qrcode`和库`qrcode-generator`生成二维码,以及使用插件和HTML5 API进行扫描,帮助开发者挑选最佳方案。无论是即插即用的插件还是灵活的JavaScript实现,都能满足不同需求。
37 0
|
4月前
|
网络协议 Python
Python实现HTTP 传输的断点续传机制
使用Python `requests`库实现HTTP断点续传下载大文件,通过设置`Range`头部从上次中断的位置开始继续下载。示例代码展示了一个名为`resume_download`的函数,它接收URL、文件名和最后字节位置参数,以追加方式打开文件并逐块写入内容。要启用HTTP长连接,可添加`Connection: keep-alive`到请求头。
163 0
|
6月前
|
前端开发 安全 JavaScript
HTTP的系统登录页面,如何避免明文传输用户密码?
该文讨论了登录页面中密码安全传输的问题。当使用HTTP时,密码以明文形式传输,存在风险。在示例中,前端使用JavaScript的CryptoJS库和当前时间戳作为动态加密key对密码进行DES加密。后端接收到密文后,利用相同的时间戳解密。为了增强安全性,文章还建议使用RSA等非对称加密算法。
1068 7
|
5月前
|
编解码 自然语言处理 算法
技术心得:前端学HTTP之字符集
技术心得:前端学HTTP之字符集
38 0
|
5月前
|
缓存 开发框架 网络协议
必知的技术知识:HTTP协议和SOCKS5协议
必知的技术知识:HTTP协议和SOCKS5协议
|
5月前
|
缓存 网络协议 应用服务中间件
深入理解 web 协议(一)- http 包体传输
深入理解 web 协议(一)- http 包体传输
|
5月前
|
缓存 安全 网络协议