HTTP协议详细说明

Hollis 收录于 Python_web_crawler 和 Python网络爬虫

2025-09-26 2025-10-09 约 8300 字预计阅读 17 分钟 - 次阅读 - 条评论

用一个最贴切的比喻来说：HTTP 是浏览器和服务器之间进行“对话”所必须遵循的“语法”和“规则”。

一、核心定义解析

全称： 超文本传输协议
- 超文本：不仅仅指文字，而是包含文字、图片、音频、视频、超链接等丰富内容的文档。最典型的超文本就是我们在浏览器中看到的网页。
- 传输：它规定了数据如何从一方（服务器）打包、发送，到另一方（客户端）接收、解包。
- 协议：这是一套双方事先约定好的规则和标准。就像两个国家元首会谈需要翻译和固定的礼仪一样，浏览器和服务器必须都遵守 HTTP 协议，才能成功地进行通信。
技术定义： HTTP 是一个在计算机世界里，用于在客户端和服务器之间传输超媒体文档的应用层协议。

二、一个生动的场景：访问网站

让我们通过你在浏览器地址栏输入 https://www.example.com 并按下回车后发生的事情，来彻底理解 HTTP 的角色。

你（客户端）发起请求：你的浏览器（客户端）想要获取 www.example.com 这个网站的主页。
建立连接：浏览器会先通过网络与 www.example.com 对应的服务器建立一条可靠的连接（通常是 TCP 连接）。
书写“请求信”（HTTP 请求）：浏览器按照 HTTP 协议的格式，写一封标准的“请求信”。这封信至少包含：
- “我想要什么？”（请求行）： GET /index.html HTTP/1.1
  - GET：方法，表示“获取”资源。
  - /index.html：路径，表示想要网站根目录下的 index.html 文件。
  - HTTP/1.1： 协议版本，表示使用 HTTP 1.1 版本的规则通信。
- “关于我的附加信息”（请求头）：
  - Host: www.example.com：我要访问的主机名（必需）。
  - User-Agent: Mozilla/5.0...：我的浏览器身份和版本。
  - Accept: text/html：我希望能接收 HTML 类型的文档。
发送请求：浏览器将这封“请求信”通过网络连接发送给服务器。
服务器处理并回复（HTTP 响应）：服务器收到请求后，找到对应的 index.html 文件，然后按照 HTTP 协议的格式，写一封“回信”。
- “处理结果如何？”（状态行）： HTTP/1.1 200 OK
  - 200： 状态码，一个非常重要的数字，表示“请求成功，这是你要的东西”。
  - OK：对状态码的简短文字描述。
- “关于回复的附加信息”（响应头）：
  - Content-Type: text/html：我返回的内容是 HTML 文本。
  - Content-Length: 1024：内容长度是 1024 字节。
- “真正的货物”（响应体）：
  - <html><body><h1>欢迎访问示例网站！</h1></body></html>：这就是 index.html 文件的实际内容，即网页的 HTML 代码。
浏览器渲染页面：你的浏览器收到“回信”后，首先看状态码是 200，知道成功了，然后读取 Content-Type 知道这是 HTML 文档，于是开始解析 HTML 代码，并将其渲染成你看到的可视化网页。

整个过程中，HTTP 协议规定了“请求信”和“回信”必须长什么样，应该包含哪些部分，以及不同状态码分别代表什么意思。 没有这套统一的规则，浏览器和服务器就无法理解对方在说什么。

三、HTTP 的关键特性

1. 请求-响应模型

这是 HTTP 最根本的交互模式。

详细描述：
- 通信总是由客户端（通常是 Web 浏览器，但也可能是移动端 App 或其他程序）主动发起一个 HTTP 请求。
- 服务器（存储网站资源的主机）则一直等待接收请求。当服务器收到请求后，会进行处理，然后返回一个 HTTP 响应 给客户端。
- 这个模型是严格的 “一问一答” 模式。客户端不问，服务器则不答。服务器永远不会主动向客户端推送任何消息（在标准 HTTP 中）。
技术类比：
- 就像顾客和服务员的对话：
  1. 顾客（客户端）： “你好，我想要一份菜单。”（请求）
  2. 服务员（服务器）： “好的，这是菜单。”（响应）
  3. 顾客： “我要点一个汉堡和一杯可乐。”（另一个请求）
  4. 服务员： “已下单，这是您的订单号。”（另一个响应）
