HTTP 和 HTTPS 请求流程

日月星辰Ace2025-04-12 10:13

HTTP 请求

当客户端发起一个 HTTP 请求 并接收到服务端响应时，整个过程可以分为以下几个主要步骤和流程。以下是详细的解释：

1. DNS 解析

  • 目的 ：将客户端请求的域名（如 www.example.com）解析为对应的服务器 IP 地址。

  • 流程：

    1. 客户端向本地 DNS 服务器查询域名对应的 IP 地址。
    2. 如果本地 DNS 服务器没有缓存该域名的记录，则会向上级 DNS 服务器递归查询，直到找到对应的 IP 地址。
    3. 返回 IP 地址给客户端。

  • 结果 ：客户端获得目标服务器的 IP 地址（如 192.168.1.1）。

2. 建立 TCP 连接

  • 目的：通过 TCP 协议建立客户端与服务器之间的可靠连接。

  • 流程：

    1. 三次握手：

      • 第一次握手：客户端发送一个 SYN（同步）包给服务器，表示请求建立连接。
      • 第二次握手：服务器收到 SYN 包后，返回一个 SYN-ACK（同步确认）包，表示同意建立连接。
      • 第三次握手：客户端收到 SYN-ACK 包后，发送一个 ACK（确认）包，表示连接建立成功。

    2. 连接建立后，客户端和服务器之间可以开始数据传输。

  • 结果：客户端与服务器之间建立了可靠的 TCP 连接。

3. 发送 HTTP 请求

  • 目的：客户端向服务器发送 HTTP 请求，获取所需的资源或服务。

  • 流程：

    1. 构建请求：

      • 客户端根据用户操作构建 HTTP 请求报文，包括以下部分：

        • 请求行 ：包含请求方法（如 GET、POST）、请求的 URL 和 HTTP 协议版本。
        • 请求头 ：包含元信息（如 User-Agent、Accept、Host 等）。
        • 请求体 （可选）：在 POST 或 PUT 请求中，包含需要发送的数据。

    2. 发送请求：

      • 客户端通过 TCP 连接将 HTTP 请求报文发送到服务器。

示例 HTTP 请求报文：

vbnet 复制代码 
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

4. 服务器处理请求

  • 目的：服务器接收并处理客户端的 HTTP 请求。

  • 流程：

    1. 接收请求：

      • 服务器通过监听的端口（如 80 或 443）接收客户端发送的 HTTP 请求报文。

    2. 解析请求：

      • 服务器解析请求报文，提取请求方法、URL、请求头等信息。

    3. 处理请求：

      • 根据请求的 URL 和方法，服务器调用相应的处理逻辑（如读取文件、查询数据库、调用后端服务等）。

    4. 生成响应：

      • 服务器根据处理结果构建 HTTP 响应报文。

5. 服务器返回 HTTP 响应

  • 目的：服务器将处理结果返回给客户端。

  • 流程：

    1. 构建响应报文：

      • 状态行 ：包含 HTTP 协议版本、状态码（如 200 OK、404 Not Found）和状态描述。
      • 响应头 ：包含元信息（如 Content-Type、Content-Length、Set-Cookie 等）。
      • 响应体（可选）：包含实际的数据内容（如 HTML 页面、JSON 数据等）。

    2. 发送响应：

      • 服务器通过 TCP 连接将 HTTP 响应报文发送到客户端。

示例 HTTP 响应报文：

less 复制代码 
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 123

<html>
  <body>
    <h1>Hello, World!</h1>
  </body>
</html>

6. 客户端接收并处理响应

  • 目的：客户端接收服务器返回的 HTTP 响应，并根据响应内容进行处理。

  • 流程：

    1. 接收响应：

      • 客户端通过 TCP 连接接收服务器发送的 HTTP 响应报文。

    2. 解析响应：

      • 客户端解析响应报文，提取状态码、响应头和响应体。

    3. 处理响应：

      • 根据状态码判断请求是否成功：

        • 2xx ：请求成功（如 200 OK）。
        • 3xx ：重定向，客户端需要根据 Location 头发起新的请求。
        • 4xx ：客户端错误（如 404 Not Found）。
        • 5xx ：服务器错误（如 500 Internal Server Error）。

      • 如果响应体包含数据（如 HTML 页面、JSON 数据等），客户端会进一步处理或渲染。

