HTTP 协议详解

0x01：HTTP 协议简介

HTTP（HyperTextTransferProtocol，超文本传输协议），是一个工作在应用层的协议，它通常运行在 TCP 之上，它指定了客户端以什么样的格式发送信息，以及得到什么样的响应信息。

0x02：HTTP 协议发展概述

0x0201：HTTP 的起源与标准化历程

HTTP 协议，作为互联网基石之一，其发展可以追溯到 1989 年，由蒂姆·伯纳斯·李博士在欧洲核子研究组织（CERN）首次提出。这一创举不仅催生了万维网（www）的诞生，还奠定了 HTTP 作为互联网内容传输核心协议的地位。随后，HTTP 的标准制定工作由两大权威组织 —— 万维网协会（W3C）与互联网工程任务组（IETF）携手推进。经过多轮讨论和迭代。HTTP 1.1 标准最终于 1999 年以 RFC 2616 的形式正式发布，这一版本至今仍广泛应用于全球互联网，支持着数以亿计的网络请求与响应。

0x0202：HTTP/2 的崛起与标准化

进入 21 世纪后，随着互联网的飞速发展，HTTP 1.1 在性能上的局限性逐渐显现。为此 IETF 的 httpbis 工作小组于 2014 年启动了 HTTP/2 标准的制定工作，旨在通过引入头部压缩、多路复用以及服务器推送等创新机制，显著提升 HTTP 协议的性能和效率。经过紧锣密鼓的研发与测试，HTTP/2 标准于 2015 年 5 月正式获得批准并以 RFC 7540 的形式发布，标志着 HTTP 协议迈进了一个全新的发展阶段。如今，HTTP/2 已成为众多现代网站和应用的首选协议，为用户带来更加流畅、快速的浏览体验。

0x03：HTTP 协议的作用以及特点

0x0301：HTTP 协议的作用

HTTP 主要用于在客户端（如 Web 浏览器）和服务器之间传输超文本（如 HTML 文档）以及其他类型的数据（如图片、视频、文件等）。HTTP 协议的主要作用可以概括为如下几点：

信息交换： HTTP 定义了客户端和服务器之间如何发送和接收数据，实现了客户端与服务器之间的信息交换。
内容获取： 用户通过浏览器发起 HTTP 请求，从服务器获取所需的网页内容或其他资源。
状态管理： HTTP 协议中的状态码（如 200 OK，404 Not Found）用于告诉客户端请求的处理结果，帮助管理客户端和服务器的交互状态。
会话控制： 虽然 HTTP 本身是无状态的，但通过 Cookie、Session 等技术可以实现会话控制，支持用户在多个请求之间保持状态。

0x0302：HTTP 协议的特点

无状态性（stateless）： HTTP 协议本身不保留之前请求的上下文信息，即每个请求都是独立的，服务器处理完请求后不会保存任何状态信息。这种无状态性简化了服务器的设计，但也要求通过其他机制（如 Cookie、Session）来维护用户会话。
明文传输： HTTP 协议在默认情况下不对传输的数据进行加密，因此传输的数据（包括用户名、密码等敏感信息）很容易就被截获。为了解决这个问题，出现了 HTTPS 协议，它在 HTTP 的基础上增加了 SSL/TLS 加密层，确保了数据传输的安全性。
灵活的数据类型： HTTP 协议支持多种类型的数据传输，包括文本、图片、视频、JSON 等。通过 Content-Type 头部字段，HTTP 可以告诉接收方具体的数据类型，从而正确地解析和处理数据。
基于请求/响应模型： 客户端发起一次请求，服务端进行一次响应，客户端不发起请求，服务端不会主动响应。但从 HTTP/2 开始，就允许了服务器主动推送资源，无需客户端明确请求。
灵活可扩展性： HTTP 协议允许开发者根据需要自定义头字段（Header Fields）以实现各种功能。这些自定义头部标签可以用于多种目的，如提供额外的信息、进行故障排除、指示缓存状态、限制带宽等。自定义头部标签通常用于那些 HTTP 标准头部标签无法满足需求的特殊场景。
可缓存性： 为了提高访问速度，HTTP 协议支持缓存机制。当客户端再次请求已经缓存的资源时，可以直接从本地缓存中获取，而无需再次从服务器下载。
支持持久连接： HTTP/1.1 版本引入了持久连接（也称为 HTTP Keep-Alive）功能，允许一个 TCP 连接上发送和接收多个 HTTP 请求/响应，减少了因建立和关闭连接所产生的延迟和开销。
支持压缩： 为了减小传输的数据量，HTTP 协议支持对传输的数据进行压缩。通过 Accept-Encoding 和 Content-Encoding 头部字段，客户端和服务器可以协商使用哪种压缩算法。

