HTTP 协议*3 ｜青训营HTTP 协议的基本定义 HTTP 协议主要特征 HTTP 协议发展历程 HTTP 协议

知识点一

HTTP 协议的基本定义
HTTP 协议主要特征
HTTP 协议发展历程
HTTP 协议的报文结构

RESTful API

知识点二

场景分析 - 静态资源
场景分析 - 登录
基础：An overview of HTTP - HTTP | MDN
进阶：Hypertext Transfer Protocol version 2
进阶：HPACK - Header Compression for HTTP/2

知识点三

HTTP 协议实战 - 浏览器
HTTP 协议实战 - Node篇
网络优化手段
HTTP 协议拓展 - 通信方式

知识点四

HTTP中与缓存有关的字段主要有以下10个，如下表所示。为明确表示其功能及用法，下表中分别区分了存储策略、过期策略、协商策略、请求头、响应头。

Key	描述	存储策略	过期策略	协商策略	请求头	响应头
Expires	指定缓存的过期时间，值为某一时刻（绝对时间）。在指定时刻后过期	✓	✓			✓
Cache-Control	指定缓存机制	✓	✓		✓	✓
Pragma	指定缓存机制(http1.0字段)				✓
Last-Modified	资源最后修改时间	乄		✓		✓
If-Modified-Since	缓存协商校验字段，为上次请求收到的Last-Modified的值。处理方式见下文。			✓	✓
If-Unmodified-Since	缓存协商校验字段，为上次请求收到的Last-Modified的值。处理方式与If-Modified-Since相反，见下文。			✓	✓
ETag	请求资源的唯一标识字符串			✓		✓
If-Match	缓存协商校验字段，请求资源的唯一标识字符串，为上次请求收到的ETag的值。处理方式见下文。			✓	✓
If-None-Match	缓存协商校验字段，请求资源的唯一标识字符串，为上次请求收到的ETag的值。处理方式与If-Match相反，见下文。			✓	✓

注：乄表示半对，Last-Modified之所以是半对，是因为有可能会触发启发式缓存，也会缓存文件。具体见下文。

缓存又分为强缓存和弱缓存（又称为协商缓存）。其中强缓存包括Expires和Cache-Control，主要是在过期策略生效时应用的缓存。弱缓存包括Last-Modified和ETag，是在协商策略后应用的缓存。强弱缓存之间的主要区别在于获取资源时是否会发送请求。

2.1 Expires

如上所述，Expires指定缓存的过期时间，为绝对时间，即某一时刻。参考本地时间进行比对，在指定时刻后过期。RFC 2616建议最大值不要超过1年。

Expire头字段是响应头字段，格式如下：Expires: Sat Oct 20 2018 00:00:00 GMT+0800 (CST)。

可以尝试以下步骤进行验证：

执行node cache-Expires.js，该脚本会给请求的资源设定Expires，值为：”2018-10-20 00:00:00”。
访问地址http://localhost:1030/，开启Network Tab，查看avatar.jpg图片，Expires值如下所示。

Expires缓存设置
再次刷新会看到该资源已经被缓存，size栏显示为(from memory cache)。此时修改本地时间，将时间修改为“2018-10-15 00:00:00”，再刷新，会发现缓存仍然有效。

Expires缓存生效
如果将本地时间修改为“2018-10-25 00:00:00”，再刷新，会发现图片不再使用缓存，而是重新获取了，因为本地时间超过了设定值。

Expires缓存过期，重新获取

Expires缓存过期，重新获取

2.2 Cache-Control

Cache-Control用于指定资源的缓存机制，可以同时在请求头和响应头中设定，涉及上述三个策略中的两个策略：存储策略、过期策略。

Cache-Control的语法如下：Cache-Control: cache-directive[,cache-directive]。cache-directive为缓存指令，大小写不敏感，共有12个与HTTP缓存标准相关，如下表所示。其中请求指令7种，响应指令9种。Cache-Control可以设置多个缓存指令，以逗号,分隔。