7. 关闭 TCP 连接

  • 目的：释放资源，关闭客户端与服务器之间的连接。

  • 流程：

    1. 四次挥手：

      • 第一次挥手：客户端发送 FIN（结束）包，表示不再发送数据。
      • 第二次挥手：服务器收到 FIN 包后，返回 ACK 包，表示确认。
      • 第三次挥手：服务器发送 FIN 包，表示不再发送数据。
      • 第四次挥手：客户端收到 FIN 包后，返回 ACK 包，表示确认。

    2. 连接关闭。

总结：HTTP 请求的完整流程

  1. DNS 解析：将域名解析为 IP 地址。
  2. 建立 TCP 连接：通过三次握手建立可靠的连接。
  3. 发送 HTTP 请求：客户端构建并发送 HTTP 请求报文。
  4. 服务器处理请求：服务器接收并处理请求，生成响应。
  5. 返回 HTTP 响应：服务器将响应报文发送给客户端。
  6. 客户端处理响应：客户端解析并处理响应内容。
  7. 关闭 TCP 连接：通过四次挥手关闭连接。

HTTPS 请求

HTTPS 是基于 HTTP 和 TLS/SSL 的安全协议，它通过加密、认证和完整性校验来确保通信的安全性。以下是 HTTPS 从请求到接收到响应的完整流程，以及它如何保证安全和使用证书的机制。

HTTPS 的完整流程

HTTPS 的流程可以分为以下几个阶段：

1. DNS 解析

  • 目的 ：将客户端请求的域名（如 www.example.com）解析为服务器的 IP 地址。

  • 流程：

    • 客户端向本地 DNS 服务器查询域名对应的 IP 地址。
    • 如果本地 DNS 没有缓存记录，则递归查询上级 DNS 服务器，直到找到对应的 IP 地址。

  • 结果：客户端获得目标服务器的 IP 地址。

2. 建立 TCP 连接

  • 目的：通过三次握手建立客户端与服务器之间的可靠连接。

  • 流程：

    • 第一次握手：客户端发送 SYN 包，表示请求建立连接。
    • 第二次握手：服务器返回 SYN-ACK 包，表示同意建立连接。
    • 第三次握手：客户端返回 ACK 包，连接建立成功。

  • 结果：客户端与服务器之间建立了可靠的 TCP 连接。

3. TLS/SSL 握手

TLS/SSL 握手是 HTTPS 的核心步骤，用于建立加密通道，确保通信的安全性。

TLS/SSL 握手的详细流程

  1. 客户端 Hello：

    • 客户端发送一个 ClientHello 消息，包含以下内容：

      • 支持的 TLS 版本（如 TLS 1.2、TLS 1.3）。
      • 支持的加密算法（如 AES、RSA）。
      • 一个随机数（Client Random），用于后续密钥生成。

  2. 服务器 Hello：

    • 服务器返回一个 ServerHello 消息，包含以下内容：

      • 确定的 TLS 版本。
      • 确定的加密算法。
      • 一个随机数（Server Random）。
      • 服务器的数字证书。

  3. 服务器证书验证：

    • 客户端验证服务器的数字证书是否可信：

      • 检查证书是否由受信任的证书颁发机构（CA）签发。
      • 检查证书是否过期或被吊销。
      • 检查证书中的域名是否与请求的域名匹配。

    • 如果验证失败，握手终止，客户端会提示安全警告。

  4. 密钥交换：

    • TLS 1.2：

      • 客户端生成一个随机数（Pre-Master Secret），并使用服务器的公钥加密后发送给服务器。
      • 服务器使用自己的私钥解密，得到 Pre-Master Secret。

    • TLS 1.3：

      • 使用椭圆曲线 Diffie-Hellman（ECDHE）算法，客户端和服务器协商生成共享密钥，无需传输 Pre-Master Secret。

  5. 生成会话密钥：

    • 客户端和服务器根据 Client Random、Server Random 和 Pre-Master Secret 生成对称加密的会话密钥。

  6. 完成握手：

    • 客户端和服务器使用会话密钥加密通信，并发送 Finished 消息，表示握手完成。