重要性：
- 这种简单的模型使得 HTTP 非常易于理解和实现，为 Web 的大规模扩展奠定了基础。

2. 无状态

这是 HTTP 一个极其重要且常被误解的特性。

详细描述：
- HTTP 协议本身不要求服务器在多个请求之间保留任何状态（或记忆）。每一个 HTTP 请求都是完全独立的，服务器不会记得之前的任何一个请求是谁发出的、做了什么。
- 从服务器的视角看，每个请求都是一个“陌生人”发来的新请求。
举例说明：
1. 你第一次访问网站，浏览器请求 GET /page1.html。
2. 你点击链接，浏览器请求 GET /page2.html。
3. 对于 HTTP 协议来说，这两个请求毫无关联。处理第二个请求的服务器进程可能和处理第一个的完全不同，它也不知道你刚刚看过 page1.html。
无状态的优点：
- 简化服务器设计：服务器不需要为成千上万的客户端分配内存来记录它们的会话状态，这使得服务器更容易开发和维护。
- 易于扩展：由于请求是独立的，它们可以被分发到任何一台服务器进行处理（这是实现负载均衡的理想基础）。如果某台服务器宕机，其他服务器可以无缝接管后续请求，因为它们不需要恢复宕机服务器的状态。
无状态的挑战与解决方案：
- 问题：现代 Web 应用（如购物网站、社交媒体）迫切需要状态（如用户登录状态、购物车内容）。
- 解决方案：为了在无状态协议上构建有状态的应用，人们引入了外部机制。最核心的是 Cookie：
  - 服务器在响应中通过 Set-Cookie 头部将一个“令牌”发送给浏览器。
  - 浏览器会保存这个 Cookie，并在后续向同一服务器发出的每一个请求的 Cookie 头部中带上它。
  - 服务器通过读取请求中的 Cookie 内容，就能识别出用户身份，从而“恢复”会话状态。虽然 HTTP 协议本身是无状态的，但通过 Cookie 在应用层“制造”出了状态。

3. 可扩展的

这是 HTTP 能够长久不衰、适应未来需求的关键。

详细描述：
- HTTP 的扩展性主要体现在其头部机制。HTTP 报文由 起始行、头部和可选的主体组成。
- 头部采用 Key: Value 的格式，允许协议引入新的功能和语义，而无需修改其核心结构。
举例说明：
- 缓存：引入了 Cache-Control, ETag, Last-Modified 等头部，实现了复杂的缓存策略。
- 内容协商：客户端可以通过 Accept, Accept-Language, Accept-Encoding 头部告诉服务器它希望接收什么类型、语言、压缩格式的内容。服务器则根据 Content-Type 等头部告知客户端返回的内容信息。
- 安全认证：引入了 Authorization 头部用于身份验证。
- 自定义功能：应用甚至可以定义自己的自定义头部（通常以 X- 开头，如 X-API-Key）。
重要性：
- 这种设计使得 HTTP 能够轻松地支持新的应用场景，从简单的静态网页到复杂的 API 交互（RESTful API），而无需创建全新的协议。

四、HTTP 请求方法

好的，我们聚焦于 GET 和 POST 方法的参数传递方式，并对其他方法进行简要总结。

1. GET 方法

GET 方法的唯一目标就是从服务器获取资源。它的所有参数都必须包含在 URL 中，因为请求本身没有正文（Body）。这决定了它的特点和限制。

参数类型与传递方式

GET 方法的参数主要通过以下两种方式附加在 URL 后面：

查询字符串（Query String）
- 格式：在 URL 末尾加上 ?，然后以 key=value 的形式拼接参数，多个参数之间用 & 分隔。
- 示例： https://api.example.com/search?q=keyword&category=books&limit=10
  - q=keyword
  - category=books
  - limit=10
- 特点：
  - 明文传输：参数在地址栏中完全可见，不适合传递敏感信息（如密码）。
  - 长度限制：虽然 HTTP 协议本身没有对 URL 长度设限，但浏览器和服务器有实际限制（通常几千个字符），因此不能传输大量数据。
  - 可被缓存、收藏：带有查询字符串的 URL 可以被浏览器缓存，也可以保存为书签。
