这里简略的介绍一下HTTP 2.0。

由HTTP 1.1 走向 HTTP 2.0

写这篇文章的时候我在听B站UP主翻唱的歌曲，而后我灵机一动打算看看B站当初用的是HTTP的哪个版本,于是我摁下了F12键。

这个h2和h3代表的是HTTP 2.0 和3.0? 这版本号刷的这么快的吗？ 不应该是2.1==>2.5 ==>3.0这样吗？为了验证我的想法，我关上了火狐浏览器。

所以就很忽然，原本依照打算只介绍HTTP/2.0的，而后HTTP/3.0也只得退出到学习打算中，所以每次学习一个知识点的时候，总会碰到新的，生也有涯，知也无涯的感觉，在后面两篇文章了，咱们曾经大抵的介绍HTTP 0.9 、1.0、1.1。

2.0 与1.1的不同

1.1 的新个性

咱们这里来再度介绍一下HTTP 1.1带来的改良:

  • 连贯能够复用，节俭了屡次关上 TCP 连贯加载网页文档资源的工夫。

HTTP 1.1 之前的连贯模型使短连贯，也是HTTP/1.0是短连贯，每一个HTTP申请都由它本人独立的连贯实现；这意味着发动每一个HTTP申请之前都会有一次TCP握手。 TCP协定自身握手自身就是消耗工夫的，所以TCP能够放弃更多的热连贯来适应负载。

火狐开发者文档是如是吐槽这个模型的: 除非是要兼容一个十分古老的，不反对长连贯的零碎，没有一个令人信服的理由持续应用这个模型。为了缓解这些问题，长连贯的概念便被设计进去了，甚至在HTTP/1.1之前。或者这被称为一个keep-alive连贯。

一个长连贯会放弃一段时间，反复用于发送一系列申请，节俭了新建TCP连贯握手的工夫，还能够利用TCP性能加强能力。当然这个连贯也不会始终保留着: 连贯在闲暇一段时间后会被敞开(服务器能够应用Keep-Alive协定头来指定一个最小的连贯放弃工夫)

然而长连贯也不是白璧无瑕的；就算是在闲暇状态，它还是会耗费服务器资源，而且在重负载时，还有可能蒙受Dos attacks攻打。在这种场景下，能够应用非长连贯，既尽快敞开那些闲暇的连贯，也能对性能有所晋升。

  • 减少管线化技术，容许在第一个应答被齐全发送之前就发送第二个申请，以升高通信提早。

管线化的英文是pipelining，pipelining还有另一个意思是流水线。我看火狐开发者文档的时候，中文版将pipelining在介绍HTTP的演变为翻译为管线化，然而在介绍连贯治理的时候，由将其译为流水线。我刚看的时候还认为是两种技术，事实上是一个名词的翻译。

然而火狐的开发者文档评估管线化技术，比拟难用，古代浏览器默认不会启用此个性。这个个性被更好的算法所代替，也就是HTTP/2

  • 反对响应分块。

简略的说这个代表分块传输，通常状况下，HTTP应答音讯中发送的数据是整个发送的，Content-Length音讯头部示意数据的长度，客户端须要直到那里是应答音讯的完结，以及后续应答音讯的开始。一个比拟常见的利用是断点续传，实现H5页面的大视频播放，实现渐进式播放，不须要将整个文件加载到内存中。

值得注意的是此个性在HTTP/2.0中并不反对，HTTP/2.0提供了一种更加有效率的数据流形式。

  • 引入额定的缓存管制机制。
简略的说就是引入了Cache-Control, 用Cache-control辨别了缓存的类型，制订了缓存过期策略。
  • 引入内容协商机制，包含语言，编码，类型等，并容许客户端和服务器之间约定以最合适的内容进行替换。
  • 凭借Host头, 可能使不同域名配置在同一个ip地址的服务器上。

有的同学看到这里会问，家喻户晓，HTTP用的是TCP协定，发送HTTP申请的时候，IP地址和端口必然是已知的，那么HOST的意义在哪里呢？举一个理论的例子是，Tomcat中部署多个服务，事实上一个Tomcat能够对应多个服务，当初是Spring Boot时代，Tomcat曾经默认集成在外面，是一个利用对一个Tomcat。如果你开发过Servlet，还没到Spring Boot，那个时候是打war包的，war被放在webapps上面，咱们在Tomcat中能够配置Host头，Tomcat会依据不同的host头转发到对应的服务上。关上Tomcat的server.xml:

