HTTP-2做错了什么?刚刚辉煌2年就要被弃用了!?

本文探讨了HTTP/2如何通过弃用管道化解决HTTP队头阻塞,但受限于TCP协议的队头阻塞问题。HTTP/3则转向基于UDP的QUIC技术,以应对TCP升级的难题。文章还涉及TCP三次握手的时长及其在网络延迟中的影响。
摘要由CSDN通过智能技术生成

所谓请求管道,就是在HTTP响应到达之前,可以将多条请求放入队列,当第一条HTTP请求通过网络流向服务器时,第二条和第三条请求也可以开始发送了。在高时延网络条件下,这样做可以降低网络的环回时间,提高性能。

image

但是,对于管道连接还是有一定的限制和要求的,其中一个比较关键的就是服务端必须按照与请求相同的顺序回送HTTP响应。

这也就意味着,如果一个响应返回发生了延迟,那么其后续的响应都会被延迟,直到队头的响应送达。这就是所谓的HTTP队头阻塞

但是HTTP队头阻塞的问题在HTTP/2中得到了有效的解决。HTTP/2废弃了管道化的方式,而是创新性的引入了帧、消息和数据流等概念。客户端和服务器可以把 HTTP 消息分解为互不依赖的帧,然后乱序发送,最后再在另一端把它们重新组合起来。

image

因为没有顺序了,所以就不需要阻塞了,就有效的解决了HTTP对队头阻塞的问题。

但是,HTTP/2仍然会存在TCP队头阻塞的问题,那是因为HTTP/2其实还是依赖TCP协议实现的。

TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包,这些数据包通过网络传输到了接收端,接收端再按照顺序将这些数据包组合成原始数据,这样就完成了数据传输。

但是如果其中的某一个数据包没有按照顺序到达,接收端会一直保持连接等待数据包返回,这时候就会阻塞后续请求。这就发生了TCP队头阻塞

HTTP/1.1的管道化持久连接也是使得同一个TCP链接可以被多个HTTP使用,但是HTTP/1.1中规定一个域名可以有6个TCP连接。而HTTP/2中,同一个域名只是用一个TCP连接。

所以,在HTTP/2中,TCP队头阻塞造成的影响会更大,因为HTTP/2的多路复用技术使得多个请求其实是基于同一个TCP连接的,那如果某一个请求造成了TCP队头阻塞,那么多个请求都会受到影响。

TCP握手时长

一提到TCP协议,大家最先想到的一定是他的三次握手与四次关闭的特性。

因为TCP是一种可靠通信协议,而这种可靠就是靠三次握手实现的,通过三次握手,TCP在传输过程中可以保证接收方收到的数据是完整,有序,无差错的。

但是,问题是三次握手是需要消耗时间的,这里插播一个关于网络延迟的概念。

网络延迟又称为 RTT(Round Trip Time)。他是指一个请求从客户端浏览器发送一个请求数据包到服务器,再从服务器得到响应数据包的这段时间。RTT 是反映网络性能的一个重要指标。

image

我们知道,TCP三次握手的过程客户端和服务器之间需要交互三次,那么也就是说需要消耗1.5 RTT。

另外,如果使用的是安全的HTTPS协议,就还需要使用TLS协议进行安全数据传输,这个过程又要消耗一个RTT(TLS不同版本的握手机制不同,这里按照最小的消耗来算)

那么也就是说,一个纯HTTP/2的连接,需要消耗1.5个RTT,如果是一个HTTPS连接,就需要消耗3-4个RTT。

而具体消耗的时长根据服务器和客户端之间的距离则不尽相同,如果比较近的话,消耗在100ms以内,对于用来说可能没什么感知,但是如果一个RTT的耗时达到300-400ms,那么,一次连接建立过程总耗时可能要达到一秒钟左右,这时候,用户就会明显的感知到网页加载很慢。

升级TCP是否可行?

基于上面我们提到的这些问题,很多人提出来说:既然TCP存在这些问题,并且我们也知道这些问题的存在,甚至解决方案也不难想到,为什么不能对协议本身做一次升级,解决这些问题呢?

