http2 3

时间：2019-09-21 17:23:14 阅读：122 评论：0 收藏：0 [点我收藏+]

标签：体验最大格式组成接受网站理解不能 tail

HTTP 2

进来支持 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.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

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