3.1Http设计思想分析

目录介绍

  • 01.什么是Http协议
  • 02.Http各个版本
  • 03.Http连接的特点
  • 08.Http代理介绍
  • 09.Http和Tcp和Socket
  • 13.Http持久连接
  • 14.Http常见状态码
  • 15.Http缓存原理

01.什么是Http协议

  • HTTP协议是一种应用层协议
    • HTTP是HyperText Transfer Protocol(超文本传输协议)的英文缩写。HTTP可以通过传输层的TCP协议在客户端和服务器之间传输数据。
    • HTTP协议主要用于Web浏览器和 Web服务器之间的数据交换。我们在使用IE或Firefox浏览网页或下载Web资源时，通过在地址栏中输入，开头的4个字母http就相当于通知浏览 器使用HTTP协议来和host所确定的服务器进行通讯。

02.Http各个版本

  • Http1.0版本
    • HTTP协议是一种应用层协议
    • HTTP是HyperText Transfer Protocol(超文本传输协议)的英文缩写。HTTP可以通过传输层的TCP协议在客户端和服务器之间传输数据。HTTP协议主要用于Web浏览器和 Web服务器之间的数据交换。我们在使用IE或Firefox浏览网页或下载Web资源时，通过在地址栏中输入，开头的4个字母http就相当于通知浏览 器使用HTTP协议来和host所确定的服务器进行通讯。
  • HTTP1.0和HTTP1.1的区别：
    • HTTP1.0默认使用短连接，HTTP1.1开始默认使用长连接
    • HTTP1.1增加更多的请求头和响应头来改进和扩充HTTP1.0的功能，比如身份认证、状态管理和Cache缓存等
    • 现在更多是使用Http1.1
  • Http2.0版本
    • Okhttp支持配置使用Http 2.0协议
    • Http2.0相对于Http1.x来说提升是巨大的，主要有以下几点：
      • 二进制格式:http1.x是文本协议，而http2.0是二进制以帧为基本单位，是一个二进制协议，一帧中除了包含数据外同时还包含该帧的标识：StreamIdentifier，即标识了该帧属于哪个request,使得网络传输变得十分灵活。多路复用:一个很大的改进，原先http1.x一个连接一个请求的情况有比较大的局限性，也引发了很多问题，如建立多个连接的消耗以及效率问题。
      • http1.x为了解决效率问题，可能会尽量多的发起并发的请求去加载资源，然而浏览器对于同一域名下的并发请求有限制，而优化的手段一般是将请求的资源放到不同的域名下来突破这种限制。而http2.0支持的多路复用可以很好的解决这个问题，多个请求共用一个TCP连接，多个请求可以同时在这个TCP连接上并发，一个是解决了建立多个TCP连接的消耗问题，一个也解决了效率的问题。
      • 那么是什么原理支撑多个请求可以在一个TCP连接上并发呢？基本原理就是上面的二进制分帧，因为每一帧都有一个身份标识，所以多个请求的不同帧可以并发的无序发送出去，在服务端会根据每一帧的身份标识，将其整理到对应的request中。header头部压缩:主要是通过压缩header来减少请求的大小，减少流量消耗，提高效率。因为之前存在一个问题是，每次请求都要带上header，而这个header中的数据通常是一层不变的。 支持服务端推送
  • Http各版本比较
    • 绘制思维导图如下所示
    • image
      image

03.Http连接的特点

  • 描述下http连接的特点？
    • 最显著的特点是，客户端每次发送的请求，都需要服务器响应，请求结束后，会主动释放连接。从建立连接到关闭连接的过程，成为”一次连接”。

08.Http代理介绍