路径参数（Path Parameters）
- 格式：参数作为 URL 路径的一部分，通常用于 RESTful API 中标识特定资源。
- 示例： https://api.example.com/users/123/posts/456
  - 这里的 123 是用户 ID，456 是文章 ID，它们本身就是参数。
- 特点：
  - 用于标识唯一的资源，语义清晰。
  - 同样是明文可见。

GET 请求总结：所有参数都在 URL 中，简单、高效，适用于不修改服务器数据的查询和请求，但缺乏安全性和大数据传输能力。

2. POST 方法

POST 方法用于向服务器提交数据，通常会改变服务器状态（如创建新资源）。它的参数主要放在请求体（Body） 中，这使得它比 GET 更灵活、更安全。

参数类型与传递方式

POST 方法的参数类型由请求头 Content-Type 决定，常见的类型有：

application/x-www-form-urlencoded
- 格式：这是 HTML 表单默认的提交方式。参数在请求体中的编码格式与 GET 的查询字符串完全一样：key1=value1&key2=value2。
- 示例：
  1 2 3 4
  
  POST /submit-form HTTP/1.1 Content-Type: application/x-www-form-urlencoded username=john_doe&password=secret123
- 特点：简单通用，几乎所有服务器都支持，但不适合传输复杂数据（如文件）。

multipart/form-data

格式：当表单需要上传文件时使用。它会将请求体分割成多个部分（Part），每个部分对应一个字段（普通文本或文件二进制流），并用一个随机生成的“边界（boundary）”字符串分隔。

示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryABC123

------WebKitFormBoundaryABC123
Content-Disposition: form-data; name="username"

john_doe
------WebKitFormBoundaryABC123
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg

...（这里是 photo.jpg 的二进制数据）...
------WebKitFormBoundaryABC123--

特点：专门用于高效传输二进制文件和数据。

application/json
- 格式：这是现代 Web API（尤其是 RESTful API）最常用的格式。请求体是一个完整的 JSON 字符串。
- 示例：
  1 2 3 4 5 6 7 8
  
  POST /api/users HTTP/1.1 Content-Type: application/json { "name": "John Doe", "email": "john@example.com", "age": 30 }
- 特点：结构清晰，可读性强，能轻松表示复杂的嵌套数据结构，是前后端分离架构的首选。
其他类型
- text/plain, application/xml 等，用于特定场景。

POST 请求总结：参数在请求体中，支持大量数据和复杂类型（如文件），更安全（不在 URL 中显示），适用于创建、更新等操作。

3. 其他 HTTP 方法

PUT：向指定 URL 位置完整地更新或创建一个资源（客户端提供全部内容）。
DELETE：删除指定 URL 的资源。
PATCH：部分更新一个资源，只提交需要修改的字段（与 PUT 的“完整更新”相对）。
HEAD：只请求资源的响应头，而不获取正文（Body），用于检查资源是否存在、是否被修改等。
OPTIONS：用于查询目标资源所支持的通信选项（即支持哪些请求方法），常用于 CORS（跨域资源共享）预检请求。

五、HTTP 消息结构

HTTP 消息是客户端和服务器之间通信的核心载体，其结构有严格的规定。

HTTP 消息分为两类：

HTTP 请求消息：由客户端发送给服务器。
HTTP 响应消息：由服务器发送给客户端。

这两种消息的结构相似，都遵循以下基本格式：

1
2
3
4
5
6


起始行
(头部字段名: 值)
(头部字段名: 值)
...
(空行)
[消息体]

第一部分：HTTP 请求消息结构

一、四个组成部分

一个标准的 HTTP 请求消息由四个部分组成：请求行、请求头、空行和 请求体。

1. 请求行

这是请求消息的第一行，包含三个基本元素，由空格分隔。

格式： 方法请求目标协议版本
示例： GET /index.html HTTP/1.1
详细说明：
- 方法：表示要对资源执行的操作。常见方法有：
  - GET：请求获取指定的资源。
  - POST：向指定资源提交数据，数据包含在请求体中。
  - PUT：替换指定资源的所有内容。
  - DELETE：请求删除指定资源。
  - HEAD：类似 GET，但只请求资源的头部信息，不返回实体主体。
  - PATCH：对资源进行部分修改。
