啊,http2还没搞明白,http3又来了?

时间:2022-07-24
本文章向大家介绍啊,http2还没搞明白,http3又来了?,主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。
  • HTTP发展阶段
    • HTTP/1.x的缺陷
    • SPDY 协议
  • **HTTP/2 新特性**
    • 1.二进制传输
    • **2.多路复用**
    • **3.Header 压缩**
    • **4.Server Push**
  • 关于 HTTP3
  • 结语

一段Java程序的报错让我有点慌。

java-http3-error

赶紧搜索研究了下,才发现原来是http3协议。

这就有点慌了,连 HTTP2 都还没搞明白, HTTP3 已经出来了。但 HTTP3 会受到关注也是有理由的:它速度很快。

HTTP/2 相比于 HTTP/1,可以说是大幅度提高了网页的性能,只需要升级到该协议就可以减少很多之前需要做的性能优化工作,当然兼容问题以及如何优雅降级应该是国内还不普遍使用的原因之一。

虽然 HTTP/2 提高了网页的性能,但是并不代表它已经是完美的了,HTTP/3 就是为了解决 HTTP/2 所存在的一些问题而被推出来的。

HTTP发展阶段

谈未来之前,咱们先讲讲现实。你了解 HTTP 吗?HTTP 协议是HyperText Transfer Protocol(超文本传输协议)的缩写,它是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。定义于 1991 年,让你可以从网页中获取资源,网页数据从 Web 服务器传输到你的浏览器上。

它基于较低级别的协议——TCP,所以HTTP协议的瓶颈及其优化技巧都是基于TCP协议本身的特性,例如TCP建立连接的3次握手和断开连接的4次挥手以及每次建立连接带来的RTT延迟时间。这里是重点——而且它是无状态的。这意味着每个请求都是完全独立的。页面上显示的每个 GIF 图片都在互联网上独立存在,这对这些 GIF 图片本身来说是好事。但对我们来说,这样的一个系统是有些支离破碎的。

HTTP/1.x的缺陷

连接无法复用:连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显,慢启动则对大量小文件请求影响较大(没有达到最大窗口请求就被终止)。

  • HTTP/1.0传输数据时,每次都需要重新建立连接,增加延迟。
  • HTTP/1.1虽然加入keep-alive可以复用一部分连接,但域名分片等情况下仍然需要建立多个connection,耗费资源,给服务器带来性能压力。

Head-Of-Line Blocking(HOLB):导致带宽无法被充分利用,以及后续健康请求被阻塞。HOLB是指一系列包(package)因为第一个包被阻塞;当页面中需要请求很多资源的时候,HOLB(队头阻塞)会导致在达到最大请求数量时,剩余的资源需要等待其他资源请求完成后才能发起请求。

timeline

协议开销大:HTTP1.x在使用时,header里携带的内容过大,在一定程度上增加了传输的成本,并且每次请求header基本不怎么变化,尤其在移动端增加用户流量。

安全因素:HTTP1.x在传输数据时,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份,这在一定程度上无法保证数据的安全性。

如上图,我们一个页面有很多个请求,每个请求一次只会查找一个文件。每次都要创建一个昂贵的 TCP 连接。想象一下,如果你的页面上有 10,000 个小技巧,这会是多么沉重的负担啊。

5分钟看懂HTTP3

尽管浏览器可以同时发出六个不同的请求,但是 HTTP 仍然很慢,并且需要很多 TCP 连接。另外,我们开发人员通常不会在意这一点。我们喜欢在页面上塞满各种垃圾。比如说巨大的 jQuery 库,包含 300 个无用的 CSS 样式表,结尾是一个透明的 8 兆大 PNG 图。

SPDY 协议

当谷歌发现我们在互联网上到处倾倒垃圾后,他们就开始搞一个称为 SPDY 的东西了。目的是什么呢?当然是加快互联网的速度。