8.1 什么 HTTP 代理？

  • 说到 HTTP 代理
    • 作为客户端开发，最熟悉的就是使用 Fiddler、Charles 等工具进行抓包时，需要在手机上挂个代理，来方便我们排查一些网络问题，这只是代理众多使用场景中的一个。
    • 实际上，HTTP 代理（Web代理）是一种存在于网络中间的实体，可以提供各种功能。如果没有 HTTP 代理，客户终端就要直接与终端服务器进行交互。而有了 HTTP 代理后，客户终端就可以与代理通信，然后由代理代表客户端与服务器进行交互。
  • 代理服务
    • 就是代理客户端完成事务处理的中间人，它接管客户端的事务，代替客户端与服务端交互。
    • 代理服务是一个抽象的中间实体，可以存在网络的各个中间点，浏览器、路由器、代理服务器、Web 服务器的反向代理等，

8.2 HTTP 代理的分类

  • 从最熟悉的抓包工具说起
    • Fiddler、Charles 这种抓包工具，封装的都非常好，哪怕我们完全不理解 HTTP 代理的细节，简单配置就可以使用。
  • 在使用过程中，你会发现两种场景：
    • 对于 HTTP 协议请求，可以直接显示请求/响应报文的细节
    • 对于 HTTPS ，如果没有导入证书，请求依然可以发送至服务器，并且也可以正常返回数据，但是不会显示报文细节。
  • 在没有导入证书的情况下，HTTPS 请求我们无法获知细节，但是并不影响我们的请求和响应。
  • 这个两种不同的表现，也对应了两种不同的 HTTP 代理：
    • 普通代理。基于修订后的 RFC 2616 在 HTTP/1.1 中被定义。这种代理扮演的是「中间人」的角色。对客户端来说，它是服务端，而对真正的服务端来说，它又是客户端，它就是负责在两端之间传递 HTTP 报文。
    • 隧道代理。这种一种基于 TCP 协议的隧道传输代理，它通过 HTTP 协议的 CONNECT 方法完成通信，以 HTTP 的方式，实现任意基于 TCP 的应用层协议代理。

8.3 普通代理

  • 普通代理
    • 它是网络中的中间实体，位于客户端和服务端之间，扮演「中间人」的角色，在两端之间来回传递报文。
    • 这个「中间人」左手牵着客户端，右手牵着服务端，在收到客户端发送的请求报文时，需要正确的处理请求和连接状态，同时向服务器发送新的请求，在收到响应后，将响应结果包装成一个响应体返回给客户端。
  • 在普通代理的流程中，代理两端都是有可能察觉不到「中间人」的存在。
    • 举个例子，我们要访问 A 网站，实际上我们是向代理服务器发送请求，而代理服务器又再向 A 网站发起请求，最终将响应体通过代理服务器，返回给我们。在我们的角度，我们正常的向一个网站服务器发起请求，并且对方也返回给我们正确的数据，在这个过程中，我作为客户端，会认为代理服务器就是 A 网站的服务器，而 A 网站的服务器，又认为代理服务器是一个真实的用户。

这里说到，代理服务器作为「中间人」是可以隐藏自己的存在，但是如果我们作为一个“守规矩”的代理服务器，想要将客户端的 IP 传递给服务端，可以通过 X-Forwarded-IP 这个自定义的 Header，来告诉服务端真正的客户端 IP 地址。

HTTP 协议作为一种松散的协议，服务器在接收到 X-Forwarded-IP 这个请求头时，是无法验证其真伪的。它可能是代理服务器伪造的，也可能是真实的。所以服务端从 HTTP 头部获取 IP 时，就需要格外小心。

普通代理很好理解，但是它也有缺陷，它只适用于 HTTP 协议。

在普通代理模式下，所有请求响应的数据，对于代理这个「中间人」来说，都是透明并且可以任意操作，这就会带来各种数据安全的隐患。

说到网络数据安全，首先想到的就是 HTTPS，但是 HTTPS 这种证书认证的机制，又是中间人劫持的克星。

严格上来说，HTTPS 下不存在中间人攻击，除非是人为的犯错了，没有对证书严格校验，或者证书被泄露。

在普通的 HTTPS 请求中，服务端不验证客户端的证书，中间人可以作为客户端与服务端完成 TLS 握手。

