Day 8-3 HTTP 协议与 HTTPS/TLS（认知）

一、HTTP 协议基础

1.1 什么是 HTTP？

HTTP（HyperText Transfer Protocol，超文本传输协议）= 浏览器和服务器之间的“聊天语言”。它定义了客户端怎么问、服务器怎么答。

HTTP 是一个基于 TCP/IP 通信协议来传递数据的协议（HTML 文件、图片文件、查询结果、视频、安装包等）。

回顾 OSI 七层模型与 TCP/IP 四层模型：

• HTTP 处于应用层。
• 依赖于传输层的 TCP 协议（默认端口 80），确保可靠传输。
• 依赖于网络层的 IP 协议，实现寻址和路由。

HTTP 协议工作于客户端——服务端架构上（Client-Server）。浏览器作为 HTTP 客户端，通过 URL 向 HTTP 服务端（即 WEB 服务器）发送所有请求。

基本通信流程：

1.2 HTTP 三大特点

1.2.1 无连接

无连接是指：在 HTTP 的原始设计中，每次请求结束后，服务器都会主动断开 TCP 连接。

这背后是早期 Web 访问量小、页面简单的时代背景。每次请求都建立/断开连接，对服务器来说实现简单、资源清理干净。

Nginx 的 keepalive_timeout 在做什么？

keepalive_timeout 65;

提示：服务器在处理完一个请求后，不立即断开 TCP 连接，而是保持连接空闲等待 65 秒。如果 65 秒内同一个客户端发来新请求，则复用这条连接。

HTTP 协议说“我默认不保持连接”，Nginx 说“但我要保持 65 秒”。前者是协议标准，后者是对标准的工程优化。

1.2.2 媒体独立

媒体独立是指：只要客户端和服务器知道如何处理数据内容，任何类型的数据都可以通过 HTTP 传输。

1.2.3 无状态

无状态是指：HTTP 协议对事务处理没有记忆能力。每次请求都是独立的，服务器不会自动保留任何之前请求的信息。

无状态的含义：

无状态导致的问题：

即使用户刚刚登录成功，下一次请求时，服务器也不知道“你是谁”。因为：

一个页面加载多个资源的场景：

用户打开一个页面，浏览器会并行发起多个请求（HTML、CSS、JS、图片 1、图片 2、图片 N）：

结论：无状态是 Web 服务器能够水平扩展（横向扩容）的基础。 因为服务器不保存用户状态，请求可以被分配到集群中的任意一台服务器上处理。这也是为什么 Session 必须集中存放到 Redis，让应用服务器变成“无状态”的。

1.3 HTTP 请求与响应结构

HTTP 报文分为请求报文和响应报文，均由三部分组成：

1. 起始行——描述请求或响应的基本信息。
2. 首部字段——包含协议的附加信息，以键值对形式表示。
3. 消息正文——实际传输的数据，可为空。

1.3.1 客户端请求报文

客户端发送一个 HTTP 请求到服务器的请求消息包括以下格式：

请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