- 请求目标：通常是要访问资源的路径（如 /index.html），也可以是完整的 URL 或其他形式。
- 协议版本：声明使用的 HTTP 协议版本，如 HTTP/1.1 或 HTTP/2。这决定了客户端和服务器应遵循的规则。

2. 请求头

请求行之后，空行之前的所有行都是请求头。它们为服务器提供关于请求的额外信息。

格式：每个头部字段占一行，格式为 字段名: 值。
分类与常见示例：
- 通用头：适用于请求和响应消息。
  - User-Agent：包含发起请求的客户端应用程序信息（浏览器类型、版本等）。
- 请求头：提供关于请求本身的更多信息。
  - Host： 必需字段。指定请求服务器的域名和端口号。
  - Accept：告知服务器客户端能够处理的内容类型（如 text/html, application/json）。
  - Accept-Language：客户端接受的语言（如 en-US, zh-CN）。
  - Accept-Encoding：客户端接受的压缩格式（如 gzip, deflate）。
  - Cookie：将之前服务器设置的 Cookie 送回给服务器，用于维持状态。
  - Authorization：包含用于访问受保护资源的凭证（如 Bearer <token>）。
  - Content-Type： （用于有Body的请求，如POST/PUT） 声明请求体的媒体类型（如 application/json， application/x-www-form-urlencoded）。
  - Content-Length： （用于有Body的请求） 声明请求体的字节大小。

3. 空行

这是一个至关重要的分隔符。

格式：一个纯粹的换行（CRLF，即 \r\n）。
作用：标志着所有请求头已经结束。服务器解析请求时，遇到空行就知道接下来该读取消息体了。

4. 请求体

也称为消息体或负载，是可选的。

何时存在：通常在发送数据给服务器时使用，例如 POST、PUT、PATCH 方法。
内容：包含要提交的数据，其格式由 Content-Type 头部指定。
- 表单数据： username=john&password=123
- JSON 数据： {"username": "john", "password": "123"}
- 文件上传：二进制数据。

二、示例

好的，这里给出三个不同且具有代表性的 HTTP 请求示例，涵盖了 GET、POST 和带有认证的 GET 请求。

示例 1：简单的 GET 请求（获取网页）

这是一个最基础的请求，用于获取指定 URL 的 HTML 页面。它没有请求体。

1
2
3
4
5
6
7


GET /articles/http-basics HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

组成部分分析：

请求行: GET /articles/http-basics HTTP/1.1
- 方法：GET
- 请求目标：/articles/http-basics
- 协议版本：HTTP/1.1
请求头:
- Host: www.example.com：指定要访问的服务器。
- User-Agent: 描述客户端软件（浏览器）。
- Accept 系列头部：告知服务器客户端偏好哪种类型的文档、语言和编码。
- Connection: keep-alive：希望保持 TCP 连接以进行后续请求。
空行: 在 Connection: keep-alive 之后有一个空行。
请求体: 对于 GET 请求，通常没有请求体。

示例 2：提交表单的 POST 请求（登录）

这是一个向服务器提交数据的典型例子，比如用户登录。请求体包含了表单数据。

1
2
3
4
5
6
7


POST /login HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/118.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 29

username=alice&password=secret123

组成部分分析：

请求行: POST /login HTTP/1.1
- 方法：POST
- 请求目标：/login
- 协议版本：HTTP/1.1
请求头:
- Host: api.example.com
- User-Agent: 描述客户端软件。
- Content-Type: application/x-www-form-urlencoded： 关键头部，指明请求体的格式是 URL 编码的表单数据。
- Content-Length: 29： 关键头部，精确计算了请求体 username=alice&password=secret123 的字节长度。
空行: 在 Content-Length 头部之后。
请求体: username=alice&password=secret123
- 这是实际提交给服务器的数据。

示例 3：带有 JSON 数据和认证的 PUT 请求（更新用户信息）

这个示例更复杂，包含了现代 API 交互中的常见元素：JSON 数据格式和 Bearer Token 认证。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


