一、 什么是域名发散和域名收敛？
1、域名发散
为了突破浏览器对于同一域名并发请求数的限制，http 静态资源采用多个子域名，通常为2～4个。
目的是充分利用现代浏览器的多线程并发下载能力。
2、域名收敛
域名收敛和域名发散正好相反：就是将静态资源只放在一个域名下面，而非发散情况下的多个域名下。
主要是为了适应移动端的发展需求。
二、为什么浏览器要做并发限制呢？
- 以前网速慢、服务器硬件设备差、负载能力差，容易崩溃，所以要对
最大并发数进行限制 - 防止 DDOS 攻击
三、什么是 DDOS 攻击？DDOS 攻击方式有哪些？如何应对 DDOS 攻击？
1、什么是 DDOS 攻击
分布式拒绝服务攻击(Distributed denial of service attack)
向目标系统同时提出数量庞大的服务请求。
2、DDOS 攻击方式
- 通过使网络过载来干扰甚至阻断正常的网络通讯；
- 通过向服务器提交大量请求，使服务器超负荷；
- 阻断某一用户访问服务器；
- 阻断某服务与特定系统或个人的通讯。
3、如何应对 DDOS 攻击
- 黑名单
- DDOS 清洗：对用户请求数据进行实时监控，及时发现
DOS攻击等异常流量，在不影响正常业务开展的情况下清洗掉这些异常流量。 - CDN 加速
- 高防服务器：高防服务器主要是指能独立硬防御 50Gbps 以上的服务器，能够帮助网站拒绝服务攻击，定期扫描网络主节点
四、http请求过程
- 对
www.abc.com这个网址进行DNS域名解析，得到对应的IP地址 - 根据这个
IP，找到对应的服务器，发起TCP的三次握手 - 建立
TCP连接后发起HTTP请求 - 服务器响应
HTTP请求，浏览器得到html代码 - 浏览器解析
html代码，并请求html代码中的资源（如js、css、图片等）（先得到html代码，才能去找这些资源） - 浏览器对页面进行渲染呈现给用户
- 服务器关闭关闭
TCP连接
1、DNS 域名如何解析的？
DNS域名解析采用的是递归查询的方
先去找DNS缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级，递归查找之后，找到了，给我们的web浏览器。
- 浏览器首先搜索自身的DNS缓存，看缓存中是否有
www.abc.com这个域名，有而且没有过期的话，解析结束。 - 如果浏览器自身的缓存中没有找到，则会搜索操作系统自身的DNS缓存，如果找到且没有过期则停止搜索，解析到此结束。
- 如果在操作系统的DNS缓存中也没有找到，那么尝试读取hosts文件，有则解析成功，解析到此结束。
- 如果在hosts文件中也没有找到，浏览器会发起一个DNS（Domain Name System：域名服务协议）系统调用，向本地配置的首选DNS服务器发起域名解析请求 （递归请求）
- 运营商的DNS服务器首先查找自身的缓存，如果能找到且没有过期则解析成功。
- 如果没有找到，则运营商的
DNS代我们的浏览器发起迭代DNS解析请求。 - 运营商DNS首先会查找根域DNS的IP地址（这个DNS服务器内置13台根DNS域服务器的IP地址），找到根域的
DNS地址，就会向其发起请求（（问一下www.abc.com这个域名的ip地址是多少啊？））。根域发现这是一个com域（顶级域）的域名，于是返回com域的IP地址，然后运营商的DNS就得到com域的IP地址。 - 运营商的DNS得到com域的IP地址之后又向com域的IP地址发起地址请求（问一下
www.abc.com这个域名的IP地址是多少啊？）。com域这台服务器告诉运营商的DNS我不知道www.abc.com这个域名的IP地址，但是我知道abc.com这个域名的DNS地址，你去找它吧。 - 运营商的
DNS又向abc.com这个域名的DNS地址发起请求，（问一下www.abc.com这个域名的IP地址是多少？） - 这个时候
abc.com域的DNS服务器在本地查找。 - 把找到的结果发给运营商的
DNS服务器，这个时候运营商的DNS服务器就拿到了www.abc.com对应的IP地址，并返回给Windows系统内核，内核就把这个结果返回给浏览器，最终浏览器得到这个IP地址，进行下一步动作。
2、TCP三次握手
- 客服端首先发送一个连接试探。
- 服务器监听到连接请求报文后，如果同意建立连接，则向
Client发送确认。 Client收到确认后还需要再次发送确认，同时携带要发送给Server的数据。
3、为什么要三次握手？
- 验证服务端和客户端是否遵循
TCP/IP协议 - 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
4、为什么HTTP协议要基于TCP来实现？
TCP是一个端到端的可靠的面相连接的协议，HTTP基于传输层TCP协议不用担心数据传输的各种问题（当发生错误时，会重传）
5、什么是面相连接协议？面向无链接协议又是什么？
1. 面相连接协议定义
通信双方在通信时，要事先建立好一条通信线路（虚拟的）。
其过程有建立连接、维护连接、释放（断开）连接三个过程。
TCP是面向连接的
2. 面向无链接协议定义
与面向连接相对，面向无连接是指通信双方不需要事先建立通信线路，而是把每个带有目的地址的报文分组送到线路上，由系统自主选定线路进行传输。
面向无连接只有**“传送数据”**的过程。
UDP是面向无连接的
6、说到三次握手，那在说下四次挥手吧？
- 客户端进程发出连接释放报文，并且停止发送数据。
- 服务器收到连接释放报文，发出确认报文，此时，服务端就进入了
CLOSE-WAIT（关闭等待）状态。(客户端向服务器方向释放了，但是服务器发送数据，客户端依然要接受) - 客户端收到服务器的确认请求后，客户端就进入
FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。 - 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，服务器就进入了
LAST-ACK（最后确认）状态，等待客户端的确认。 - 客户端收到服务器的连接释放报文后，必须发出确认，客户端就进入了
TIME-WAIT（时间等待）状态。 - 服务器只要收到了客户端发出的确认，立即进入
CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。（服务器结束TCP连接的时间要比客户端早一些。）
1、为什么要四次挥手
TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
2、为什么建立连接是三次握手，关闭连接确是四次挥手呢？
建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
7、如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器。但是客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
8、http请求方式有哪些？
- GET：请求一个指定资源的表示形式. 使用
GET的请求应该只被用于获取数据。 - HEAD：请求一个与
GET请求的响应相同的响应，但没有响应体。 - POST：将实体提交到指定的资源。
- PUT：请求有效载荷替换目标资源的所有当前表示。
- DELETE：删除指定的资源。
- OPTIONS：用于描述目标资源的通信选项。
- PATCH：对资源应用部分修改。
- CONNECT：建立一个到由目标资源标识的服务器的隧道。
- TRACE：沿着到目标资源的路径执行一个消息环回测试。
9、常用的请求状态码？
| 状态码 | 含义 | 内容 |
|---|---|---|
| 200 | OK | 表明请求已经成功. 默认情况下状态码为200的响应可以被缓存 |
| 201 | Created | 表示该请求已成功，并因此创建了一个新的资源。 |
| 202 | Accepted | 表示服务器端已经收到请求消息，但是尚未进行处理 |
| 203 | Non-Authoritative Information | 表示服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。 |
| 204 | No Content | 表示服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。 |
| 205 | Reset Content | 表示服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。 |
| 206 | Partial Content | 表示服务器已经成功处理了部分 GET 请求。 |
| 300 | Multiple Choices | 表示重定向的响应状态码，表示该请求拥有多种可能的响应 |
| 301 | Moved Permanently | 说明请求的资源已经被移动到了由 Location 头部指定的url上，是固定的不会再改变 |
| 302 | Found | 表明请求的资源被暂时的移动到了由Location 头部指定的 URL 上 |
| 303 | OK | 表示重定向链接指向的不是新上传的资源，而是另外一个页面，比如消息确认页面或上传进度页面 |
| 304 | See Other | 表示重定向链接指向的不是新上传的资源，而是另外一个页面，比如消息确认页面或上传进度页面 |
| 307 | Temporary Redirect | Temporary Redirect（临时重定向）是表示重定向的响应状态码，说明请求的资源暂时地被移动到 Location 首部所指向的 URL 上 |
| 308 | Permanent Redirect | Permanent Redirect（永久重定向） |
| 400 | Bad Request | 代表客户端错误，表示由于语法无效，服务器无法理解该请求 |
| 401 | Unauthorized | 代表客户端错误，指的是当前请求需要用户验证。 |
| 403 | Forbidden | 代表客户端错误，服务器已经理解请求，但是拒绝执行它。 |
| 404 | Not Found | 代表客户端错误，指的是服务器端无法找到所请求的资源 |
| 405 | Method Not Allowed | 表明请求行中指定的请求方法不能被用于请求相应的资源。 |
| 406 | Not Acceptable | 表示客户端错误，指代服务器端无法提供与 Accept-Charset 以及 Accept-Language 消息头指定的值相匹配的响应 |
| 407 | Proxy Authentication Required | 代表客户端错误，指的是由于缺乏位于浏览器与可以访问所请求资源的服务器之间的代理服务器（proxy server ）要求的身份验证凭证，发送的请求尚未得到满足 |
| 408 | Request Timeout | 表示服务器想要将没有在使用的连接关闭 |
| 409 | Conflict | 表示请求与当前服务器端的状态相冲突 |
| 410 | Gone | 说明请求的内容在服务器上不存在了，同时是永久性的丢失 |
| 411 | Length Required | 属于客户端错误，表示由于缺少确定的Content-Length 首部字段，服务器拒绝客户端的请求 |
| 412 | Precondition Failed | 表示客户端错误，意味着对于目标资源的访问请求被拒绝 |
| 413 | Payload Too Large | 表示请求主体的大小超过了服务器规定的限度，服务器可以选择关闭连接或者返回 Retry-After 首部字段 |
| 414 | URI Too Long | 表示客户端所请求的 URI 超过了服务器允许的范围 |
| 415 | Unsupported Media Type | 表示服务器由于不支持其有效载荷的格式，从而拒绝接受客户端的请求 |
| 416 | Range Not Satisfiable | 意味着服务器无法处理所请求的数据区间，最常见的情况是所请求的数据区间不在文件范围之内 |
| 417 | Expectation Failed | 意味着服务器无法满足 Expect 请求消息头中的期望条件 |
| 426 | Upgrade Required | 表示服务器拒绝处理客户端使用当前协议发送的请求，但是可以接受其使用升级后的协议发送的请求 |
| 428 | Precondition Required | 这种情况意味着必要的条件首部——如 If-Match ——的缺失 |
| 429 | Too Many Requests | 表示在一定的时间内用户发送了太多的请求，即超出了“频次限制” |
| 431 | Request Header Fields Too Large | 表示由于请求中的首部字段的值过大，服务器拒绝接受客户端的请求 |
| 451 | Unavailable For Legal Reasons | 表示服务器由于法律原因，无法提供客户端请求的资源，例如可能会导致法律诉讼的页面 |
| 500 | Internal Server Error | 表示服务器遇到了不知道如何处理的情况。 |
| 501 | Not Implemented | 服务器错误响应码表示请求的方法不被服务器支持，因此无法被处理 |
| 502 | Bad Gateway | 表示此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。 |
| 503 | Service Unavailable | 表示服务器尚未处于可以接受请求的状态 |
| 504 | Gateway Timeout | 表示扮演网关或者代理的服务器无法在规定的时间内获得想要的响应 |
| 505 | HTTP Version Not Supported | 表示服务器不支持请求所使用的 HTTP 版本 |
| 511 | Network Authentication Required | 表示客户端需要通过验证才能使用该网络 |
五、TCP和UDP的区别以及应用场景
1、UDP
- UDP在传输层上
- 是面向无连接的
- 不需要建立可靠的连接
- 是面向报文
- 限制就是发送一些比较小的包文件，而且没有错误处理机制。包没了就是没了。可以做一些处理，比如超时重发
- 一对一、一对多、多对一、多对多通信
- 适用于实时应用
2、TCP
- TCP在传输层上
- 是TCP是面向连接的
- 可以互相信任的进行数据发送，这样的保密性强一些
- 面向字节流
- 一对一通信
- 适用于可靠传输的应用
3、应用场景
| UDP | TCP |
|---|---|
| app应用 | web browsing |
| DNS查找 | |
| 广播传输,流媒体 | 文件传输 |
| 线上游戏 | 线上游戏 |
六、http和https
HTTP：(HyperText Transfer Protocol)超文本传输协议
HTTPS：(Hypertext Transfer Protocol Secure)超文本传输安全协议
1、http和https的区别
| 名称/区别 | http | https |
|---|---|---|
| 名称 | 超文本传输协议 | 超文本传输安全协议 |
| 默认端口 | 80 | 443 |
| 发送方式 | 明文发送 | 加密传输 |
| 安全性 | 安全性相对差 容易被监听 被伪装 被篡改 | 安全性相对较好 防止监听 防止伪装 防止篡改 |
| 响应速度 | 响应快(3个包) | 响应慢(12个包) tcp 3个 ssl 9个 |
| 成本 | 较低 | 成本较高 证书需要购买 |
| 链接缓存 | 相对高效 | 相对不高 会增加数据开销和功耗 |
2、https的访问过程
- 客户使用
https的URL访问Web服务器，要求与Web服务器建立SSL连接。 Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。- 客户端的浏览器与
Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。 - 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
Web服务器利用自己的私钥解密出会话密钥。Web服务器利用会话密钥加密与客户端之间的通信。
详细解释：
- 客户端发起
HTTPS请求
用户在浏览器里输入一个https网址，然后连接到server的443端口。
- 服务端的配置
就是指上述提到的数字证书；
- 传送证书
Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
- 客户端解析证书
客户端会对证书进行判断，验证公钥是否有效，存在问题弹出会警告；若没有问题，生成一个随机值（私钥），然后用证书继续进行加密；
- 传送加密信息
客户端将上加密后的随机值（私钥）提供给服务端，服务端会对其进行解密；
- 服务端解密信息
服务端解密后得到随机值（私钥），然后把内容通过该值进行对称加密。对称加密就是指把要返回的信息和随机值（私钥）混合加密，这样除非知道随机值（私钥），不然无法获取数据。
- 传输加密后的信息
继续将加密后的信息传递给客户端；
- 客户端解密信息
客户端用之前生成的私钥（随机值）解密服务端传过来的信息，于是获取了解密后的内容。
3、https的优缺点？
1. 优点
- 正确发送数据到客户端
使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器
- 更安全
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性
- 增加中间人攻击的成本
HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
- 搜索排名更高
谷歌在2014跳转搜索算法，采用HTTPS加密的网站在搜索结果中的排名将会更高
百度也在2018年发布百度对HTTPS站点的扶持态度，表明HTTPS将作为优质特征之一影响搜索排序。
2、缺点
- 页面渲染更耗时间
因为SSL的缘故，HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%；
- 成本增加
SSL证书需要花钱，功能越强大的证书费用越高；
- HTTPS连接缓存不如HTTP高效
HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
- SSL证书通常需要绑定IP
SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
- 有局限性
HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
4、https如何进行性能优化？
1、https访问速度优化
- 设置HSTS
服务端返回一个 HSTS 的 http header，浏览器获取到 HSTS 头部之后，在一段时间内，不管用户输入www.baidu.com还是http://www.baidu.com，都会默认将请求内部跳转成https://www.baidu.com。
- Session resume
Session Resume 顾名思义就是复用 Session，实现简化握手。
1. 减少了 CPU 消耗，因为不需要进行非对称密钥交换的计算。
2. 提升访问速度，不需要进行完全握手阶段二，节省了一个 RTT 和计算耗时。
3. Nginx设置Ocsp stapling
OSCP Stapling 工作原理简单来说就是浏览器发起 Client Hello 时会携带一个 certificate status request 的扩展，服务端看到这个扩展后将 OCSP 内容直接返回给浏览器，完成证书状态检查。由于浏览器不需要直接向 CA 站点查询证书状态，这个功能对访问速度的提升非常明显。
- 使用
SPDY或者HTTP2
SPDY 最大的特性就是多路复用，能将多个 HTTP 请求在同一个连接上一起发出去，不像目前的 HTTP 协议一样，只能串行地逐个发送请求。
HTTP2支持多路复用，有同样的效果。
1. SPDY 和 HTTP2 目前的实现默认使用 HTTPS 协议。
2. SPDY 和 HTTP2 都支持现有的 HTTP 语义和 API，对 WEB 应用几乎是透明的。
5. False start
简单概括 False Start 的原理就是在 client_key_exchange 发出时将应用层数据一起发出来，能够节省一个 RTT。
2、https计算性能优化
- 优先使用 ECC椭圆加密算术。
ECC 椭圆加密算术相比普通的离散对数计算速度性能要强很多。
- 使用最新版的 openssl。
一般来讲，新版的 OpenSSL 相比老版的计算速度和安全性都会有提升。
- 硬件加速方案。
- SSL 专用加速卡。
- GPUSSL 加速。
- TLS 远程代理计算
七、http/2
1、http/2项目设定目标
- 页面加载时间 (PLT) 减少 50%。
- 无需网站作者修改任何内容。
- 将部署复杂性降至最低，无需变更网络基础设施。
- 与开源社区合作开发此新协议。
- 收集真实性能数据，验证实验性协议是否有效。
2、http/2特性
1. 二进制分帧层
HTTP/2 所有性能增强的核心在于新的二进制分帧层，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。
2. 多路复用(请求与响应复用)
HTTP/2 中新的二进制分帧层突破了这些限制，实现了完整的请求和响应复用：客户端和服务器可以将 HTTP 消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来。
3. 数据流优先级
将 HTTP 消息分解为很多独立的帧之后，我们就可以复用多个数据流中的帧，客户端和服务器交错发送和传输这些帧的顺序就成为关键的性能决定因素。 为了做到这一点，HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系：
- 可以向每个数据流分配一个介于 1 至 256 之间的整数。
- 每个数据流与其他数据流之间可以存在显式依赖关系。
4. 每个来源一个连接
每个数据流都拆分成很多帧，而这些帧可以交错，还可以分别设定优先级。 因此，所有 HTTP/2 连接都是永久的，而且仅需要每个来源一个连接，随之带来诸多性能优势。
5. 流控制
流控制是一种阻止发送方向接收方发送大量数据的机制，以免超出后者的需求或处理能力：发送方可能非常繁忙、处于较高的负载之下，也可能仅仅希望为特定数据流分配固定量的资源。
6. 服务器推送
HTTP/2 新增的另一个强大的新功能是，服务器可以对一个客户端请求发送多个响应。 换句话说，除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端明确地请求。
7. 标头压缩
每个 HTTP 传输都承载一组标头，这些标头说明了传输的资源及其属性。
HTTP/2 使用 HPACK 压缩格式压缩请求和响应标头元数据，这种格式采用两种简单但是强大的技术：
- 这种格式支持通过静态霍夫曼代码对传输的标头字段进行编码，从而减小了各个传输的大小。
- 这种格式要求客户端和服务器同时维护和更新一个包含之前见过的标头字段的索引列表（换句话说，它可以建立一个共享的压缩上下文），此列表随后会用作参考，对之前传输的值进行有效编码。
八、说下http缓存吧
1、什么是缓存？又有什么用？
定义：缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。
作用：
- 可以显著提高网站和应用程序的性能。
- 减少了等待时间和网络流量
- 减少了显示资源表示形式所需的时间。
- 是页面更加响应性。
- 缓解服务器端压力，提升性能。
2、你知道有哪些缓存方式吗？
- 浏览器缓存
- 代理缓存
- 网关缓存
- CDN缓存
- 反向代理缓存
3、缓存位置
- Service Worker
- Memory Cache
- Disk Cache
- Push Cache
1. Service Worker
Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。
2. Memory Cache (内存中的缓存)
读取高效，但是持续性很短，一旦关闭 Tab 页面，内存中的缓存也就被释放了。
3. Disk Cache (硬盘中的缓存)
读取速度慢，容量和存储时效性上有优势，
4. Push Cache (推送缓存)
push Cache 是 http/2 中的内容，只在会话（Session）中存在，一旦会话结束就被释放，并且缓存时间也很短暂。
4、http缓存怎样生效的？
http缓存分为强制缓存和协商缓存
1. 强制缓存
强制缓存就是文件直接从缓存中获取，不需要发送请求
2. 协商缓存
协商缓存意思是文件已经被缓存了，但是否从缓存中读取是需要和服务器进行协商，具体如何协商要看请求头/响应头的字段设置。
协商缓存还是会发送请求的。
3. 强缓存-Cache-Control
Cache-Control 通用消息头字段，被用于在http请求和响应中，通过指定指令来实现缓存机制。
1. 缓存请求指令
Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: only-if-cached
2. 缓存响应指令
Cache-control: must-revalidate
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds>
3. 指令解释
| 指令名 | 解释 |
|---|---|
| public | 表明响应可以被任何对象（客户端，代理服务器，等等）缓存。 |
| private | 表明响应只能被单个用户缓存，不能作为共享缓存（即代理服务器不能缓存它）。 |
| no-cache | 强制要求缓存把请求提交给原始服务器进行验证(协商缓存验证)。 |
| no-store | 不使用任何缓存。 |
max-age=<seconds> | 设置缓存存储的最大周期。 |
s-maxage=<seconds> | 覆盖max-age或者Expires头，但是仅适用于共享缓存(比如各个代理)，私有缓存会忽略它。 |
max-stale[=<seconds>] | 表示多少时间内，及时缓存过期也适用缓存 |
min-fresh=<seconds> | 表示在多少时间内获取最新的响应 |
| must-revalidate | 一旦资源过期（比如已经超过max-age），在成功向原始服务器验证之前，缓存不能用该资源响应后续请求。 |
| proxy-revalidate | 与must-revalidate作用相同，但它仅适用于共享缓存（例如代理），并被私有缓存忽略。 |
| immutable | 表示响应正文不会随时间而改变。 |
| no-transform | 不得对资源进行转换或转变。 |
| only-if-cached | 客户端只接受已缓存的响应，并且不要向原始服务器检查是否有更新的拷贝。 |
