HTTP 2.0面试通关：强制缓存和协商缓存

•  HTTP1.0和HTTP1.1的区别
  • 长连接(Persistent Connection)
  • 节约带宽
  • HOST域
  • 缓存处理
• 请求响应和长连接
• HTTP 2.0 的多路复用
• HTTP 方法
• 强制缓存
• 协商缓存
• 总结
  • 头部数据压缩
  • 服务器推送

超文本传输协议(HyperText Transfer Protocol，HTTP)是目前使用最广泛的应用层协议。 在网站、App、开放接口中都可以看到它。HTTP 协议设计非常简单，但是涵盖的内容很多。相信你平时工作中已经多多少少接触过这个协议。

HTTP1.0和HTTP1.1的区别

长连接(Persistent Connection)

HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启长连接keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。

节约带宽

HTTP1.0中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP1.1支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器;如果返回401，客户端就可以不用发送请求body了节约了带宽。

HOST域

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名(hostname)，HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers)，并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误(400 Bad Request)。

缓存处理

在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

请求响应和长连接

HTTP 协议采用请求/返回模型。客户端(通常是浏览器)发起 HTTP 请求，然后 Web 服务端收到请求后将数据回传。

HTTP 的请求和响应都是文本，你可以简单认为 HTTP 协议利用 TCP 协议传输文本。当用户想要看一张网页的时候，就发送一个文本请求到 Web 服务器，Web 服务器解析了这段文本，然后给浏览器将网页回传。

那么这里有一个问题，是不是每次发送一个请求，都建立一个 TCP 连接呢?

当然不能这样，为了节省握手、挥手的时间。当浏览器发送一个请求到 Web 服务器的时候，Web 服务器内部就设置一个定时器。在一定范围的时间内，如果客户端继续发送请求，那么服务器就会重置定时器。如果在一定范围的时间内，服务器没有收到请求，就会将连接断开。这样既防止浪费握手、挥手的资源，同时又避免一个连接占用时间过长无法回收导致内存使用效率下降。

这个能力可以利用 HTTP 协议头进行配置，比如下面这条请求头：

Keep-Alive: timeout=10s 

会告诉 Web 服务器连接的持续时间是 10s，如果 10s 内没有请求，那么连接就会断开。

HTTP 2.0 的多路复用

Keep-Alive 并不是伯纳斯·李设计 HTTP 协议时就有的能力。伯纳斯·李设计的第一版 HTTP 协议是 0.9 版，后来随着协议逐渐完善，有了 1.0 版。而 Keep-Alive 是 HTTP 1.1 版增加的功能，目的是应对越来越复杂的网页资源加载。从 HTTP 协议诞生以来，网页中需要的资源越来越丰富，打开一张页面需要发送的请求越来越多，于是就产生了 Keep-Alive 的设计。

同样，当一个网站需要加载的资源较多时，浏览器会尝试并发发送请求(利用多线程技术) 。浏览器会限制同时发送并发请求的数量，通常是 6 个，这样做一方面是对用户本地体验的一种保护，防止浏览器抢占太多网络资源;另一方面也是对站点服务的保护，防止瞬时流量过大。

在 HTTP 2.0 之后，增加了多路复用能力。和 RPC 框架时提到的多路复用类似，请求、返回会被拆分成切片，然后混合传输。这样请求、返回之间就不会阻塞。你可以思考，对于一个 TCP 连接，在 HTTP 1.1 的 Keep-Alive 设计中，第二个请求，必须等待第一个请求返回。如果第一个请求阻塞了，那么后续所有的请求都会阻塞。而 HTTP 2.0 的多路复用，将请求返回都切分成小片，这样利用同一个连接，请求相当于并行的发出，互相之间不会有干扰。

HTTP 方法

在 Restful 架构中，除了约定了上述整体架构方案之外，还约束了一些实现细节，比如用名词性的接口和 HTTP 方法来设计服务端提供的接口。

我们用 GET 获取数据，或者进行查询。比如下面这个例子，就是在获取 id 为 123 的订单数据：