4. 发送 HTTPS 请求

  • 目的：客户端通过加密通道发送 HTTP 请求。

  • 流程：

    1. 客户端构建 HTTP 请求报文（如 GET /index.html HTTP/1.1）。
    2. 使用会话密钥对请求报文进行加密。
    3. 将加密后的数据通过 TCP 连接发送到服务器。

5. 服务器处理请求

  • 目的：服务器接收并处理客户端的 HTTPS 请求。

  • 流程：

    1. 服务器接收加密的请求数据。
    2. 使用会话密钥解密请求数据。
    3. 解析 HTTP 请求报文，调用相应的业务逻辑处理请求。
    4. 构建 HTTP 响应报文。

6. 返回 HTTPS 响应

  • 目的：服务器将处理结果返回给客户端。

  • 流程：

    1. 服务器构建 HTTP 响应报文（如 HTTP/1.1 200 OK）。
    2. 使用会话密钥对响应报文进行加密。
    3. 将加密后的数据通过 TCP 连接发送到客户端。

7. 客户端接收并处理响应

  • 目的：客户端接收服务器返回的 HTTPS 响应，并解密和处理。

  • 流程：

    1. 客户端接收加密的响应数据。
    2. 使用会话密钥解密响应数据。
    3. 解析 HTTP 响应报文，提取状态码、响应头和响应体。
    4. 根据响应内容进行处理（如渲染 HTML 页面）。

HTTPS 如何保证安全

  1. 加密：

    • 使用对称加密（如 AES）对通信数据进行加密，防止数据被窃听。
    • 即使攻击者截获了数据包，也无法解密数据。

  2. 身份验证：

    • 使用数字证书验证服务器的身份，确保客户端连接的是合法的服务器，而不是中间人。
    • 证书由受信任的证书颁发机构（CA）签发，包含服务器的公钥和身份信息。

  3. 数据完整性：

    • 使用消息认证码（MAC）或哈希算法（如 SHA-256）校验数据的完整性，防止数据被篡改。

  4. 防止中间人攻击：

    • TLS/SSL 握手过程中，客户端和服务器直接协商密钥，中间人无法伪造证书或解密数据。

HTTPS 中的证书机制

  1. 数字证书的作用：

    • 验证服务器的身份。
    • 提供服务器的公钥，用于加密通信。

  2. 证书的组成：

    • 公钥。
    • 服务器的域名。
    • 证书颁发机构（CA）的签名。
    • 有效期。

  3. 证书的验证过程：

    • 客户端检查证书是否由受信任的 CA 签发。
    • 客户端检查证书是否过期或被吊销。
    • 客户端检查证书中的域名是否与请求的域名匹配。

HTTPS 的优点

  1. 数据加密：防止数据被窃听。
  2. 身份验证：确保服务器的合法性。
  3. 数据完整性：防止数据被篡改。
  4. 用户信任：浏览器会显示安全锁标志，增强用户信任。

总结

HTTPS 的流程在 HTTP 的基础上增加了 TLS/SSL 握手 和 加密通信，通过加密、身份验证和完整性校验，确保通信的安全性。它使用数字证书验证服务器身份，并通过对称加密保护数据传输，是现代 Web 安全的基础。

受信任的证书颁发机构（CA，Certificate Authority）

受信任的证书颁发机构（CA，Certificate Authority） 是一种专门负责签发和管理数字证书的第三方机构。它们在互联网安全体系中扮演着"信任中介"的角色，通过签发数字证书来验证服务器或客户端的身份，从而确保通信的安全性。

