http2 3

HTTP 2

推荐阅读：https://segmentfault.com/a/1190000011172823?utm_source=tag-newest

进来支持 HTTP 2 的网站越来愈多了，这是一个很好的趋势。虽然 HTTP 2 的 RFC 写得很厚，但是总的来说可以总结为以下几点：

1. 通过 TCP 多路复用，降低延迟

3. 强制使用 TLS，保证安全性问题

4. 头部压缩

5. Server Push

多路复用

简单的来说，就是所有HTTP请求都走同一个TCP。

在 HTTP 1.1

实现并发，一般是通过建立多个TCP连接来实现，现代浏览器支持最大并发数一般达到6~10(chrome 最多6个)。

虽然 HTTP 1.1 规范给出来 Pipelining，但是受限于出现的一些问题，浏览器都是默认关闭的 ：

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response).
A server MUST send its responses to those requests in the same order that the requests were received. 
一个支持持久连接的客户端可以在一个连接中发送多个请求（不需要等待任意请求的响应）。收到请求的服务器必须按照请求收到的顺序发送响应。

因为 HTTP 1.1 是基于文本的，所以并不能区分Response对应的是哪个请求，因此，只能规定必须按顺序返回响应，这样就会有一个“队首阻塞”的问题。

即使靠后接受到的请求，已经处理完毕，也得需要前面的请求处理好了，才能往回响应。

这样的话，实际TCP只能串行响应请求。

在 HTTP 2

改变 HTTP 基于文本的特性，变成基于流。

每一个请求都是一个流，每个流由多个帧组成，可以简单理解成每一次传输就是一帧。

帧头会有标识，来表示这一帧是属于那个流（请求）的。

这样的话，一个TCP连接就不会因为一个HTTP请求响应慢，而阻塞了，因此对于并发，我们完全可以用一个TCP请求就可以了。

我们来看看下面的图：

HTTP/1.1通过pipelining管道技术实现一次性发送多个请求，以期提高吞吐和性能，如上图中的序列2。

如果，第一个请求被堵塞了，则后面的请求即使处理完毕了，也需要等待，如上图中的序列3。

那么，HTTP/2是怎么解决这个问题的呢？

那就是数据分帧：多个请求复用一个TCP连接，然后每个request-response都被拆分为若干个帧发送，这样即使一个请求被阻塞了，也不会影响其他请求，如上图序列4所示。

PS：值得注意的是“多路复用”，仅仅解决了 HTTP 1.1 在应用层上的限制（不允许响应数据交错到达），而如果 HTTP 的传输层仍然采用TCP的话，TCP在传输层的“队首阻塞”也仍然存在（就是丢包的时候，需要后续的包等待丢的包重传到达。）如果这样的话，这个丢包的影响，在HTTP 2 甚至比 HTTP  1.1 更严重，因为只有一个 TCP连接，而这个 TCP 发生了 对首阻塞”。

推荐阅读：https://www.zhihu.com/question/65900752/answer/255085226

　　　　    https://www.jianshu.com/p/11c2614ef3f2

TLS 和 SSL

对于 HTTP 2 浏览器会强制使用TLS（实际上现在我们用的都是TLS，但是由于历史上的习惯，我们都叫它做SSL）

SSL是Netscape开发的专门用户保护Web通讯的，目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。两者差别极小，可以理解为SSL 3.1，它是写入了RFC的。

头部压缩

1. 使用 HPACK 压缩格式，对 header 进行压缩

2. 双方维护一份头部索引表，如果是已经发送过的相同的头部，用索引号来代替（例如cookie只需要发送一次，如果没有发生变化，下次用索引号代替）

服务端 Push

如果服务端接收到客户端主请求，能够“预测”主请求的依赖资源，在响应主请求的同时，主动并发推送依赖资源至客户端。客户端解析主请求响应后，可以”无延时”从本地缓存获取依赖资源, 减少访问延时, 提高访问体验，也加大了链路的并发能力。

server push 和 websocket 的区别：https://blog.csdn.net/axman/article/details/79875463

HTTP 3

如果底层始终是基于TCP的话，那么我们始终存在“队首阻塞”的问题。

因此，google 另起炉灶，搞了一个基于UDP的QUIC协议，因此我们所提到的HTTP 3还有一个名字叫做HTTP-over-QUIC

QUIC

之前我们了解过 UDP 协议的内容，知道这个协议虽然效率很高，但是并不是那么的可靠。QUIC 虽然基于 UDP，但是在原本的基础上新增了很多功能：

多路复用

HTTP 2 支持多路复用，但是TCP终究不能真正满足多路复用（在网络畅通的时候可以，但是一旦丢包就会出现“对首阻塞“，从而影响到后续的请求，不能真正做到每个请求之间互不影响）QUIC 原生就实现了多路复用这个功能，并且传输的单个数据流可以保证有序交付且不会影响其他的数据流，这样的技术就解决了之前 TCP 存在的问题。

并且 QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的，这种方式在多变的移动端网络环境下是很脆弱的。但是 QUIC 是通过 ID 的方式去识别一个连接，不管你网络环境如何变化，只要 ID 不变，就能迅速重连上。

0-RTT

通过使用类似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只需要将之前的缓存传递给服务端验证通过就可以进行传输了。

纠错机制

假如说这次我要发送三个包，那么协议会算出这三个包的异或值并单独发出一个校验包，也就是总共发出了四个包。

当出现其中的非校验包丢包的情况时，可以通过另外三个包计算出丢失的数据包的内容。

当然这种技术只能使用在丢失一个包的情况下，如果出现丢失多个包就不能使用纠错机制了，只能使用重传的方式了。