HTTP 知识点速览

Table of contents

HTTP/2 与 HTTP/1.1

HTTP 的版本进化看了太多知识点真的很容易晕，平时不太关注，太多真记不住，关注一下最重要的几个点。

HTTP 缓存策略

HTTP 缓存主要分为强缓存和协商缓存。 强缓存可以通过 Expires / Cache-Control 控制，命中强缓存时不会发起网络请求，资源直接从本地获取，浏览器显示状态码 200 from cache。 协商缓存可以通过 Last-Modified / If-Modified-Since 和 Etag / If-None-Match 控制，开启协商缓存时向服务器发送的请求会带上缓存标识，若命中协商缓存服务器返回 304 Not Modified 表示浏览器可以使用本地缓存文件，否则返回 200 OK 正常返回数据。

流程图

强缓存

Expires

• HTTP/1.0 产物。
• 优先级低于 Cache-control: max-age。
• 缺点：使用本地时间判断是否过期，而本地时间是可修改的且并非一定准确的。

Expires 是由服务端返回的资源过期时间（GMT 日期格式/时间戳），若用户本地时间在过期时间前，则不发送请求直接从本地获取资源。

Cache-Control

• HTTP/1.1 产物。
• 优先级高于 Expires。
• 正确区分 no-cache / no-store 的作用。

Cache-Control 是用于页面缓存的通用消息头字段，可以通过指定指令来实现缓存机制。

• public:所有内容都将被缓存(客户端和代理服务器都可缓存)
• private:所有内容只有客户端可以缓存，Cache-Control的默认取值
• no-cache:跳过当前当前强缓存，客户端缓存内容，直接进入协商缓存阶段。
• no-store:所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
• max-age=xxx (xxx is numeric):缓存内容将在xxx秒后失效，只有http1.1可用。

协商缓存

强制缓存失效后，browser携带缓存标识tag向server发请求，由服务器根据缓存tag决定是否使用缓存的过程。 tag分为两种:Last-Modified和ETag，不分上下。

Last-Modified / If-Modified-Since

• 通过资源的最后修改时间来验证缓存。
• 优先级低于 ETag / If-None-Match。
• 缺点：只能精确到秒，若 1s 内多次修改资源 Last-Modified 不会变化。

如果资源请求的响应头里含有 Last-Modified，客户端可以在后续的请求的头中带上 If-Modified-Since 头来验证缓存。若服务器判断资源最后修改时间一致，则返回 304 状态码告知浏览器可从本地读取缓存。

ETag / If-None-Match

• 通过唯一标识来验证缓存。
• 优先级高于 Last-Modified / If-Modified-Since。

如果资源请求的响应头里含有 ETag，客户端可以在后续的请求的头中带上 If-None-Match 头来验证缓存。若服务器判断资源标识一致，则返回 304 状态码告知浏览器可从本地读取缓存。 唯一标识内容是由服务端生成算法决定的，可以是资源内容生成的哈希值，也可以是最后修改时间戳的哈希值。所以 Etag 标识改变并不代表资源文件改变，反之亦然。

扩展

缓存位置

• 从 Service Worker 中读取缓存（只支持 HTTPS）。
• 从内存读取缓存时 network 显示 memory cache。
• 从硬盘读取缓存时 network 显示 disk cache。
• Push Cache（推送缓存）（HTTP/2.0）。
• 优先级 Service Worker > memory cache > disk cache > Push Cache。

最佳实践：

资源尽可能命中强缓存，且在资源文件更新时保证用户使用到最新的资源文件

• 强缓存只会命中相同命名的资源文件。
• 在资源文件上加 hash 标识（webpack 可在打包时在文件名上带上）。
• 通过更新资源文件名来强制更新命中强缓存的资源。

HTTP 状态码

HTTPS 加密过程

HTTP 报文默认是明文发送，协议本身不具备加密，极易导致数据泄漏，流量劫持，受到中间人攻击。

HTTPS 工作流程

先放结论，再解释