Key	描述	存储策略	过期策略	请求字段	响应字段
可缓存性相关	---	---	---	---	---
public	资源在客户端和代理服务器缓存	✓			✓
private	资源仅在在客户端缓存，代理服务器不缓存	✓			✓
no-cache	资源被缓存，但立即过期，下次访问时强制向服务器验证资源有效性。相当于`max-age:0,must-revalidate`	✓	✓	✓	✓
过期相关	---	---	---	---	---
max-age=	在请求头中：指出客户端不接受有效时间大于指定时间的缓存。在响应头中：规定资源的最大新鲜时间，指定时间后过期，单位为秒。	✓	✓	✓	✓
s-maxage=	同上，但只对代理服务器生效，如果是`private`缓存，会忽略该字段。会覆盖`max-age`或`Expires`头字段	✓	✓		✓
max-stale=	指定时间内, 即使缓存过时, 资源依然有效		✓	✓
min-fresh=	缓存的资源至少要保持指定时间的新鲜期		✓	✓
验证与重载相关	---	---	---	---	---
must-revalidate	使用缓存资源之前，必须先验证状态，并且过期资源不应该再使用。		✓		✓
proxy-revalidate	同上，但只对代理服务器生效，如果是`private`缓存，会忽略该字段。		✓		✓
其他	---	---	---	---	---
no-store	请求和响应都不缓存	✓		✓	✓
only-if-cached	仅返回已经缓存的资源，不再向服务器获取新的内容。若无缓存则返回504			✓
no-transform	强制要求代理服务器不要对资源进行转换, 禁止代理服务器对 Content-Encoding, Content-Range, Content-Type字段的修改(因此代理的gzip压缩将不被允许)			✓	✓

2.3.1 cache-directive大小写不敏感

如上，cache-directive指令大小写不敏感，所以在设置Cache-Control时，指令可以不区分大小写。不过建议统一使用小写。验证如下：

执行node cache-directive-case-insensitive.js，会服务端会将max-age写成大写，如下Cache-Control: MAX-AGE=86400。
再次请求浏览器会发现缓存同样会生效。

2.3.2 在请求头中的max-age

max-age在请求头中的主要应用为max-age=0表示不使用缓存。Chrome和Firefox浏览器下的刷新操作（Command+ R / F5）均是在请求头上添加了max-age=0�指令，表示不使用强缓存，但允许协商缓存（在介绍了协商缓存的Last-Modified和ETag之后，可以自行验证下这一点）。

刷新时Cache-Control为max-age=0验证如下：

单独访问图片资源http://localhost:1030/avatar.jpg，开启Network
刷新，可在响应头中看到上述内容。（Firefox下相同，不单独验证，主要最开始提到的主资源和派生资源在两个浏览器中表现形式的不同）。

Chrome下刷新时，请求中的max-age值

此外，经验证，Chrome和Firefox均对max-age>0的情况支持不好。
在Chrome下，通过Modify Headers插件（Chrome和Firefox下均有类似插件）给请求添加max-age=7200。
执行node cache-max-age.js，访问http://localhost:1030，先强刷保证资源更新。
打开NetWork，查看avatar.jpg，刷新，会发现，资源访问仍然走的是缓存。如果按照规范的定义应该是不生效。

max-age > 0 在Chrome/Firefox下无效

2.3.3 max-age与Expires

Cache-Control中的max-age指令用于指定缓存过期的相对时间。资源达到指定时间后过期。该功能与Expires类似。但其优先级高于Expires，如果同时设置max-age和Expires，max-age生效，忽略Expires。验证如下：

执行node cache-max-age+Expires.js，会同时设置Cache-Control: max-age=86400 / Expires: Mon Oct 20 2018 00:00:00 GMT+0800 (CST)。

同时设置max-age和Expires
刷新，然后再把本地时间改成当前时间延后2小时(不超过20号)，会发现缓存生效。(以下两步不再附截图，与上述示例类似)。
如果将时间改为两天后（假设20号离现在大于两天，否则结果相反），会发现缓存不再生效，因为超出了max-age的限制。

相反，可以再试一下，max-age的有效时间大于Expires的情况，会发现依然是max-age生效。

2.3.4 no-cache和no-store

还有一点需要注意的是，no-cache并不是指不缓存文件，no-store才是指不缓存文件。no-cache仅仅是表明跳过强缓存，强制进入协商策略。