但是由于代理中间人没有证书密钥，也就无法伪造服务端和客户端简历的 TLS 连接，这会导致请求失败。

这个场景，对标到抓包工具的工作流程中，你会发现，如果想用 Charles（或Fiddler） 抓 HTTPS 的网络数据包，就需要在手机上安装一个 Charles 的 CA 证书，让手机设备信任此证书，才可以完成抓包，此时走的就是普通代理的模式。

那换个角度，假如在手机上没有安装 Charles 提供的证书，也并没有影响到请求和响应，Charles 只是无法解密 HTTPS 数据，这是如何做到的呢？

8.4 隧道代理

隧道代理，又称为 Web 隧道（Web tunnel），这种方式可以通过 HTTP 连接发送非 HTTP 流量，这样可以在 HTTP 上捎带其他协议的数据。

隧道代理是利用 HTTP 的 CONNECT 方法建立起来的。CONNECT 方法，最初并不是 HTTP/1.1 的核心规范，但却是一种得到广泛使用的扩展，它在 2014 年发布的 HTTP/1.1 修订版中，才对 CONNECT 及隧道代理有了清晰的描述。

HTTP 隧道代理的工作流程是什么样的？

一次普通的 HTTP 请求，Header 部分以连续的两组 CRLF（\r\n）作为结束标记，如果后面还有内容，就是 Content 部分的内容，也称为请求/响应体（Content），如果存在 Content 内容，就需要在 Header 中增加 Content-Length 来标记 Content 部分的长度。接收方（服务端）会根据这个长度来读取数据。

CONNECT 报文的请求，是没有 Content 部分的，只有 Request-Line 和 Header，他们仅供代理服务器使用，并不会传递给终端服务器。请求的 Header 部分一旦结束（两组连续的 CRLF），后面的所有数据，都被视为应该转发给终端服务器的数据，代理需要把他们无脑的直接转发，并且不限制长度，直到从客户端的 TCP 读通道关闭。

CONNECT 的响应报文，在代理服务器和终端服务器建立连接后，可以向客户端返回一个 200 Connect established 的状态码，以此表示和终端服务器的连接，建立成功。这个 200 Connect established 的 Header 部分一旦结束（两组连续的 CRLF），后面所有的数据均为远端服务器返回的数据，同理，代理服务器会直接转发终端服务器的数据给客户端，直到终端服务器的 TCP 读通道关闭。

了解清楚 HTTP 隧道的工作流程之后，就知道 CONNECT 方法请求隧道网管创建一条到达任意目的服务器和端口的 TCP 连接，并对客户端和服务端之间的后续数据，进行无脑的盲转发。

通过隧道代理，代理服务器不再作为中间人，不再需要改写浏览器的请求，而是把浏览器和终端服务器的数据，原样转发，这样浏览器就可以直接和终端服务器进行 TLS 握手，并传输加密的数据。

8.5 最后总结一下

  • HTTP 代理可以分为两类，普通代理和隧道代理。
    • 普通代理作为「中间人」存在，在一次请求中，客户端明文请求代理服务器，在收到请求后，代理服务器又明文去请求终端服务器。在这整个过程中，数据都是明文传输，中间人可以对其中传递的数据进行改写，这就是著名的中间人攻击，可见其有多不安全。
    • 这就引申出了支持 HTTPS 的隧道代理，此时代理服务器就不再作为中间人，无法改写客户端的请求，而仅仅是在建立连接后，将客户端的请求，通过建立好的隧道，无脑的转发给终端服务器。

