chrome浏览器自带的开发者工具查看http头以及详解http头

1.浏览器常见HTTP请求头解释

使用chrome浏览器自带的开发者工具查看http头的方法

1.在网页任意地方右击选择审查元素或者按下 shift+ctrl+c, 打开chrome自带的调试工具;

2.选择network标签, 刷新网页(在打开调试工具的情况下刷新);

3.刷新后在左边找到该网页url,点击 后右边选择headers,就可以看到当前网页的http头了;

请求Header(HTTP request header )

Host 请求的域名

User-Agent 浏览器端浏览器型号和版本

Accept 可接受的内容类型

Accept-Language 语言

Accept-Encoding 可接受的压缩类型 gzip,deflate

Accept-Charset 可接受的内容编码 UTF-8,*

服务器端的响应Header(response header)

Date 服务器端时间

Server 服务器端的服务器软件 Apache/2.2.6

Etag 文件标识符

Content-Encoding传送启用了GZIP压缩 gzip

Content-Length 内容长度

Content-Type 内容类型

但是实际上 HTTP请求头和响应头是有很多种的

HTTP 请求头和响应头是 HTTP 协议中非常重要的组成部分，本文将详细介绍常见的 HTTP 请求头和响应头，以及它们的作用和场景，同时还会对比不同 HTTP 协议版本中的差异。

2.HTTP 请求头

2.1. Accept

作用：告诉服务器客户端能够接受的 MIME 类型，用于指定客户端可以接受的响应内容格式。

场景：通常在客户端向服务器发送请求时使用，以便服务器返回适合客户端的响应内容格式。

可接受值：MIME 类型，例如 text/html、application/json 等。

2.2. Accept-Encoding

作用：告诉服务器客户端能够接受的压缩方式，用于指定客户端可以接受的压缩方式。

场景：通常在客户端向服务器发送请求时使用，以便服务器返回适合客户端的压缩方式。

可接受值：压缩方式，例如 gzip、deflate 等。

2.3. Accept-Language

作用：告诉服务器客户端能够接受的语言类型，用于指定客户端可以接受的响应内容语言类型。

场景：通常在客户端向服务器发送请求时使用，以便服务器返回适合客户端的响应内容语言类型。

可接受值：语言类型，例如 zh-CN、en-US 等。

2.4. Authorization

作用：告诉服务器客户端的身份认证信息，用于进行身份验证和授权。

场景：通常在客户端向服务器发送需要身份认证的请求时使用，以便服务器进行身份验证和授权。

可接受值：身份认证信息，例如 Basic、Digest、Bearer 等。

2.5. Cache-Control

作用：告诉服务器客户端对缓存的处理方式，用于指定客户端对缓存的处理方式。

场景：通常在客户端向服务器发送请求时使用，以便服务器返回适合客户端的缓存处理方式。

可接受值：缓存处理方式，例如 no-cache、max-age、no-store 等。

2.6. Connection

作用：告诉服务器客户端与服务器之间的连接类型，用于指定客户端与服务器之间的连接类型。

场景：通常在客户端向服务器发送请求时使用，以便服务器返回适合客户端的连接类型。

可接受值：连接类型，例如 Keep-Alive、Close 等。

2.7. Content-Length

作用：告诉服务器请求体的长度，用于指定客户端发送的请求体长度。

场景：通常在客户端向服务器发送含有请求体的请求时使用，以便服务器正确地解析请求体。

可接受值：请求体的长度，例如 1024、2048 等。

2.8. Content-Type

作用：告诉服务器请求体的 MIME 类型，用于指定客户端发送的请求体类型。

场景：通常在客户端向服务器发送含有请求体的请求时使用，以便服务器正确地解析请求体。

可接受值：MIME 类型，例如 application/json、application/x-www-form-urlencoded 等。

2.9. Cookie

作用：告诉服务器客户端的 Cookie 信息，用于指定客户端的状态和历史记录。

