Java 面试题:HTTP版本演变--xunznux

2024-08-30 04:04

本文主要是介绍Java 面试题:HTTP版本演变--xunznux,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

  • HTTP版本演变
    • HTTP/0.9
    • HTTP/1.0
    • HTTP/1.1
      • 新引入:
      • 问题:
      • 长连接是什么:
      • 管道网络传输:
      • 队头阻塞是什么?
      • 解决http队头阻塞的方法:
      • HTTP1.1常见性能问题
      • 为解决HTTP1.1性能问题而提出的常见优化手段
    • HTTP/2
      • 1、兼容HTTP1.1
      • 2、头部压缩
      • 3、二进制帧
      • 4、Stream并发传输(多路复用)
      • 5、服务器主动推送(存在TCP层的队头阻塞)
    • HTTP/3(解决TCP队头阻塞)
      • HTTP/3 基于 QUIC 协议,具有以下特点:
      • HTTP/2的缺点
      • QUIC协议的特点(将UDP变成可靠的)
      • 无队头阻塞
      • 更快的连接建立
        • 为什么QUIC只需要一个RTT就可以完成建立连接与密钥协商
      • 连接迁移

HTTP版本演变

目前为止,HTTP 常见的版本有 HTTP/1.1,HTTP/2.0,HTTP/3.0,不同版本的 HTTP 特性是不一样的。

HTTP/0.9

HTTP/0.9 是最早的HTTP版本,在1991年就已经发布,只支持GET方法,也没有请求头,服务器只能返回 HTML格式的内容。

HTTP/1.0

HTTP/1.0 是HTTTP 协议的第一个正式版本,主要具有以下特性:

  • 引入了请求头和响应头,支持多种请求方法和状态码
  • 不支持持久连接,每次请求都需要建立新的连接

HTTP/1.1

新引入:

  • 引入长连接:只要客户端和服务器任意⼀端没有明确提出断开连接,则保持TCP连接状态。
  • 管道网络传输,管道化技术:同一个 TCP 连接里面,客户端可以发起多个请求,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去。
  • 管道解决了请求的队头阻塞问题,但是没有解决响应的队头阻塞。

问题:

  • 头部冗余:每个请求和响应都需要带有一定的头部信息,每次互相发送相同的首部造成的浪费较多;
  • 服务器是按请求的顺序响应的,如果服务器响应慢,会招致客户端一直请求不到数据,也就是响应队头阻塞;
  • 没有请求优先级控制;
  • 请求只能从客户端开始,服务器只能被动响应。

长连接是什么:

持久连接,只要客户端和服务器任意⼀端没有明确提出断开连接,则保持TCP连接状态。

管道网络传输:

在同一个 TCP 连接里面,客户端可以发起多个请求,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,可以减少整体的响应时间。
客户端需要请求两个资源。以前的做法是,在同一个 TCP 连接里面,先发送 A请求,然后等待服务器做出回应收到后再发出 B 请求。那么,管道机制则是允许浏览器同时发出 A请求和 B 请求。
但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应,如果服务端在处理 A 请求时耗时比较长,那么后续的请求的处理都会被阻塞住,这称为「队头堵塞」。所以,HTTP/1.1 管道解决了请求的队头阻塞,但是没有解决响应的队头阻塞。
HTTP/1.1 管道化技术不是默认开启,而且浏览器基本都没有支持。

队头阻塞是什么?

当顺序发送的请求序列中的一个请求因为某种原因被阻塞时,在后面排队的所有请求也一同被阻塞了,会招致客户端一直请求不到数据,这也就是「队头阻塞」。
http队首阻塞:简单理解就是需要排队,队首的事情没有处理完的时候,后面的人都要等着。
队头阻塞”与短连接和长连接无关,而是由 HTTP 基本的“请求 - 应答”机制所导致的。因为 HTTP 规定报文必须是“一发一收”,这就形成了一个先进先出的“串行”队列。
而http的队首阻塞,在管道化和非管道化下,表现是不同的。
http1.0的队首阻塞 ( 非管道化下 ) :对于同一个tcp连接,所有的http1.0请求放入队列中,只有前一个请求的响应收到了,然后才能发送下一个请求,由下图可以看到,如果前一个请求卡着了,那么队列中后续的http就会阻塞。可见,http1.0的队首组阻塞在客户端。
http1.1的队首阻塞 ( 管道化下 ):对于同一个tcp连接,开启管道化后,http1.1允许一次发送多个http1.1请求,也就是说,不必等前一个响应收到,就可以发送下一个请求,这样就解决了http1.0的客户端的队首阻塞。但是,http1.1规定,服务器端的响应的发送要根据请求被接收的顺序排队,也就是说,先接收到的请求需要先响应回来。这样造成的问题是,如果最先收到的请求的处理时间长的话,响应生成也慢,就会阻塞已经生成了的响应的发送。也会造成队首阻塞,响应的阻塞。可见,应用管道化技术后,http1.1的队首阻塞发生在服务器端。
因此说,HTTP/1.1 管道解决了请求的队头阻塞,但是没有解决响应的队头阻塞。