09.Http和Tcp和Socket

  • HTTP 、TCP、Socket三者之间的区别是什么？
    • TCP/IP代表传输控制协议/网际协议，指的是一系列协组
    • HTTP本身就是一个协议，是从Web服务器传输超文本到本地浏览器的传送协议
    • Socket是TCP/IP网络的API其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议
    • 综上所述：需要IP协议来连接网络;TCP是一种允许我们安全传输数据的机制，使用TCP协议来传输数据的HTTP是Web服务器和客户端使用的特殊协议。HTTP基于TCP协议，但是却可以使用socket去建立一个TCP连接
  • HTTP和Socket的区别
    • HTTP是应用层协议；基于TCP协议；使用“请求—响应”方式建立连接，在请求时需要先建立连接且客户端要先发出请求，可见服务器需要等到客户端发送一次请求后才能将数据传回给客户端
    • Socket（套接字）是对TCP/IP协议的封装，是接口而不是协议；创建Socket连接时可以指定传输层协议TCP或UDP；Socket建立连接过程三步骤：服务器监听->客户端请求->连接确认，可见服务器可以直接将数据传送给客户端（HTTP2.0也增加了服务端推送的功能）

13.Http持久连接

13.1 最初通信方式

  • HTTP 协议的初始版本中，每进行一次 HTTP 通信就要断开一次 TCP连接。
    • 以当年的通信情况来说，因为都是些容量很小的文本传输，所以即使这样也没有多大问题。可随着 HTTP 的普及，文档中包含大量图片的情况多了起来。
  • 三次握手保证数据准确性
    • 客户端与服务器端要进行通信，TCP协议为了保证通信的准确性，会进行“三次握手”来保证信息传递的准确性，确认完之后才会进行HTTP请求和响应的传输，传输完之后服务器端发出终止信号FIN，断开TCP连接。
  • 遇到的问题
    • 针对复杂的页面，这样太频繁会造成资源的开销。
    • 比如，使用浏览器浏览一个包含多张图片的 HTML 页面时，在发送请求访问 HTML 页面资源的同时，也会请求该 HTML 页面里包含的其他资源。因此，每次的请求都会造成无谓的 TCP 连接建立和断开，增加通信量的开销。

13.2 解决的方式

  • 解决方式
    • 持久化链接
    • 管线化
  • 持久化链接
    • 什么是持久化链接
      • 为了解决上述TCP连接的问题，HTTP/1.1想出了持久连接的方法，持久连接就是只要任意一端没有明确提出断开连接，则保持TCP连接状态。
      • image
        image
    • 持久连接的好处：
      • 减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
      • 减少开销的那部分时间，使HTTP请求和响应能够更早的结束，因此Web页面显示速度也就相应提高了。
  • 管线化
    • 什么是管线化
      • 持久连接使得多数请求以管线化方式发送称为可能。从前发送请求后需等待并受到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。
      • image
        image
    • 管线化的好处
      • 比如当请求一个包含10张图片的HTMLWeb页面，与挨个连接相比，用持久连接可以让请求更快，而管线化技术则比持久连接还要快。请求越多，时间差就越明显！

13.3 判断传输完成

  • 在早期不支持持久连接的时候，其实是可以依靠连接断开来判定当前传输已经结束，大部分浏览器也是这么干的，但这并不是规范的操作。应该使用 Content-Length 这个头部，来指定当前传输的实体内容长度。
  • 在保持持久连接的情况下，依赖 Content-Length 来确定数据发送完毕。
    • Content-Length 在这里起到了一个响应实体已经发送结束的判断依据。这样的情况下，我们就要求 Content-Length 必须和内容实体的长度一致，如果不一致，就会出现各种问题。
    • 如果 Content-Length 小于内容实体的长度，则会截断，反之则无法判定当前响应已经结束，会将请求持续挂起造成 Padding 状态。
  • 在响应一个请求的时候，就需要知道它的内容实体的大小。
    • 但是在实际应用中，有些时候内容实体的长度并没有那么容易获得。例如内容实体来自网络文件、或者是动态生成的。这个时候如果依然想要提前获取到内容实体的长度，只能开一个足够大的 Buffer，等内容全部缓存好了再计算。
    • 但这并不是一个好的方案，全部缓存到 Buffer 里，第一会消耗更多的内存，第二也会更耗时，让客户端等待过久。
    • 此时就需要一个新的机制，不依赖 Content-Length 的值，来判定当前内容实体是否传输完成，此时就需要 Transfer-Encoding 这个头部来判定。