0x04：HTTP 协议组成

HTTP 协议由 HTTP 请求和 HTTP 响应组成，当用户在浏览器中输入网址访问某个网站时，浏览器会将用户的请求内容封装成一个 HTTP 请求报文发送给该网站对应的服务器。服务器接收到请求后，会将网页数据封装成一个 HTTP 响应报文并返回给用户的浏览器。

0x0401：HTTP 请求报文格式 - Request

HTTP 请求报文主要由 3 部分组成：请求行 + 请求头 + 请求体，如下图所示：

接下来我们利用上图详解每部分的内容，以及格式：

1. 请求行（Request Line）

请求行必须在 HTTP 请求报文的第一行，其内容格式如下：

 请求方式 资源路径 协议/版本

比如在上面的例子中，请求行就是：

 POST /sqli-labs/Less-11/ HTTP/1.1

传达的含义就是，使用 POST 方式请求目标站点的 /sqli-labs/Less-11/ 目录下的资源，本次请求采用的是 HTTP 1.1 协议版本。

1.1 HTTP 请求方式

HTTP 请求方式定义了客户端与服务器之间交互时请求资源或执行操作的不同方法。这些请求方式帮助服务器理解客户端的意图，从而返回相应的响应。以下是一些常见的 HTTP 请求方式及其简要说明：

常用 - GET 方式：请求从服务器获取资源

GET 方式用于请求访问已被 URL（统一资源标识符）识别的资源。

GET 方法是“安全的”（不会对服务器上的数据造成改变）、“幂等的”（多次请求结果相同）和“可缓存的”（响应可以在本地缓存以提高效率）。

GET 请求的的数据会附加在 URL 后，以 ? 分隔 URL 和传输数据，参数之间以 & 相连，例如：
 http://www.example.com/resource?name=John&age=30

常用 - POST 方式：向服务器提交数据

POST 方式通常用于向指定的资源提交要被处理的数据。 POST 请求可能会导致服务器上的数据被更新（如表单提交），但是本地不会缓存 POST 请求的响应。POST 请求的数据通常放在 HTTP 消息的请求体中。

常用 - HEAD 方式：类似 GET 请求，但不会返回实体数据，只获取报头

HEAD 方式与 GET 请求类似，但服务器在响应包中只返回首部（header）信息，而不返回实际内容。这个方式常用于测试超链接的有效性、获取资源的更新日期或者检查资源是否存在等情况。

常用 - PUT 方式：更新服务器的资源

PUT 方式通常用于向指定资源位置上传其最新内容。 PUT 请求是“幂等的”，即多次相同的 PUT 请求对资源的影响是相同的。PUT 请求通常用于更新资源，如果指定资源不存在，服务器可能会根据需要创建它。

常用 - PATCH 方式：对资源应用进行部分修改

PATCH 请求与 PUT 请求类似，但 PUT 请求会替换掉目标资源的全部内容，而 PATCH 请求只修改部分内容。 PATCH 请求是幂等的，但实现起来比 PUT 请求更加复杂。

不常用 - DELETE 方式：请求服务器删除指定的资源

DELETE 方式通常用于请求服务器删除指定的资源。 DELETE 请求是 “幂等的”。客户端使用 DELETE 请求表明资源应该被删除。

不常用 - TRACE 方式：对链路进行测试或诊断

回显服务器收到的请求，主要用于测试或诊断。由于 TRACE 请求可能会暴露敏感信息，许多服务器默认禁用 TRACE 请求。

不常用 - OPTIONS 方式：列出可对资源实行的操作方法，Allow 字段里返回

OPTIONS 方式用于描述目标资源的通信选项。客户端可以通过 OPTIONS 请求得知其对特定资源或资源集合支持的 HTTP 方法，或者对于特定资源支持的功能（如 CORS 预检）。

不常用 - CONNECT 方式：要求服务器和另一台服务器建立连接，充当代理

HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。通常用于 SSL 加密服务器的隧道协议。

1.2 HTTP 资源路径

HTTP 资源路径（通常是指 URL 的一部分，即统一资源定位符中的路径部分，位于协议名和域名之后）是用来指定服务器上特定资源的地址。以下是一些不同场景下的 HTTP 资源路径示例：

访问网站首页：http://www.example.com
资源路径：/ — 这个路径简单地指向网站首页。
访问网站中的特定页面：http://www.example.com/about
资源路径：/about — 这通常用于访问站点中的 “关于我们” 页面。
访问网站中的图片：http://www.example.com/images/logo.png
资源路径：/images/logo.png — 这个路径指向了网站 images 文件夹下的 logo.png 文件。
访问网站中的文档：http://www.example.com/docs/user-guide.pdf
资源路径：/docs/user-guide.pdf — 这个路径指向了网站 docs 文件夹下的 user-guide.pdf 文件。
访问具有查询参数的页面：http://www.example.com/search.php?query=http
资源路径：/search.php?query=http — 这个路径用于访问搜索页面 search.php 并向该页面传递的查询参数 query，其值为 http。

1.3 HTTP 协议/版本

在 HTTP 请求包中，协议/版本部分指定了客户端和服务器之间通信所使用的 HTTP 协议的版本。这个内容是浏览器自动指定的，我们只需要了解不同版本的 HTTP 协议的大致特点即可（主要是 1.0 版本和 1.1 版本）：

HTTP/0.9 - 1991 年

功能简陋： HTTP/0.9 是 HTTP 协议的第一个版本，功能非常有限，仅支持 GET 方法，不支持 POST 等其他方法。

响应格式单一： 服务器只能回应 HTML 格式字符串，无法处理其他类型的数据。

无状态： 每次请求都是独立的，服务器不会保存客户端的状态信息。

无头部信息： 请求和响应都不包含头部信息，只有简单的请求行和响应体。

HTTP/1.0 - 1996 年 5 月

引入头部信息：HTTP/1.0 引入了请求和响应的头部信息，使得 HTTP 协议更加灵活和可扩展。

支持多种请求方法：除了GET 方法外，还支持 HEAD、POST 等方法。

MIME类型：引入了 Content-Type 字段，支持多种数据格式的传输，如文本、图片、视频等。

状态码：定义了丰富的状态码来表示请求的处理结果。

缓存机制：支持缓存机制，允许客户端缓存服务器响应的内容，以提高响应速度和减少网络流量。

缺点：不支持持久连接，每次请求都需要建立新的 TCP 连接，增加了网络开销。

HTTP/1.1 - 1997 年 1 月

持久连接：默认支持持久连接（Connection: keep-alive），减少了建立和关闭连接的次数，提高了传输效率。

管道机制：支持管道机制，允许在同一个 TCP 连接中同时发送多个请求，进一步提高了传输效率。

新增请求方法：增加了 PUT、DELETE、OPTIONS、TRACE 等请求方法。

Host 头：引入了 Host 头，允许在同一台服务器上部署多个域名。

缓存控制：提供了更丰富的缓存控制选项，如 E-tag、If-Match、If-None-Match 等。

带宽优化：通过压缩头部信息和优化数据传输方式，进一步提高了带宽利用率。

HTTP/2.0 - 2015 年 5 月

二进制协议：HTTP/2 采用二进制协议替代原本的文本协议，提高了传输效率和安全性。

多路复用：支持在同一 TCP 连接中并行处理多个请求和响应，避免了队头阻塞问题。

头部压缩：引入头部压缩机制，减少了头部信息的传输量。

服务器推送：允许服务器主动向客户端推送资源，无需客户端明确请求。

流控制：提供了流控制机制，允许客户端和服务器对数据传输进行更精细的控制。

HTTP/3.0 - 2018 年

基于 QUIC 协议：HTTP/3 使用 QUIC 协议作为传输层协议，替代了传统的 TCP 协议。QUIC 协议基于 UDP 协议，具有更低的延迟和更快的连接建立速度。

加密传输：HTTP/3 默认使用 TLS 加密传输，提高了数据传输的安全性。

无连接依赖：由于 QUIC 协议的特性，HTTP/3 不再依赖于 TCP 连接，进一步提高了传输效率和灵活性。

