这里简略的介绍一下 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…