PUT /v1/users/12345 HTTP/1.1
Host: api.myservice.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json
Content-Length: 62

{
  "name": "Alice Smith",
  "email": "alice.smith@example.com"
}

组成部分分析：

请求行: PUT /v1/users/12345 HTTP/1.1
- 方法：PUT（通常用于更新资源）
- 请求目标：/v1/users/12345（指定要更新 ID 为 12345 的用户）
- 协议版本：HTTP/1.1
请求头:
- Host: api.myservice.com
- Authorization: Bearer ...： 关键头部，提供 JWT Token 以证明请求者有权限执行此操作。
- Content-Type: application/json： 关键头部，指明请求体是 JSON 格式的数据。
- Content-Length: 62：计算了后面 JSON 字符串的精确字节数。
空行: 在 Content-Length 头部之后。

请求体:

1
2
3
4


{
  "name": "Alice Smith",
  "email": "alice.smith@example.com"
}

这是要更新的新数据，以 JSON 格式组织。

第二部分：HTTP 响应消息结构

一个标准的 HTTP 响应消息也由四个部分组成：状态行、响应头、空行和 响应体。

1. 状态行

这是响应消息的第一行，也包含三个部分。

格式： 协议版本状态码状态文本
示例： HTTP/1.1 200 OK
详细说明：
- 协议版本：同请求行。
- 状态码：一个三位数字，表示请求的处理结果。这是服务器对客户端最直接的“回答”。
  - 1xx：信息性状态码（请求已被接收，继续处理）。
  - 2xx：成功（如 200 OK， 201 Created）。
  - 3xx：重定向（如 301 Moved Permanently， 304 Not Modified）。
  - 4xx：客户端错误（如 404 Not Found， 403 Forbidden）。
  - 5xx：服务器错误（如 500 Internal Server Error， 502 Bad Gateway）。
- 状态文本：对状态码的简短文字描述，便于人类理解。

2. 响应头

与请求头类似，为响应提供元信息。

常见示例：
- 通用头：
  - Date：响应生成的日期和时间。
- 响应头：
  - Server：服务器软件信息（如 Apache/2.4.1）。
  - Content-Type： 极其重要。声明响应体的媒体类型（如 text/html; charset=UTF-8， application/json， image/jpeg）。
  - Content-Length：响应体的字节大小。
  - Content-Encoding：响应体使用的压缩编码（如 gzip），浏览器需要据此解压。
  - Cache-Control：指示客户端和中间代理如何缓存该响应（如 max-age=3600）。
  - Set-Cookie：要求客户端存储一个 Cookie，用于后续请求识别身份。
  - Location： （用于重定向，如 302） 指定重定向的目标 URL。

3. 空行

作用同请求消息中的空行，用于分隔头部和消息体。

4. 响应体

这是响应消息的核心内容，也是可选的。

何时存在：当请求成功（如状态码为 200）时，响应体通常包含客户端请求的资源。
内容：可以是任何格式的数据，具体由 Content-Type 决定。
- HTML 文档： <html>...<body>网页内容</body>...</html>
- JSON 数据： {"userId": 1, "name": "John"}
- 图片、视频、CSS、JavaScript 文件：二进制数据。

完整示例

HTTP 请求示例（登录）

1
2
3
4
5
6
7
8
9


POST /login HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Accept: text/html,application/xhtml+xml
Cookie: session-id=abc123

username=john&password=secret

解析：客户端使用 POST 方法向 www.example.com 的 /login 接口发送了一段表单数据（用户名和密码），并附上了之前存储的 Cookie。

HTTP 响应示例（登录成功）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


HTTP/1.1 200 OK
Date: Mon, 27 May 2024 10:00:00 GMT
Server: Apache/2.4.1 (Unix)
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Set-Cookie: session-id=new-abc-123; Path=/
Cache-Control: no-cache

<html>
<head><title>Welcome</title></head>
<body>
    <h1>Login Successful!</h1>
    <!-- ... 更多HTML内容 ... -->
</body>
</html>

解析：服务器返回状态码 200 表示成功，设置了一个新的 Cookie，并返回了一个 HTML 页面作为响应体。

总结