2. 请求头（Request Header）

HTTP 请求头，从 HTTP 请求报文的第二行开始，到第一个空行结束（请求头和请求体之间存在一个空行）。请求头中每一行的内容格式如下：

 key: value

比如，在最开始的例子中，请求头的内容如下：

 Host: 127.0.0.1Content-Length: 34Cache-Control: max-age=0sec-ch-ua: "Not A(Brand";v="24", "Chromium";v="110"sec-ch-ua-mobile: ?0sec-ch-ua-platform: "Windows"Upgrade-Insecure-Requests: 1Origin: http://127.0.0.1Content-Type: application/x-www-form-urlencodedUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.5481.178 Safari/537.36Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7Sec-Fetch-Site: same-originSec-Fetch-Mode: navigateSec-Fetch-User: ?1Sec-Fetch-Dest: documentReferer: http://127.0.0.1/sqli-labs/Less-11/Accept-Encoding: gzip, deflateAccept-Language: zh-CN,zh;q=0.9Connection: close

接下来我们仔细分析一下，HTTP 常见的请求头的属性字段所代表的含义：

Accept — 告诉 WEB 服务器自己可以接收什么样的数据类型。
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
表示客户端可以接收 HTML、XHTML+XML 等类型的数据，同时给出了不同媒体类型的优先级（通过 q 参数指定）。

Accept-Charset — 浏览器申明自己接收的字符集。
 Accept-Charset: utf-8, iso-8859-1;q=0.5
表示客户端优先接收 UTF-8 编码的字符集，同时也支持 ISO-8859-1 编码，但优先级较低。

Accept-Encoding — 浏览器申明自己接收的编码方法，通常指压缩方法。
 Accept-Encoding: gzip, deflate
表示客户端支持 gzip 和 deflate 两种压缩方式。

Accept-Language — 浏览器申明自己接收的语言。
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
表示客户端首选中文简体（zh-CN），同时也支持中文（zh）、美式英文（en-US）和英文（en），但优先级逐渐降低。

Authorization — 当客户端访问受密码保护的资源时，用于向服务器提供身份验证信息。
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
这里使用了 Base64 编码的用户名和密码（例如：“Aladdin:open sesame”）。

Cache-Control — 用于指示缓存系统（服务器上的或浏览器上的）应该如何处理缓存。
Cache-Control: max-age=0
max-age 用于定义资源在本地缓存中可以被视为新鲜（即，不需要向服务器验证）的最长时间，（以秒为单位）。所以上面的内容意味着，该资源被请求过一次之后，无论其在本地缓存中存储了多久，再次请求该资源时，浏览器都会认为缓存中的版本已经过期，必须向服务器发送请求来验证是否有更新的版本。这通常用于确保用户始终获取到最新的内容，比如在一些动态变化的页面上。

Connection — 指示客户端是否可以处理持久 HTTP 连接。
Connection: keep-alive
表示客户端希望保持连接，以便在同一个连接上发送多个请求。

Content-Length — 表示请求体的长度（以字节为单位）。
Content-Length: 348
表示请求体包含 348 个字节的数据。

Content-Type — 表示请求体的媒体类型（MIME 类型）。
Content-Type: application/x-www-form-urlencoded
表示请求体中的数据是以表单数据的形式提交的。

Cookie — 浏览器向服务器发送请求时，会携带之前服务器发送给浏览器的 Cookie 信息。
Cookie: user=admin
表示客户端向服务器发送了一个名为 user 的 cookie，其值为 admin。

Host — 指定请求的服务器域名和端口号（如果端口号不是默认端口）。
Host: www.blue17.vip:8000
表示将请求发送到 www.blue17.vip 的服务器的 8000 端口上。

Referer — 表示当前请求是从哪个页面链接过来的，即当前请求的源页面地址。
Referer: http://www.blue17.vip/page.htm
表示用户是从 http://www.blue17.vip/page.htm 页面链接到当前请求的。

User-Agent — 浏览器表明自己的身份（是哪种浏览器），包括操作系统、浏览器类型、版本等信息。
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3
表示客户端使用的是 Windows 10 操作系统上的 Chrome 浏览器。

3. 请求体（Request Body）（可选）