受信任的证书颁发机构（CA）是什么？

  1. CA 的职责：

    • 签发数字证书：为服务器或客户端生成并签发数字证书。
    • 验证身份：在签发证书之前，验证申请者的身份（如域名所有权、组织合法性等）。
    • 证书管理：提供证书的吊销、更新和查询服务（如 CRL 或 OCSP）。
    • 建立信任链：通过自身的可信性，确保签发的证书可以被广泛信任。

  2. CA 的作用：

    • 确保通信的安全性：通过数字证书提供加密通信的公钥。
    • 验证身份：确保客户端连接的是合法的服务器，而不是中间人或攻击者。

  3. 常见的受信任 CA：

    • 全球知名 CA：

      • DigiCert
      • Sectigo（原 Comodo）
      • GlobalSign
      • Let's Encrypt（免费证书颁发机构）
      • Entrust

    • 本地或行业 CA：

      • 一些国家或行业可能有自己的 CA，例如中国的 CFCA（中国金融认证中心）。

为什么可以放心使用 CA 签发的证书？

  1. CA 的可信性来源于操作系统和浏览器的信任列表：

    • 操作系统（如 Windows、macOS）和浏览器（如 Chrome、Firefox）内置了一个"受信任的根证书列表"，其中包含了全球范围内被广泛信任的 CA 的根证书。
    • 这些 CA 的根证书经过严格审核，确保它们的可信性。

  2. 严格的身份验证流程：

    • 在签发证书之前，CA 会验证申请者的身份。例如：

      • 验证域名所有权（通过 DNS 验证或文件验证）。
      • 验证组织的合法性（通过营业执照、政府注册信息等）。

    • 只有通过验证的申请者才能获得证书。

  3. 数字签名的安全性：

    • CA 使用自己的私钥对证书进行数字签名，确保证书的真实性和完整性。
    • 客户端（如浏览器）可以使用 CA 的公钥验证证书的签名，确保证书未被篡改。

  4. 信任链机制：

    • CA 的根证书是受信任的，所有由该 CA 签发的证书都可以通过信任链被验证。
    • 如果一个中间 CA 签发了证书，它的签名也会被验证，直到追溯到根 CA。

  5. 证书吊销机制：

    • 如果证书被发现存在问题（如私钥泄露、签发错误等），CA 可以吊销证书。
    • 客户端可以通过证书吊销列表（CRL）或在线证书状态协议（OCSP）检查证书的有效性。

  6. 行业标准和监管：

    • CA 必须遵守严格的行业标准（如 CA/Browser Forum 的 Baseline Requirements）。
    • 一些 CA 还会接受第三方审计，确保其操作的安全性和合规性。

CA 的信任体系是如何建立的？

  1. 根证书的信任：

    • CA 的根证书被预装在操作系统和浏览器中，这些根证书是整个信任链的基础。
    • 例如，Windows 的"受信任的根证书颁发机构"存储中包含了所有受信任的 CA 的根证书。

  2. 信任链验证：

    • 当客户端收到服务器的证书时，会验证证书的签名，逐级向上追溯到根证书。
    • 如果信任链中的所有证书都有效，客户端就会信任该服务器。

  3. 严格的审核和管理：

    • CA 必须通过严格的审核才能被操作系统和浏览器信任。
    • 如果 CA 被发现存在问题（如签发了错误的证书），它可能会被移出信任列表。

为什么不能随便信任未知的 CA？

  1. 未知 CA 的证书可能是伪造的：

    • 如果一个 CA 没有被操作系统或浏览器信任，其签发的证书可能是伪造的，无法保证通信的安全性。

  2. 中间人攻击的风险：

    • 如果客户端信任了一个不可信的 CA，攻击者可能利用该 CA 签发伪造的证书，实施中间人攻击。

  3. 缺乏监管：

    • 未知 CA 可能没有经过严格的审核和监管，其签发的证书可能存在安全隐患。

总结

受信任的证书颁发机构（CA）是互联网安全体系的核心，通过严格的身份验证、数字签名和信任链机制，确保通信的安全性和可信性。我们可以放心使用它们的证书，因为：

  1. 它们的根证书被操作系统和浏览器信任。
  2. 它们遵守严格的行业标准和监管。
  3. 它们提供了证书吊销机制，确保问题证书不会被滥用。