解决http队头阻塞的方法:

1、并发TCP连接(浏览器一个域名采用6-8个TCP连接,并发HTTP请求),可以理解成增加了任务队列,不会导致一个任务阻塞了该任务队列的其他任务。
2、域名分片(多个域名,可以建立更多的TCP连接,从而提高HTTP请求的并发)可以在一个域名下分出多个二级域名出来,而它们最终指向的还是同一个服务器,这样子的话就可以并发处理的任务队列更多,也更好的解决了队头阻塞的问题。
3、HTTP2方式(多路复用特性)

HTTP1.1常见性能问题

  • 延迟难以下降,虽然现在网络的「带宽」相比以前变多了,但是延迟降到一定幅度后,就很难再下降了,说白了就是到达了延迟的下限;
  • 并发连接有限,谷歌浏览器最大并发连接数是6个,而且每一个连接都要经过 TCP 和 TLS握手耗时,以及TCP 慢启动过程给流量带来的影响;
  • 队头阻塞问题,同一连接只能在完成一个 HTTP 事务(请求和响应)后,才能处理下一个事务;HTTP 头部巨大且重复,由于 HTTP 协议是无状态的,每一个请求都得携带 HTTP 头部,特别是对于有携带cookie 的头部,而 cookie 的大小通常很大;
  • 不支持服务器推送消息,因此当客户端需要获取通知时,只能通过定时器不断地拉取消息,这无疑浪费大量了带宽和服务器资源。

为解决HTTP1.1性能问题而提出的常见优化手段

  • 将多张小图合并成一张大图供浏览器 JavaScript来切割使用,这样可以将多个请求合并成一个请求,但是带来了新的问题,当某张小图片更新了,那么需要重新请求大图片,浪费了大量的网络带宽;
  • 将图片的二进制数据通过 base64 编码后,把编码数据嵌入到 HTML或 CSS 文件中,以此来减少网络请求次数;
  • 将多个体积较小的 JavaScript 文件使用 webpack 等工具打包成一个体积更大的 JavaScript 文件,以一个请求替代了很多个请求,但是带来的问题,当某个 js 文件变化了,需要重新请求同一个包里的所有 js 文件;
  • 将同一个页面的资源分散到不同域名,提升并发连接上限,因为浏览器通常对同一域名的 HTTP 连接最大只能是6个。
    总的来说:
  • 将多个小资源合并为一个大资源,从而将多个请求合并为一个请求,减少请求次数,带来的问题是其中一个资源变化却需要更新所有资源,占用了带宽;
  • 将同一个页面的资源分散到不同的域名,提升并发连接上限,因为浏览器对同一域名的 HTTP 连接最大只能是6个。

HTTP/2

HTTP/2 协议是基于 HTTPS 的, 所以HTTP/2的安全性也是有保障的。
HTTP2协议还包括:流控制、流状态、依赖关系等。
在这里插入图片描述

1、兼容HTTP1.1

  1. 第一点,HTTP/2 没有在 URI里引入新的协议名,仍然用「http://」表示明文协议,用「https://」表示加密协议,于是只需要浏览器和服务器在背后自动升级协议,这样可以让用户意识不到协议的升级,很好的实现了协议的平滑升级。
  2. 第二点,只在应用层做了改变,还是基于 TCP 协议传输,应用层方面为了保持功能上的兼容,HTTP/2 把 HTTP 分解成了「语义」和「语法」两个部分,「语义」层不做改动,与 HTTP/1.1 完全一致,比如请求方法、状态码、头字段等规则保留不变。但是,HTTP/2 在「语法」层面做了很多改造,基本改变了 HTTP 报文的传输格式。

