请求报文和响应报文双方都会使用的首部。
一、Cache-Control
请求指令：
no-cache：要求获取的响应必须是新的，即使缓存中有也不使用，这并不会阻止缓存，只是要求在使用缓存前要到服务器验证是否是最新的。no-store：不要存储任何关于客户端请求或服务器响应的事。max-age=<秒>：客户端愿意接受在指定的秒数内的响应。max-stale[=<秒>]：客户端愿意接受超出 max-age 时间的响应，如果提供了可选的秒数，则客户端愿意接受超出 max-age 多出的指定秒数内的响应。min-fresh=<秒>：客户端希望在指定的时间内获取一个新鲜的响应。no-transform：不希望代理对响应进行转换。
响应指令：
public：响应可以被任何对象（包括：发送请求的客户端，代理服务器，等等）缓存。private：响应只能被特定的用户（比如浏览器）缓存。no-cache：缓存的内容现在必须去服务器端进行验证，确认是否仍然是最新的。no-store：禁止缓存此响应。no-transform：禁止代理转换媒体类型。must-revalidate：一旦资源过期（根据max-age或者Expires计算），在成功向原服务器验证之前，缓存不能用该响应回答后续请求。proxy-revalidate：与 must-revalidate 作用相同，但它不适用于私有缓存。max-age=<秒>：告诉缓存资源的有效期还剩多少秒。s-maxage=<秒>：仅适用于公共缓存，覆盖max-age以及Expires头字段，与max-age不同的是s-maxage可以在一个HTTP事务内被修改。
1-1.no-cache 与 no-store 的区别
no-cache 是确保数据的实时性，每次使用前都会进行验证，但如果验证有效仍会使用缓存数据。
而 no-store 则是直接禁止缓存，每次都会从服务器获取数据。
1-2.Max-age
指定了从原始服务器获取资源时，资源在本地缓存中的最大生存时间（以秒为单位）。超过这个时间后，浏览器或缓存服务器会重新向原始服务器发送请求，检验资源是否有更新。
例如，如果一个HTTP响应的头部包含"Cache-Control: max-age=3600"，那么这意味着接下来的3600秒内，如果浏览器需要再次取得这个资源，它可以直接从缓存中取得，而无需再次向服务器发送请求。
1.3.Max-stale
它允许客户端接受过期的响应。当设置了max-stale后，即使缓存的资源已经过期，客户端也会在过期后的一段时间内继续使用这个版本的资源。这个时间通常由max-stale的值来指定，该值以秒为单位。
例如，如果一个HTTP请求头包含"Cache-Control: max-stale=60"，那么这意味着客户端愿意接收一个最多在60秒前过期的版本。如果缓存中的资源已经过期，但未超过60秒，则这个资源仍然可以被客户端接受和使用。
1.4Min-fresh
让客户端可以指定他们愿意接受的响应还有至少多少秒时间到期。
举个例子，如果客户端发送了一个请求，并在请求头中设置了"Cache-Control: min-fresh=600"，那么这意味着客户端希望获得的响应至少在未来的600秒（也就是10分钟）内都是新鲜的，也就是在这个时间段内都不会过期。
如果缓存服务器中的响应在600秒内就要过期，那么缓存服务器就不会直接返回这个响应，而是会去源服务器中获取一个新的响应返回给客户端。
通常来说，min-fresh指令更适用于那些需要实时或近实时数据，或者对数据新鲜度有一定要求的场景。在这些场景中，min-fresh可以确保客户端总是获取到满足新鲜度要求的数据。
1.4.1如何查看是否过期
对于min-fresh，客户端通过查看服务器返回的HTTP头中的Cache-Control指令的max-age值或者Expires头来计算剩余的新鲜度。例如，如果Cache-Control: max-age=600，那么这个资源在接下来的600秒内都是新鲜的。
当客户端发送带有min-fresh=300的请求时，它会查看缓存中的资源，如果max-age=600，并且自从资源被存入缓存以来已经过去了200秒，那么资源的剩余新鲜度就是400秒。因为400秒大于min-fresh的值300秒，所以客户端会接受这个缓存的资源。
如果资源的剩余新鲜度小于min-fresh的值，那么客户端就会向服务器发送新的请求来获取新鲜的资源。
如果没有设置max-age，那么客户端会试图去看Expires头部字段。
Expires头部字段提供一个日期/时间，表示在这个时间点之后，缓存的资源就被认为是过期的。客户端会将当前的日期/时间与Expires头部字段的日期/时间进行比较，以确定资源的剩余新鲜度。
如果既没有设置max-age，也没有设置Expires，那么缓存的新鲜度就无法确定，客户端通常会选择重新向服务器发送请求，以确保获取的资源是最新的。
1.5 No-transform
no-transform是HTTP协议中的一个缓存控制指令。当服务器在响应头中设置了这个指令，那么代理服务器（比如CDN等）就不能改变这个响应的主体部分。
HTTP代理服务器有时会对响应的内容进行一些变换，比如压缩、转换图片格式、简化HTML等，以优化传输性能或适应客户端的能力。但在某些情况下，这些变换可能影响到应用的功能，或者改变了资源的语义，因此服务器希望禁止这些变换。
当no-transform指令被设置后，无论是公开的还是私有的缓存，都不能改变响应的主体部分。这包括但不限于：添加、删除、改变消息体的编码或媒体类型等。
例如，一个HTTP响应头可能会包含这样的指令："Cache-Control: no-transform"。这表示这个响应的内容必须按照原样传递，不能被任何中间代理进行改变或优化。
响应指令
1.6 Public
可向任意方提供响应的缓存
1.7 Private
仅向特定用户返回响应
1.8 No-cache（告诉浏览器行为）
HTTP中的no-cache响应头指令告诉浏览器或其他兼容的缓存系统，对于这个特定的响应，不能缓存其内容，除非在后续的请求中验证了其有效性。这就意味着，即使一个响应被缓存了，每次在使用这个响应之前，都必须向原服务器发送一个验证请求来确认这个缓存的数据是否仍然是最新的。
值得注意的是，no-cache并不是说“不要缓存这个数据”。它实际上是说：“无论何时，只要使用这个数据，你都需要先去验证它是否还是最新的”。
例如，如果一个响应头包含"Cache-Control: no-cache"的指令，那么在使用这个响应的数据之前，浏览器或者其他的缓存都需要先发送一个请求到原服务器，确认这个数据是否已经过期。如果服务器返回的响应状态码是304（Not Modified），那么浏览器就可以继续使用这个缓存的数据；如果状态码是200（OK），那么浏览器需要用新的响应数据替换缓存的数据。
1.9 No-store（告诉浏览器）
请求头的no-store是告诉服务器
响应头的no-store是告诉浏览器
1.10 No-transform
和请求头一样
1.11 Must-revalidate
must-revalidate 是一个 HTTP 响应头部的 Cache-Control 指令。当服务器在响应头部中设置了 Cache-Control: must-revalidate，这意味着一旦缓存过期，客户端（如浏览器）必须再次向服务器发送请求，验证缓存的响应是否仍然有效。
这有助于确保客户端不会使用过时的缓存数据，而是总是使用最新和最准确的数据。如果缓存的响应仍然有效（服务器返回 304 Not Modified），那么客户端可以继续使用缓存数据。如果缓存响应已经无效（服务器返回 200 OK 和新的响应数据），那么客户端必须使用新的响应数据并更新其缓存。
这与 no-cache 指令有些不同，no-cache 会导致客户端每次都向服务器发送请求，而 must-revalidate 只有在缓存过期时才会向服务器发送请求。
1.12 Proxy-revalidate
Proxy-revalidate 是 HTTP 的一个响应头部 Cache-Control 指令，与 must-revalidate 类似，但是 Proxy-revalidate 只对共享缓存（如代理服务器）有效。
当服务器在响应头部中设置了 Cache-Control: proxy-revalidate，这意味着一旦缓存过期，共享缓存（代理服务器）必须再次向服务器发送请求，验证缓存的响应是否仍然有效，而对私有缓存（如用户的浏览器）不强制执行此规则。
这有助于确保代理服务器不会向其客户端提供过时的缓存数据，每次都使用最新和最准确的数据。如果缓存的响应仍然有效（服务器返回 304 Not Modified），那么代理服务器可以继续使用缓存数据。如果缓存响应已经无效（服务器返回 200 OK 和新的响应数据），那么代理服务器必须使用新的响应数据并更新其缓存。
1.13 Max-age
请求头中的 max-age 是客户端设置的，用来控制它愿意接受的响应的新旧程度；
响应头中的 max-age 是服务器设置的，用来控制资源在客户端缓存中的寿命。
1.13.1如果响应头设置了max-age=100 请求头又设置了max-age=60 这个时候是继续请求服务器还是使用了缓存呢？
在这种情况下，将按照更严格（更短的时间）的 max-age 来操作，即按照请求头中的 max-age=60 来执行。
也就是说，如果缓存的资源在60秒内未被修改，客户端将使用缓存的版本，无需再向服务器请求新的资源。如果超过60秒，客户端将向服务器发出请求，以确认资源是否有更新。
尽管响应头中设置的 max-age 是100秒，但是由于请求头中设置的 max-age 是60秒，所以60秒后，客户端仍然会认为缓存的资源可能已经过期，因此会向服务器发送请求以验证资源的新鲜度。
1.14 S-maxage
S-maxage 是一个属于 HTTP 响应头的 Cache-Control 指令，它用于定义共享缓存（如CDN、代理服务器等）中的资源的最大寿命。这个指令的值是一个表示秒数的非负整数。
S-maxage 和 max-age 在功能上是类似的，都是用来指定资源在缓存中可以存储的最大寿命。区别在于，max-age 主要用于客户端缓存（如浏览器缓存），而 S-maxage 则主要用于共享缓存。
例如，如果服务器在响应头中设置了 Cache-Control: s-maxage=120，那么代理服务器或者 CDN 等共享缓存会缓存这个响应120秒。在这个时间内，如果有新的请求到达，共享缓存可以直接返回缓存的响应，而不需要向原始服务器发送新的请求。
需要注意的是，如果响应头中同时存在 max-age 和 s-maxage，并且他们的值不相同，那么 s-maxage 的值将被用于共享缓存，而 max-age 的值将被用于客户端缓存。
1.14.1共享缓存
共享缓存是指根据 HTTP 协议存储并为多个用户提供资源副本的缓存。这些缓存通常位于原始服务器和客户端之间，例如代理服务器或内容分发网络（CDN）等。它们接收来自客户端的请求，然后将请求转发给原始服务器或直接返回缓存的响应。
为了确保用户获取的资源的新鲜度，共享缓存需要遵守 HTTP 缓存控制机制，如 Cache-Control 头中的 s-maxage、max-age、no-cache、no-store 等指令。
共享缓存就是位于客户端与服务器之间的、为多个用户提供服务的缓存。这些缓存通常位于各种透明代理、反向代理、CDN节点等。这些代理或网关在转发请求或响应的时候，会根据HTTP头部的缓存控制字段（如 Cache-Control）进行相应的缓存操作。
当其他客户端发起相同的请求时，这些代理或网关可以直接从它们的缓存中返回结果，而不需要将请求转发到服务器，从而减少服务器的负载，并且能够更快地将结果返回给客户端。这就是所谓的共享缓存。
二、connection
Connection 是一个 HTTP 头字段，主要用于控制网络连接的行为。它有两个主要的值，keep-alive 和 close。
-
Connection: keep-alive：这个头信息会告诉 web 服务器保持连接，不要在发送完一个响应后立即关闭连接，而是保持打开状态，以便客户端可以继续使用该连接发送更多的请求。这个机制可以减少 TCP 握手的开销，从而提高 HTTP 请求的性能。 -
Connection: close：这个头信息会告诉 web 服务器，在发送完一个响应后立即关闭连接。这个设定在一些场景下是有用的，比如 HTTP/1.0 默认的行为就是这样的。不过在现代的网络中，由于keep-alive可以显著提高性能，所以close使用得较少。
另外，Connection 头也可以用来控制代理行为。如果在 Connection 头中列出其他的头字段名，那么这些头字段在经过代理时将不会被转发。举个例子，Connection: keep-alive, Upgrade 意味着 keep-alive 和 Upgrade 这两个头字段只对当前连接有效，而不应该被代理转发。
三、Date
Date 是一个 HTTP 头字段，用于表示服务器生成响应的时间。Date 字段的值是一个 HTTP 日期，格式为：Date: Tue, 15 Nov 1994 08:12:31 GMT。
这个日期和时间是以格林尼治标准时间（GMT）表示的，并且遵循 RFC 7231 规定的日期和时间格式。
在 HTTP/1.1 中，除非这个 HTTP 消息是一个应答（这种情况下 Date 字段可能会被省略）或者 Date 字段已经被应用程序添加，否则所有的 HTTP 响应都应该包含一个 Date 头字段。如果接收到的响应中没有 Date 头字段，那么接收者可以使用接收时间作为消息的日期。
Date 字段还可以被用于判断服务器时间与客户端时间的差异，或者用于缓存控制等目的。
四、Pragma（1.0版本字段）
Pragma 是一个 HTTP/1.0 头字段，主要用于向后兼容 HTTP/1.0 服务器或客户端，用于设置特定的指令。在 HTTP/1.1 和更高版本中，它已经基本被 Cache-Control 头字段取代。
最常见的 Pragma 头字段是 Pragma: no-cache。在 HTTP/1.0 没有 Cache-Control 头字段的时候，Pragma: no-cache 会告诉浏览器和其他中间代理（如 CDN 服务）不要缓存这个响应的内容，每次都需要从服务器重新获取。
然而在 HTTP/1.1 和以上版本，更推荐使用 Cache-Control: no-cache 来达到同样的目的。
虽然 Pragma 在现代的 HTTP 协议中已经很少使用，但在一些需要兼容旧版本 HTTP/1.0 客户端或服务器的场合，可能还会看到它的身影。
五、Traielr
HTTP 头字段 Trailer 用于指示哪些头部字段在消息体的尾部（chunked 编码方式的末尾）会出现。
HTTP/1.1 版本引入了 Transfer-Encoding: chunked，它允许在不知道内容长度的情况下发送响应。当使用 chunked 编码传输数据时，可以在消息体的末尾添加额外的 HTTP 头部字段。这些尾部的头部字段可以使用 Trailer 头部字段来声明。
例如，假设服务器希望计算响应体的摘要（例如，使用 MD5 哈希），并将其作为 Content-MD5 头部字段发送。但是，如果服务器在开始发送响应体之前不知道响应体的内容，那么就无法计算摘要。这种情况下，服务器可以使用 chunked 编码来发送响应体，并在所有数据发送完毕后，添加一个 Content-MD5 头部字段到尾部来发送摘要。服务器在响应的开始就会发送一个 Trailer: Content-MD5 头部字段，来告诉客户端可以在尾部找到 Content-MD5 头部字段。
六、Transfer-Encoding
规定了传输报文主体时采用的编码方式。
例如Transfer-Encoding 头字段可以设置多个值，表示消息正文需要经过多次编码。例如，Transfer-Encoding: gzip, chunked 表示消息正文先进行 gzip 压缩，然后再进行分块传输。
七、UpHTTP协议的Upgrade 头字段用于请求和切换到另一种协议，比如从 HTTP 协议切换到 WebSocket 协议。
客户端在请求中使用 Upgrade 头字段来提出使用新的协议，例如：
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
这里，Upgrade: websocket 表示客户端希望切换到 WebSocket 协议。
服务器如果同意切换协议，会在响应中也包含Upgrade头，并且状态码为101，表示服务器理解并接受了协议切换的请求。例如：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
这样就完成了从 HTTP 协议到 WebSocket 协议的切换。
值得注意的是，不是所有的 HTTP 服务器都会支持 Upgrade 头字段提出的协议切换，如果服务器不支持，那么它通常会忽略这个头字段，并继续使用 HTTP 协议处理请求。
此外，Upgrade 头字段也可以同时提出多种协议切换，通过逗号分隔，服务器会选择其支持的协议进行切换。例如：
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
八、Via
HTTP的Via头字段被用来追踪消息的转发，包括协议和接收者（代理或网关）的信息。Via头字段可以用来避免请求的循环，也可以用来确定消息的路径或者查看经过了哪些代理。
每个代理或网关在转发请求或响应的时候，都会在消息中添加一个Via字段，其中包含代理或网关自身的协议版本和主机名。
例如，一个请求原始发送到代理A（主机名为proxy1.example.com），然后被转发到代理B（主机名为proxy2.example.com），最后到达服务器。在这个过程中，每个代理都会添加一个Via头字段，所以到达服务器的请求中，Via头字段可能会看起来是这样的：
Via: 1.1 proxy1.example.com, 1.1 proxy2.example.com
这表示这个请求先后经过了主机名为proxy1.example.com和proxy2.example.com的两个代理。
需要注意的是，代理或网关可以选择在Via头字段中添加更多的注释信息，例如它可能会包含代理的软件版本信息或者对请求的描述。例如：
Via: 1.1 vegur, 1.1 example-proxy:8080 (Cisco-WSA/10.1.1)
在这个例子中，请求先后经过了两个代理，第一个代理的主机名是vegur，第二个代理的主机名是example-proxy，监听在8080端口，它使用的是Cisco WSA软件，版本是10.1.1。
值得一提的是，按照规范，发送请求的客户端或者服务器应当能够处理Via头字段，但是并不是所有的客户端或者服务器都会这么做，有些可能会忽略这个字段。
首部字段
一、Accept
Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。 可使用type/subtype 这种形式，一次指定多种媒 体类型。
二、Accept-Charset
Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集 及宇符集的相对优先顺序。另外，可一次性指定多种字符集。与首部字 段Accept 相同的是可用权重q 值来表示相对优先级。
三、Accept-Encoding
Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。可一次性指定多种内容编码。
四、Accept-Language
首部字段Accept-Language 用来告知服务器用户代理能够处理的自 然语言集(指中文或英文等)，以及自然语言集的相对优先级。可一次指定多种自然语言集。
五、Authorization
首部字段Authorization 是用来告知服务器，用户代理的认证信息 ( 证书值)。通常，想要通过服务器认证的用户代理会在接收到返回 的401状态码响应后，把首部字段Authorization 加人请求中。
六、Expect
客户端使用首部宇段Expect 来告知服务器，期望出现的某种特定行为。因服务器无法理解客户端的期望作出回应而发生错误时，会返回状态码417。
七、Host
首部字段Host 会告知服务器，请求的资源所处的互联网主机名和 端又号。Host 首部字段在HTTP/ 1. 1规范内是唯一一个必须被包含在请 求内的首部字段。
八、If-Match
形如If-xxx 这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。
只有当1f-Match 的字段值跟ETag 值匹配一致时，服务器才会接受请求
九、If-Modified-Since
首部字段IfModified-Since，属附带条件之一，它会告知服务器若IfModified-Since字段值早于资源的更新时间 ，则希望能处理该请求。
If-Modified-Since 是一个 HTTP 请求头字段，它允许客户端向服务器查询自某个日期以来资源是否被修改过。
如果自指定日期以来资源未被修改，服务器会返回304状态码（Not Modified），并且不会返回资源的内容。这种情况下，客户端可以继续使用其缓存的版本，从而节省了数据传输。如果资源被修改过，服务器会返回200状态码（OK），并返回资源的最新内容。
If-Modified-Since 的值是一个 GMT 格式的日期，例如："Tue, 15 Nov 1994 12:45:26 GMT"。这个日期通常是在之前的响应头中 Last-Modified 字段中取得的。
下面是一个例子：
- 首次请求：
GET /index.html HTTP/1.1
Host: www.example.com
响应：
HTTP/1.1 200 OK
Date: Tue, 15 Nov 1994 12:45:26 GMT
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Content-Length: 138
- 使用
If-Modified-Since发出的后续请求：
GET /index.html HTTP/1.1
Host: www.example.com
If-Modified-Since: Tue, 15 Nov 1994 12:45:26 GMT
如果在 "Tue, 15 Nov 1994 12:45:26 GMT" 之后，index.html 没有被修改过，服务器会返回304状态；如果被修改过，服务器会返回200状态和更新的内容。
max-age 和 If-Modified-Since 是两种不同的 HTTP 缓存控制机制，它们可以独立使用，也可以配合使用。
十、If-None-Match
首部宇段IfNone-Match属于附带条件之一 。它和首部字段If-Match作用相反。用于指定If-None-Match字段值 的实体标记 ( ETag ) 值与请求资源的ETag不一致时，它就告知服务器处理该请求。
十一、If-Range
首部字段If-Range 属于附带条件之一。它告知服务器若指定的
If-Range字段值 (ETag值或者时间)和请求资源的ETag值或时间相一致时, 则作为范围请求处理。反之，则返回全体资源。
If-Range 是一个 HTTP 头，主要用于请求部分资源，多用于大文件或者流媒体的分块传输。
当你需要请求一个文件的某个部分时，你可能会使用 Range 头来指定你想获取的范围。同时，你可能也会使用 If-Range 头来指定一个条件：只有当文件没有被修改过，服务器才应该返回所请求的范围。否则，服务器应该返回整个文件。
I**f-Range 头的值可以是服务器在之前的响应中返回的 ETag 值，也可以是资源的最后修改时间（Last-Modified 值）。如果 If-Range 头的值与服务器当前的 ETag 或 Last-Modified 值匹配，服务器将返回所请求的部分内容。如果不匹配，那么服务器将返回整个资源。**
这样的机制可以防止在服务器上的资源已被修改，但客户端仍尝试获取资源的旧版本部分的情况，从而确保客户端总是获取到的是最新、最准确的数据。
十二、If-Unmodified-Since
If-Unmodified-Since 是一个 HTTP 请求头，用于告诉服务器，只有当请求的资源在指定的时间之后没有被修改过，服务器才应该处理此请求。如果资源在指定的时间之后被修改过，服务器将返回一个 412 Precondition Failed 的状态码，表示预设条件失败。
这个请求头主要用于在 PUT 操作或其他需要修改资源的操作中，确保在修改过程中资源没有被其他请求修改过。例如，如果一个客户端正在尝试更新一个资源，但另一个客户端已经更新了这个资源，那么第一个客户端的更新请求将被拒绝，以防止覆盖另一个客户端的更改。
If-Unmodified-Since 头的值通常是一个日期时间值，表示客户端最后一次获取资源的时间。如果资源在这个时间后被修改过，服务器将返回 412 Precondition Failed 的状态码，表示请求不能被满足。
例如：
PUT /file.txt HTTP/1.1
Host: www.example.com
If-Unmodified-Since: Sat, 29 Oct 2019 19:43:31 GMT
以上的请求表示，只有当 /file.txt 自 2019 年 10 月 29 日 19:43:31 GMT 后没有被修改过，服务器才应该处理此 PUT 请求。
十三、Max-Forwards
最大转发次数
十四、Proxy-Authorization
接收到从代理服务器发来的认证质询时，客户端会发送包含首部字 段Proxy-Authorization 的请求，以告知服务器认证所需要的信息。Proxy-Authorization 是一个 HTTP 请求头。当客户端需要通过代理服务器进行身份验证时，这个请求头会被使用。
代理服务器在接收到需要身份验证的请求时，会返回一个 407 Proxy Authentication Required 的状态码，同时在响应头中包含一个 Proxy-Authenticate 头，此头的值包含了代理服务器接受的身份验证方法。
然后，客户端可以选择一个方法进行身份验证，并在下一次请求中包含 Proxy-Authorization 头。该头的值通常包含了使用选定方法的身份验证信息。
Proxy-Authorization 头的格式如下：
Proxy-Authorization: <type> <credentials>
其中，<type> 是代理服务器接受的身份验证方法，例如 Basic。<credentials> 是使用选定方法的身份验证信息，其格式取决于具体的身份验证方法。
例如，如果选择 Basic 身份验证，那么 Proxy-Authorization 头的值可能是这样的：
Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
这里，YWxhZGRpbjpvcGVuc2VzYW1l 是 username:password 经过 Base64 编码后的结果。
十五、Range
Range 是一个 HTTP 请求头，用于请求服务器返回资源的一部分。这对于大文件或流媒体内容特别有用，因为它允许客户端只请求并接收他们需要的特定部分，而不是整个资源。
Range 头的格式如下：
Range: bytes=start-end
其中，start 和 end 是字节范围，用于指定你想要获取的资源的部分。例如，Range: bytes=0-499 表示你只想获取资源的前 500 个字节。
如果服务器接受这个范围请求，它将返回一个 206 Partial Content 的状态码，以及请求的资源部分。如果范围无效（例如，超出了资源的大小），服务器将返回一个 416 Range Not Satisfiable 的状态码。
此外，你也可以在 Range 头中指定多个范围，例如 Range: bytes=0-499,1000-1499。这表示你想要获取资源的前 500 个字节和第 1000 到 1499 个字节。对于这种情况，服务器会返回一个 206 Partial Content 的状态码，以及一个多部分消息，每个部分包含请求的一个范围。
注意，Range 请求常与 If-Range 头一同使用，如果资源在指定时间之后被修改，服务器将返回整个资源，而不是部分内容。
十六、Referer
首部字段Referer 会告知服务器请求的原始资源的URI。
十七、User-Agent
首部字段User-Agent 会将创建请求的浏览器和用户代理名称等信息传达给服务器。
响应首部字段
响应首部字段是由服务器端向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求 等信息。
一、Accept-Ranges
首部字段Accept-Ranges 是用来告知客户端服务器是否能处理范围
请求，以指定获取服务器端某个部分的资源。 可指定的字段值有两种，可处理范围请求时指定其为bytes，反之
则指定其为none。
二、Age
Age 是一个 HTTP 响应头，表示自原始服务器生成响应以来的时间（以秒为单位）。这个头部字段主要用于缓存机制。
当一个响应从源服务器发送到客户端时，它可能会经过一个或多个缓存服务器。这些缓存服务器可能会存储响应的副本，并在后续的请求中返回这个副本，而不是从源服务器获取新的响应。
当缓存服务器返回一个存储的响应时，它会包含一个 Age 响应头。这表示从源服务器最初生成这个响应到现在经过的时间。
例如：
Age: 600
这表示响应在缓存中已经有 600 秒了。
Age 响应头有助于客户端判断响应的新鲜度。如果 Age 的值接近或超过响应的 max-age（在 Cache-Control 响应头中定义），客户端可能会决定获取新的响应，而不是使用缓存的响应。
三、ETag
首部宇段ETag 能告知客户端实体标识。它是一种可将资源以字符 串形式做唯一性标识的方式。服务器会为每份资源分配对应的ETag 值。
ETag（Entity Tag）是一个 HTTP 响应头，它提供了一个资源的唯一标识符，用于确定资源的版本。这对于缓存管理及资源更新非常有用。
当某个资源发生变化时（比如文件被修改），其对应的 ETag 也会发生改变。客户端在发送请求时，可以在请求头中包含 If-None-Match 字段，其值为之前获取到的 ETag。然后，服务器会对比这个 ETag 和当前资源的 ETag：如果两者一样，表示资源没有改变，服务器就会返回 304 Not Modified 状态码，客户端可以继续使用本地缓存的资源；如果不一样，表示资源已经发生变化，服务器会返回更新的资源以及新的 ETag。
例如，服务器响应可能包含这样的 ETag：
ETag: "686897696a7c876b7e"
然后客户端可以在后续的请求中包含这个 ETag：
GET /resource HTTP/1.1
Host: example.com
If-None-Match: "686897696a7c876b7e"
ETag 实际上是一种轻量级的、可用于快速检查资源是否已被修改的机制，比起完整地获取资源内容进行对比，使用 ETag 可以节省大量的带宽和时间。
强弱ETag
强ETag在任何情况下，只要资源发生了改变，无论这个改变多么微小，强ETag都会改变。这保证了无论是缓存还是实际资源，内容都是完全一样的。强ETag主要用于文件、文档等要求严格一致性的资源。
弱ETag则在资源发生了有意义的改变时才会改变。所谓有意义的改变，可能是根据实际的应用场景来定义的。比如对于一个动态生成的新闻网站来说，可能只有当新闻内容发生了实质性改变时，才认为资源发生了改变，而像是页面布局的微小调整、广告内容的更换等，并不认为是资源的改变。弱ETag用于这样的、要求较低的一致性的资源。
在HTTP头中，弱ETag的表现形式是在ETag的值前加上W/前缀，比如W/"686897696a7c876b7e"。而强ETag则没有前缀，直接就是ETag的值，比如"686897696a7c876b7e"。
四、Location
HTTP响应头Location主要用于两个目的：
-
在3XX（例如301, 302, 307或308）重定向响应中，
Location用于指示客户端应该向哪个URL重新发出请求。例如，如果一个请求的资源已经被移动到另一个位置，服务器可能会返回一个301 Moved Permanently响应，并在Location头中给出新位置的URL。 -
在201 Created响应中，
Location用于指示新创建资源的URL。例如，当客户端向服务器发送POST请求创建新资源时，服务器可能会返回201 Created响应，并在Location头中给出新资源的URL。
这是一个Location响应头的例子：
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-url
在这个例子中，服务器使用301状态码告诉客户端资源已经被永久移动，并在Location头中提供了新位置的URL。客户端应该使用这个新URL重新发出请求。
五、Proxy-Authenticate
首部字段Proxy-Authenticate 会把由代理服务器所要求的认证信息
发送给客户端。
六、Retry-After
首部字段Retry-After 告知客户端应该在多久之后再次发送请求。主要配合状态码503Service Unavailable响应，或3xx Redirect 响应一起使用。
七、Server
首部字段Server 告知客户端当前服务器上安装的HTTP服务器应用 程序的信息。不单单会标出服务器上的软件应用名称，还有可能包括版本号和安装时启用的可选项。
八、Vary
当代理服务器接收到带有Vary 首部字段指定获取资源的请求时，如果使用 的Accept-Language 字段的值相同，那么就直接从缓存返回响应。反之， 则需要先从源服务器端获取资源后才能作为响应返回
实体首部字段
实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。
一、Allow
首 部 字段 A l l o w 用 于通 知 客 户 端 能够 支持 R e q u e s t - U R I 指 定 资 源 的 所有HTTP 方法。 当服务器接收到不支持的HTTP 方法时，会以状态码 405MethodNot Allowed作为响应返回。与此同时，还会把所有能支持 的HTTP 方法写人首部字段Allow后返回。
二、Content-Encoding
告知客户端服务器对实体的主体部分选用的内容编码方式。如：Gzip、compress...
三、Content-Language
主题使用的自然语言
四、Content-Length
资源大小(单位字节)
五、Content-Location
首部字段Content-Loc ation 给出与报文主体部分相对应的URI。和 首部字段Location 不同，Content-Location 表示的是报文主体返回资源URI.
六、Content-MD5
首部宇段Content- MD5 是一串由MD5算法生成的值，其目的在于 检查报文主体在传输过程中是否保持完整，以及确认传输到达。
七、Content-Range
Content-Range 是一个 HTTP 响应头，用于指定在整个资源中的部分内容的位置。这主要用在对大型资源进行分块传输或恢复中断的下载时。
Content-Range 的格式通常如下：
Content-Range: bytes 0-499/1234
这表示当前的响应包含了整个资源的前500字节，即第0字节到第499字节，而整个资源的大小是1234字节。
此外，如果服务器无法或不愿提供资源的总大小，也可以用 * 来代替，例如：
Content-Range: bytes 500-999/*
这表示当前的响应包含了资源的第500字节到第999字节，但是资源的总大小未知。
需要注意的是，Content-Range 响应头通常需要配合 206 Partial Content 状态码一起使用。此外，服务器在收到包含 Range 请求头的请求时，也可以使用 Content-Range 来进行响应。
八、Content-Type
主体类型
九、Expires
Expires是HTTP响应头的一部分，它定义了响应的过期时间。一旦过了这个时间，缓存的响应就被认为是“陈旧的”。这就意味着，如果需要再次获取这个资源，客户端应该向服务器进行新的请求，而不是使用缓存的版本。
Expires的值是一个日期/时间，遵循HTTP日期格式，如下例：
Expires: Wed, 21 Oct 2020 07:28:00 GMT
在这个例子中，这个响应在2020年10月21日07:28:00 GMT之后就被认为是过期的。
需要注意的是，使用Expires头需要确保服务器和客户端的时钟同步。如果服务器和客户端的时钟不同步，可能会导致缓存行为出现问题。
在现代的HTTP/1.1规范中，Cache-Control头被推荐用于控制缓存行为，它提供了更多的选项，并且不依赖于精确的时间同步。然而，Expires头仍然在许多情况下被广泛使用。
cache-control存在 但是已经过期了 还是会采用Expires吗?
如果Cache-Control首部字段中的max-age指令已经过期，浏览器通常不会再去考虑Expires首部字段，而是认为该资源已经过期，需要重新向服务器请求。
这是因为Cache-Control首部字段中的max-age指令通常被认为是一个更精确的、基于相对时间的缓存控制机制，所以它的优先级高于Expires首部字段。
当max-age过期后，无论Expires首部字段的值是什么，浏览器通常都会认为该资源已经过期，需要重新请求。除非在某些特殊情况下，例如在某些老的HTTP/1.0实现中，可能会退回到使用Expires。
为Cookie服务的首部字段
一、Set-Cookies
Set-Cookie 是一个 HTTP 响应头，服务器通过Set-Cookie 响应头向客户端发送 cookies。当浏览器（或其他兼容的客户端）接收到这个响应头时，它会储存这个 cookie，并在后续的请求中将这个 cookie 发送回服务器（只有当发送请求的网站符合 cookie 的域和路径条件时）。
Set-Cookie 响应头的格式大致如下：
Set-Cookie: <cookie-name>=<cookie-value>; expires=<date>; domain=<domain-name>; path=<path>; secure; HttpOnly
这里的各个部分解释如下：
-
<cookie-name>=<cookie-value>：这是必须的部分，定义了 cookie 的名字和值。 -
expires=<date>：这是可选的部分，定义了 cookie 的过期日期和时间。如果没有定义，那么 cookie 将会在浏览器关闭时过期。 -
domain=<domain-name>：这是可选的部分，定义了哪些网站可以接收这个 cookie。如果没有定义，那么默认值是发送Set-Cookie指令的服务器的域名。 -
path=<path>：这是可选的部分，定义了给定域中的哪些路径可以接收这个 cookie。如果没有定义，那么默认值是发送Set-Cookie指令的服务器的路径。 -
secure：这是可选的部分，指定了只有在使用 HTTPS 连接时才能将 cookie 发送回服务器。 -
HttpOnly：这是可选的部分，指定了通过 JavaScript（Document.cookie）、AppleScript 等脚本语言无法访问 cookie。
需要注意的是，Set-Cookie 响应头可以在一个响应中出现多次，以设置多个 cookie。
1.1 设置多个cookies
设置多个cookie当服务器通过Set-Cookie响应头设置了Cookie后，浏览器会存储这些Cookie，然后在后续的请求中，如果请求的URL匹配这些Cookie的域和路径，浏览器就会自动将这些Cookie添加到请求头的Cookie字段中，发送给服务器。
例如，如果服务器在响应中设置了如下的Set-Cookie首部：
Set-Cookie: sessionId=abc123; Path=/; Secure; HttpOnly
然后浏览器在后续的请求中，如果请求的URL匹配了Cookie的路径（在这个例子中，路径是/，匹配任何URL），浏览器就会自动将这个Cookie添加到请求头中，大致如下：
Cookie: sessionId=abc123
服务器可以通过查看请求头的Cookie字段来获取浏览器发送过来的Cookie。注意，服务器设置的Set-Cookie首部和浏览器发送的Cookie首部是不同的。服务器使用Set-Cookie来设置Cookie，而浏览器使用Cookie来发送Cookie。
1.2 响应头包含多个Cookie 如何展示当服务器设置了多个Cookie，并且这些Cookie的域和路径与后续请求的URL匹配时，浏览器会将这些Cookie全部添加到请求头的Cookie字段中，发送给服务器。多个Cookie之间用分号和空格分隔。
例如，如果服务器在响应中设置了如下的Set-Cookie首部：
Set-Cookie: sessionId=abc123; Path=/; Secure; HttpOnly
Set-Cookie: username=john; Path=/; Secure; HttpOnly
然后浏览器在后续的请求中，如果请求的URL匹配了这些Cookie的路径（在这个例子中，路径是/，匹配任何URL），浏览器就会自动将这两个Cookie添加到请求头中，大致如下：
Cookie: sessionId=abc123; username=john
服务器可以通过查看请求头的Cookie字段来获取浏览器发送过来的多个Cookie。
二、Cookie
首部字段Cookie 会告知服务器，当客户端想获得HTTP状态管理 支持时，就会在请求中包含从服务器接收到的Cookie。接收到多个 Cookie 时，同样可以以多个Cookie 形式发送。
其他首部字段
HTTP 首部字段是可以自行扩展的。所以在Web 服务器和浏览器的 应用上，会出现各种非标准的首部字段。
一、X-Frame-Options
首部宇段X-Frame-Options 属于HTTP响应首部，用于控制网站内 容在其他Web网站的Frame 标签内的显示问题。其主要目的是为了防 止点击劫持 (clickjacking) 攻击。
二、X-XSS-Protection
首部字段X-XSS-Protection 属于HTTP响应首部，它是针对跨站脚 本攻击(xSS )的一种对策，用于控制浏览器XSS防护机制的开关。
首部字段X-XSS-Protection 可指定的字段值如下。
• 0: 将XSS 过滤设置成无效状态
• 1: 将XSS过滤设置成有效状态
三、DNT
首部字段DNT属于HTTP请求首部，其中DNT是DoNot Track 的简称，意为拒绝个人信息被收集，是表示拒绝被精准广告追踪的一 种方法。