HTTP 消息的标准化结构是其成功的关键。无论是简单的网页浏览还是复杂的 API 调用，都遵循着这套清晰的规则：

起始行/状态行 定义了操作的基本意图和结果。
头部提供了丰富的元数据，用于控制缓存、认证、内容格式等。
空行作为一个明确的分隔符。
消息体 承载着通信的实质内容。

理解这套结构是进行 Web 开发、调试网络问题和使用 API 的基础。

六、HTTP 状态码

用于表示请求的处理结果，分为五类：

1xx（信息性状态码）：请求已被接收，继续处理。
- 100 Continue：客户端应继续发送请求的剩余部分。
2xx（成功状态码）：请求已成功被服务器接收、理解、并接受。
- 200 OK：请求成功。
- 201 Created：请求成功并且服务器创建了新的资源（常用于 POST/PUT）。
- 204 No Content：服务器成功处理了请求，但不需要返回任何实体内容。
3xx（重定向状态码）：需要客户端采取进一步的操作才能完成请求。
- 301 Moved Permanently：请求的资源已被永久移动到新位置。
- 302 Found：请求的资源临时从不同的 URI 响应请求。
- 304 Not Modified：资源未修改，客户端可以使用缓存的版本。
4xx（客户端错误状态码）：请求含有语法错误或者无法被满足。
- 400 Bad Request：请求报文存在语法错误。
- 401 Unauthorized：请求需要用户认证。
- 403 Forbidden：服务器理解请求，但拒绝执行（权限不足）。
- 404 Not Found：服务器找不到请求的资源。
5xx（服务器错误状态码）：服务器在处理请求的过程中发生了错误。
- 500 Internal Server Error：服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。
- 502 Bad Gateway：作为网关或代理的服务器，从上游服务器收到无效响应。
- 503 Service Unavailable：服务器当前无法处理请求（由于超载或停机维护）。

七、 HTTP 与 HTTPS 的关系

HTTP：传输内容是明文的，就像寄送一张明信片，途中的任何人都可以看到上面的内容。这非常不安全，尤其不适合传输密码、银行卡号等敏感信息。
HTTPS：可以理解为 HTTP + SSL/TLS 加密层。
- 它是在 HTTP 之下加入了一个安全加密层（SSL/TLS）。所有 HTTP 的请求和响应在发送前都会被加密，变成乱码，到达对方后再解密。
- 这就好比把“明信片”换成了“上锁的保密信”，只有拥有正确钥匙的收件人才能阅读。因此，HTTPS 能够提供：
  1. 数据加密：防止通信被窃听。
  2. 身份认证：确保你访问的是真正的网站，而不是钓鱼网站。
  3. 数据完整性：确保数据在传输过程中未被篡改。

八、Cookie机制详解

Cookie是一种网络技术，用于在客户端（通常是浏览器）存储少量的文本信息。它是Web应用程序用于记录用户状态和跟踪用户行为的重要机制。

工作流程

服务器设置Cookie：通过响应头的Set-Cookie字段
客户端存储Cookie：浏览器按照规则保存Cookie
自动发送Cookie：后续向同一域名的请求自动携带Cookie
服务器识别状态：通过解析Cookie恢复会话状态

Cookie示例

服务器设置Cookie：

1
2
3
4


HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session_id=abc123; Expires=Wed, 21 Oct 2025 07:28:00 GMT; HttpOnly; Secure
Set-Cookie: user_pref=dark_mode; Max-Age=3600

客户端发送Cookie：

1
2
3


GET /dashboard HTTP/1.1
Host: www.example.com
Cookie: session_id=abc123; user_pref=dark_mode

Cookie的应用场景

会话管理：用户登录状态、购物车内容
个性化设置：主题偏好、语言设置
用户追踪：行为分析、广告投放

总结

HTTP 是万维网的基石，它定义了一种简单而强大的通信模式。从最初简单的文本协议，发展到今天支持多路复用、头部压缩和强加密的 HTTP/2 和 HTTP/3，其核心目标始终是高效、可靠地传输超媒体信息。理解 HTTP 的工作原理对于 Web 开发、网络运维和网络安全都至关重要。

收录于合集・Python网络爬虫 5

Python基础语法学习 Requests库发送HTTP请求