多路复用:TCP 与 HTTP2

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

你可以同时使用两者吗?当然可以! (计算机)科学来了……

转向 HTTP/2 的一大性能优势来自其对多路复用的广泛使用。对于外行来说,多路复用是为多个 HTTP 请求和响应重用单个 TCP 连接的做法。看,在过去 (HTTP/1),请求/响应对需要它自己的特殊 TCP 连接。这最终导致对浏览器强加的每个主机的 TCP 连接限制,并且由于如今的网站平均由 86 个或更多单独的对象组成,每个对象都需要自己的请求/响应,从而减慢了传输速度。 HTTP/1.1 让我们使用“持久”HTTP 连接,这是多路复用(连接可以重用)的出现,但受限于 HTTP 本身的同步(顺序)要求。所以你会打开 6 或 7 或 8 个连接,然后重新使用它们来获取这 80 多个对象。

有了 HTTP/2,情况就不再如此了。只需要一个 TCP 连接,因为 HTTP/2 利用多路复用 并允许异步(并行)请求。许多请求/响应对可以通过该单个连接并行传输,从而实现更快的传输和更少的网络开销。因为众所周知,TCP 的三向握手和窗口机制(慢启动,有人吗?)可能会拖累应用程序性能(从字面上看)。

所以问题是,既然我们已经在等式的客户端获得了 HTTP/2 及其多路复用功能,我们是否仍然可以在等式的服务器端看到 TCP 多路复用的好处?

是的。绝对地。

这样做的原因是它是可操作的,并且与非常传统的转换直接相关,每当对 HTTP 等基础协议进行重大“升级”时,这种转换就必须发生。请记住,IPv6 已经可用并准备就绪十年了,但我们仍未完全过渡。当您考虑 HTTP/2 的采用曲线可能会持续多长时间时,想一想。

部分原因是虽然许多浏览器已经支持 HTTP/2,但很少有组织拥有支持 HTTP/2 的 Web 或应用程序服务器。这意味着虽然它们可以在客户端支持 HTTP,但不能在服务器端支持。假设服务器端 可以 支持 HTTP/2,那么组织可能会选择延迟迁移的业务和架构原因——包括许可、支持,以及升级中断的成本。

所以 HTTP2 最终成为了禁区。组织不会在客户端迁移到 HTTP/2,即使它具有显着的性能优势,尤其是对于他们越来越多的移动应用程序用户群体来说,因为他们不能在服务器端支持它。但是存在 HTTP2 网关(能够在客户端支持 HTTP/2 并在服务器端支持 HTTP/1 的代理)。因此,这是一种在客户端迁移到 HTTP/2 而无需在服务器端“全力以赴”的可行且破坏性较小的方法。

但这当然意味着您只能获得与 HTTP/2 相关的多路复用的一半好处。当然,除非您在服务器端使用 TCP 多路复用。

多路复用为 HTTP/2 的客户端提供了什么,负载均衡器和代理中的 TCP 多路复用功能为 HTTP/1 的服务器提供了什么。这不是一项新功能。 很长一段时间以来,它一直是一种核心的 TCP 优化技术, 它被大量用于提高性能和减少 Web/应用程序服务器的负载(这意味着它们具有更大的容量,更有效地运行,并提高任何规模经济)应用程序)。

在服务器端,TCP 多路复用打开(并维护)到它正在虚拟化的每个 Web/应用程序服务器的 TCP 连接。当请求来自客户端时,负载均衡器或代理通过现有(打开的)连接将请求发送到适当的应用程序实例。这意味着应用程序的性能随着打开和增加 TCP 连接所需的时间而提高。这也意味着中介(负载均衡器或代理)可以接受多个 HTTP 请求并有效地并行处理它们( 我们称之为内容切换 )。在 HTTP/1 的世界里,这意味着如果客户端打开 6 个 TCP 连接,然后发送 6 个不同的 HTTP 请求,中介可以通过现有的 TCP 连接将所有 6 个发送到适当的 web/app 服务器,从而加快响​​应速度并提高应用程序的整体性能。

HTTP/2 也是如此。不同之处在于,对于 HTTP/2,这 6 个不同的请求是通过同一个 TCP 连接传入的。但他们仍在进来。这意味着支持 TCP 多路复用的负载平衡器(或代理)可以将这些请求并行化到 Web/应用程序服务器,并实现对客户端来说(以一种好的方式)明显的性能提升。

诚然,对于大多数应用程序而言,这种增益可能会在不到一秒的时间内测得,但这意味着用户接收数据的速度更快。当用户希望在 3 秒内得到响应(如整个页面)时。或者 5,具体取决于您查看的是谁的研究。用户界面设计之父 Jakob Nielsen 指出,用户会注意到 1 秒的延迟 。那是在 1993 年。我很确定我 7 岁的孩子注意到了亚秒级的延迟——并且对此感到沮丧。

关键是,您可以减少交付过程(接收请求和发送响应)的每一微秒都将改善与用户(包括消费者和企业)的互动。 HTTP/2 的有效作用是在等式的 客户端 提供与 TCP 多路复用在 服务器端提供的类似的 TCP 优化。 因此,同时使用 HTTP/2 和基于网络的 TCP 多路复用将提供比单独使用其中任何一个更大的性能增益。如果您将 HTTP/2 和 TCP 多路复用与内容切换相结合,那么……您将收获更多。

所以是的,继续吧。在应用程序和客户端进行多路复用并获得性能优势。