因为 HTTP/1.x 的问题,我们会引入雪碧图、将小图内联、使用多个域名等等的方式来提高性能。不过这些优化都绕开了协议,直到2009年,谷歌公开了自行研发的 SPDY 协议,主要解决 HTTP/1.1 效率不高的问题。谷歌推出SPDY,才算是正式改造 HTTP 协议本身。降低延迟,压缩 header 等等, SPDY 的实践证明了这些优化的效果,也最终带来 HTTP/2 的诞生。

SPDY 是一个规范,建议继续使用 HTTP ,但要更改一些规则。通过压缩标头、对请求进行优先级排序和多路复用,它将把所有 TCP 请求和连接变成单独的一个!

具体来说,当你读取 HTML 时,浏览器会查看你在页面中要询问的所有内容。然后,它可以一次获取所有内容,这样就可以避免一个文件一个文件地获取了。

HTTP2 的第一份草案基于 SPDYHTTP2 很快被广泛采用,随后互联网上的一切变得快多了。今天,互联网上 42.7%的内容使用 HTTP2

5分钟看懂HTTP3

HTTP/2 新特性

1.二进制传输

HTTP/2 采用二进制格式传输数据,而非 HTTP 1.x 的文本格式,二进制协议解析起来更高效。HTTP / 1 的请求和响应报文,都是由起始行,首部和实体正文(可选)组成,各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧,并且它们采用二进制编码

接下来我们介绍几个重要的概念:

  • 流:流是连接中的一个虚拟信道,可以承载双向的消息;每个流都有一个唯一的整数标识符(1、2…N);
  • 消息:是指逻辑上的 HTTP 消息,比如请求、响应等,由一或多个帧组成;
  • 帧:HTTP 2.0 通信的最小单位,每个帧包含帧首部,至少也会标识出当前帧所属的流,承载着特定类型的数据,如 HTTP 首部、负荷等等。

img

HTTP/2 中,同域名下所有通信都在单个连接上完成,该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送,而消息又由一个或多个帧组成。多个帧之间可以乱序发送,根据帧首部的流标识可以重新组装。

2.多路复用

在 HTTP/2 中引入了多路复用的技术。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题,同时也接更容易实现全速传输,毕竟新开一个 TCP 连接都需要慢慢提升传输速度。

大家可以通过 该链接 直观感受下 HTTP/2 比 HTTP/1 到底快了多少。

img

在 HTTP/2 中,有了二进制分帧之后,HTTP /2 不再依赖 TCP 链接去实现多流并行了,在 HTTP/2中:

  • 同域名下所有通信都在单个连接上完成;
  • 单个连接可以承载任意数量的双向数据流;
  • 数据流以消息的形式发送,而消息又由一个或多个帧组成,多个帧之间可以乱序发送,因为根据帧首部的流标识可以重新组装。

这一特性,使性能有了极大提升:

  • 同个域名只需要占用一个 TCP 连接,使用一个连接并行发送多个请求和响应,消除了因多个 TCP 连接而带来的延时和内存消耗;
  • 并行交错地发送多个请求,请求之间互不影响;
  • 并行交错地发送多个响应,响应之间互不干扰;
  • 在HTTP/2中,每个请求都可以带一个31bit的优先值,0表示最高优先级, 数值越大优先级越低。有了这个优先值,客户端和服务器就可以在处理不同的流时采取不同的策略,以最优的方式发送流、消息和帧。

img

如上图所示,多路复用的技术可以只通过一个 TCP 连接就可以传输所有的请求数据。

3.Header 压缩

在 HTTP/1 中,我们使用文本的形式传输 header,在 header 携带 cookie 的情况下,可能每次都需要重复传输几百到几千的字节。

为了减少这块的资源消耗并提升性能, HTTP/2对这些首部采取了压缩策略:

  • HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对,对于相同的数据,不再通过每次请求和响应发送;
  • 首部表在HTTP/2的连接存续期内始终存在,由客户端和服务器共同渐进地更新;
  • 每个新的首部键-值对要么被追加到当前表的末尾,要么替换表中之前的值。

例如下图中的两个请求,请求一发送了所有的头部字段,第二个请求则只需要发送差异数据,这样可以减少冗余数据,降低开销。