### 流水线(pipelining)的设计问题

下面咱们提到了HTTP 1.1引入了流水线，容许第一个响应被齐全返回前，客户端发送第二个申请，我认为这是正当的设计，然而为什么古代浏览器大多没启用此个性吗？

I would always recommend going to the authoritative source when trying to understand the meaning and purpose of HTTP headers.

如果你在尝试了解HTTP头的含意和用头时，我总是倡议你去原始权威文档.

下面这句话出自StackOverflow中What is HTTP "Host" header?的答案下，我挺喜爱这句话的。其实这个答案我在StackOverFlow上曾经看到了答案，有同学可能会问，百度找不到吗？说句羞愧的话，找的到，然而比拟吃力，Stackoverflow这种问答式网站找起问题来更快。

答案是: 流水线要求响应按申请程序返回。

这种设计会带来队头阻塞问题(Head of line Blocking), 只有第一个HTTP流遭逢到阻塞，那么第二个响应就得始终排队期待。那为什么你要按程序返回呢？

答案是: Because there is no identifier in the response indicating to which request it belongs.

响应没有标识符区别响应式属于哪一个申请的。

那么请问HTTP/2.0是如何解决这个问题的？

HTTP/2 solves this with stream identifiers.

HTTP / 2应用流标识符来解决了这个问题。

为了更快的速度-来吧HTTP/2

HTTP/2 的改良

HTTP/2是有官网的, 咱们能够在官网看到对HTTP/2的认知

  • is binary, instead of textual
传输的是二进制数据，不再是文本。
  • is fully multiplexed, instead of ordered and blocking
多路复用取代了程序和阻塞。
  • can therefore use one connection for parallelism
能够并行申请
  • uses header compression to reduce overhead
压缩申请缩小耗费
  • allows servers to “push” responses proactively into client caches
其容许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制来提前申请。

is fully multiplexed 多路复用与并行申请

咱们举一个小例子来阐明HTTP 1.0 ==> HTTP1.1 ==> HTTP/2的变动， 为了阐明这个变动，咱们须要请出网购达人小明。

如果小明须要在一个淘宝店网购多个货色，在HTTP 1.0下, 不能放在一个订单外面(一个TCP连贯外面)，只能是一个商品一个订单。

这也太浪费时间了吧，于是小明切换到了HTTP/1.1, 尽管不必开多个订单，但其实限度也比拟大，也还是只能一次订购一个，尽管最初都被算在了一个订单中(一个TCP连贯)。于是小明切换到了HTTP/1.1的流水线模式，在一个订单里买了10件商品，然而他们会依照申请程序顺次达到，如果某件商品缺货或者遗失，那么小明必须期待这件商品到货或者补发到货之后，能力收到下一个商品。这也太简单了吧。

小明马上切换到了HTTP/2模式，在这个模式下，小明能够依照任意程序购买商品，哪个商品筹备好了，哪个商品就率先发货，所以他们的达到程序和你的购买程序可能是不一样的，为了减速，商家还可能拆分商品。这也就是HTTP/2的多路复用，一个连贯上多个申请，不再像HTTP/1.1要求的那样，要求响应按申请程序返回。

下面这个绝妙的比喻来于StackOverFlow下What does multiplexing mean in HTTP/2这个问题的答复，这个后果颇为简略易懂。

is binary, instead of textual 二进制的而不是文本的

下面的话也就是在说，HTTP/2之前应用的是文本的，然而最终传输的不都是二进制的吗？ 咱们能够说二进制是令人困惑的术语，因为数据在计算机中最初都是二进制模式的。所以有什么区别呢？

