带你读《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

相关文章
|
10天前
|
网络协议 Python
Python实现HTTP 传输的断点续传机制
使用Python `requests`库实现HTTP断点续传下载大文件,通过设置`Range`头部从上次中断的位置开始继续下载。示例代码展示了一个名为`resume_download`的函数,它接收URL、文件名和最后字节位置参数,以追加方式打开文件并逐块写入内容。要启用HTTP长连接,可添加`Connection: keep-alive`到请求头。
|
21天前
|
编解码 自然语言处理 算法
技术心得:前端学HTTP之字符集
技术心得:前端学HTTP之字符集
14 0
|
21天前
|
缓存 开发框架 网络协议
必知的技术知识:HTTP协议和SOCKS5协议
必知的技术知识:HTTP协议和SOCKS5协议
|
2月前
|
前端开发 安全 JavaScript
HTTP的系统登录页面,如何避免明文传输用户密码?
该文讨论了登录页面中密码安全传输的问题。当使用HTTP时,密码以明文形式传输,存在风险。在示例中,前端使用JavaScript的CryptoJS库和当前时间戳作为动态加密key对密码进行DES加密。后端接收到密文后,利用相同的时间戳解密。为了增强安全性,文章还建议使用RSA等非对称加密算法。
130 7
|
28天前
|
缓存 网络协议 应用服务中间件
深入理解 web 协议(一)- http 包体传输
深入理解 web 协议(一)- http 包体传输
|
1月前
|
缓存 安全 网络协议
|
2月前
|
Go
深度探讨 Golang 中并发发送 HTTP 请求的最佳技术
深度探讨 Golang 中并发发送 HTTP 请求的最佳技术
|
2月前
|
前端开发 API UED
AngularJS的$http服务:深入解析与进行HTTP请求的技术实践
【4月更文挑战第28天】AngularJS的$http服务是核心组件,用于发起HTTP请求与服务器通信。$http服务简化了通信过程,通过深入理解和实践,能构建高效、可靠的前端应用。
|
2月前
|
存储 缓存 开发框架
Flutter的网络请求:使用Dart进行HTTP请求的技术详解
【4月更文挑战第26天】了解Flutter网络请求,本文详述使用Dart进行HTTP请求
|
2月前
|
安全 网络协议 算法
【计算机网络】http协议的原理与应用,https是如何保证安全传输的
【计算机网络】http协议的原理与应用,https是如何保证安全传输的