2.3 Pragma

http1.0字段, 通常设置为Pragma:no-cache, 作用与Cache-Control:no-cache相同。当在浏览器进行强刷（Comand + Shift + R / Ctrl + F5）或在NetWork面板内勾选禁用缓存（Disable Caches）时，会自动带上Pragma:no-cache和Cache-Control:no-cache，并且不会带上协商策略中所涉及的信息（下面介绍的If-Modified-Since/If-None-Match） 。这是不会使用任何缓存，重新获取资源。

强刷浏览器自动设置no-cache

2.4 Last-Modified/If-Modified-Since/If-Unmodified-Since

Last-Modified用于标记请求资源的最后一次修改时间。语法格式为：Last-Modified: <day-name>，<day> <month> <year> <hour>:<minute>:<second> GMT，即GMT(格林尼治标准时间)。可用 new Date().toGMTString()获取当前GMT时间。由于Last-Modified只能精确到秒，因此不适合在一秒内多次改变的资源。

如果Expires，Cache-Control: max-age，或 Cache-Control:s-maxage都没有在响应头中出现，并且设置了Last-Modified时，那么浏览器默认会采用一个启发式的算法，即启发式缓存。通常会取响应头的Date_value - Last-Modified_value值的10%作为缓存时间。验证如下：

执行node cache-Last-Modified.js，服务器会获取资源的最后修改时间，设置为Last-Modified的值。访问localhost:1030，查看avatar.jpg。

Last-Modified设定
刷新浏览器，会发现图片会从缓存获取。
通过启发式缓存的公司可以计算出缓存的时间，修改本地时间超过缓存时间后，再刷新，会发现缓存失效。

2.4.1 If-Modified-Since

返回的资源带有Last-Modified标识时，再次请求该资源，浏览器会自动带上If-Modified-Since，值为返回的Last-Modified值。请求到达服务器后，服务器进行判断，如果从上次更新后没有再更新，则返回304。如果更新了则重新返回。验证如下：

执行node cache-Last-Modified.js，服务器会获取资源的最后修改时间，设置为Last-Modified的值。如下图所示，并且注意看一下资源的大小。

Last-Modified设定

请求资源大小

刷新页面，再次查看NetWork。会发现请求头中带上了If-Modified-Since。如果服务器判断资源未改变，则返回304，此外由于服务器返回304，资源会从缓存获取，所以资源大小也减少了。

304 请求资源大小
修改index.html文件的内容，再次刷新。会发现返回变成200，html内容更新了，并且返回了新的Last-Modified的值，资源大小也相应地改变了。

修改后资源大小

304请求也可以触发存储策略，如文章开头的流程判断图所示，可自行验证，返回时添加相应header即可。

注意，If-Modified-Since只能用于GET、HEAD请求。

2.4.2 If-Unmodified-Since

If-Unmodified-Since表示资源未修改则正常执行更新，否则返回412(Precondition Failed)状态码的响应。主要有如下两种场景。

用于不安全的请求中从而是请求具备条件性（如POST或者其他不安全的方法），如请求更新wiki文档，文档未修改时才执行更新。
与If-Range字段同时使用时，可以用来保证新的片段请求来自一个未修改的文档。

2.5 ETag/If-Match/If-None-Match

ETag是请求资源在服务器的唯一标识，浏览器可以根据ETag值缓存数据。在再次请求时通过If-None-Match携带上次的ETag值，如果值不变，则返回304，如果改变你则返回新的内容。

需要注意的是，ETag和If-None-Match的值均为双引号包裹的。

验证步骤与Last-Modified相似。执行node cache-ETag.js即可。此处不再详述。

If-Match判断逻辑逻辑与If-None-Match相反。

最后，ETag的优先级高于Last-Modified。当ETag和Last-Modified，ETag优先级更高，但不会忽略Last-Modified，需要服务端实现。验证如下，其中服务端判断优先级：

执行node cache-ETag+Last-Modified.js。服务端会在资源的响应头中，同时设置ETag和Last-Modified。

同时设置ETag和Last-Modified
刷新浏览器，会发现index.html请求时304。查看node日志，会看到ETag生效。

HTTP 协议*3 ｜ 青训营