HTTP_HTTPS协议

一、前置

1.1 域名

https://blog.csdn.net/

像这样的网址，我们称之为 域名
浏览器在访问网站时并不会直接使用域名通信，而是先通过 DNS（域名解析服务） 将域名解析成对应的 IP 地址。
这一步是网络访问的第一步，也就是“找目标主机在哪”

浏览器访问时一般会自动补全协议头，比如输入 blog.csdn.net 实际上访问的是：

http://blog.csdn.net/   或   https://blog.csdn.net/

不同协议使用的默认端口号是固定的：

• HTTP → 80

• HTTPS → 443

因此，当浏览器使用默认协议时，会自动为请求添加端口号，无需手动填写。

---

1.2 认识 URL

https://mp.csdn.net/spm=1001.2014.3001.5448

我们常把这种字符串叫作 URL(统一资源定位符)
网络上的所有资源——网页、图片、视频、接口数据——都可以被一个唯一的 URL 标识和访问。

• URL 的作用：在互联网上“唯一定位一个资源”

一个完整的 URL 一般包含以下部分：

协议://用户名:密码@主机:端口/路径?查询参数#片段标识符

登录信息（用户名和密码）在现代网页中几乎不再使用。

网络行为中，最常见的两种方式就是：

• GET：从服务器“拿东西”
• POST：向服务器“交东西”

1.3 urlencode 与 urldecode

URL 中的一些字符（如 / ? : & = # 等）具有特殊意义，因此在参数中不能直接出现。
如果要传这些字符，就必须先进行 URL 编码(urlencode)

规则：
把特殊字符转成对应的十六进制 ASCII 值，并在前面加上 %。
例如：

空格 -> %20
# -> %23
/ -> %2F

URL 解码（urldecode）就是把 %xx 形式的编码再还原回原字符。

• 编码和解码是 HTTP 请求中保证数据安全和正确解析的重要一环

二、HTTP 请求与响应

HTTP 协议是浏览器与服务器之间通信的规则。
一个完整的 HTTP 交互包括两部分：请求（Request） 与 响应（Response）

2.1 请求结构

HTTP 请求由三部分组成：

请求行（Request Line）

包含请求方法、URL、协议版本。例如：

GET /index.html HTTP/1.1

请求头（Request Header）

一系列键值对形式的信息，每行都以 \r\n 结尾，例如：

Host: www.csdn.net
User-Agent: Mozilla/5.0

请求正文（Request Body）

用于 POST 或 PUT 请求时传输数据（如表单、JSON 内容）

请求头与请求体之间通过一个空行（\r\n\r\n）分隔。

2.2 响应结构

服务器接收请求后会返回 HTTP 响应，同样分为三部分：

状态行（Status Line）

HTTP/1.1 200 OK

包含协议版本、状态码、状态描述。

响应头（Response Header）

服务器返回的各种信息，如内容类型、长度、Cookie 等

响应正文（Response Body）

服务器返回的实际数据（网页内容、图片、接口数据等）

2.3 抓包与分析

使用 telnet、curl 或 fiddler 都能直观看到完整的请求与响应。

示例图（Fiddler 抓包）：

在抓包中我们能清楚看到：

• 请求行：方法、路径、协议版本

• 状态行：HTTP 版本、状态码、说明文字

三、HTTP 方法

方法	说明	支持的 HTTP协议版本
GET	获取资源	1.0、1.1
POST	传输实体主体	1.0、1.1
PUT	传输文件	1.0、1.1
HEAD	获得报文首部	1.0、1.1
DELETE	删除文件	1.0、1.1
OPTIONS	询问支持的方法	1.1
TRACE	追踪路径	1.1
CONNECT	要求用隧道协议连接代理	1.1
LINK	建立和资源之间的联系	1.0
UNLINE	断开连接关系	1.0

常见区别：

• GET：参数放在 URL 中，数量有限制（一般几 KB），不适合敏感数据

• POST：参数放在请求体中，大小无限制，更安全，常用于登录或上传

四、HTTP 状态码

状态码反映服务器处理结果，分为五类：

分类	含义	示例
1XX	信息提示	100 Continue
2XX	成功	200 OK
3XX	重定向，需要附加操作	301 Moved Permanently, 302 Found
4XX	客户端错误	404 Not Found, 403 Forbidden
5XX	服务器错误	500 Internal Error, 504 Gateway Timeout

3XX：重定向

浏览器访问旧地址时，服务器返回一个 3XX 状态码和一个新的 Location 地址：

Location: https://new.example.com/

浏览器收到后会自动重新访问新地址。

• 永久重定向 (301)：该 URL 已永久迁移到新地址
• 临时重定向 (302)：暂时迁移，原地址未来仍可能使用

五、常见 HTTP Header

Header	含义
Content-Type	返回内容类型，例如 text/html, application/json
Content-Length	正文长度（字节数）
Host	请求的主机名和端口
User-Agent	客户端信息（系统与浏览器版本）
Referer	当前页面来源地址
Location	搭配 3XX 重定向使用
Cookie	客户端保存的登录状态或偏好数据
Connection	控制连接是否保持，例如 keep-alive