1. Client 发起一个 HTTPS 的请求，连接 443 端口，这个过程可以理解成是请求公钥的过程
2. Server 端收到请求后，通过第三方机构私钥加密，会把数字证书（也可以认为是公钥证书）发送给 Client
3. Client 验证公钥证书，比如是否在有效期内，证书的用途是不是匹配 Client 请求的站点，是不是在 CRL 吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的 Root 证书或者 Client 内置的 Root 证书），如果验证通过则继续，不通过则显示警告信息
4. Client 使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给 Server
5. Server 使用自己的私钥（private key）解密这个消息，得到对称密钥，至此，Client 和 Server 双方都持有了相同的对称密钥
6. Server 使用对称密钥加密明文内容 A，发送给 Client
7. Client 使用对称密钥解密响应的密文，得到明文内容 A
8. Client 再次发起 HTTPS 的请求，使用对称密钥加密请求的明文内容 B，然后 Server 使用对称密钥解密密文，得到明文内容 B

注意，并不是每次请求都要经历一次密钥传输验证的过程。服务器会维护一个当前会话的 sessionID，客户端每次请求带上这个 sessionID，服务器匹配到会话密钥，就不需要再重新建立 SSL 连接。

不理解再往下看，已理解就不必了。

对称加密

通信双方都持有同一个密钥，并通过这个密钥进行信息的加解密。

如果这个密钥只有通信双方知道，那自然是极好的。在浏览器到服务器的通信场景里，浏览器首先需要服务器下发告知这个密钥，如果第一步就被劫持了，那后续就裸奔了，加解密都毫无意义。

非对称加密

通信双方持有两个不同的密钥，一个叫公钥，一个叫私钥。用公钥加密的信息必须私钥才能解密，反过来用私钥加密的信息也只有公钥才能解开。

通常是服务端持有私钥，第一步也是要下发公钥给浏览器，那么也会面临公钥下发过程被劫持的情形。此时对于中间人，服务器下发的加密数据是可以被解密的。

对称加密 + 非对称加密

这也是 HTTPS 采用的方式。使用对称加密的好处的加解密效率高，非对称加密的好处是传输内容更加不容易被破解。将两者结合，思路是：

1. 浏览器端利用伪随机数，生成会话的密钥，作为后续对称加密的公钥；
2. 用【网站的公钥（取自下面要讲的证书）】加密会话密钥，发送给网站服务器；
3. 服务器用私钥解密 ，得到会话密钥，即为公钥；
4. 后续双方均使用该公钥，对称加解密明文内容传输。

数字证书

单纯的对称加密和非对称加密方式，都无法解决【浏览器获取到网站服务器的可信的公钥】这个问题。

这里就引入了 CA（Certificate Authority）认证机构，网站在使用 HTTPS 之前，需要向 CA 机构申领一份数字证书，包含了【持有者信息、公钥】等。服务器把证书传递给浏览器，浏览器从证书里获取网站的公钥即可。证书就如同身份证，证明“该公钥对应该网站”。那证书传输会不会被篡改呢？

所以这里有引入了数字签名，数字签名是由 CA 机构做到数字证书里的，过程如下：

1. CA机构拥有非对称加密的私钥和公钥；
2. CA机构对证书明文数据T进行hash；（这里为什么要hash？因为证书内容可能会很长，hash 之后得到固定长度的值，在非对称加密时会更高效）
3. 对hash后的值用私钥加密，得到数字签名S。

这样【证书数据 + 数字签名】组成完整的数字证书。

浏览器验证过程：

1. 拿到证书，得到明文T，签名S。
2. 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥，见 PS），得到S’。
3. 用证书里指明的hash算法对明文T进行hash得到T’。
4. 显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。
5. 然后就可以从证书中拿到网站的公钥和持有者信息，进行加密通信了。

PS：浏览器会默认安装一些权威认证机构的根证书，如果其中有 CA 机构的根证书，就可以拿到他的可信公钥了。

参考

• https://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html
• https://zhuanlan.zhihu.com/p/43789231
• https://heptaluan.github.io/2020/08/09/HTTP/09/