请求体（Request Body）是 HTTP 请求中的一个可选部分，它位于请求头（Headers）之后，用于向服务器发送数据。请求体的内容、格式和是否必须发送，取决于 HTTP 请求的方法和服务器对特定资源的期望。以下是一些常见情况下请求体内容的示例：

3.1 POST 请求（发送表单数据）

当你使用 POST 方法提交表单数据时，请求体通常包含表单字段及其值。此时，请求头中的 Content-Type 通常为：application/x-www-form-urlencoded 或 multipart/form-data 格式。

换句话说，若 Content-Type 值为 application/x-www-form-urlencoded 时，表示该请求体中的数据来源是表单，其请求体中的数据格式可能如下所示：

key1=value1&key2=value2&key3=value3

而当 Content-Type 值为 multipart/form-data 格式时，表示数据来源通常为 “文件上传”，或者说，上传的内容为一个文件。

3.2 POST 请求（发送 JSON 数据）

当与 RESTful API 交互时，经常需要将数据作为 JSON 格式发送。此时，请求头中的 Content-Type 字段一般为 application/json。

0x0402：HTTP 响应报文格式 - Response

HTTP 的响应报文也主要由三部分构成：响应行 + 响应头 + 响应体，如下图所示：

接下来我们利用上图详解每部分的内容，以及格式：

1. 响应行（Response Line）

HTTP 响应行（也称为状态行）是 HTTP 响应消息的第一行，它包含了协议版本、状态码以及状态消息（也称为原因短语）。比如上图中的响应行内容如下：

协议/版本 状态码 状态消息
HTTP/1.1 200  OK

1.1 HTTP 响应状态码及其状态消息

HTTP（HyperText Transfer Protocol）响应状态码用于指示 HTTP 请求是否成功，以及失败的原因。这些状态码被组织成五个类别，分别是：

信息性响应（100-199） - 主要用于表示一个中间状态，表示请求已被接收，正在处理中。
- 100 Continue：继续。客户端应继续其请求。
- 101 Switching Protocols：切换协议。服务器根据客户端的请求切换协议版本。
成功响应（200-299） - 表示请求已成功被服务器接收、理解、并接受。
- 200 OK：请求成功。服务器已成功处理了请求。
- 201 Created：已创建。请求成功并且服务器创建了新的资源。
- 202 Accepted：已接受。服务器已接受请求，但尚未处理。
- 203 Non-Authoritative Information：非授权信息。服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。
- 204 No Content：无内容。服务器成功处理了请求，但没有返回任何内容。
- 205 Reset Content：重置内容。服务器成功处理了请求，但没有返回任何内容。与204响应不同，此响应要求请求方重置文档视图。
- 206 Partial Content：部分内容。服务器成功处理了部分GET请求。
重定向响应（300-399） - 表示需要客户端采取进一步的操作才能完成请求。
- 300 Multiple Choices：多种选择。被请求的资源有一系列可供选择的表征形式。
- 301 Moved Permanently：永久移动。请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URL之一。
- 302 Found：临时移动。请求的资源现在临时从不同的URI响应请求。
- 303 See Other：查看其他位置。对应当前请求的响应可以在另一个 URL 上被找到，而且客户端应当采用 GET 的方式访问那个资源。
- 304 Not Modified：未修改。如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。
- 307 Temporary Redirect：临时重定向。请求的资源现在临时从不同的 URL 响应请求。
客户端错误响应（400-499） - 表示请求包含语法错误或无法完成请求。
- 400 Bad Request：错误请求。由于明显的客户端错误（例如，格式错误的请求语法，太大的请求，无效的请求域等），服务器无法理解该请求。
- 401 Unauthorized：未授权。请求要求身份验证。
- 403 Forbidden：禁止。服务器理解请求客户端的请求，但是拒绝执行此请求。
- 404 Not Found：未找到。服务器无法根据客户端的请求找到资源（网页）。
- 405 Method Not Allowed：不允许的方法。请求行中指定的方法不被允许。
- 408 Request Timeout：请求超时。客户端没有在服务器预期请求的时间内完成请求。
服务器错误响应（500-599） - 表示服务器在处理请求的过程中发生了错误。
- 500 Internal Server Error：服务器内部错误。服务器遇到了一个未曾预料到的情况，导致了它无法完成对请求的处理。
- 501 Not Implemented：未实现。服务器不支持当前请求所需要的某个功能。
- 502 Bad Gateway：错误网关。作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
- 503 Service Unavailable：服务不可用。由于临时的服务器维护或者过载，服务器当前无法处理请求。
- 504 Gateway Timeout：网关超时。作为网关或者代理的服务器没有及时从上游服务器收到请求。这些状态码和消息是HTTP协议中定义的标准部分，旨在帮助客户端和服务器之间进行更有效的通信。