六、HTTP 连接管理

6.1 短连接（HTTP/1.0）

每次请求-响应后即断开 TCP 连接
适用于简单访问，但每次都要三次握手，效率低

客户端 -> 请求 -> 服务器 -> 响应 -> 断开

6.2 长连接（HTTP/1.1）

HTTP/1.1 默认开启 Connection: keep-alive
一个 TCP 连接可以传输多个请求与响应，减少握手次数，显著提升性能。

当我们在访问某东的时候我们会看到一个巨大的页面包含非常多的元素，每一个元素就是一个资源

此时如果我们用一个请求响应一个资源，关闭连接，短链接–http 1.0采用

现在采用的是，建立一个TCP连接，发送和返回多个http的request和response，本轮请求完毕该链接再断开–长连接–http 1.1采用

七、Cookie 与 Session

HTTP 本身是 无状态协议，服务器无法区分用户
为了实现登录等需要“记住你是谁”的功能，引入了 Cookie 与 Session

7.1 Cookie

Cookie 是浏览器本地保存的一小段信息（键值对）
服务器通过响应头中的 Set-Cookie 字段向浏览器下发 Cookie

Set-Cookie: user=XXX; Path=/; Expires=Wed, 09 Jun 2027 10:18:14 GMT

浏览器保存后，今后访问该网站时会自动附上：

Cookie: user=XXX

Cookie 可分为：

• 会话级（Session Cookie）：关闭浏览器即失效

• 持久级（Persistent Cookie）：保存到文件，可长期使用

Cookie 暴露在客户端中，容易被窃取，安全性较弱

7.2 Session

为了更安全，服务器常用 Session 机制 管理登录状态

流程如下：

1. 用户登录 → 服务器验证用户名密码
2. 服务器生成唯一的 Session ID，并保存登录信息
3. 服务器通过 Set-Cookie 把 Session ID 发给客户端
4. 客户端后续访问时只需携带该 Session ID，服务器即可识别身份

Session 文件存在服务器端，可以集中管理、设置过期时间，也能强制注销

八、HTTPS：安全的 HTTP

8.1 什么是 HTTPS

• HTTPS= HTTP + SSL/TLS 加密层

• HTTP 传输的所有数据都是明文，如果中间有人截获数据包，就能直接看到用户名、密码等敏感信息

• HTTPS 在 HTTP 和 TCP 之间加上一个加密层，使得通信内容即使被截获也无法解读

8.2 加密的基本概念

• 加密（Encryption）：把明文转换为密文的过程
• 解密（Decryption）：把密文还原为明文的过程

整个过程需要一个或多个密钥（Key）。

常见加密方式

对称加密

• 加密与解密使用同一个密钥。

• 速度快，但密钥必须在双方共享，一旦泄露，通信就不安全

• 常见算法：AES、DES

非对称加密

• 使用一对密钥：公钥和 私钥

• 公钥加密的数据只能用私钥解密，反之亦然

• 安全性高，但运算速度慢

• 常见算法：RSA

8.3 数据摘要与哈希指纹

除了加密外，HTTPS 还利用了 哈希算法（Hash） 来确保数据完整性

哈希的特点：

• 输出长度固定

• 不可逆

• 输入稍变输出大变

• 极低概率产生冲突

例如：

hello → 5d41402abc4b2a76b9719d911017c592

这串“摘要”可以当作数据指纹，用于验证数据是否被篡改。

---

8.4 HTTPS 的加密方案演进

HTTPS 的目标是：让浏览器和服务器之间的数据安全传输，
既不能被别人偷看，也不能被篡改。
下面是加密方案从简单到安全的演化过程

方案一：只使用对称加密

加密和解密都使用同一个密钥

双方各自保存这把密钥，只要不泄露，通信内容就安全

但问题是：

• 浏览器要先从服务器拿到密钥

• 密钥在传输过程中可能被别人截获

• 一旦被截获，所有通信都被破解

所以：对称加密虽然快，但密钥分发不安全

方案二：只使用非对称加密

服务器生成一对密钥：

• 公钥：可以公开

• 私钥：只能自己保存

服务器把公钥发送给客户端

客户端用公钥加密要发送的内容

服务器用私钥解密得到原文

优点：

• 公钥可以随意公开

• 没有私钥的人无法解密

缺点:

• 非对称加密运算速度非常慢

• 服务器发回的数据只能用私钥加密、公钥解密

• 公钥是公开的，别人也能解密

• 所以“服务器 → 客户端”方向仍然不安全

所以：只用非对称加密，安全性也不完整，还很慢

方案三：双方都使用非对称加密

• 服务器：有自己的公钥 P、私钥 P′

• 客户端：也有自己的公钥 C、私钥 C′

双方先交换公钥；

通信时都用对方的公钥加密，用自己的私钥解密

