1、HTTP 1.0

• 是一种无状态，无连接的应用层协议
  • 规定浏览器和服务器保持短暂的链接。
  • 浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接（短连接），服务器不跟踪也每个客户单，也不记录过去的请求（无状态）。
  • 这种无状态性可以借助cookie/session机制来做身份认证和状态记录。
• 存在的问题：
  • 无法复用连接：每次发送请求/返回响应，都需要进行一次TCP连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
  • 队头阻塞（head of line blocking）：由于HTTP1.0规定下一个请求必须在前一个请求响应到达之后才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。

Http 1.0的致命缺点:

1. 无法复用TCP连接和并行发送请求，这样每次一个请求都需要三次握手，而且其实建立连接和释放连接的这个过程是最耗时的，传输数据相反却不那么耗时。

2. 不支持文件断点续传。

3. 本地时间被修改导致响应头expires的缓存机制失效的问题。

---

2、HTTP1.1

HTTP1.1继承了HTTP1.0的简单，克服了HTTP1.0性能上的问题。
HTTP1.1也是当前使用最为广泛的HTTP协议

• 1. 长连接:HTTP1.1增加Connection字段，通过设置Keep-Alive保持HTTP连接不断开，直到连接的某一段主动提出断开连接的请求（Connection:Close）。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection:Close来告知服务器关闭请求。
• 2. 管道化:HTTP1.1支持请求管道化（pipelining)。基于HTTP1.1的长连接，使得请求管线化成为可能。 管线化使得请求能够“并行”传输。但需要注意的是：服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。
  • 也就是说，HTTP管道化可以让我们把先进先出队列从客户端（请求队列）迁移到服务端（响应队列）,如果，客户端同时发了两个请求分别获取html和css，假如说服务器的css资源先准备就绪，服务器也会先发送html，再发送css。 换句话来说，只有等到html响应的资源完全传输完毕后，css响应的资源才开始传输，不允许同时存在两个并行的响应。
  • 可见，HTTP1.1还是无法解决队头阻塞（head of line blocking）的问题，只是把先进先出队列从客户端（请求队列）迁移到服务端（响应队列）。
• 3. RANGE:bytes字段： 是HTTP/1.1新增内容，断点续传，表示要求服务器从文件XXXX字节处开始传送。
• 4. 真并行传输 — 浏览器优化策略
  • HTTP1.1支持管道化，但是服务器也必须进行逐个响应的送回，这个是很大的一个缺陷。实际上，现阶段的浏览器厂商采取了另外一种做法，它允许我们打开多个TCP的会话，也就是说，其实是不同的TCP连接上的HTTP请求和相应，这也就是我们所熟悉的浏览器对同域下并行加载6~8个资源的限制。
• 5. 缓存处理 — 强缓存、协商缓存，启发式缓存（新增）
  • 此外，HTTP1.1还加入了缓存处理（强缓存和协商缓存），新的字段如cache-control，支持断点传输，以及增加了Host字段（使得一个服务器能够用来创建多个Web站点）

Http 1.1的致命缺点：

• 1.明文传输。
• 2.其实还是没有解决无状态连接的。
• 3.当有多个请求同时被挂起的时候 就会拥塞请求通道，导致后面请求无法发送（没有真正的解决队头阻塞）。
• 4.臃肿的消息首部:HTTP/1.1能压缩请求内容，但是消息首部不能压缩;在现今请求中，**消息首部占请求绝大部分(**甚至是全部)也较为常见。

我们也可以用dns-prefetch和 preconnect tcp来优化～

<link rel="preconnect" href="//example.com" crossorigin>
<link rel="dns=prefetch" href="//example.com">

• Tip: webpack可以做任何事情，这些都可以用插件实现

---

3、HTTP2.0

相较于HTTP1.1，HTTP2.0的主要优点有：

1. 采用二进制帧封装
2. 传输变成多路复用
3. 流量控制算法优化
4. 服务器端推送
5. 首部压缩
6. 优先级

1、 二进制帧封装 / 二进制分帧

HTTP1.x的解析是基于文本的，基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多。

而HTTP2.0会将所有传输的信息分割为更小的消息和帧，然后采用二进制的格式进行编码，HTTP1.x的头部信息会被封装到HEADER frame（单独成帧，不再在后续数据传输中携带），而相应的RequestBody则封装到DATAframe里面。

不改动HTTP的语义，使用二进制编码，实现方便且健壮。

2、 多路复用 && 优先级

所有的请求都是通过一个 TCP 连接并发完成。

HTTP/1.x 虽然通过 pipeline 也能并发请求，但是多个请求之间的响应会被阻塞的，所以 pipeline 至今也没有被普及应用，而 HTTP/2 做到了真正的并发请求。

同时，流还支持优先级和流量控制。当流并发时，就会涉及到流的优先级和依赖。

即：HTTP2.0对于同一域名下所有请求都是基于流的，不管对于同一域名访问多少文件，也只建立一路连接。优先级高的流会被优先发送和响应。图片请求的优先级要低于 CSS 和 SCRIPT，这个设计可以确保重要的东西可以被优先加载完（相较HTTP1.1，响应不再死板的按照请求顺序返回，而是根据流中请求数据的优先级响应）。

3、 流量控制

TCP协议通过sliding window(滑动窗口)的算法来做流量控制。

发送方有个sending window，接收方有receive window。http2.0的flow control是类似receive window的做法，数据的接收方通过告知对方自己的flow window大小表明自己还能接收多少数据。

只有Data类型的frame才有flow control的功能。对于flow control，如果接收方在flow window为零的情况下依然更多的frame，则会返回block类型的frame，这种场景一般表明http2.0的部署出了问题。

4、 服务器端推送

服务端推送是一种在客户端请求之前发送数据的机制。可以做到（客户端的）缓存。

服务器端的推送，就是服务器可以对一个客户端请求发送多个响应。

除了对最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确地请求。 当浏览器请求一个html，服务器其实大概知道你是接下来要请求资源了，而不需要等待浏览器得到html后解析页面再发送资源请求。

5、 首部压缩

1. HTTP 2.0 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对，对于相同的数据，不再通过每次请求和响应发送；

   通信期间几乎不会改变的通用键-值对(用户代理、可接受的媒体类型,等等)只需发送一次。事实上,如果请求中不包含首部(例如对同一资源的轮询请求),那么 首部开销就是零字节。此时所有首部都自动使用之前请求发送的首部。

2. 如果首部发生变化了，那么只需要发送变化了数据在Headers帧里面，新增或修改的首部帧会被追加到“首部表”。首部表在 HTTP 2.0 的连接存续期内始终存在，由客户端和服务器共同渐进地更新 。

3. 本质上是为了减少请求，通过多个js或css合并成一个文件，多张小图片拼合成Sprite图，可以让多个HTTP请求减少为一个，减少额外的协议开销，而提升性能。

   当然，一个HTTP的请求的body太大也是不合理的，有个度。文件的合并也会牺牲模块化和缓存粒度，可以把“稳定”的代码or 小图 合并为一个文件or一张Sprite，让其充分地缓存起来，从而区分开迭代快的文件。

   HTTP/1.1并不支持 HTTP 首部压缩，为此 SPDY 和 HTTP/2 应运而生， SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。