2. 响应头（Response Header）

HTTP 响应头，从 HTTP 响应报文的第二行开始，到第一个空行结束（响应头和响应内容之间存在一个空行）。响应头中每一行的内容格式如下：

key: value

比如，在上面的例子中，响应头中的内容如下：

Date: Sun, 01 Sep 2024 09:38:51 GMT
Server: Apache/2.4.39 (Win64) OpenSSL/1.1.1b mod_fcgid/2.3.9a mod_log_rotate/1.02
X-Powered-By: PHP/5.3.29
Connection: close
Content-Type: text/html
Content-Length: 1435

HTTP 响应头部分包含了服务器返回给客户端的一系列元数据信息，用于描述服务器响应的内容、类型、大小、缓存控制等。以下是一些常见的响应头字段及其含义（省略了部分和 HTTP 请求头中相同作用的字段）：

Cache-Control — 指示客户端如何缓存响应的内容。
Cache-Control: no-cache
no-cache 表示不要使用缓存的资源，每次请求都需要从原始服务器获取。
Cache-Control: max-age=3600
max-age=3600 表示资源在缓存中的有效时间为 3600 秒，即 1 个小时内，客户端可以直接从缓存中获取资源而无需请求服务器。

Last-Modified — 指示响应内容的最后修改时间。
Last-Modified: Fri, 23 Sep 2023 09:12:34 GMT
这个响应头表示资源的最后修改时间是格林尼治标准时间（GMT）的 2023 年 9 月 23 日 9 时 12 分 34 秒。客户端可以根据这个时间来判断资源是否是最新的。

ETag — 指示响应内容的实体标签，用于验证缓存的内容是否过期。
ETag: "637060cd8c284d8af7ad3082f209582d"
这个响应头是一个特定的标识符，用于验证资源的完整性。当资源发生变化时，ETag 的值也会改变。客户端可以通过比较 ETag 的值来判断资源是否发生了变化。

Set-Cookie — 设置响应的 Cookie 值，用于在客户端存储状态信息。
Set-Cookie: UserID=JohnDoe; Path=/; HttpOnly
这个响应头用于设置 Cookie，以便在客户端存储用户的状态信息。在这个例子中，设置了一个名为 UserID 的 Cookie，其值为 JohnDoe，并且这个 Cookie 对所有路径都有效（Path=/），同时设置了 HttpOnly 标志，表示这个 Cookie 只能通过 HTTP 协议访问，不能通过客户端的脚本（如JavaScript）访问。

Server — 告诉客户端关于服务器的类型和版本信息。
Server: Apache/2.4.46
这个响应头告诉客户端关于服务器的类型和版本信息。在这个例子中，服务器是 Apache，版本号为 2.4.46。这有助于客户端了解服务器的配置和性能。

Date — 表示消息创建的日期和时间。
Date: Sun, 01 Sep 2024 20:50:48 GMT
这个响应头表示消息创建的日期和时间（即服务器发送响应的时间）。这有助于客户端了解响应的生成时间，并据此进行时间同步或日志记录等操作。

Transfer-Encoding — 指定了消息体的传输编码方式。
Transfer-Encoding: chunked
这个响应头指定了消息体的传输编码方式。chunked 编码方式表示响应体被分割成多个块（chunk），每个块都有自己的大小信息，并在最后发送一个 0 长度的块来表示传输结束。这种方式允许服务器在不知道整个响应体大小的情况下开始发送数据。

3. 响应体（Response Body）

HTTP响应体（body）部分的内容是实际发送给客户端的数据，它的内容、格式和编码取决于Content-Type响应头所指定的 MIME 类型。由于 HTTP 响应体可以包含多种类型的数据，以下是一些常见类型的响应体内容示例。

3.1 HTML 内容

当Content-Type为text/html时，响应体可能包含 HTML 文档。