场景：通常在客户端向服务器发送请求时使用，以便服务器识别客户端并进行相应的处理。

可接受值：Cookie 信息。

2.10. Host

作用：告诉服务器请求的主机名，用于指定客户端请求的目标主机名。

场景：通常在客户端向服务器发送请求时使用，以便服务器将请求转发到相应的主机。

可接受值：主机名，例如 www.example.com。

2.11. If-Modified-Since

作用：告诉服务器客户端上次请求资源的时间，用于指定客户端上次请求资源的时间。

场景：通常在客户端向服务器发送 GET 请求时使用，以便服务器判断资源是否发生过修改，从而决定是否返回新的资源。

可接受值：日期时间字符串，例如 Sat, 29 Oct 1994 19:43:31 GMT。

2.12. Referer

作用：告诉服务器客户端请求的来源页面，用于指定客户端请求的来源页面。

场景：通常在客户端向服务器发送请求时使用，以便服务器了解客户端请求的来源，从而进行相应的处理。

可接受值：来源页面的 URL。

2.13. User-Agent

作用：告诉服务器客户端的浏览器类型和版本号，用于指定客户端的浏览器类型和版本号。

场景：通常在客户端向服务器发送请求时使用，以便服务器了解客户端的浏览器类型和版本号，从而进行相应的处理。

可接受值：浏览器类型和版本号。

2.14. Upgrade

作用：告诉服务器客户端希望升级的协议，用于指定客户端希望升级的协议。

场景：通常在客户端向服务器发送请求时使用，以便服务器了解客户端希望升级的协议，从而进行相应的处理。

可接受值：协议名称，例如 HTTP/2.0。

2.15. Origin

作用：告诉服务器请求的来源地址，用于进行跨域请求时的安全验证。

场景：通常在客户端向服务器发送跨域请求时使用，以便服务器验证请求的合法性。

可接受值：来源地址，例如 https://www.example.com。

3.HTTP 响应头

3.1. Access-Control-Allow-Origin

作用：告诉客户端响应是否允许跨域请求，用于指定服务器是否允许来自指定域名的跨域请求。

场景：通常在服务器向客户端发送跨域响应时使用，以便客户端了解响应是否允许跨域请求。

3.2. Content-Encoding

作用：告诉客户端响应的压缩方式，用于指定服务器使用的压缩方式。

场景：通常在服务器向客户端发送响应时使用，以便客户端正确解压响应内容。

可接受值：压缩方式，例如 gzip、deflate 等。

3.3. Content-Language

作用：告诉客户端响应的语言类型，用于指定服务器返回的响应内容语言类型。

场景：通常在服务器向客户端发送响应时使用，以便客户端了解响应内容的语言类型。

可接受值：语言类型，例如 zh-CN、en-US 等。

3.4. Content-Length

作用：告诉客户端响应的长度，用于指定服务器返回的响应内容长度。

场景：通常在服务器向客户端发送响应时使用，以便客户端正确解析响应内容。

可接受值：响应内容的长度，例如 1024、2048 等。

3.5. Content-Type

作用：告诉客户端响应的 MIME 类型，用于指定服务器返回的响应内容类型。

场景：通常在服务器向客户端发送响应时使用，以便客户端正确解析响应内容。

可接受值：MIME 类型，例如 text/html、application/json 等。

3.6. ETag

作用：告诉客户端响应的实体标识，用于指定服务器返回的响应内容的实体标识。

场景：通常在服务器向客户端发送响应时使用，以便客户端缓存响应内容。

可接受值：实体标识，例如 “12345”。

3.7. Last-Modified

作用：告诉客户端响应的最后修改时间，用于指定服务器返回的响应内容的最后修改时间。

场景：通常在服务器向客户端发送响应时使用，以便客户端缓存响应内容并在下一次请求时进行缓存验证。

可接受值：日期时间字符串，例如 Sat, 29 Oct 1994 19:43:31 GMT。

