HTTP报文分为两种，HTTP请求报文跟HTTP响应报文。
HTTP请求报文的结构如下：
其中，请求行中包括的内容有方法、URI和HTTP版本，请求首部字段、通用首部字段和实体首部字段隶属于HTTP首部字段。
HTTP响应报文的结构如下：
其中，状态行包括的内容有HTTP版本、状态码，响应首部字段、通用首部字段和实体首部字段是在HTTP首部字段的范畴内。
HTTP首部字段
HTTP首部字段可以传递额外重要信息，使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言等附加信息。HTTP首部字段结构是由首部字段名和字段值构成：
而HTTP首部字段根据实际用途被分为以下4种类型：
通用首部字段：请求报文和响应报文两方都会使用的首部。
请求首部字段：从客户端向服务器端发送请求报文时使用的首部，可补充请求的附加内容、客户端信息、响应内容相关优先级等信息。
响应首部字段：从服务端向客户端返回响应报文时使用的首部，可补充响应的附加内容，也会要求客户端附加额外的内容信息。
实体首部字段：针对请求报文和响应报文的实体部分使用的首部，可以补充更新时间等与实体有关的信息。
当然，HTTP首部字段是有规定的，在RFC2616中有47个，除了这47种首部字段，还有Cookie，Set-Cookie等在其他RFC中定义的首部字段。这些非正式的首部字段统一归纳在RFC4229中。而且HTTP首部字段将定义成缓存代理和非缓存代理的行为，分成两种类型，端到端首部(End-to-end Header)和逐跳首部(Hop-by-hop Header)、其中端到端首部会转发给请求/响应对应的最终接收目标，且必须保存在有缓存生成的响应中，另外规定它必须转发。而逐跳首部只对单次转发有效，会因通过缓存或代理而不再转发。
逐跳首部字段只有八种，分别是Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Trailer、TE、Transfer-Encoding、Upgrade，除了这八个首部字段之外，其余全属于端到端首部。
HTTP/1.1通用首部字段
HTTP通用首部字段是指请求报文和响应报文都可以使用的首部字段。接下来介绍一些首部字段。
① Cache-Control
Cache-Control首部字段的指令是操作缓存的工作指令，能够控制缓存行为。
缓存请求指令：
| 指令 | 参数 | 说明 |
| no-cache | 无 | 强制向源服务器再次验证 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| max-age=[秒] | 必需 | 响应的最大Age值 |
| max-stale(=[秒]) | 可省略 | 接受已过期的响应 |
| min-fresh=[秒] | 必需 | 期望在指定时间内的响应仍有效 |
| no-transform | 无 | 代理不可更改媒体类型 |
| only-if-cached | 无 | 从缓存获取资源 |
| cache-extension | - | 新指令标记(token) |
缓存响应指令：
| 指令 | 参数 | 说明 |
| public | 无 | 可向任意方提供相应的缓存 |
| private | 可省略 | 仅向特定用户返回响应 |
| no-cache | 可省略 | 缓存前必须先确认其有效性 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| no-transform | 无 | 代理不可更改媒体类型 |
| must-revalidate | 无 | 可缓存但必须再向源服务器进行确认 |
| proxy-revalidate | 无 | 要求中间缓存服务器对缓存的响应有效性再进行确认 |
| max-age=[秒] | 必需 | 相应的最大Age值 |
| s-maxage=[秒] | 必需 | 公共缓存服务器相应的最大Age值 |
| cache-extension | - | 新指令标记(token) |
表示是否能缓存的指令：
① public指令--明确表明其他用户也可利用缓存。
② private指令--缓存服务器只会对特定用户响应提供资源缓存请求。
③ no-cache指令--如果是客户端发送的请求中有这个指令，表示它不要缓存服务器的可能过期的资源，它要直接从源服务器拿出来的资源。如果是服务端的响应请求中有这个指令，那么缓存服务器就不能对资源进行缓存，源服务器以后也不能对缓存服务器请求中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作。
控制可执行缓存的对象的指令：
① no-store指令--暗示请求或响应中数据中包含机密信息，所以该指令规定缓存不能在本地存储请求或响应的任一部分。
指定缓存期限和认证的指令：
① max-age指令--max-age表示缓存资源在缓存服务器上有效的最大时间，如果判定缓存资源的缓存时间比指定时间的数值更小，那么客户端就可以直接接收缓存的资源，而不用向源服务器拿资源。当指定max-age值为0，那么缓存服务器通常需要将请求转发给源服务器。而且HTTP/1.1版本的缓存服务器中，在遇到同时存在Expires首部字段的时候，会优先处理max-age指令。
② s-maxage指令--该指令与max-age指令的功能相同，但是此指令只适用于供多位用户使用的公共缓存服务器，对于向同一用户重复返回相应的服务器来说没有效。而且当时用s-maxage指令后，会直接忽略max-age指令和Expires字段。
③ min-fresh指令--要求缓存服务器返回至少还没有超过缓存期限的缓存资源。
④ max-stale指令--要求即使是过期了的指令，只要客户端要求了，那也照样响应已经过期的缓存资源。
⑤ only-if-cached指令--表示只有是缓存服务器本地缓存着客户端所要求的资源，客户端才会要求返回其资源，如果本地缓存无响应，则会返回504状态码。
⑥ must-revalidate指令--代理会向源服务器再次验证即将返回的响应缓存目前是否依然有效，如果无效，则会返回504状态码。而且，如果使用了must-revalidate指令，会忽略max-stale指令。
⑦ poxy-revalidate指令--要求所有缓存服务器在接收到客户端带有该指令的请求返回响应之前，必须再次验证缓存的有效性。
⑧ no-transform指令--规定无论是在请求还是在响应中，缓存都不能改变实体主体的媒体类型，这样做可以防止缓存或代理压缩图片等类似操作。
Cache-Control扩展
① cache-extension token--可以扩展Cache-Control首部字段内的指令。
Connection
Connection首部字段具有两个作用：控制不再转发给代理的首部字段、管理持久连接。
控制不再转发给代理的首部字段就是用Connection来指向，在代理服务器转发请求给服务器时，删去的首部字段。
管理持久连接就是用Connection指向，服务器对客户端连接的关系，关系词有Close和Keep-Alive。
Date
表明创建HTTP报文的日期和时间
Date的格式有三种:
Pragma
Pragma是HTTP/1,1之前版本的历史遗留字段，仅作为与HTTP的向后兼容而定义。与Cache-Control的功能是相同的，但是Cache-Control指令是HTTP/1.1为基准的。所以在发送的请求中会同时含有这两个首部字段：
Trailer
首部字段Trailer会事先说明在报文主体后记录了哪些首部字段，该首部字段可应用在HTTP/1.1版本分块传输编码。
Transfer-Encoding
该首部字段规定了传输报文主体时的编码方式。
Upgrade
首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来制定一个完全不同的通信协议。但是，使用首部字段Upgrade时，还需要额外指定Connection: Upgrade。对于首部字段Upgrade的请求，服务器可用101状态码作为响应返回。
Via
使用首部字段Via是为了追踪客户端与服务器之间的请求或响应报文的传输路径。报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发。首部字段Via不仅用于追踪报文的转发，还可以避免请求回环的发生。并且如果在客户端发送的请求需要经过若干个代理服务器的转发，那么代理服务器会将自身的信息附加到Via首部，返回该请求的响应。
Warning
该首部通常会告知用户一些与缓存相关的问题的警告。
格式如下：
HTTP报文分为两种，HTTP请求报文跟HTTP响应报文。
HTTP请求报文的结构如下：
其中，请求行中包括的内容有方法、URI和HTTP版本，请求首部字段、通用首部字段和实体首部字段隶属于HTTP首部字段。
HTTP响应报文的结构如下：
其中，状态行包括的内容有HTTP版本、状态码，响应首部字段、通用首部字段和实体首部字段是在HTTP首部字段的范畴内。
HTTP首部字段
HTTP首部字段可以传递额外重要信息，使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言等附加信息。HTTP首部字段结构是由首部字段名和字段值构成：
而HTTP首部字段根据实际用途被分为以下4种类型：
通用首部字段：请求报文和响应报文两方都会使用的首部。
请求首部字段：从客户端向服务器端发送请求报文时使用的首部，可补充请求的附加内容、客户端信息、响应内容相关优先级等信息。
响应首部字段：从服务端向客户端返回响应报文时使用的首部，可补充响应的附加内容，也会要求客户端附加额外的内容信息。
实体首部字段：针对请求报文和响应报文的实体部分使用的首部，可以补充更新时间等与实体有关的信息。
当然，HTTP首部字段是有规定的，在RFC2616中有47个，除了这47种首部字段，还有Cookie，Set-Cookie等在其他RFC中定义的首部字段。这些非正式的首部字段统一归纳在RFC4229中。而且HTTP首部字段将定义成缓存代理和非缓存代理的行为，分成两种类型，端到端首部(End-to-end Header)和逐跳首部(Hop-by-hop Header)、其中端到端首部会转发给请求/响应对应的最终接收目标，且必须保存在有缓存生成的响应中，另外规定它必须转发。而逐跳首部只对单次转发有效，会因通过缓存或代理而不再转发。
逐跳首部字段只有八种，分别是Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Trailer、TE、Transfer-Encoding、Upgrade，除了这八个首部字段之外，其余全属于端到端首部。
HTTP/1.1通用首部字段
HTTP通用首部字段是指请求报文和响应报文都可以使用的首部字段。接下来介绍一些首部字段。
① Cache-Control
Cache-Control首部字段的指令是操作缓存的工作指令，能够控制缓存行为。
缓存请求指令：
| 指令 | 参数 | 说明 |
| no-cache | 无 | 强制向源服务器再次验证 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| max-age=[秒] | 必需 | 响应的最大Age值 |
| max-stale(=[秒]) | 可省略 | 接受已过期的响应 |
| min-fresh=[秒] | 必需 | 期望在指定时间内的响应仍有效 |
| no-transform | 无 | 代理不可更改媒体类型 |
| only-if-cached | 无 | 从缓存获取资源 |
| cache-extension | - | 新指令标记(token) |
缓存响应指令：
| 指令 | 参数 | 说明 |
| public | 无 | 可向任意方提供相应的缓存 |
| private | 可省略 | 仅向特定用户返回响应 |
| no-cache | 可省略 | 缓存前必须先确认其有效性 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| no-transform | 无 | 代理不可更改媒体类型 |
| must-revalidate | 无 | 可缓存但必须再向源服务器进行确认 |
| proxy-revalidate | 无 | 要求中间缓存服务器对缓存的响应有效性再进行确认 |
| max-age=[秒] | 必需 | 相应的最大Age值 |
| s-maxage=[秒] | 必需 | 公共缓存服务器相应的最大Age值 |
| cache-extension | - | 新指令标记(token) |
表示是否能缓存的指令：
① public指令--明确表明其他用户也可利用缓存。
② private指令--缓存服务器只会对特定用户响应提供资源缓存请求。
③ no-cache指令--如果是客户端发送的请求中有这个指令，表示它不要缓存服务器的可能过期的资源，它要直接从源服务器拿出来的资源。如果是服务端的响应请求中有这个指令，那么缓存服务器就不能对资源进行缓存，源服务器以后也不能对缓存服务器请求中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作。
控制可执行缓存的对象的指令：
① no-store指令--暗示请求或响应中数据中包含机密信息，所以该指令规定缓存不能在本地存储请求或响应的任一部分。
指定缓存期限和认证的指令：
① max-age指令--max-age表示缓存资源在缓存服务器上有效的最大时间，如果判定缓存资源的缓存时间比指定时间的数值更小，那么客户端就可以直接接收缓存的资源，而不用向源服务器拿资源。当指定max-age值为0，那么缓存服务器通常需要将请求转发给源服务器。而且HTTP/1.1版本的缓存服务器中，在遇到同时存在Expires首部字段的时候，会优先处理max-age指令。
② s-maxage指令--该指令与max-age指令的功能相同，但是此指令只适用于供多位用户使用的公共缓存服务器，对于向同一用户重复返回相应的服务器来说没有效。而且当时用s-maxage指令后，会直接忽略max-age指令和Expires字段。
③ min-fresh指令--要求缓存服务器返回至少还没有超过缓存期限的缓存资源。
④ max-stale指令--要求即使是过期了的指令，只要客户端要求了，那也照样响应已经过期的缓存资源。
⑤ only-if-cached指令--表示只有是缓存服务器本地缓存着客户端所要求的资源，客户端才会要求返回其资源，如果本地缓存无响应，则会返回504状态码。
⑥ must-revalidate指令--代理会向源服务器再次验证即将返回的响应缓存目前是否依然有效，如果无效，则会返回504状态码。而且，如果使用了must-revalidate指令，会忽略max-stale指令。
⑦ poxy-revalidate指令--要求所有缓存服务器在接收到客户端带有该指令的请求返回响应之前，必须再次验证缓存的有效性。
⑧ no-transform指令--规定无论是在请求还是在响应中，缓存都不能改变实体主体的媒体类型，这样做可以防止缓存或代理压缩图片等类似操作。
Cache-Control扩展
① cache-extension token--可以扩展Cache-Control首部字段内的指令。
Connection
Connection首部字段具有两个作用：控制不再转发给代理的首部字段、管理持久连接。
控制不再转发给代理的首部字段就是用Connection来指向，在代理服务器转发请求给服务器时，删去的首部字段。
管理持久连接就是用Connection指向，服务器对客户端连接的关系，关系词有Close和Keep-Alive。
Date
表明创建HTTP报文的日期和时间
Date的格式有三种:
Pragma
Pragma是HTTP/1,1之前版本的历史遗留字段，仅作为与HTTP的向后兼容而定义。与Cache-Control的功能是相同的，但是Cache-Control指令是HTTP/1.1为基准的。所以在发送的请求中会同时含有这两个首部字段：
Trailer
首部字段Trailer会事先说明在报文主体后记录了哪些首部字段，该首部字段可应用在HTTP/1.1版本分块传输编码。
Transfer-Encoding
该首部字段规定了传输报文主体时的编码方式。
Upgrade
首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来制定一个完全不同的通信协议。但是，使用首部字段Upgrade时，还需要额外指定Connection: Upgrade。对于首部字段Upgrade的请求，服务器可用101状态码作为响应返回。
Via
使用首部字段Via是为了追踪客户端与服务器之间的请求或响应报文的传输路径。报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发。首部字段Via不仅用于追踪报文的转发，还可以避免请求回环的发生。并且如果在客户端发送的请求需要经过若干个代理服务器的转发，那么代理服务器会将自身的信息附加到Via首部，返回该请求的响应。
Warning
HTTP报文分为两种，HTTP请求报文跟HTTP响应报文。
HTTP请求报文的结构如下：
其中，请求行中包括的内容有方法、URI和HTTP版本，请求首部字段、通用首部字段和实体首部字段隶属于HTTP首部字段。
HTTP响应报文的结构如下：
其中，状态行包括的内容有HTTP版本、状态码，响应首部字段、通用首部字段和实体首部字段是在HTTP首部字段的范畴内。
HTTP首部字段
HTTP首部字段可以传递额外重要信息，使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言等附加信息。HTTP首部字段结构是由首部字段名和字段值构成：
而HTTP首部字段根据实际用途被分为以下4种类型：
通用首部字段：请求报文和响应报文两方都会使用的首部。
请求首部字段：从客户端向服务器端发送请求报文时使用的首部，可补充请求的附加内容、客户端信息、响应内容相关优先级等信息。
响应首部字段：从服务端向客户端返回响应报文时使用的首部，可补充响应的附加内容，也会要求客户端附加额外的内容信息。
实体首部字段：针对请求报文和响应报文的实体部分使用的首部，可以补充更新时间等与实体有关的信息。
当然，HTTP首部字段是有规定的，在RFC2616中有47个，除了这47种首部字段，还有Cookie，Set-Cookie等在其他RFC中定义的首部字段。这些非正式的首部字段统一归纳在RFC4229中。而且HTTP首部字段将定义成缓存代理和非缓存代理的行为，分成两种类型，端到端首部(End-to-end Header)和逐跳首部(Hop-by-hop Header)、其中端到端首部会转发给请求/响应对应的最终接收目标，且必须保存在有缓存生成的响应中，另外规定它必须转发。而逐跳首部只对单次转发有效，会因通过缓存或代理而不再转发。
逐跳首部字段只有八种，分别是Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Trailer、TE、Transfer-Encoding、Upgrade，除了这八个首部字段之外，其余全属于端到端首部。
HTTP/1.1通用首部字段
HTTP通用首部字段是指请求报文和响应报文都可以使用的首部字段。接下来介绍一些首部字段。
① Cache-Control
Cache-Control首部字段的指令是操作缓存的工作指令，能够控制缓存行为。
缓存请求指令：
| 指令 | 参数 | 说明 |
| no-cache | 无 | 强制向源服务器再次验证 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| max-age=[秒] | 必需 | 响应的最大Age值 |
| max-stale(=[秒]) | 可省略 | 接受已过期的响应 |
| min-fresh=[秒] | 必需 | 期望在指定时间内的响应仍有效 |
| no-transform | 无 | 代理不可更改媒体类型 |
| only-if-cached | 无 | 从缓存获取资源 |
| cache-extension | - | 新指令标记(token) |
缓存响应指令：
| 指令 | 参数 | 说明 |
| public | 无 | 可向任意方提供相应的缓存 |
| private | 可省略 | 仅向特定用户返回响应 |
| no-cache | 可省略 | 缓存前必须先确认其有效性 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| no-transform | 无 | 代理不可更改媒体类型 |
| must-revalidate | 无 | 可缓存但必须再向源服务器进行确认 |
| proxy-revalidate | 无 | 要求中间缓存服务器对缓存的响应有效性再进行确认 |
| max-age=[秒] | 必需 | 相应的最大Age值 |
| s-maxage=[秒] | 必需 | 公共缓存服务器相应的最大Age值 |
| cache-extension | - | 新指令标记(token) |
表示是否能缓存的指令：
① public指令--明确表明其他用户也可利用缓存。
② private指令--缓存服务器只会对特定用户响应提供资源缓存请求。
③ no-cache指令--如果是客户端发送的请求中有这个指令，表示它不要缓存服务器的可能过期的资源，它要直接从源服务器拿出来的资源。如果是服务端的响应请求中有这个指令，那么缓存服务器就不能对资源进行缓存，源服务器以后也不能对缓存服务器请求中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作。
控制可执行缓存的对象的指令：
① no-store指令--暗示请求或响应中数据中包含机密信息，所以该指令规定缓存不能在本地存储请求或响应的任一部分。
指定缓存期限和认证的指令：
① max-age指令--max-age表示缓存资源在缓存服务器上有效的最大时间，如果判定缓存资源的缓存时间比指定时间的数值更小，那么客户端就可以直接接收缓存的资源，而不用向源服务器拿资源。当指定max-age值为0，那么缓存服务器通常需要将请求转发给源服务器。而且HTTP/1.1版本的缓存服务器中，在遇到同时存在Expires首部字段的时候，会优先处理max-age指令。
② s-maxage指令--该指令与max-age指令的功能相同，但是此指令只适用于供多位用户使用的公共缓存服务器，对于向同一用户重复返回相应的服务器来说没有效。而且当时用s-maxage指令后，会直接忽略max-age指令和Expires字段。
③ min-fresh指令--要求缓存服务器返回至少还没有超过缓存期限的缓存资源。
④ max-stale指令--要求即使是过期了的指令，只要客户端要求了，那也照样响应已经过期的缓存资源。
⑤ only-if-cached指令--表示只有是缓存服务器本地缓存着客户端所要求的资源，客户端才会要求返回其资源，如果本地缓存无响应，则会返回504状态码。
⑥ must-revalidate指令--代理会向源服务器再次验证即将返回的响应缓存目前是否依然有效，如果无效，则会返回504状态码。而且，如果使用了must-revalidate指令，会忽略max-stale指令。
⑦ poxy-revalidate指令--要求所有缓存服务器在接收到客户端带有该指令的请求返回响应之前，必须再次验证缓存的有效性。
⑧ no-transform指令--规定无论是在请求还是在响应中，缓存都不能改变实体主体的媒体类型，这样做可以防止缓存或代理压缩图片等类似操作。
Cache-Control扩展
① cache-extension token--可以扩展Cache-Control首部字段内的指令。
Connection
Connection首部字段具有两个作用：控制不再转发给代理的首部字段、管理持久连接。
控制不再转发给代理的首部字段就是用Connection来指向，在代理服务器转发请求给服务器时，删去的首部字段。
管理持久连接就是用Connection指向，服务器对客户端连接的关系，关系词有Close和Keep-Alive。
Date
表明创建HTTP报文的日期和时间
Date的格式有三种:
Pragma
Pragma是HTTP/1,1之前版本的历史遗留字段，仅作为与HTTP的向后兼容而定义。与Cache-Control的功能是相同的，但是Cache-Control指令是HTTP/1.1为基准的。所以在发送的请求中会同时含有这两个首部字段：
Trailer
首部字段Trailer会事先说明在报文主体后记录了哪些首部字段，该首部字段可应用在HTTP/1.1版本分块传输编码。
Transfer-Encoding
该首部字段规定了传输报文主体时的编码方式。
Upgrade
首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来制定一个完全不同的通信协议。但是，使用首部字段Upgrade时，还需要额外指定Connection: Upgrade。对于首部字段Upgrade的请求，服务器可用101状态码作为响应返回。
Via
使用首部字段Via是为了追踪客户端与服务器之间的请求或响应报文的传输路径。报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发。首部字段Via不仅用于追踪报文的转发，还可以避免请求回环的发生。并且如果在客户端发送的请求需要经过若干个代理服务器的转发，那么代理服务器会将自身的信息附加到Via首部，返回该请求的响应。
Warning
HTTP/1.1 中定义了7种警告。而且警告码具备扩展性，今后有可能追加新的警告码。
HTTP警告码：
| 警告码 | 说明 |
| 110 | 代理返回已过期的资源 |
| 111 | 代理再验证资源有效性时失败 |
| 112 | 代理与互联网连接被故意切断 |
| 113 | 响应的试用期超过24小时 |
| 199 | 任意大的警告内容 |
| 214 | 代理对内容编码或媒体类型等执行了某些处理时 |
| 299 | 任意的警告内容（持久） |
---------------------------------------------------------------------------------------------------------------------
请求首部字段
请求首部字段是从客户端往服务器端发送请求报文中所使用的，用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。
Accept
Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用type/subtype这种形式，一次指定多种媒体类型，如文本文件(text/html, text/plain, rexr/css, application/xhtml+xml, application/xml......)，图片文件(image/jpeg, image/gif, image/png......)，视频文件(video/mpeg, video/quickingtime......)，应用程序使用的二进制文件(application/octet-stream, application/zip......)
若要想给显示的媒体类型增加优先级，则使用q=(0~1)来额外表示权值，用分号(;)进行分隔，不定权值的时候默认q=1.0、
以下是Accept的格式：
Accept-Charset
该首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序，还可以一次性指定多种字符集，然后用q=来表示相对优先级。该首部字段应用于内容协商机制的服务器驱动协商。
以下是Accept-Charset的格式：
Accept-Encoding
该首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序，可一次性指定多种内容编码，并且用q值来确定相对优先级。也就是说，客户端可以告诉服务器，响应的资源可以以压缩等的形式传送过去。
以下是Accept-Encoding的格式：
Accept-Language
该首部字段用来告知服务器用户代理能够的自然语言集，以及自然语言集的优先性，并且可以用q值来表示相对优先级。
以下是Accept-Language的格式：
Authorization
该首部字段是用来告知服务器，用户代理的认证信息。
以下是Authorization的格式：
Except
客户端可以利用该首部字段，写明所期望的扩展，但是HTTP/1.1只规定了100-continue。所以等待状态码100响应的客户端在发生请求时，需要指定Except: 100-continue。
以下是Except的格式：
From
该首部字段From用来告知服务器使用用户代理的用户的电子邮件地址。其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。
以下是From的格式：
Host
因为一个物理主机可以运行虚拟主机，也就是多个域名可同时存在于同一个IP地址上，所以当客户端要访问某一资源的时候，需要使用首部字段Host加以区分，首部字段Host会告知服务器，请求的资源所处的互联网主机名称和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。
以下是Host的格式：
If-Match
只有当If-Match的字段值跟ETag(实体标记)值匹配一致时，服务器才会接受请求。
If-Modified-Since
如果在If-Modified-Since字段指定的日期时间后，资源发生了更新，服务器会接受请求。
If-None-Match
只有在If-None-Match的字段值与ETag值不一致时，可处理该请求。与If-Match首部字段的作用相反。
If-Range
If-Range字段值若是跟ETag值或更新的日期时间匹配一致，那么就作为范围请求处理，如果不一致，则忽略范围请求，返回全部资源。如果不用首部字段If-Range，如果服务端的资源更新，客户端持有资源中的一部分也会随之无效，所以范围请求作为前提也是无效的，这时，服务器会暂且以状态码412作为响应返回，催促客户端再次发送请求，那么这就需要进行两次处理。
If-Unmodified-Since
作用与If-Modified-Since相反，作用是告知服务器，指定的请求资源只有在字段值内指定的日期时间之后，未发生更新的情况下，才能处理请求。如果更新了，则返回状态码412。
Max-Forwards
通过TRACE方法或OPTIONS方法，发送包含首部字段Max-Forwards的请求时，该字段以十进制整数形式指定可经过的服务器最大数目。服务器在往下一个服务器转发请求之前，会将Max-Forwards值为0的请求时，则不再进行转发，而是直接返回响应。
Proxy-Authorization
接收到从代理服务器发来的认证质询时，客户端会发送包含首部字段Proxy-Authorization的请求，以告知服务器认证所需要的信息。这个行为与认证相似，但是认证是发生在达利和客户端之间的，而客户端与服务器之间的“认证”就可以用Authorization起到相同作用。
Range
对于只需获取部分资源的范围请求，包含首部字段Range即可告知服务器资源的指定范围，接收到请求的服务器响应成功会以206状态码进行响应，如果无法处理该范围请求时会返回状态码200和全部资源来响应。
Referer
此字段会告知服务器请求的原始资源的URI，就是说Referer字段会告诉服务器请求的URI是从哪个客户端发起的。
TE
首部字段TE会告知服务器客户端能够处理响应的传输方式及相对优先级，而且还可以指定班队trailer字段的分块传输编码方式。
User-Agent
盖子吨会将创建请求的浏览器和用户代理名称等信息传达给服务器。
响应首部字段
响应首部字端是由服务器端向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。
响应首部字段有以下几种：
Accept-Ranges
该字段是用来告知客户端服务器是否能处理范围请求，以指定获取服务器端某个部分的资源。可指定的字段值仅有两种，可处理范围请求时指定其为bytes，反之则指定其为none。
Age
该字段能告知客户端，源服务器在多久之前创建了响应，而却字段值的单位为秒。若创建该响应的服务器时缓存服务器，Age值是指缓存后的响应再次发起认证到认证完成的时间值。代理创建响应时必须加上首部字段Age。
ETag
该首部字段是一种可将资源以字符串形式做唯一性标识的方式。资源被缓存时，就会被分配唯一性标识，也就是服务器会为每份资源分配对应的ETag值，当资源更新时，ETag值也需要更新。生成ETag值时，并没有统一的算法规则，仅仅是由服务器来分配。强ETag值，就是不论实体发生多么细微的变化都会改变其值；弱ETag值只有在资源发生根本变化，产生差异时才会改变ETag值，这时会在字段值最开始处附加W/。
Location
该首部字段可以将响应接收方引导至某个与请求URI位置不同的资源，而且该字段会配合3xx : Redirection的响应，提供重定向的URI，几乎所有的浏览器在接收到包含首部字段Location的响应后，都会强制性地尝试对已提示的重定向资源的访问。
Proxy-Authenticate
该字段会把由代理服务器所要求的认证信息发送给客户端。
Retry-After
该首部字段告知客户端应该在多久之后再次发送请求。主要配合状态码503响应，或3xx Redirect响应一起使用，此字段值可以制定为具体的日期时间，也可以是创建响应后的秒数。
Server
该首部字段告知客户端当前服务器上安装的HTTP服务器应用程序的信息。不单单会标出服务器上的软件应用名称，还有可能包括版本号和安装时启用的可选项。
Vary
该首部字段可对缓存进行控制，元服务器会向代理服务器传达关于本地缓存使用方法的命令。当代理服务器接收到带有Vary首部字段指定获取资源的请求时，如果使用的Accept-Language字段的值相同，那么就直接从缓存返回响应。反之，则需要先从源服务器端获取资源后才能作为响应返回。
WWW-Authenticate
该首部字段用于HTTP访问，而且会告知客户端使用与访问请求URI所指定资源的认证方案(Basic/Digest)和带参数提示的质询、状态码401响应中一定带有此字段。
---------------------------------------------------------------------------------------------------------------------
实体首部字段
实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，而且请求和响应双方的HTTP报文中都含有与实体相关的首部字段，用于补充内容的更新时间等与实体相关的信息。
Allow
该首部字段用于通知客户端能能够支持Request-URI指定资源的所有HTTP方法。当服务器接收到不支持的HTTP方法时，会以状态码405作为响应返回。与此同时，还会把所有能支持的HTTP方法写入首部字段Allow后返回。
Content-Encoding
该首部字段会告知客户端服务器对实体的主体部分选用内容编码方式，而内容编码是指不丢失实体信息的前提下所进行的压缩。而内容编码方式只有四种，就是gzip、compress、deflate、identity。
Content-Language
该首部字段会告知客户端，实体主体使用的自然语言。
Content-Length
该首部字段表明了实体主体部分的大小，但是对实体主体进行内容编码传输时，就不能再使用Content-Length首部字，因为实体主体大小的计算方法会根据内容编码的不同而有所改变且计算方法略复杂。
Content-Location
该首部字段给出与报文主体部分相对应的URI，而且是报文主体返回资源对应的URI。
Content-MD5
该首部字段是一串由MD5算法生成的值，其目的是在与检查报文主体在传输过程中是否保持完整，以及确认传输到达。Content-MD5字段值的生成过程如下：
为确保报文的有效性，作为接收方的客户端会对报文主体再执行一次相同的MD5算法。计算出的值与字段值作比较后，即可判断出报文主体的准确性。
Content-Range
该字段可以针对范围请求返回响应，能告知客户端作为响应返回的实体的哪个部分符合范围请求，字段值以字节为单位，表示当前发送部分及整个实体大小。
Content-Type
该字段说明了实体主体内对应的媒体类型。
Expires
该首部字段会将资源失效的日期告知客户端，缓存服务器在接收到含有首部字段Expires的响应后，会以缓存来应答请求，在Expires字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。
Last-Modified
该首部字段指明资源最终修改的时间，一般来说，这个值就是Request-URI指定资源被修改的时间。
为Cookie服务的首部字段
Cookie的工作机制是用户识别及状态管理。Web网站为了管理用户的状态会通过Web浏览器，把一些数据临时写入用户的计算机内，当用户访问该Web网站时，可通过通信方式取回之前存放的Cookie，调用Cookie时，由于可校验Cookie的有效期以及发送方的域、路径、协议等信息，所以正规发布的Cookie内的数据不会因来自其他Web站点和攻击者的攻击而泄露。
在此介绍两个最普遍的Cookie的首部字段：
| 首部字段名 | 说明 | 首部类型 |
| Set-Cookie | 开始状态管理所使用的的Cookie信息 | 响应首部字段 |
| Cookie | 服务器接收到的Cookie信息 | 请求首部字段 |
Set-Cookie
当服务器准备开始管理客户端的状态时，会事先告知各种信息。下面列举Set-Cookie的字段值：
| 属性 | 说明 |
| NAME=VALUE | 赋予Cookie的名称和其值(必需项) |
| expires=DATE | Cookie的有效期(若不明确指定则默认为浏览器关闭前为止) |
| path-PATH | 将服务器上的文件目录作为Cookie的适用对象(若不指定则默认为文档所在的文件目录) |
| domain=域名 | 作为Cookie适用对象的域名(若不指定则默认为创建Cookie的服务器的域名) |
| Secure | 仅在HTTPS安全通行时才会发送Cookie |
| HttpOnly | 加以限制，使Cookie不能被JavaScript脚本访问，目的是为防止跨站脚本攻击对Cookie信息的获取 |
Cookie
该首部字段会告知服务器，当客户端想获得HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie。接收到多个Cookie时，同样可以以多个Cookie形式发送。
其他首部字段
HTTP首部字段是可以自行扩展的。所以Web服务器和浏览器的应用上，会出现各种非标你准的首部字段。
X-Frame-Options
该首部字段属于HTTP响应首部，用于控制网站内容在其他Web网站的Frame标签内的现实问题，主要目的是为了防止点击劫持攻击。该字段有两个可指定的字段值：
| 字段值 | 含义 |
| DENY | 拒绝 |
| SAMEORIGIN | 仅同源域名下的匹配时许可 |
X-XSS-Protection
该首部字段属于HTTP响应首部，它是针对跨站脚本攻击(XSS)的一种对策，用于控制浏览器XSS防护机制的开关。该字段有两个可指定的字段值：
| 字段值 | 含义 |
| 0 | 将XSS过滤设置成无效状态 |
| 1 | 将XSS过滤设置成有效状态 |
DNT
该首部字段属于HTTP请求首部，DNT首部自担是拒绝个人信息被收集，是表示拒绝被精准广告追踪的一种方法。该字段有两个可以指定的值：
| 字段值 | 含义 |
| 0 | 同意被追踪 |
| 1 | 不同意被追踪 |
P3P
该首部字段属于HTTP响应首部，通过利用P3P技术，可以让Web网站上的个人隐私贬称过一种仅供程序可理解的形式，以达到保护用户隐私的目的。
要进行P3P的设定，需要这么做：
---------------------------------------------------------------------------------------------------------------------
HTTP主要有下列缺点：
通信使用明文(不加密)，内容可能会被窃听；
不验证通信方的身份，因此有可能遭遇伪装；
无法证明报文的完整性，所以有可能已遭篡改。
这些缺点是由什么引起的呢？怎么处理这些个缺点呢？
通信使用明文可能会被窃听
也就是说，HTTP报文使用的是未经过加密的报文方式发送。因为TCP/IP是可能被窃听的网络，而且TCP/IP协议族的工作机制就是可以使，通信内容在所有的通信线路上都有可能遭到窥视，即使是已经加密处理够的通信，也会被窥视到通信内容，因为加密处理后的报文信息本身还是会被看到。
如此一来，为了在信息有可能会被窥视的情况下还能保证信息的安全，可以采取加密技术，加密的方法有两种：
| 加密的对象 | 加密的解释 |
| 通信的加密 | HTTP协议本身没有加密机制，但是可以通过和SSL或TLS的组合使用，加密HTTP的通信内容，用SSL建立安全通信线路后，就可以在这条线路上进行HTTP通信了 |
| 内容的加密 | 把HTTP报文里所含的内容进行加密处理 |
不验证通信方的身份就可能遭遇伪装
HTTP协议中的请求和响应不会对通信方进行确认。
也就是说，在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是说都会返回一个响应(但也仅限于发送端的IP地址和端口号没有被Web服务器设定限制访问的前提下)。所以，会出现以下隐患：
①无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的客户端。
②无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
③无法确定正在通信的对方是否具备访问权限。因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限。无法判定请求是来自何方、出自谁手。
④即使是无意义的请求也会照单全收。无法阻止海量请求下的DoS攻击。
那么要怎么确认通信方？可以使用SSL，SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方，而证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术上角度来说是异常困难的事情，所以只要能够确认通信方持有的证书，即可判断通信方的真实意图。
无法证明报文完整性，可能已遭篡改
由于HTTP协议无法证明通信的报文完整性，所以没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的，所以在请求或响应在传输途中，造攻击者拦截并篡改内容的攻击即中间人攻击，我们一般是察觉不到的。
那么可以用MD5和SHA-1等散列值校验的方法，以及用来确认文件的数字签名方法来防止篡改，不过即使是这样，还是有较大的漏洞，所以还是采用HTTPS协议会更好一点。
由以上的缺点和缺点的处理方法，我们可以知道，一个更可靠的协议需要被创造出来，于是HTTP加上加密处理和认证以及完整性保护后即是HTTPS的技术出现了。
HTTPS并非是应用层的一种新协议，它其实就是身披SSL协议外壳的HTTP，因为通常HTTP直接和TCP通信，所以当时用SSL时，则演变成先和SSL通信，再由SSL和TCP通信。如下图所展示：
接下来介绍数据传输过程中的加密方式。
共享密钥加密
加密和解密同用一个密钥的方式称为共享密钥加密，也被叫做对称密钥加密。共享密钥加密是通过互联网将密钥发送给别人，让别人跟自己一样有一把一模一样的钥匙，但是这样很容易被攻击者获取到钥匙，但是不发送，对方就不能解密。 于是，公开密钥加密的加密方式应运而生。
公开密钥加密
公开密钥加密使用一对非对称的密钥，一把叫做私有密钥，另一把叫做公开密钥。私有密钥不能被任何人知道，公开密钥则可以随意发布，任何人都可以获得。
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密，这样就不必担心密钥被攻击者窃听而盗走了，而且想要根据密文和公开密钥恢复到信息原文是很困难的。
HTTPS采用混合加密机制
仅仅是使用公开密钥加密，因为公开密钥加密方式更为复杂，所以效率会很低，因此，混合共享密钥加密和公开密钥加密机制会更加合适。
① 使用公开密钥加密方式安全地交换在稍后的共享密钥加密中要使用的密钥。
② 确保交换的密钥是安全的前提下，使用共享密钥加密方式进行通信。
证明公开密钥正确性的证书
遗憾的是，公开密钥加密方式存在一个问题，那就是无法证明公开密钥本身就是货真价实的公开密钥，有可能，公开密钥已经在传输过程中被攻击者调包了。
所以，一个新的解决方案产生了，可以使用第三方验证---由数字证书认证机构(CA, Centificate Authority)和其相关机关颁发的公开密钥证书。以下是数字证书认证机构的业务流程：
可证明组织真实性的EV SSL证书
证书的一个租用是用来证明作为通信一方的服务器是否规范，另外一个作用是可确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书就是EV SSL证书。EV SSL证书是基于国际标准的认证指导方针颁发的证书，其严格规定了对运营组织是否真实的确认方针，所以，通过认证的Web网站能够获得更高的认可度。(地址栏背景色是绿色)
用以确认客户端的客户端证书
以客户达UN证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端。但是有几个问题需要注意：
① 证书的获取和发布。想获取证书，用户先是要自行安装客户端证书，而且客户端证书是需要付费购买的。另外要让知识层次不同的用户们自行安装证书，这本身就充满了各种挑战。
② 客户端证书只能用来证明客户端实际存在，而不能证明用户本人的真实有效性。
由上面我们可以总结，目前还是HTTPS的通信机制比较可以保证数据传输过程的安全性。
HTTPS的安全通信机制：
接下来是对HTTPS的安全通信机制的分部解释：
步骤①: 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表。
步骤②: 服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的的。
步骤③: 之后服务器发送Certificate报文。报文中包含公开密钥证书。
步骤④: 最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
步骤⑤: SSL第一次握手结束之后，客户端以Client Key Exchanges报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤③中的公开密钥进行加密。
步骤⑥: 接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，再次报文之后的通信会采用Pre-master secret密钥加密。
步骤⑦: 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
步骤⑧: 服务器同样发送Change Cipher Spec报文。
步骤⑨: 服务器同样发送Finished报文。
步骤⑩: 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
步骤⑪: 应用层协议通信，即发送HTTP响应。
步骤⑫: 最后由客户端断开连接。断开连接时，发送close_notify报文，这步之后，再发送TCP FIN报文来关闭与TCP的通信。
在以上流程中，应用层发送数据时会附加一种叫做MAC的报文摘要。MAC能够查知报文是否遭到篡改，从而保护报文的完整性。
---------------------------------------------------------------------------------------------------------------------
计算机本身无法判断使用者的身份，这时就需要使用者“自报家门”，通常需要核对的信息有这些：
① 密码：只有本人才会知道的字符串信息。
② 动态令牌：仅限本人持有的设备内显示的一次性密码。
③ 数字证书：仅限本人(终端)持有的信息。
④ 生物认证：指纹和虹膜等本人的生理信息。
⑤ IC卡等：仅限本人持有的信息。
而HTTP/1.1使用的认证方式有这些：
① BASIC认证(基本认证)。
② DIGEST认证(摘要认证)。
③ SSL客户端认证。
④ FormBase认证(基于表单认证)。
⑤ WIndows统一认证(《图解HTTP》里面没有讲解，再次也先不对其进行介绍)
BASIC认证
BASIC认证(基本认证)是从HTTP/1.0就定义的认证方式，是Web服务器与通信客户端之间进行的认证方式。
步骤① 当请求的资源需要BASIC认证时，服务器会随状态码401Authorization Required，返回带WWW-Authenticate首部字段的响应。该字段内包含认证的方式(BASIC)及Request-URI安全域字符串。
步骤② 接收到状态码401的客户端为了通过BASIC认证，需要将用户ID及密码发送给服务器。发送的字符串内容是由用户ID和密码构成，两者中间以冒号(:)连接后，再经过Base64编码处理。
步骤③ 接受到包含首部字段Authorization请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含Request-URI资源的响应。
BASIC认证虽然采用Base64编码方式，但这不是加密处理。不需要任何附加信息即可对其解码，所以很容易被别人盗取信息，而且，想在进行一次BASIC认证时，一般的浏览器却无法实现认证注销操作。
于是，DIGEST认证诞生了。
DIGEST认证
DIGEST认证同样使用质询/响应的方式，但不会像BASIC认证那样直接发送明文密码。
所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那里接收到的质询吗计算生成响应码。最后将响应码返回给对方进行认证的方式。因为发送给对方的知识响应摘要及由质询码产生的计算结果，所以比起BASIC认证，密码泄露的可能性就降低了。
步骤① 请求需认证的资源时，服务器会随着状态码401，返回带WWW-Authenticate首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码。首部字段WWW-Authenticate内必须包含realm和nonce这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。nonce是一种每次随返回的401响应生成的任意随机字符串。该字符串通常推荐由Base64编码的十六进制数的组成形式，但实际内容依赖服务器的具体实现。
步骤② 接收到401状态码的客户端，返回的响应中包含DIGEST认证必须的首部字段Authorization信息。首部字段Authorization内必须包含username、realm、nonce、uri和response的字段信息。其中，realm和nonce就是之前从服务器接收到的响应中的字段。
步骤③ 接收到包含首部字段Authorization请求的服务器，会确认认证信息的正确性。认证通过后则返回包含Request-URI资源的响应。并且这时会在首部字段Authentication-Info写入一些认证成功的相关信息。DIGEST认证提供了高于BASIC认证的安全等级，但是和HTTPS的客户端认证相比仍旧很弱。DIGEST认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。
SSL客户端认证
SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。
为达到SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。一下是SSL客户端认证的认证步骤：
步骤① 接收到需要认证资源的请求，服务器hi发送Certificate Request报文，要求客户端提供客户端证书。
步骤② 用户选择将发送的客户端证书后，客户端会把客户端证书信息以Client Certificate报文方式发送给服务器。
步骤③ 服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信。
而且一般SSL客户端认证会和基于表单认证组合形成一种双因素认证来使用。也就是说，第一个认证因素的SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。通过双因素认证后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。
基于表单认证
多数情况下，输入已事先登陆的用户ID和密码等登陆信息后，发送给Web应用程序，基于认证结果来决定认证是否成功。基于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session。
基于表单认证本身是通过服务器端的Web应用，将客户端发送过来的用户ID和密码与之前登陆过的信息做匹配来进行认证的。但是结余HTTP是无状态协议，所以我们会使用Cookie来管理Session，以弥补HTTP协议中不存在的状态管理功能。
步骤① 客户端就把用户ID和密码等登陆信息放入报文的实体部分，通常是以POST方法把请求发送给服务器。而这时，会使用HTTPS通信来进行HTML表单画面的显示和用户怓数据的发送。
步骤② 服务器会发放用以识别用户的Session ID。通过客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与SessionID绑定后记录在服务器端。向客户端返回响应时，会在首部字段Set-Cookie内写入Session ID。
步骤③ 客户端接收到从服务器端发送来的Session ID后，会将其作为Cookie保存在本地，下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID也随之发送到服务器。服务器可通过验证接收到的Session ID识别用户和其认证状态。