<!DOCTYPE html>  
<html lang="en">  
<head>  <meta charset="UTF-8">  <title>示例页面</title>  
</head>  
<body>  <h1>欢迎来到我的网站！</h1>  <p>这是一个示例页面，用于展示HTML内容的HTTP响应体。</p>  
</body>  
</html>

3.2 JSON 内容

当Content-Type为application/json时，响应体可能包含JSON格式的数据。

{  "status": "success",  "data": {  "message": "Hello, World!",  "timestamp": "2023-09-23T12:34:56Z"  }  
}

3.3 纯文本内容

当Content-Type为text/plain时，响应体可能包含纯文本。

这是一个纯文本响应体。  
它直接显示给用户，没有HTML格式。

3.4 图片内容

对于图片，如 JPEG 或 PNG，Content-Type 将相应地设置为 image/jpeg 或 image/png ，但响应体的内容在这里无法直接以文本形式展示，因为它是二进制数据。不过，你可以想象响应体包含的是图片的字节流。

3.5 XML 内容

当Content-Type为application/xml时，响应体可能包含 XML 格式的数据。

<?xml version="1.0" encoding="UTF-8"?>  
<response>  <status>success</status>  <info>  <message>操作成功</message>  <code>1000</code>  </info>  
</response>

0x05：HTTP 协议工作流程

HTTP 协议定义了 WEB 客户端如何从 WEB 服务器请求 WEB 页面，以及服务器如何把 WEB 页面传送给客户端。其工作流程可以概括为以下几个步骤：

客户端连接到 WEB 服务器（建立 TCP 连接）： 在发送 HTTP 请求之前，客户端需要与服务器建立 TCP 连接。这个过程通常包括 TCP 的三次握手，以确保双方都能可靠地发送和接收数据。
发送 HTTP 请求： 客户端通过 TCP 连接向服务器发送 HTTP 请求，告诉服务器我要访问你的哪个资源，以及对该资源的操作（通过请求头和请求体中的内容进行）。比如，如果是 GET 请求就是说，我要获取你这个路径下的资源。
服务器处理请求并返回 HTTP 响应： 服务器接收到了 HTTP 请求后，根据请求中的方法和路径，对指定资源进行处理，并在处理成功后返回 HTTP 响应包。如果请求失败或者资源不存在，服务器也将返回对应的错误响应。
关闭 TCP 连接： 若 connection 模式为 close，则服务器主动关闭 TCP 连接，客户端被动关闭连接，释放 TCP 连接；若 connection 模式为 keep-alive，则该连接会保持一段时间，在这段时间内，依旧可以继续接收请求。
客户端解析响应内容： 客户端首先解析状态行，查看请求是否被成功响应。然后解析每一个响应头，根据响应头中的内容，来处理响应体中的数据，并进行展示（也可能不展示）。

0x06：参考资料

HTTP请求头大全 - 常用参考表对照表 - 脚本之家在线工具HTTP请求头在编写采集器、模拟登录、远程获取内容等是必须要考虑的内容,本工具的作用就是把请求头罗列并说明,方便开发人员参考。https://tools.jb51.net/table/http_headerHTTP协议是什么 - 知百科HTTP协议（超文本传输协议）是一种网络通信协议，它允许将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。默认端口：80。https://www.knowbaike.com/it/49294.htmlHttp协议详解(深入理解)-CSDN博客文章浏览阅读10w+次，点赞195次，收藏1.3k次。引入超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。Ted...https://blog.csdn.net/weixin_38087538/article/details/82838762【网络协议】精讲HTTP协议各版本特点！图解超赞超详细！！！零基础入门到精通，收藏这一篇就够了-CSDN博客文章浏览阅读859次，点赞14次，收藏16次。HTTP 0.9（1991年）只支持get方法的单行协议HTTP 1.0（1996年）更加完整、接近现代化的协议：请求方法、请求头、状态码…HTTP 1.1（1997年）标准化协议：新增请求方法、持久连接、管道、Host头…HTTP 2.0（2015年）更优异的表现：二进制、多路复用、头部压缩、服务器推送…HTTP 3.0（2018年）构建高效网络：QUIC协议。_图解超赞超详细https://blog.csdn.net/leah126/article/details/140116928

https://www.cnblogs.com/an-wen/p/11180076.htmlhttps://www.cnblogs.com/an-wen/p/11180076.html