其实,这就涉及到一个"协议僵化"的问题。

这样讲,我们在互联网上浏览数据的时候,数据的传输过程其实是极其复杂的。

我们知道的,想要在家里使用网络有几个前提,首先我们要通过运行商开通网络,并且需要使用路由器,而路由器就是网络传输过程中的一个中间设备。

中间设备是指插入在数据终端和信号转换设备之间,完成调制前或解调后某些附加功能的辅助设备。例如集线器、交换机和无线接入点、路由器、安全解调器、通信服务器等都是中间设备。

在我们看不到的地方,这种中间设备还有很多很多,一个网络需要经过无数个中间设备的转发才能到达终端用户。

如果TCP协议需要升级,那么意味着需要这些中间设备都能支持新的特性,我们知道路由器我们可以重新换一个,但是其他的那些中间设备呢?尤其是那些比较大型的设备呢?更换起来的成本是巨大的。

而且,除了中间设备之外,操作系统也是一个重要的因素,因为TCP协议需要通过操作系统内核来实现,而操作系统的更新也是非常滞后的。

所以,这种问题就被称之为"中间设备僵化",也是导致"协议僵化"的重要原因。这也是限制着TCP协议更新的一个重要原因。

所以,近些年来,由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用!

放弃TCP?

上面提到的这些问题的根本原因都是因为HTTP/2是基于TPC实现导致的,而TCP协议自身的升级又是很难实现的。

那么,剩下的解决办法就只有一条路,那就是放弃TCP协议。

放弃TCP的话,就又有两个新的选择,是使用其他已有的协议,还是重新创造一个协议呢?

看到这里,聪明的读者一定也想到了,创造新的协议一样会受到中间设备僵化的影响。近些年来,因为在互联网上部署遭遇很大的困难,创造新型传输层协议的努力基本上都失败了!

所以,想要升级新的HTTP协议,那么就只剩一条路可以走了,那就是基于已有的协议做一些改造和支持,UDP就是一个绝佳的选择了。

总结

因为HTTP/2底层是采用TCP协议实现的,虽然解决了HTTP队头阻塞的问题,但是对于TCP队头阻塞的问题却无能为力。

TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包,这些数据包通过网络传输到了接收端,接收端再按照顺序将这些数据包组合成原始数据,这样就完成了数据传输。

但是如果其中的某一个数据包没有按照顺序到达,接收端会一直保持连接等待数据包返回,这时候就会阻塞后续请求。这就发生了TCP队头阻塞

另外,TCP这种可靠传输是靠三次握手实现的,TCP三次握手的过程客户端和服务器之间需要交互三次,那么也就是说需要消耗1.5 RTT。如果是HTTPS那么消耗的RTT就更多。

而因为很多中间设备比较陈旧,更新换代成本巨大,这就导致TCP协议升级或者采用新的协议基本无法实现。

所以,HTTP/3选择了一种新的技术方案,那就是基于UDP做改造,这种技术叫做QUIC。

那么问题来了,HTTP/3是如何使用的UDP呢?做了哪些改造?如何保证连接的可靠性?UDP协议就没有僵化的问题了吗?下次继续解答…敬请期待…

作者:HollisChuang
原文链接:https://juejin.cn/post/6905925275888926734

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(资料价值较高,非无偿)

img

最后

由于文案过于长,在此就不一一介绍了,这份Java后端架构进阶笔记内容包括:Java集合,JVM、Java并发、微服务、SpringNetty与 RPC 、网络、日志 、Zookeeper 、Kafka 、RabbitMQ 、Hbase 、MongoDB、Cassandra 、Java基础、负载均衡、数据库、一致性算法、Java算法、数据结构、分布式缓存等等知识详解。

image

本知识体系适合于所有Java程序员学习,关于以上目录中的知识点都有详细的讲解及介绍,掌握该知识点的所有内容对你会有一个质的提升,其中也总结了很多面试过程中遇到的题目以及有对应的视频解析总结。

image

image

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》点击传送门即可获取!
mg-10qkSIFS-1711618338463)]

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》点击传送门即可获取!

  • 23
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值