2、头部压缩

HTTP/2 使用 HPACK 压缩算法对请求和响应头部进行压缩,减少了传输的头部数据量,降低了延迟。
HPACK算法包含三个组成部分:
(i)静态字典
(ii)动态字典
(iii)Huffman编码(压缩算法)
客户端和服务器都会建立和维护【字典】,用长度较小的索引号表示重复的字符串,再用 Huffman 编码压缩数据。
为什么要压缩头部?

  1. 含很多固定的字段,比如Cookie、User Agent、Accept等,这些字段加起来也高达几百字节甚至上千字节,所以有必要压缩;
  2. 大量的请求和响应的报文里有很多字段值都是重复的,这样会使得大量带宽被这些冗余的数据占用了,所以有必要避免重复性;
  3. 字段是 ASCI 编码的,虽然易于人类观察,但效率低,所以有必要改成二进制编码。

3、二进制帧

二进制帧: HTTP/2 将数据分割成二进制帧进行传输,分为头信息帧(Headers Frame)和数据帧(Data Frame),增加了数据传输的效率。
HTTP2更厉害的地方在于: 将HTTP1的文本格式改成二进制格式传输数据,极大提高了HTTP传输效率,而且二进
制数据使用位运算能高效解析。
暂时无法在飞书文档外展示此内容

4、Stream并发传输(多路复用)

引出了 Stream 概念,多个 Stream 复用在一条 TCP 连接,针对不同的 HTTP 请求用独一无二的Stream ID 来区分,接收端可以通过 Stream lD 有序组装成 HTTP 消息,不同 Stream 的帧是可以乱序发送的,因此可以并发不同的 Stream ,也就是 HTTP/2 可以并行交错地发送请求和响应。
流标识符:用来标识该Frame属于哪个Stream。接收方可以根据这个信息从乱序的帧里找到相同Stream ID的帧,从而有序组装信息。

  • HTTP1.1 基于请求-响应模型。同一个连接中,HTTP完成一个事务(请求与响应),才能处理下一个事务。即:再发出请求等待响应的过程中是没办法做其他事情的,会造成【队头阻塞】问题。
  • HTTP2通过Stream这个设计(多个Stream复用一条TCP连接,达到并发的效果),解决了【队头阻塞】的问题,提高了HTTP传输的吞吐量。

在这里插入图片描述

  • 1个 TCP 连接包含一个或者多个 Stream,Stream 是 HTTP/2 并发的关键技术;
  • Stream 里可以包含1个或多个 Message,Message 对应 HTTP/1 中的请求或响应,由 HTTP 头部和包体构成,
  • Message 里包含一条或者多个 Frame,Frame是 HTTP/2 最小单位,以二进制压缩格式存放 HTTP/1 中的内容(头部和包体)。包括头信息帧(Headers Frame)和数据帧(Data Frame)。
  • HTTP消息可以由多个Frame构成。
  • 一个Frame可以由多个TCP报文构成。

在HTTP2连接上,不同Stream的帧可以乱序发送(因此可以并发不同的Stream),接收端可以通过Stream ID 有序组装HTTP消息。

  • HTTP/2 通过 Stream 实现的并发,比 HTTP/1.1 通过 TCP 连接实现并发要厉害的多,因为当 HTTP/2 实现 100 个并发 Stream 时,只需要建立一次 TCP 连接,而 HTTP/1.1 需要建立 100 个 TCP 连接,每个 TCP 连接都要经过TCP 握手、慢启动以及 TLS 握手过程,这些都是很耗时的。
  • HTTP/2 还可以对每个 Stream 设置不同优先级,帧头中的「标志位」可以设置优先级,比如客户端访问HTML CSS 和图片资源时,希望服务器先传递 HTML/CSS,再传图片,那么就可以通过设置 Stream 的优先级来实现,以此提高用户体验。

5、服务器主动推送(存在TCP层的队头阻塞)