img

4.Server Push

Server Push即服务端能通过push的方式将客户端需要的内容预先推送过去,也叫“cache push”。

可以想象以下情况,某些资源客户端是一定会请求的,这时就可以采取服务端 push 的技术,提前给客户端推送必要的资源,这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch。

例如服务端可以主动把JS和CSS文件推送给客户端,而不需要客户端解析HTML时再发送这些请求。

img

服务端可以主动推送,客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过,浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略,换句话说,服务器不能随便将第三方资源推送给客户端,而必须是经过双方确认才行。

关于 HTTP3

HTTP2 是以 HTTP 为基础并改动一些规则的产物。HTTP3 也是如此。换句话说,解释清楚现状后,我就可以很容易地讲明白未来是什么样子的。

谷歌是一个极客组织,他们永远不会停止脚步。SPDY 演变成为 HTTP2 后,他们认为它仍然不够快。因此,他们开始讨论 QUIC 这个项目。这是谷歌开发的第二项将成为 HTTP 协议的正式升级的技术。那么,这个协议有什么特别之处?

HTTP3 的主要改进在传输层上。传输层不会再有我前面提到的那些繁重的 TCP 连接了。现在,一切都会走 UDP。

顺便说一下,QUIC 的意思是“快速 UDP Internet 连接”。协议的这种更改将显著加快连接建立和数据传输的速度。然而,虽说 UDP 肯定更快、更简单,但它不具备 TCP 的可靠性和错误处理能力。

TCP 必须进行多次往返,才能以方形且稳定的方式建立连接。UDP 不会顾虑那么多,而且它确实可以快速运行,代价是稳定性下降和丢包的风险。但是,UDP 能大大减少请求中的延迟。到同一服务器的重复连接的延迟几乎为零,因为不需要往返来建立连接。

5分钟看懂HTTP3

HTTP3 是 HTTP2 的复用和压缩,协议从 TCP 更改为 UDP。然后,谷歌的那些人在协议中添加了他们做的层,以确保稳定性、数据包接收顺序及安全性。

因此,HTTP3 在保持 QUIC 稳定性的同时使用 UDP 来实现高速度,同时又不会牺牲 TLS 的安全性。是的,在 QUIC 中就有 TLS1.3,你可以用它发起优雅的 SSL。这些层的底层机制是下面这样:

5分钟看懂HTTP3

2018 年,QUIC 演变成为 HTTP3。互联网工程任务组(Internet Engineerring Task Force)的那帮制定互联网协议的哥们同意了这个提案。这是个好消息,因为对于我们这些急躁的人们来说,互联网的速度永远都不够快。

结语

  • HTTP/1.x 有连接无法复用、队头阻塞、协议开销大和安全因素等多个缺陷;
  • HTTP/2 通过多路复用、二进制流、Header 压缩等等技术,极大地提高了性能,但是还是存在着问题的;
  • QUIC 基于 UDP 实现,是 HTTP/3 中的底层支撑协议,该协议基于 UDP,又取了 TCP 中的精华,实现了即快又可靠的协议。
  • HTTP3 代表着充满魅力的未来,它的 HTTP 基础潜能已经被谷歌的那些极客发挥到极致。在撰写本文时,只有 4.6%的互联网内容在使用 HTTP3,但这个数字在未来几年中可能会增长许多。
  • 参考

https://baike.baidu.com/item/http/243074?fromtitle=HTTP%E5%8D%8F%E8%AE%AE&fromid=1276942

https://www.jesuisundev.com/en/understand-http3-in-5-minutes

https://wiki.mbalib.com/wiki/Http%E5%8D%8F%E8%AE%AE

https://www.infoq.cn/article/WhCObxfbgtphY7ijv1kp

https://www.sohu.com/a/299243519_115128

https://www.ruanyifeng.com/blog/2016/08/http.html

https://kamranahmed.info/blog/2016/08/13/http-in-depth/

https://tools.ietf.org/html/rfc1945

https://http2.github.io/http2-spec/