在使用 HTTPS 时，确保证书是由受信任的 CA 签发的，这是保障通信安全的关键。

常见请求头

以下是一些常用的 HTTP 请求头的详细介绍，包括 Host 和其他常见的请求头：

1. Host

作用：
  • Host 请求头用于指定客户端请求的目标主机名和端口号。
  • 它是 HTTP/1.1 中的必需字段，因为同一个服务器可能托管多个域名（虚拟主机），服务器需要通过 Host 确定请求的目标。
示例：
vbnet 复制代码 
GET /index.html HTTP/1.1
Host: www.example.com
  • 解释 ：客户端请求 www.example.com 的 /index.html 页面。
注意：
  • 如果没有指定端口号，默认使用协议的标准端口（HTTP 为 80，HTTPS 为 443）。
  • 在 HTTP/1.1 中，Host 是必需的，否则服务器会返回 400 Bad Request。

2. User-Agent

作用：
  • User-Agent 请求头用于标识客户端的类型、操作系统、浏览器版本等信息。
  • 服务器可以根据 User-Agent 提供不同的响应内容（如适配移动设备）。
示例：
sql 复制代码 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
  • 解释：客户端是运行在 Windows 10 上的 Chrome 浏览器。

3. Accept

作用：
  • Accept 请求头用于告诉服务器，客户端希望接收的响应内容类型（MIME 类型）。
  • 服务器会根据 Accept 的值返回匹配的内容类型。