3.8. Location

作用：告诉客户端响应的重定向地址，用于指定客户端重定向到的地址。

场景：通常在服务器向客户端发送重定向响应时使用，以便客户端重定向到指定的地址。

可接受值：重定向地址，例如 https://www.example.com。

3.9. Server

作用：告诉客户端服务器的软件信息，用于指定服务器的软件信息。

场景：通常在服务器向客户端发送响应时使用，以便客户端了解服务器的软件信息。

可接受值：服务器的软件信息，例如 Apache、Nginx 等。

3.10. Set-Cookie

作用：告诉客户端设置 Cookie，用于指定客户端设置 Cookie。

场景：通常在服务器向客户端发送响应时使用，以便客户端设置 Cookie。

可接受值：Cookie 信息。

4.HTTP 协议版本差异

其实不同版本之间也是有差异的，我们整理以下：

HTTP/1.0 和 HTTP/1.1 的主要差异在于：

持久连接（Persistent Connection）

HTTP/1.0 默认使用非持久连接，即每次请求都需要建立一个新的连接，而 HTTP/1.1 默认使用持久连接，即多个请求可以使用同一个连接。

管道化（Pipelining）

HTTP/1.1 支持管道化，即在同一个连接中可以发送多个请求，而 HTTP/1.0 不支持管道化。

Host 头部

HTTP/1.1 强制要求在请求头中包含 Host 头部，而 HTTP/1.0 不要求。

缓存控制

HTTP/1.1 引入了更多的缓存控制机制，例如 Cache-Control 和 ETag。

错误处理

HTTP/1.1 引入了更多的错误处理机制，例如 100 Continue 状态码。

总的来说，HTTP/1.1 相对于 HTTP/1.0 在性能、安全、错误处理等方面有了很大的改进，因此在现代 Web

开发中，HTTP/1.1 已经成为了主流。同时，HTTP/2.0 又在性能和效率方面进行了更大的优化，成为了当前的主流 HTTP 协议。

HTTP/1.0 和 HTTP/1.1 是 HTTP 协议的两个主要版本，而 HTTP/2.0 是 HTTP 协议的最新版本。

简单了解一下发展历史

HTTP/1.0 是在 1996 年发布的，它是  HTTP 协议的第一个正式版本。HTTP/1.0 默认使用非持久连接，在每次请求和响应之间都要关闭连接，这会导致很多性能问题，如服务器过载、资源浪费等。此外，HTTP/1.0 不支持管道化（pipelining），也不支持请求头部的 Host 字段。因此，HTTP/1.0 的性能和可扩展性都存在一定的局限性。

为了解决这些问题，HTTP/1.1 在 1999 年发布。HTTP/1.1 默认采用持久连接，即一个 TCP 连接可以发送多个请求和响应，这样可以减少连接建立和关闭的开销。HTTP/1.1 还支持管道化，一个 TCP 连接可以同时发送多个请求，这样可以减少延迟和提高吞吐量。HTTP/1.1 还引入了请求头部的 Host 字段，这样可以支持虚拟主机（Virtual Host），即一个 Web 服务器可以提供多个网站服务。此外，HTTP/1.1 还支持缓存控制、错误处理、压缩等功能，这些都有助于提高性能和可扩展性。

HTTP/2.0 是在 2015 年发布的最新版本，它基于 Google 发布的 SPDY 协议，并且充分吸收了 HTTP/1.1 的优点。HTTP/2.0 采用二进制协议，可以更高效地传输数据；HTTP/2.0 支持多路复用（Multiplexing），即一个 TCP 连接可以同时发送多个请求和响应，这样可以减少延迟和提高吞吐量；HTTP/2.0 引入了头部压缩等技术，可以减少网络传输的数据量；HTTP/2.0 还支持服务器推送（Server Push），即服务器可以在客户端请求前主动推送资源，这样可以进一步提高性能和用户体验。