在 HTTP/2 中,服务器可以对客户端的一个请求发送多个响应,即服务器可以额外的向客户端推送资源,而无需客户端明确的请求。
但是 HTTP/2 仍然存在着队头阻塞的问题,只不过问题是在传输层。
HTTP/2 是基于 TCP 协议来传输数据的,TCP 是字节流协议,TCP 层必须保证收到的字节数据是完整且连续的,这样内核才会将缓冲区里的数据返回给 HTTP 应用,那么当「前1个字节数据」没有到达时,后收到的字节数据只能存放在内核缓冲区里,只有等到这1个字节数据到达时,HTTP/2 应用层才能从内核中拿到数据,这就是 HTTP/2队头阻塞问题。
HTTP1.1不支持服务器主动推送资源给客户端,都是由客户端向服务器发起请求后,才能获取到服务器响应的资
源。在HTTP2中,客户端在访问HTML时,服务器可以直接主动推送CSS⽂件,减少了消息传递的次数。

客户端发起的请求,必须使用的是奇数号 Stream,服务器主动的推送,使用的是偶数号 Stream。服务器在推送资源时,会通过 PUSH_PROMISE 帧传输 HTTP 头部,并通过帧中的 Promised Stream ID 字段告知客户端,接下来会在哪个偶数号 Stream 中发送包体。
暂时无法在飞书文档外展示此内容

HTTP/3(解决TCP队头阻塞)

HTTP/2 队头阻塞的问题是因为 TCP,所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP!
在这里插入图片描述

HTTP/3 基于 QUIC 协议,具有以下特点:

  • 零 RTT 连接建立: QUIC(Quick UDP Internet Connections)允许在首次连接时进行零往返时间(Zero Round Trip Time)连接建立,从而减少了连接延迟,加快了页面加载速度。
  • 无队头阻塞: QUIC 使用 UDP 协议来传输数据。一个连接上的多个stream之间没有依赖,如果一个stream丢了一个UDP包,不会影响后面的stream,不存在TCP 队头阻塞。
  • 连接迁移: OUIC允许在网络切换(如从 Wi-Fi到移动网络)时,将连接迁移到新的 IP 地址,从而减少连接的中断时间。
  • 向前纠错机制: 每个数据包除了它本身的内容之外,还包括了部分其他数据包的数据,因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。向前纠错牺牲了每个数据包可以发送数据的上限,但是减少了因为丢包导致的数据重传。

HTTP/2的缺点

HTTP2 协议是基于TCP实现的,所以存在三个缺陷:

  1. 队头阻塞:TCP 是字节流协议,TCP 层必须保证收到的字节数据是完整且有序的,如果序列号较低的 TCP 段在网络传输中丢失了,即使序列号较高的 TCP 段已经被接收了,应用层也无法从内核中读取到这部分数据,从HTTP 视角看,就是请求被阻塞了。
  2. TCP与TLS的握手时延迟:发出HTTP请求时,需要经过TCP三次握手和TLS四次握手(TLS 1.2是4次,TLS 1.3是三次,开启Fast Open后可以和TCP同时进行),共计3 RTT的时延才能发出请求数据。
  3. 网络迁移需要重新连接:一个TCP连接由【源IP地址,源端口,目标IP地址,目标端口】确定。若IP地址或端口发生变暖,这需要重新进行连接。这不利于移动设备切换网络的场景。要解决该问题,就要修改传输层协议。在HTTP3中传输层协议修改为了 UDP。

QUIC协议的特点(将UDP变成可靠的)

UDP是一个简单的、不可靠的传输协议,而且UDP包之间是无序的,也没有依赖关系。UDP也不需要连接。
HTTP3基于UDP协议在应用层实现了 QUIC 协议,它有类似TCP的连接管理、拥塞窗口、流量控制的网络特性,相当于将不可靠的UDP协议变成可靠的了,无需担心数据包丢包的问题。

无队头阻塞

  • HTTP2:只要某个流中的数据包丢失了,其他流也会因此受影响。
  • HTTP3:流与流(Stream)之间不影响

更快的连接建立

对于 HTTP/1 和 HTTP/2 协议,TCP 和 TLS 是分层的,分别属于内核实现的传输层、openssl库实现的表示层,因此它们难以合并在一起,需要分批次来握手,先 TCP 握手,再 TLS 握手。
HTTP/3 在传输数据前虽然需要 QUIC协议握手,这个握手过程只需要1RTT,握手的目的是为确认双方的「连接ID」,连接迁移就是基于连接 ID 实现的。
但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层,而是QUIC 内部包含了 TLS,它在自己的帧会携带 TLS 里的“记录”、再加上 QUIC 使用的是 TLS1.3,因此仅需1个 RTT 就可以「同时」完成建立连接与密钥协商,甚至在第二次连接的时候,应用数据包可以和 QUIC握手信息(连接信息+TLS 信息)一起发送,达到 0-RTT 的效果。