优点：

• 双向通信都能加密

• 双方都无法伪造对方

缺点：

• 双方都要维护自己的密钥对，过程繁琐

• 加解密效率仍然很低

• 依旧存在中间人替换公钥的问题

所以：双向非对称安全性高，但太慢、不实用

方案四：非对称加密 + 对称加密

这就是 HTTPS 最终采用的方案。

核心思路：

• 用“非对称加密”安全地传递一把“对称密钥”
• 后续数据传输用对称加密（速度快）

详细流程：

1. 服务器有一对密钥（公钥 P、私钥 P′）；

2. 服务器把公钥 P 发送给客户端；

3. 客户端生成一个随机对称密钥 C；

4. 客户端用服务器的公钥 P 加密密钥 C；

5. 加密后的密钥（密文）发送给服务器；

6. 服务器用自己的私钥 P′ 解密得到真正的对称密钥 C；

7. 从此客户端和服务器就都拥有相同的密钥 C；

8. 后续所有通信都用密钥 C 进行对称加密传输

效果：

• 公钥传输公开、无风险

• 对称加密通信高速

• 兼顾了安全性与性能

中间人攻击

即便有加密，也可能被“中间人”破坏
假设有个攻击者在你和服务器之间拦截通信

1. 客户端请求服务器公钥；

2. 中间人截获请求，用自己的公钥 M 替换服务器公钥；

3. 客户端以为这是服务器的公钥，用 M 加密自己的对称密钥；

4. 中间人用自己的私钥 M′ 解密，得到对称密钥；

5. 中间人再用服务器的公钥重新加密发给服务器；

6. 结果：

客户端 ↔ 中间人：加密通信

中间人 ↔ 服务器：加密通信

但中间人同时能解密两边数据！

问题根本：

客户端无法确认收到的公钥是否是真的服务器公钥。

---

九、数字证书与 CA 认证机制

9.1 证书的作用

为了解决“公钥是否可信”的问题，互联网引入了 数字证书
证书由权威机构 CA签发，相当于**“公钥身份证”**

证书中包含：

• 网站域名

• 申请者信息（组织名、公司等）

• 公钥

• 有效期

• 颁发机构信息

• 签名（由 CA 使用其私钥生成）

---

9.2 获取证书的过程

1. 网站管理员生成一对密钥（公钥、私钥）

2. 准备域名与申请者信息，生成 .csr 文件

3. 提交给 CA 机构审核（公司信息、域名所有权等）

4. 审核通过后，CA 使用其私钥对网站信息加签生成证书

5. 管理员将证书安装到服务器

6. 客户端访问网站时，服务器会将证书发送给浏览器

9.3 客户端验证流程

当浏览器收到证书后，会进行以下验证：

1. 检查证书是否过期；

2. 检查证书是否由受信任的 CA 签发；

3. 检查域名是否与证书中的域名一致；

4. 使用内置 CA 公钥对证书的签名部分进行验证；

5. 验证通过后，从证书中取出服务器公钥建立安全连接。

如果任一步失败，浏览器会弹出“此连接不安全”警告

9.4 签名机制详解

CA 签发证书时的签名过程：

1. CA 对证书明文部分做哈希，得到摘要

2. 用 CA 的私钥对摘要加密，生成签名

3. 明文 + 签名 → 形成完整证书

客户端验证时：

1. 取出证书明文部分，再次计算哈希

2. 用 CA 的公钥解密签名部分，得到摘要

3. 比对两者，如果一致，说明证书可信

客户端只信任系统中预置的 CA 公钥，因此中间人无法伪造签名。

9.5 为什么要“签名 + 哈希”，不直接加密

直接加密整个证书内容不仅效率低，而且加密结果太大。
通过先哈希后加密，只需加密固定长度的摘要，大大提升了验证速度

器

9.3 客户端验证流程

当浏览器收到证书后，会进行以下验证：

1. 检查证书是否过期；

2. 检查证书是否由受信任的 CA 签发；

3. 检查域名是否与证书中的域名一致；

4. 使用内置 CA 公钥对证书的签名部分进行验证；

5. 验证通过后，从证书中取出服务器公钥建立安全连接。

如果任一步失败，浏览器会弹出“此连接不安全”警告

9.4 签名机制详解

CA 签发证书时的签名过程：

1. CA 对证书明文部分做哈希，得到摘要

2. 用 CA 的私钥对摘要加密，生成签名

3. 明文 + 签名 → 形成完整证书

客户端验证时：

1. 取出证书明文部分，再次计算哈希

2. 用 CA 的公钥解密签名部分，得到摘要

3. 比对两者，如果一致，说明证书可信

客户端只信任系统中预置的 CA 公钥，因此中间人无法伪造签名。

9.5 为什么要“签名 + 哈希”，不直接加密

直接加密整个证书内容不仅效率低，而且加密结果太大。
通过先哈希后加密，只需加密固定长度的摘要，大大提升了验证速度