14.Http常见状态码

  • 服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果。
    状态码类别原因短语
    1XXInformational（信息性状态码）接收的请求正在处理
    2XXSuccess（成功状态码）请求正常处理完毕
    3XXRedirection（重定向状态码）需要进行附加操作以完成请求
    4XXClient Error（客户端错误状态码）服务器无法处理请求
    5XXServer Error（服务器错误状态码）服务器处理请求出错

14.1 关于http状态码介绍

  • 如果向您的服务器发出了某项请求要求显示您网站上的某个网页（例如，当用户通过浏览器访问您的网页或在检测工具抓取该网页时），那么，您的服务器会返回 HTTP 状态代码以响应该请求。
  • 一些常见的状态代码为：
    • 200 - 服务器成功返回网页
    • 404 - 请求的网页不存在
    • 503 - 服务器暂时不可用

14.2 关于1xx【临时响应】

  • 用于表示临时响应并需要请求者执行操作才能继续的状态代码。
  • 100（继续）
    • 请求者应继续进行请求。服务器返回此代码以表示，服务器已收到某项请求的第一部分，正等待接收剩余部分。
  • 101（切换协议）
    • 请求者已要求服务器切换协议，服务器已确认并准备进行切换。

14.3 关于2xx【成功】

  • 用于表示服务器已成功处理相应请求的状态代码。
  • 200（成功）
    • 服务器成功处理了相应请求。通常，这表示服务器已提供了请求的网页。如果您的 robots.txt 文件显示为此状态，则表示 检测工具 已成功检索到该文件。
  • 201（已创建）
    • 请求成功且服务器已创建了新的资源。
  • 202（已接受）
    • 服务器已接受相应请求，但尚未对其进行处理。
  • 203（非授权信息）
    • 服务器已成功处理相应请求，但返回了可能来自另一来源的信息。
  • 204（无内容）
    • 服务器已成功处理相应请求，但未返回任何内容。
  • 205（重置内容）
    • 服务器已成功处理相应请求，但未返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图（例如清除表单内容以输入新内容）。
  • 206（部分内容）
    • 服务器成功处理了部分 GET 请求。

14.4 关于3xx【已重定向】

  • 您需要进一步操作才能完成请求。此类状态代码通常可用于重定向。 建议您针对每一请求使用重定向的次数少于五次。您可以使用网站站长工具确定 检测工具 是否会在抓取重定向网页时遇到问题。抓取下的抓取错误页列出了由于重定向错误而导致 检测工具 无法抓取的网址。
  • 300（多种选择）
    • 服务器可以根据请求来执行多项操作，例如：按照请求者（用户代理）的要求来选择某项操作或者展示列表以便请求者选择其中某项操作。
  • 301（永久移动）
    • 请求的网页已永久移动到新位置。服务器返回此响应（作为对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。您应使用此代码通知 检测工具 某个网页或网站已被永久移动到新位置。
  • 302（临时移动）
    • 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 检测工具 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 检测工具 某个页面或网站已被移动。
  • 303（查看其他位置）
    • 当请求者应对不同的位置进行单独的 GET 请求以检索响应时，服务器会返回此代码。对于除 HEAD 请求之外的所有请求，服务器会自动转到其他位置。
  • 304（未修改）
    • 请求的网页自上次请求后再也没有修改过。当服务器返回此响应时，不会返回相关网页的内容。
    • 如果网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。服务器可以告诉 检测工具 自从上次抓取后网页没有变更，进而节省带宽和开销。
  • 305（使用代理）
    • 请求者只能使用代理访问请求的网页。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
  • 307（临时重定向）
    • 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 检测工具 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 检测工具 某个页面或网站已被移动。

