Http的演进1.0、1.1、2.0、3.0

前段时间面试 遇到的这个问题 当时答得不好,现在做个复盘整理

Http1.1

首先介绍一下Http1.1

性能

长连接

1.0存在一个很大的性能问题就是,每次TCP都要三次握手,1.1就采用长连接的方式,减少重复建立连接带来的性能问题,长时间没有数据交互就会断开连接。

管道网络传输

简而言之,不用等回复,就可以直接发下一个请求,但是接受响应还是要延迟的,因为是根据请求的顺序返回响应的,所以解决了队头阻塞问题,但是没有解决响应的队头阻塞

优点

  1. 灵活易拓展 OSI第七层,底下的层可以随意拓展,比如TCP和UDP 比如在HTTP和TCP之间增加了TLS安全传输层

  2. 天然跨平台

缺点(缺点才是比较重要的,也就是后面升级的原因):

  1. 无状态,服务端不会记得你是哪个人 有没有鉴权,所以每次都要鉴权之后才能操作

好处:不需要额外的资源去存储资源信息

坏处:每次操作都要鉴权(可以用Cookie解决)

  1. 明文传输,对相当于信息裸奔,非常危险
  2. 不安全,除了上面说的明文传输,别人篡改了请求你也是不知道的,所以 很危险

Http1.0和1.1的区别

改进:

  1. 长连接减少重复建立连接的损耗
  2. 管道传输,消除队头阻塞

缺点:

  1. Header无法压缩
  2. 每次发相同的首部
  3. (响应的)队头阻塞(可以理解为他要按请求顺序响应,如果有慢的话就会堵着)
  4. 服务端只能被动响应

Http2.0的优化

HTTP/2是基于HTTPS的,所以安全性有保障

优点

  1. 头部压缩 压缩多个请求重复的请求头
  2. 二进制传输 请求头和数据体都是二进制的 不同再进行格式转化
  3. 并发传输

上面我们说到会有队头阻塞的问题?

ok,Http/2就很厉害了,引出了Stream的概念,多个Stream复用在一条TCP连接上。1个TCP包含多个Stream,一个Stream有多个Message,一个个Message包含多个Frame,就是上面压缩的东西

每一个Stream都有一个ID,这样就解决了上面的队头阻塞的问题了。

  1. 服务端也可以建立Stream连接,不再只能被动地处理请求

缺点

队头阻塞问题不在传输层了,在网络层,TCP接受数据按照Segment来接收,有的早到 有的迟到或者丢失 还要等重传,所以这个阻塞着。

Http3.0的优化

上面2.0的问题是TCP的问题,于是直接换成UDP了。是基于UDP的QUIC协议,这里就不展开了。

优点

  1. 无队头阻塞,包丢失只会影响这个Stream
  2. 0-RTT :缓存当前会话的上下文,下次恢复会话的时候,只需要将之前的缓存传递给服务器,验证通过,就可以进行传输了。(这是 QUIC 协议相比HTTP2.0的最大优势 ) 3.多路复用:QUIC基于UDP,一个连接上的多个stream之间没有依赖,即使丢包,只需要重发丢失的包即可,不需要重传整个连接。

QUIC 如何保证可靠传输?

Packet Header :分为Long Packet Header用于首次建立连接、和Short Packet Header用于日常传输数据。QUIC也是需要三次握手来建立连接的,目的是为了协商连接ID。协商出连接ID后,后续传输时,双方只需要固定住连接 ID,从而实现连接迁移功能。Short Packet Header 中的 Packet Number 每个报文有独一无二的编号,并且严格递增。单调递增的设计,可以让数据包不再像 TCP 那样必须有序确认,当数据包Packet N 丢失后,只要有新的已接收数据包确认,当前窗口就会继续向右滑动,从而解决了队头阻塞的问题。

当使用单调递增的设计并结合窗口滑动机制时,即使某个数据包丢失,接收方可以继续接收后续的数据包,而不会因等待丢失的数据包而发生队头阻塞。接收方能够识别出已丢失的数据包,并通知发送方进行重传,而发送方则可以继续发送新的数据包。这种机制提高了网络的吞吐量和效率,减少了传输延迟。这与传统的TCP协议中的严格有序确认机制有所不同,TCP需要按顺序等待所有数据包的确认,因此可能会导致队头阻塞。

QUIC Frame Header:一个 Packet 报文中可以存放多个 QUIC Frame。用于传输的Stream Frame有Stream ID、Offset和length字段,Stream ID用于多个并发传输的 HTTP 消息,通过不同的 Stream ID 加以区别、Offset字段类似于 TCP 协议中的 Seq 序号,保证数据的顺序性和可靠性;Length标识了 Frame 数据的长度。如果发生丢包了进行重传,通过比较两个数据包的Stream ID 与 Stream Offset,如果都是一致,就说明这两个数据包的内容一致。

所以,QUIC 通过单向递增的 Packet Number,配合 Stream ID 与 Offset 字段信息,可以支持乱序确认而不影响数据包的正确组装,摆脱了TCP必须按顺序确认的限制。

相关推荐
Wyang_XXX3 分钟前
CSS 选择器和优先级权重计算这么简单,你还没掌握?一篇文章让你轻松通关面试!(下)
面试
爱吃水果蝙蝠汤35 分钟前
DATACOM-IP单播路由(BGP)-复习-实验
网络·网络协议·tcp/ip
liyinuo20173 小时前
嵌入式(单片机方向)面试题总结
嵌入式硬件·设计模式·面试·设计规范
代码中の快捷键4 小时前
java开发面试有2年经验
java·开发语言·面试
bufanjun0017 小时前
JUC并发工具---ThreadLocal
java·jvm·面试·并发·并发基础
言成言成啊8 小时前
TCP与UDP的端口连通性
网络协议·tcp/ip·udp
敲代码娶不了六花8 小时前
对计算机网络中“层”的理解
网络·网络协议·tcp/ip·计算机网络
x66ccff8 小时前
HTTPS如何通过CA证书实现安全通信,以及HTTPS的局限性
网络协议·安全·https
Graceful_scenery8 小时前
https双向认证
服务器·网络·网络协议·http·https
Zhu_S W18 小时前
Java web的发展历史
面试·职场和发展