找公司网站建设3,wordpress预约,如何在百度上做公司做网站,wordpress阿里云推送QUIC取代了TCP成为HTTP3的基础传输协议#xff0c;不是因为QUIC能够取代TCP的所有应用场景#xff0c;而是因为QUIC更适合HTTP的请求/响应业务模型。原文: QUIC Is Not a TCP Replacement TCP新规范(RFC 9293)的发布是网络界的一件大事#xff0c;值得围绕这一主题发表第二篇… QUIC取代了TCP成为HTTP3的基础传输协议不是因为QUIC能够取代TCP的所有应用场景而是因为QUIC更适合HTTP的请求/响应业务模型。原文: QUIC Is Not a TCP Replacement TCP新规范(RFC 9293)的发布是网络界的一件大事值得围绕这一主题发表第二篇文章(第一篇: 下一代TCP[1])本文我们将围绕QUIC和TCP的比较展开。 我们在上一篇关于TCP的过去和未来的文章中谈到了QUIC可能取代TCP的可能性。本文我们想说的是实际上QUIC解决的问题与TCP解决的问题有所不同因此不应该被视为TCP的替代品。对于某些(甚至大多数)应用来说QUIC很可能成为默认传输方式但这是因为TCP被用到了原本就不适合的场景。接下来看看为什么这么说。 早在1995年Larry和我编写《计算机网络: 一种系统方法》第一版的时候当我们编写传输协议那一章时将其命名为端到端协议[2]。那时候互联网上只有两种值得注意的传输协议UDP和TCP所以我们分别给它们写了独立的章节。由于那本书旨在教授网络原理而不仅仅是RFC的内容因此我们将这两个部分框定为两种不同的通信范式: 一个是简单的多路复用服务(以UDP为例)一个是可靠字节流(TCP)。但还有第三种范式即远程过程调用(Remote Procedure Call[3], RPC)Larry认为有必要介绍这种范式但并没有真正知名的互联网协议示例实现了该范式。当时我们用来说明RPC的例子现在看来很奇怪是SunRPC[4]以及Larry当时研究x-kernel[5]时自己写的一个例子。不过现在有许多基于IP的RPC实现gRPC[6]就是最著名的例子之一。 当大多数网络书籍只涉及TCP和UDP时为什么我们觉得需要完整的章节来讨论RPC 呢首先RPC在当时是分布式系统社区的关键研究领域之一1984年Nelson和Birrell的论文[7]刺激了一代与RPC相关的项目。在我们看来可靠字节流并不是RPC的正确抽象。RPC的核心是请求/应答范式。客户端发送一堆参数到服务器服务器用这些参数做一些计算然后返回计算结果。是的可靠字节流可能有助于通过网络正确获得所有参数和结果但对于RPC来说还有更多东西。先不考虑通过网络传输序列化参数的问题RPC实际上并不是传输字节流而是发送消息并获得对应的响应。有点像数据报文服务(如UDP或IP提供的)但它需要的不仅仅是不可靠的数据报文传递而是需要处理丢包、无序和重复的消息需要一个标识符空间来匹配请求和响应还需要支持消息的分片和重组以及其他一些需求。可靠字节流可以防止乱序传递这也是RPC所需要的。这可能是为什么在20世纪八九十年代出现了这么多RPC框架的原因因为分布式系统需要RPC机制而标准TCP/IP协议套件没有任何现成的东西。(RFC 1045实际上定义了一种实验性的面向RPC的传输但从未流行起来。)当时TCP/IP是否会像今天这样占据主导地位也并不明显因此一些RPC框架(例如DCE)被设计成独立于底层网络协议。 TCP/IP协议栈中缺少对RPC的支持从而为QUIC奠定了基础。当HTTP在20世纪90年代初出现时并没有试图解决RPC问题而是试图解决信息共享问题但它确实实现了请求/响应语义。HTTP的设计者由于缺乏明显更好的选择决定在TCP上运行HTTP由于每个GET都使用一个新连接在早期版本中性能非常差。为了提高性能引入了对HTTP的各种优化如流水线(pipelining)、持久化连接以及并行连接但是TCP的可靠字节流模型从来都不是完美适配HTTP的。随着传输层安全(TLS)的引入又叠加了一组加密信息的双向交互HTTP的需求和TCP的支持之间的不匹配变得越来越明显。Jim Roskind在2012年的QUIC设计文档中清晰的解释了这一点行首阻塞、拥塞响应不佳以及TLS引入的额外RTT都被认为是在TCP上运行HTTP的固有问题。 简单介绍一下这里发生的事情: 互联网的窄腰(narrow waist)最初只是IP协议旨在支持上面的各种协议。但不知何故腰也开始包括TCP和UDP这两者是唯一可用的传输协议。如果只想要数据报文服务可以使用UDP。如果需要任何可靠传输TCP就是答案。如果需要的东西既不能完全映射到不可靠的数据报文也不能完全映射到可靠的字节流那么就不走运了。但是要让TCP支持这么多上层协议要求就太高了。 QUIC正在做很多工作其定义跨越三个RFC涵盖了基本协议(RFC 9000)、TLS的使用(9001[8])和拥塞控制机制(9002[9])。但其核心是互联网缺失的第三种范式: RPC的实现。如果需要真正的可靠字节流(例如下载几个G的操作系统更新时)那么TCP确实是为这项工作而设计的但是HTTP(S)更像RPC而不是可靠字节流。可以这样理解QUIC它最终将RPC范式交付给了互联网协议族而这肯定会使运行在HTTP(S)上的应用程序受益特别是包括gRPC以及大家广为依赖的RESTful API。 之前的文章[10]提到QUIC时我们认为这是一个很好的案例研究可以在需求变得更清晰时重新考虑系统分层要点是TCP(可靠字节流)满足了一组需求并且其拥塞控制算法[11]持续演进并为这些需求服务。QUIC实际上满足了一组不同的需求。由于HTTP在今天的互联网处于绝对中心地位(确实有人争论它是否正在成为新的窄腰)QUIC可能成为主要传输协议(不是因为取代TCP而是因为满足了运行其上的主要应用程序的需求)。 你好我是俞凡在Motorola做过研发现在在Mavenir做技术工作对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣平时喜欢阅读、思考相信持续学习、终身成长欢迎一起交流学习。 微信公众号DeepNoMind 参考资料 [1] 下一代TCP: https://www.mdnice.com/writing/6c05ab8e49954207a5f583268b6c4e58 [2] 端到端协议: https://book.systemsapproach.org/e2e.html [3] Remote Procedure Call: https://book.systemsapproach.org/e2e/rpc.html [4] SunRPC: https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_Procedure_Call [5] x-kernel: https://dl.acm.org/doi/10.1145/74850.74860 [6] gRPC: https://grpc.io [7] Implementing remote procedure calls: https://dl.acm.org/doi/10.1145/2080.357392 [8] RFC 9001: https://datatracker.ietf.org/doc/html/rfc9001 [9] RFC 9002: https://datatracker.ietf.org/doc/html/rfc9002 [10] The Importance of Thinking Across Layer Boundaries: https://systemsapproach.substack.com/p/the-importance-of-thinking-across [11] TCP拥塞控制: https://mp.weixin.qq.com/mp/appmsgalbum?__bizMzU2MTgxODgwNAactiongetalbumalbum_id2460055314927255553#wechat_redirect - END - 本文由 mdnice 多平台发布