# POST 方法测试
[root@yangge ~]# curl -v -X POST https://postman-echo.com/post \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"123456"}'
> POST /post HTTP/2
> Host: postman-echo.com
> User-Agent: curl/8.12.1
> Accept: */*
> Content-Type: application/json
> Content-Length: 40
>
* upload completely sent off: 40 bytes
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< date: Wed, 29 Jul 2026 14:46:30 GMT
< content-type: application/json; charset=utf-8
< content-length: 359
< etag: W/"167-uifdlbAzM0m0MLvoYA8WO0Wyjl8"
< vary: Accept-Encoding
< x-envoy-upstream-service-time: 5

1.3.2 服务器响应报文

HTTP 响应也由四个部分组成：

状态行、消息报头、空行和响应正文。

图中响应体示例（底部水印区域裁去后，原有内容补录于此）：

<a href="https://www.baidu.com/">Moved Permanently</a>.

响应体就是实际传输的数据内容，例如 HTML。

1.4 HTTP 请求方法

HTTP/1.1 定义了多种请求方法，以下是运维必须掌握的 6 个核心方法：

关于幂等性：

幂等性 = 多次执行同一操作，产生的结果相同。

• GET、PUT、DELETE 都是幂等的 → 可以安全地重试。
• POST 不是幂等的 → 重试可能产生两个订单、两条评论。

运维视角：设计 POST 接口时必须做“防重提交”处理，否则用户双击提交按钮会产生两条重复数据。

1.5 HTTP 状态码

1.5.1 常见状态码

HTTP 状态码由三个十进制数字组成，第一个数字定义了状态码的类型：

运维必知的高频状态码：

容易混淆的两组状态码 301 vs 302：

1.5.2 测试案例一：200 请求成功

[root@yangge ~]# curl -I https://www.jd.com
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jul 2026 11:08:54 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 191209
Connection: keep-alive
Cache-Control: max-age=120
Expires: Wed, 29 Jul 2026 11:10:00 GMT

1.5.3 测试案例二：301 永久重定向

[root@yangge ~]# curl -I jd.com
HTTP/1.1 301 Moved Permanently
Date: Wed, 29 Jul 2026 11:04:08 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://www.jd.com
Server: jfe
Cache-Control: no-cache

[root@yangge ~]# curl -v jd.com
* Host jd.com:80 was resolved.
* IPv6: (none)
* IPv4: 106.39.171.134, 211.144.24.218, 211.144.27.126, 111.13.149.108
*   Trying 106.39.171.134:80...
* Connected to jd.com (106.39.171.134) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: jd.com
> User-Agent: curl/8.12.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Date: Wed, 29 Jul 2026 10:57:00 GMT
< Content-Type: text/html
< Content-Length: 178
< Connection: keep-alive
< Location: https://www.jd.com
< Server: jfe
< Cache-Control: no-cache

1.5.4 测试案例三：302 临时重定向

[root@yangge ~]# curl -I https://postman-echo.com/status/302
HTTP/2 302
date: Wed, 29 Jul 2026 11:16:22 GMT
content-type: application/json; charset=utf-8
content-length: 14
etag: W/"e-81YCV6LzGcGN2+vhBJCJku78JQY"
vary: Accept-Encoding
x-envoy-upstream-service-time: 5
cf-cache-status: DYNAMIC

1.5.4 测试案例三：304 缓存命中

[root@yangge ~]# curl -I https://postman-echo.com/status/304
HTTP/2 304
date: Wed, 29 Jul 2026 15:12:33 GMT
etag: W/"e-yKIv+EWfjBvzq4aQf7hqeeQWS/I"
x-envoy-upstream-service-time: 6
cf-cache-status: DYNAMIC
set-cookie: sails.sid=s%3A7vi1tZEfe2kSzlaZThq1b3zVnGZIil6X.EnEVHh6tQ%2Fm76v1WGbuNfxllFliHt5Y8Qh6l6AQ%2BDb8; Path=/; HttpOnly

1.5.5 测试案例四：403 禁止访问

[root@yangge ~]# curl -I https://postman-echo.com/status/403
HTTP/2 403
date: Wed, 29 Jul 2026 11:15:02 GMT
content-type: application/json; charset=utf-8
content-length: 14
etag: W/"e-wN+xT2c5ZvCPo0YIdQiMpDVsb6o"
vary: Accept-Encoding
x-envoy-upstream-service-time: 6
cf-cache-status: DYNAMIC

1.5.6 测试案例五：404 资源不存在

[root@yangge ~]# curl -I https://postman-echo.com/yangge.html
HTTP/2 404
date: Wed, 29 Jul 2026 11:13:26 GMT
content-type: application/json; charset=utf-8
vary: Accept-Encoding
x-envoy-upstream-service-time: 5
cf-cache-status: DYNAMIC

1.5.7 测试案例六：502 网关错误

[root@yangge ~]# curl -I https://postman-echo.com/status/502
HTTP/2 502
date: Wed, 29 Jul 2026 11:21:18 GMT
content-type: text/plain; charset=UTF-8
content-length: 16
cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
expires: Thu, 01 Jan 1970 00:00:01 GMT
referrer-policy: same-origin
x-frame-options: SAMEORIGIN

1.6 常用请求头与响应头

1.6.1 常见请求头

1.6.2 常见响应头

1.7 Cookie 与 Session

1.7.1 为什么需要 Cookie 和 Session？

HTTP 是无状态协议——每次请求都是独立的，服务器不记得你是谁。但网站需要记住用户的登录状态，于是有了 Cookie 和 Session 机制。

1.7.2 Cookie vs Session 对比

1.7.3 会话保持的完整流程

1. 用户提交账号密码 → 服务器验证通过。
2. 服务器创建 Session（存储用户身份、权限等信息），生成唯一的 Session ID。
3. 服务器通过 Set-Cookie 响应头将 JSESSIONID=xxx 下发给浏览器。
4. 浏览器将 Session ID 保存在 Cookie 中。
5. 后续每次请求，浏览器自动通过 Cookie 请求头携带 Session ID。
6. 服务器根据 Session ID 找到对应的 Session 数据 → 识别用户身份。

1.7.4 生产环境 Session 存储问题

Session 存储问题：

• 单机环境：Session 存本地内存（默认）或文件 → 没问题。
• 负载均衡环境（多台服务器）：Session 必须集中存储（Redis/数据库），否则用户在 A 服务器登录后，请求落到 B 服务器时 B 没有该 Session，用户会被踢出登录。

方案一：负载均衡 + Session 存储本地（❌ 错误方式）

问题：用户在服务器 A 登录成功，Session 存在 A 的本地内存中。第二次请求被负载均衡器分配到服务器 B，B 的本地没有该用户的 Session → 用户被踢出登录。

方案二：负载均衡 + Session 集中存储（✅ 正确方式）

图 1：登录——Session 写入 Redis。

图 2：查询订单——从 Redis 读取 Session。

解决方案：Session 统一存放到 Redis（或数据库）中。无论用户请求落到哪台服务器，都能从 Redis 读取到相同的 Session 数据 → 用户会话保持。

对比总结：

二、HTTPS 与 TLS

2.1 为什么需要 HTTPS？

HTTP 是明文传输的——中间的任何人都能看到通信内容（密码、Token、业务数据）。

HTTP（上图）：yangge 发送的密码在网络中以明文传输，任何中间人都能看到。

HTTPS（下图）：yangge 发送的密码经过加密后再传输，中间人无法解读。

HTTPS = HTTP + TLS（传输层安全协议）。

HTTPS 并不是一个新的应用层协议，而是在 HTTP 和 TCP 之间插入了一层 TLS 加密层，对传输的所有数据进行加密。

2.2 对称加密 vs 非对称加密

图中文字：plaintext（明文）→ encryption（加密）→ ciphertext（密文）→ decryption（解密）→ plaintext（明文）。

公钥（public key）可公开，私钥（private key）需保密。

2.2.1 为什么 HTTPS 需要两种加密结合？

2.2.2 使用的流程

1. 客户端和服务器在握手阶段使用非对称加密（RSA/ECC）安全地交换一个临时的对称密钥（Pre-Master Secret 衍生）。
2. 双方用这个对称密钥派生出会话密钥。
3. 后续所有 HTTP 数据都使用对称加密（AES）加密传输 → 又快又安全。

2.3 TLS 握手流程（TLS 1.2）

TLS 握手是客户端与服务器建立加密通道的过程，TLS 1.2 需要 2 次 RTT（往返时间）。

2.3.1 握手步骤详解

2.3.2 TLS 1.2 vs TLS 1.3

TLS 1.3 的改进：减少了 1 次 RTT，握手更快。同时移除了有安全漏洞的旧算法，强制支持前向保密（即使私钥泄露，历史通信内容仍无法被解密）。

2.4 证书链（Certificate Chain）

2.4.1 证书链的三层结构

2.4.2 jd.com 三层证书链

三层对应关系：

关键点：

2.4.3 证书链验证流程

1. 浏览器收到服务器发送的服务器证书。
2. 检查证书的 Issuer（签发者）字段 → 找到签发该证书的“中间 CA 证书”。
3. 检查中间 CA 证书的 Issuer → 找到“根 CA 证书”。
4. 根 CA 证书是否在浏览器内置的“可信根 CA 列表”中？是 → 信任链建立，继续下一步；否 → 报错 NET::ERR_CERT_AUTHORITY_INVALID。

2.4.3 常见证书错误

2.4.3 根证书信任列表

1. 按 Win + R，输入 certmgr.msc，点击“确定”。
2. 展开“受信任的根证书颁发机构”→“证书”。