14.5 关于4xx【请求错误】

  • 此类状态代码表示，相应请求可能出错，已阻止了服务器对请求的处理。
  • 400（错误请求）
    • 服务器不理解相应请求的语法。
  • 401（未授权）
    • 请求要求进行身份验证。登录后，服务器可能会返回对页面的此响应。
  • 403（已禁止）
    • 服务器正在拒绝相应请求。如果 检测工具 在尝试抓取网站的有效网页时收到此状态代码（您可在 网站站长工具中运行工具下的抓取错误页上进行查看），则可能是因为您的服务器或主机正在阻止 检测工具 进行访问。
  • 404（未找到）
    • 服务器找不到请求的网页。例如，如果相应请求是针对服务器上不存在的网页进行的，那么服务器通常会返回此代码。
    • 如果您的网站上没有 robots.txt 文件，而您在 网站站长工具中的已拦截的网址页上看到此状态，那么这就是正确的状态。然而，如果您有 robots.txt 文件而又发现了此状态，那么，这说明您的 robots.txt 文件可能是命名错误或位于错误的位置。（该文件应当位于顶级域名上，且应当名为 robots.txt）。
    • 如果您在 检测工具 尝试抓取的网址上看到此状态，那么这表示 检测工具 追踪的可能是另一网页中的无效链接（旧链接或输入有误的链接）。
  • 405（方法禁用）
    • 禁用相应请求中所指定的方法。
  • 406（不接受）
    • 无法使用相应请求的内容特性来响应请求的网页。
  • 407（需要代理授权）
    • 此状态代码与 401（未授权）类似，但却指定了请求者应当使用代理进行授权。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
  • 408（请求超时）
    • 服务器在等待请求时超时。
  • 409（冲突）
    • 服务器在完成请求时遇到冲突。服务器必须在响应中包含该冲突的相关信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会提供两个请求的差异列表。
  • 410（已删除）
    • 如果请求的资源已被永久删除，那么服务器会返回此响应。该代码与 404（未找到）代码类似，但在资源以前有但现在已经不复存在的情况下，有时会替代 404 代码出现。如果资源已永久删除，您应使用 301 指定资源的新位置。
  • 411（需要有效长度）
    • 服务器不会接受包含无效内容长度标头字段的请求。
  • 412（未满足前提条件）
    • 服务器未满足请求者在请求中设置的其中一个前提条件。
  • 413（请求实体过大）
    • 服务器无法处理相应请求，因为请求实体过大，已超出服务器的处理能力。
  • 414（请求的 URI 过长）
    • 请求的 URI（通常为网址）过长，服务器无法进行处理。
  • 415（不支持的媒体类型）
    • 相应请求的格式不受请求页面的支持。
  • 416（请求范围不符合要求）
    • 如果相应请求是针对网页的无效范围进行的，那么服务器会返回此状态代码。
  • 417（未满足期望值）
    • 服务器未满足“期望”请求标头字段的要求。

14.6 关于5xx【服务器错误】

  • 此类状态代码表示，服务器在尝试处理相应请求时发生内部错误。此类错误往往与服务器本身有关（与请求无关）。
  • 500（服务器内部错误）
    • 服务器遇到错误，无法完成相应请求。
  • 501（尚未实施）
    • 服务器不具备完成相应请求的功能。例如，当服务器无法识别请求方法时，可能便会返回此代码。
  • 502（错误网关）
    • 服务器作为网关或代理，从上游服务器收到了无效的响应。
  • 503（服务不可用）
    • 目前无法使用服务器（由于超载或进行停机维护）。通常，这只是暂时状态。
  • 504（网关超时）
    • 服务器作为网关或代理，未及时从上游服务器接收请求。
  • 505（HTTP 版本不受支持）
    • 服务器不支持相应请求中所用的 HTTP 协议版本。

15.Http缓存原理

15.1 http缓存有何控制

  • Http的缓存主要利用header里的两个字段来控制：
    • Cache-control，ETag
  • 缓存优点
    • 缓解服务器压力；
    • 降低客户端获取资源的延迟：缓存通常位于内存中，读取缓存的速度更快。并且缓存在地理位置上也有可能比源服务器来得近，例如浏览器缓存。
  • 缓存实现方法
    • 让代理服务器进行缓存；
    • 让客户端浏览器进行缓存。