GET /order/123 

GET 是 HTTP 方法，/order 是一种名词性质的命名。这样设计语义非常清晰，这个接口是获取订单的数据(也就是订单的 Representation 用的)。

对于更新数据的场景，按照 HTTP 协议的约定，PUT 是一种幂等的更新行为，POST 是一种非幂等的更新行为。举个例子：

PUT /order/123  
{...订单数据} 

上面我们用 PUT 更新订单，如果订单 123 还没有创建，那么这个接口会创建订单。如果 123 已经存在，那么这个接口会更新订单 123 的数据。为什么是这样?因为 PUT 代表幂等，对于一个幂等的接口，请求多少遍最终的状态是一致的，也就是说操作的都是同一笔订单。

如果换成用 POST 更新订单：

POST /order 
{...订单数据} 

POST 代表非幂等的设计，像上面这种用 POST 提交表单的接口，调用多次往往会产生多个订单。也就是非幂等的设计每次调用结束后都会产生新的状态。

另外在 HTTP 协议中，还约定了 DELETE 方法用于删除数据。其实还有几个方法，感兴趣的同学可以查询下，比如 OPTIONS、PATCH，然后我们在留言区中讨论。

缓存 在 HTTP 的使用中，我们经常会遇到两种缓存，强制缓存和协商缓存，接下来一一介绍。

强制缓存

你的公司用版本号管理某个对外提供的 JS 文件。比如说 libgo.1.2.3.js，就是 libgo 的 1.2.3 版本。其中 1 是主版本，2 是副版本，3 是补丁编号。每次你们有任何改动，都会更新 libgo 版本号。在这种情况下，当浏览器请求了一次 libgo.1.2.3.js 文件之后，还需要再请求一次吗?

整理下我们的需求，浏览器在第一次进行了GET /libgo.1.2.3.js这个操作后，如果后续某个网页还用到了这个文件(libgo.1.2.3.js)，我们不再发送第二次请求。这个方案要求浏览器将文件缓存到本地，并且设置这个文件的失效时间(或者永久有效)。这种请求过一次不需要再次发送请求的缓存模式，在 HTTP 协议中称为强制缓存。当一个文件被强制缓存后，下一次请求会直接使用本地版本，而不会真的发出去。

使用强制缓存时要注意，千万别把需要动态更新的数据强制缓存。一个负面例子就是小明把获取用户信息数据的接口设置为强制缓存，导致用户更新了自己的信息后，一直要等到强制缓存失效才能看到这次更新。

协商缓存

我们再说一个场景：小明开发了一个接口，这个接口提供全国省市区的 3 级信息。先问你一个问题，这个场景可以用强制缓存吗?小明一开始觉得强制缓存可以，然后突然有一天接到运营的通知，某市下属的两个县合并了，需要调整接口数据。小明错手不急，更新了接口数据，但是数据要等到强制缓存失效。

为了应对这种场景，HTTP 协议还设计了协商缓存。协商缓存启用后，第一次获取接口数据，会将数据缓存到本地，并存储下数据的摘要。第二次请求时，浏览器检查到本地有缓存，将摘要发送给服务端。服务端会检查服务端数据的摘要和浏览器发送来的是否一致。如果不一致，说明服务端数据发生了更新，服务端会回传全部数据。如果一致，说明数据没有更新，服务端不需要回传数据。

从这个角度看，协商缓存的方式节省了流量。对于小明开发的这个接口，多数情况下协商缓存会生效。当小明更新了数据后，协商缓存失效，客户端数据可以马上更新。和强制缓存相比，协商缓存的代价是需要多发一次请求。

总结

目前 HTTP 协议已经发展到了 2.0 版本，不少网站都更新到了 HTTP 2.0。大部分浏览器、CDN 也支持了 HTTP 2.0。HTTP 2.0 更多解决队头阻塞、HPack 压缩算法、Server Push 等问题，当你将这些回答出来，基本就可以获得面试官的青睐了。

头部数据压缩

在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。

HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

服务器推送

服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。

为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。