为了解决我的问题，我决定应用Wireshark进行抓包，比照HTTP/1.1和HTTP/2的区别。然而我疏忽了一点，目前基本上应用HTTP/2网站都是HTTPS，而后我在抓包工具中看到的就是TLS V 1.2这样的货色，这些都是密文。所以我又想用Spring Boot做一个反对HTTP/2的后盾，而后本人抓包剖析一下，而后发现Spring Boot 不反对HTTP/2的明文版本, 原来HTTP/2分成两个版本，一个是明文版，一个是基于加密的。然而目前浏览器和Spring Boot 只反对基于加密的版本，所以必须有加密证书，如果你禁用加密，通过浏览器进行拜访的时候，浏览器会进行主动降级，将HTTP/2降级为HTTP/1.1。

所以通过本人搭建反对HTTP/2网站的想法报销了，因为比拟麻烦。我只能将心愿转到有反对HTTP/2明文的网站, 于是我找到了上面这篇文章:

  • HTTP/2 协定抓包实战 https://zhuanlan.zhihu.com/p/...

外面给了一个HTTP/2的明文网站，遗憾的是在我去抓的时候，人家升级成HTTP/2密文了，同样的curl命令，他抓到申请中有申请降级协定的，我这里没抓到，我进到网站一看，发现人家曾经是HTTPS了。所以思来想去，可能咱们提出的问题自身就是由问题的，咱们的问题是最终传输的时候都是二进制，所以提出的问题是有什么区别？我想上面的答复能够部分答复咱们的问题:

The first is that some people have suggested that the bottom layer of the HTTP protocol is still 0 and 1. How can it be a text protocol? The answer is whether a protocol is a text protocol or not, it has nothing to do with the upper and lower layers of the network model, but only with itself.

有人认为HTTP协定的底层依然是0和1，那为什么HTTP就算是文本协定了呢？ 答案是一个协定是基于文本还是其余，不在于他的下层还是上层，仅仅在于它自身。

那你还是没答复HTTP/1.1交付给传输层的数据和HTTP/2交付给传输层的有什么区别啊？ 我想大略就是在编码和格局上了。这里简略的介绍一下文本编码和二进制编码的区别，他们都是示意数据的模式。对于数字来说，一个数字比如说用二进制协定，比方98765，这是个五位数，两个字节不大够，咱们大抵要上三个字节来示意。那如果用文本协定呢，那就是一个字符一个字节，五个数字也就是五个字节。这就节俭了两个字节。第二个就是固定了格局，将原来的Header+Body变为数个扩散的帧:

为什么是HTTP/2而不是HTTP 1.2

最后的HTTP/2被称为HTTP/2.0，HTTP/2工作组给出了解释，他们认为以前的1.0,1.1造成了很多换乱和误会，让人在理论的应用难以辨别差别，所以将这次的版本号定位HTTP/2，弃用主要版本号“.0”。

Java 畛域对HTTP/2的反对

尽管当初HTTP/3曾经进去了，然而Java畛域对此反对的HTTP Client，就我相熟的而言，还处于踊跃的适配HTTP/2中，Maven 仓库中的Apache HttpClient最新版本还处于4.5.2，这个目前还只是反对HTTP1.1版本。

写在最初

本篇的定位是简介，简略介绍了HTTP/2的次要个性，自身是想做抓包的，然而抓包的相干的解析又会加大大本篇的篇幅，所以思考将报文解析挪动前面的文章序列了。其实这篇文章，自身我预计打算一天实现的，前面查二进制协定和文本协定的区别，倒是让我花了不少工夫，这到让我颇为意外。

参考资料

  • HTTP/2 中的多路复用是什么意思 https://stackoverflow.com/que...
  • Transfer-Encoding:chunked详解 https://blog.csdn.net/qq_3233...
  • How does HTTP2 solve Head of Line blocking (HOL) issue https://stackoverflow.com/que...
  • HTTP Head of line blocking: Why responses must come back in order? https://stackoverflow.com/que...
  • What is HTTP "Host" header? https://stackoverflow.com/que...
  • Why is it said that HTTP2 is a binary protocol? https://stackoverflow.com/que...
  • How to enable http2 using spring boot and tomcat without SSL configuration https://stackoverflow.com/que...
  • Binary vs Text https://dev.to/cacilhas/binar...
  • 透视 HTTP 协定 https://zq99299.github.io/not...
  • HTTP/2 官网 https://httpwg.org/specs/rfc9...