15.2 Cache-control介绍

  • Cache-control主要包含以及几个字段：
    private:则只有客户端可以缓存
public:客户端和代理服务器都可以缓存
max-age:缓存的过期时间
no-cache:需要使用对比缓存来验证缓存数据
no-store:所有内存都不会进行缓存
  • 实际上就是在这里面设置了一个缓存策略，由服务端第一次通过header下发给客户端，可以看到：
    • max-age即缓存过期的时间，则之后再次请求，如果没有超过缓存失效的时间则可以直接使用缓存。
    • no-cache:表示需要使用对比缓存来验证缓存数据，如果这个字段是打开的，则就算max-age缓存没有失效，则还是需要发起一次请求向服务端确认一下资源是否有更新，是否需要重新请求数据，至于怎么做对比缓存，就是下面要说的Etag的作用。如果服务端确认资源没有更新，则返回304，取本地缓存即可，如果有更新，则返回最新的资源。
    • no-store:这个字段打开，则不会进行缓存，也不会取缓存。
  • Cache-Control
    • HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。
  • 禁止进行缓存
    • no-store 指令规定不能对请求或响应的任何一部分进行缓存。
    Cache-Control: no-store
  • 强制确认缓存
    • no-cache 指令规定缓存服务器需要先向源服务器验证缓存资源的有效性，只有当缓存资源有效才将能使用该缓存对客户端的请求进行响应。
    Cache-Control: no-cache
  • 私有缓存和公共缓存
    • private指令规定了将资源作为私有缓存，只能被单独用户所使用，一般存储在用户浏览器中。
    Cache-Control: private
    • public 指令规定了将资源作为公共缓存，可以被多个用户所使用，一般存储在代理服务器中。
    Cache-Control: public
  • 缓存过期机制
    • max-age指令出现在请求报文中，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。
    • max-age指令出现在响应报文中，表示缓存资源在缓存服务器中保存的时间。
    Cache-Control: max-age=31536000
    • Expires首部字段也可以用于告知缓存服务器该资源什么时候会过期。
    Expires: Wed, 04 Jul 2012 08:26:05 GMT
    • 在 HTTP/1.1 中，会优先处理 max-age 指令；
    • 在 HTTP/1.0 中，max-age 指令会被忽略掉。

15.3 ETag介绍

  • ETag:即用来进行对比缓存，Etag是服务端资源的一个标识码

    • 当客户端发送第一次请求时服务端会下发当前请求资源的标识码Etag，下次再请求时，客户端则会通过header里的If-None-Match将这个标识码Etag带上，服务端将客户端传来的Etag与最新的资源Etag做对比，如果一样，则表示资源没有更新，返回304。
    • 通过Cache-control和Etag的配合来实现Http的缓存机制。

  • URL 不能唯一表示资源，例如 http://www.google.com/ 有中文和英文两个资源，只有 ETag 才能对这两个资源进行唯一标识。

    ETag: "82e22293907ce725faf67773957acd12"
    • 可以将缓存资源的ETag值放入If-None-Match 首部，服务器收到该请求后，判断缓存资源的 ETag 值和资源的最新ETag值是否一致，如果一致则表示缓存资源有效，返回 304 Not Modified。
    If-None-Match: "82e22293907ce725faf67773957acd12"
    • Last-Modified首部字段也可以用于缓存验证，它包含在源服务器发送的响应报文中，指示源服务器对资源的最后修改时间。但是它是一种弱校验器，因为只能精确到一秒，所以它通常作为 ETag 的备用方案。如果响应首部字段里含有这个信息，客户端可以在后续的请求中带上 If-Modified-Since 来验证缓存。服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 OK。如果请求的资源从那时起未经修改，那么返回一个不带有消息主体的 304 Not Modified 响应。
    Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

  • 02 | HTTP是什么？HTTP又不是什么？

    • https://blog.csdn.net/qq_37756660/article/details/134055043
贡献者: yangchong211