为什么QUIC只需要一个RTT就可以完成建立连接与密钥协商

首先,TCP的三次握手需要 1个RTT 来完成。
三次握手过程:

  1. 客户端发送SYN(Synchronize)报文:客户端向服务器发送一个SYN报文,用于请求建立连接。这是握手的第一步。
  2. 服务器响应SYN-ACK:服务器收到SYN报文后,回应一个SYN-ACK报文,表示同意建立连接,并确认收到了客户端的SYN。这是握手的第二步。
  3. 客户端发送ACK:客户端收到SYN-ACK后,发送一个ACK(Acknowledgment)报文,确认收到了服务器的响应。这是握手的第三步,完成了连接的建立。
    时延解释:
  • 发送SYN并接收到SYN-ACK:这一步耗费1个RTT(客户端到服务器再返回客户端)。
  • 发送ACK:这一步通常不需要额外的RTT,因为在发送ACK后,客户端和服务器都已经可以开始发送数据了。
    因此,TCP三次握手只需要 1个RTT 来完成连接的建立。

总结:而QUIC使用的是TLS 1.3 只需要三次握手,与TCP相同,因此如果它与TCP一起传输数据,可以看作只需要进行TCP连接,也就是只需要 1个RTT。

连接迁移

基于 TCP 传输协议的 HTTP 协议,由于是通过四元组(源 IP、源端口、目的IP、目的端口)确定一条 TCP 连接,那么当移动设备的网络从 4G 切换到 WIFI 时,意味着 IP 地址变化了,那么就必须要断开连接,然后重新建立连接,而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延,以及 TCP 慢启动的减速过程,给用户的感觉就是网络突然卡顿了一下,因此连接的迁移成本是很高的。

而 QUIC 协议没有用四元组的方式来“绑定”连接,而是通过连接 ID来标记通信的两个端点,客户端和服务器可以各自选择一组 ID 来标记自己,因此即使移动设备的网络变化后,导致IP 地址变化了,只要仍保有上下文信息(比如连接 ID、TLS 密钥等),就可以“无缝”地复用原连接,消除重连的成本,没有丝毫卡顿感,达到了连接迁移的功能。

HTTP/3 同 HTTP/2 一样采用二进制帧的结构,不同的地方在于 HTTP/2 的二进制帧里需要定义 Stream,而HTTP/3 自身不需要再定义 stream,直接使用 QUIC 里的 Stream,于是 HTTP/3 的帧的结构也变简单了。

这篇关于Java 面试题:HTTP版本演变--xunznux的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1119742

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权,允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true (Spring security默认会带有ROLE_前缀),去

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类,它们之间的依赖,构建起了整个框架。想要理解整个架构,最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文(security context)的信息。当前操作的用户是谁,该用户是否已经被认证,他拥有哪些角色权限…这些都被保

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物

Java进阶13讲__第12讲_1/2

多线程、线程池 1.  线程概念 1.1  什么是线程 1.2  线程的好处 2.   创建线程的三种方式 注意事项 2.1  继承Thread类 2.1.1 认识  2.1.2  编码实现  package cn.hdc.oop10.Thread;import org.slf4j.Logger;import org.slf4j.LoggerFactory

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来,一站式有声阅读平台听书系统 🌟 开篇:遇见未来,从“智听”开始 在这个快节奏的时代,你是否渴望在忙碌的间隙,找到一片属于自己的宁静角落?是否梦想着能随时随地,沉浸在知识的海洋,或是故事的奇幻世界里?今天,就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统,它正悄悄改变着我们的阅读方式,让未来触手可及! 📚 第一站:海量资源,应有尽有 走进“智听

Android实现任意版本设置默认的锁屏壁纸和桌面壁纸(两张壁纸可不一致)

客户有些需求需要设置默认壁纸和锁屏壁纸  在默认情况下 这两个壁纸是相同的  如果需要默认的锁屏壁纸和桌面壁纸不一样 需要额外修改 Android13实现 替换默认桌面壁纸: 将图片文件替换frameworks/base/core/res/res/drawable-nodpi/default_wallpaper.*  (注意不能是bmp格式) 替换默认锁屏壁纸: 将图片资源放入vendo