示例：
bash 复制代码 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  • 解释 ：客户端优先希望接收 HTML 或 XML 格式的内容，但也可以接受任意类型的内容（*/*）。

4. Content-Type

作用：
  • Content-Type 请求头用于告诉服务器，客户端发送的请求体的内容类型（MIME 类型）。
  • 服务器会根据 Content-Type 的值解析请求体。
示例：
bash 复制代码 
Content-Type: application/json
  • 解释：客户端发送的请求体是 JSON 格式的数据。

5. Accept-Encoding

作用：
  • Accept-Encoding 请求头用于告诉服务器，客户端支持的内容压缩编码方式。
  • 服务器可以根据此头返回压缩后的响应内容，以减少传输数据量。
常见的编码方式：
  • gzip：Gzip 压缩。
  • deflate：Deflate 压缩。
  • br：Brotli 压缩。
示例：
makefile 复制代码 
Accept-Encoding: gzip, deflate, br
  • 解释：客户端支持 Gzip、Deflate 和 Brotli 压缩。

6. Authorization

作用：
  • Authorization 请求头用于向服务器提供认证信息（如用户名和密码、令牌等）。
  • 常用于需要身份验证的 API 请求。
常见的认证方式：
  • Basic：基本认证，使用 Base64 编码用户名和密码。
  • Bearer：令牌认证，通常用于 OAuth。
示例：
makefile 复制代码 
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
  • 解释 ：客户端使用基本认证，dXNlcm5hbWU6cGFzc3dvcmQ= 是 Base64 编码的用户名和密码。
作用：
  • Cookie 请求头用于向服务器发送客户端存储的 Cookie 数据。
  • 服务器可以通过 Cookie 识别用户会话或存储用户偏好。
示例：
ini 复制代码 
Cookie: sessionId=abc123; theme=dark
  • 解释 ：客户端发送了两个 Cookie：sessionId=abc123 和 theme=dark。

8. Referer

作用：
  • Referer 请求头用于告诉服务器，当前请求的来源页面 URL。
  • 常用于统计流量来源或防止盗链。
示例：
arduino 复制代码 
Referer: https://www.google.com/
  • 解释：客户端是从 Google 搜索结果页面跳转到当前页面的。

9. Accept-Language

作用：
  • Accept-Language 请求头用于告诉服务器，客户端希望接收的语言版本。
  • 服务器可以根据此头返回对应语言的内容。
示例：
css 复制代码 
Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8
  • 解释 ：客户端优先希望接收美式英语（en-US），其次是普通英语（en），最后是简体中文（zh-CN）。

10. Range

作用：
  • Range 请求头用于请求部分资源（如文件的一部分），支持断点续传。
  • 常用于大文件下载或视频流媒体。
示例：
ini 复制代码 
Range: bytes=0-1023
  • 解释：客户端请求文件的前 1024 字节（从第 0 字节到第 1023 字节）。

11. If-Modified-Since

作用：
  • If-Modified-Since 请求头用于告诉服务器，客户端希望只返回自指定日期以来修改过的资源。
  • 如果资源未修改，服务器返回 304 Not Modified，节省带宽。
示例：
yaml 复制代码 
If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT
  • 解释：客户端希望只返回自 2023 年 10 月 21 日 07:28:00 GMT 以来修改过的资源。

12. Connection

作用：

  • Connection 请求头用于控制当前连接的行为。

  • 常见值：

    • keep-alive：保持连接，允许复用 TCP 连接。
    • close：关闭连接。
示例：
makefile 复制代码 
Connection: keep-alive
  • 解释：客户端希望服务器保持连接，避免为每个请求重新建立 TCP 连接。

总结

请求头 作用
Host 指定目标主机名和端口号。
User-Agent 标识客户端的类型、操作系统和浏览器版本。
Accept 指定客户端希望接收的响应内容类型。
Content-Type 指定客户端发送的请求体内容类型。
Accept-Encoding 指定客户端支持的压缩编码方式。
Authorization 提供认证信息（如用户名密码或令牌）。
Cookie 向服务器发送客户端存储的 Cookie 数据。
Referer 指定当前请求的来源页面 URL。
Accept-Language 指定客户端希望接收的语言版本。
Range 请求部分资源（如文件的一部分）。
If-Modified-Since 请求自指定日期以来修改过的资源。
Connection 控制连接行为（如保持连接或关闭连接）。

这些请求头在客户端与服务器的通信中起着重要作用，帮助双方正确理解和处理请求与响应。

相关推荐
只会写Bug的程序员11 小时前
面试之《websocket》
网络·websocket·网络协议
vvilkim11 小时前
深入解析TCP与UDP：核心区别与应用场景
网络协议·tcp/ip·udp
无名之逆12 小时前
[特殊字符] Hyperlane：为现代Web服务打造的高性能Rust文件上传解决方案
服务器·开发语言·前端·网络·后端·http·rust
左灯右行的爱情12 小时前
HTTP 协议-应用层
网络·网络协议·http
你不是我我12 小时前
HTTP 教程 : 从 0 到 1 全面指南 教程【全文三万字保姆级详细讲解】
网络·网络协议·http
cyz14100114 小时前
树莓派4B配置wifi热点，可访问http协议
linux·网络·windows·后端·网络协议·http·树莓派
开心码农1号14 小时前
当一个 HTTP 请求发往 Kubernetes（K8s）部署的微服务时，整个过程流转时怎样的？
http·微服务·kubernetes
落——枫16 小时前
IP组播技术与internet
网络·网络协议·tcp/ip
Mr_Chenph18 小时前
为啥物联网用MQTT？
物联网·mqtt·http·报文字节对比
Danileaf_Guo20 小时前
常用VPN性能对比测试(IPsec、L2TP VPN、SSL VPN、L2TP over IPsec等)
网络·网络协议·ssl
热门推荐
01我决定放弃搞 Java 了02RAG 实践- Ollama+RagFlow 部署本地知识库03从零安装 LLaMA-Factory 微调 Qwen 大模型成功及所有的坑04Vue3 + TypeScript 的 Hooks 实用示例05DeepSeek RAGFlow构建本地知识库系统06如何在WPS和Word/Excel中直接使用DeepSeek功能07【WRF理论第十三期】详细介绍 Registry 的作用、结构和内容08汽车上的各种质量：整备质量、总质量、装载质量、簧上质量、簧下质量09DeepSeek各版本说明与优缺点分析10快刷每日面经😋