HTTP 和 HTTPS 详解：工作原理、通信流程、使用方法及核心区别

前言

在浏览器地址栏中输入一个网址时，通常会看到下面两种形式：

http://www.example.com
https://www.example.com

其中：

HTTP 是超文本传输协议；
HTTPS 是使用 TLS 加密保护的 HTTP；
HTTP 默认使用 80 端口；
HTTPS 默认使用 443 端口。

HTTP 和 HTTPS 是 Web 开发、前后端通信、接口调用、物联网设备联网以及移动端开发中最常见的网络协议。

很多初学者知道“HTTPS 比 HTTP 安全”，但并不清楚以下问题：

HTTP 到底负责什么？
浏览器是如何向服务器发送请求的？
GET 和 POST 有什么区别？
HTTPS 是怎样实现加密的？
为什么有了 HTTPS，别人就不能直接看到密码？
HTTP/1.1、HTTP/2 和 HTTP/3 又有什么关系？

本文将从基础概念开始，系统讲解 HTTP 和 HTTPS。

一、HTTP 是什么

HTTP 的英文全称是：

HyperText Transfer Protocol

中文名称是：

超文本传输协议

HTTP 是一种应用层协议，主要用于客户端和服务器之间传输数据。

这里的客户端可以是：

浏览器；
手机 App；
小程序；
嵌入式设备；
Python 程序；
Java 程序；
Postman；
curl；
其他网络应用。

服务器则通常是：

Nginx；
Apache；
Tomcat；
Node.js；
Spring Boot；
Django；
Flask；
FastAPI；
云服务器上的 Web 服务。

HTTP 最初主要用于传输 HTML 网页，但现在已经可以传输多种数据，例如：

HTML 页面；
CSS 文件；
JavaScript 文件；
JSON 数据；
XML 数据；
图片；
音频；
视频；
压缩包；
二进制文件。

因此，HTTP 并不只是“传输网页”，它实际上是客户端和服务器之间非常通用的数据通信协议。

二、HTTP 位于网络模型的哪一层

HTTP 属于应用层协议。

一个典型的 HTTP 网络通信过程可以简化为：

应用层：HTTP
传输层：TCP
网络层：IP
数据链路层：以太网或 Wi-Fi
物理层：网线、光纤、无线信号

传统 HTTP 通常工作在 TCP 之上：

HTTP
↓
TCP
↓
IP
↓
以太网或 Wi-Fi

HTTPS 则是在 HTTP 和 TCP 之间加入 TLS：

HTTP
↓
TLS
↓
TCP
↓
IP
↓
以太网或 Wi-Fi

需要注意，HTTP/3 的底层不再直接使用 TCP，而是使用基于 UDP 的 QUIC 协议：

HTTP/3
↓
QUIC
↓
UDP
↓
IP

三、HTTP 的基本通信模型

HTTP 采用请求和响应模型。

客户端主动发送请求，服务器接收到请求后返回响应。

基本过程如下：

客户端服务器

——– HTTP 请求 ——–>

<——- HTTP 响应 ——–

例如，用户在浏览器中访问：

http://www.example.com/index.html

浏览器会向服务器发送请求：

GET /index.html HTTP/1.1
Host: www.example.com

服务器处理后返回响应：

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<html>
<body>
<h1>Hello HTTP</h1>
</body>
</html>

浏览器收到 HTML 后，对内容进行解析和渲染，最终显示出网页。

四、访问一个 HTTP 网站时发生了什么

当用户在浏览器中输入：

http://www.example.com

浏览器通常会执行以下步骤。

1. 解析 URL

URL 可以拆分为：

http://www.example.com:80/index.html?name=zhangsan

各部分含义如下：

http 协议
www.example.com 域名
80 端口
/index.html 资源路径
name=zhangsan 查询参数

如果没有明确写出端口，HTTP 默认使用 80 端口。

2. DNS 域名解析

计算机通信最终使用的是 IP 地址，而不是域名。

浏览器需要将：

www.example.com

解析为类似下面的 IP 地址：

192.0.2.10

这个过程由 DNS 完成。

可以简单理解为：

域名：www.example.com
↓ DNS
IP地址：192.0.2.10

3. 建立 TCP 连接

获得服务器 IP 地址后，客户端需要与服务器建立 TCP 连接。

TCP 建立连接需要进行三次握手：

客户端服务器

——– SYN ————->

<—– SYN + ACK ———-

——– ACK ————->

三次握手完成后，客户端和服务器之间建立可靠的 TCP 连接。

4. 发送 HTTP 请求

TCP 连接建立后，浏览器向服务器发送 HTTP 请求。

例如：

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

5. 服务器处理请求

服务器接收到请求后，会根据请求路径进行处理。

例如：

/index.html
/api/user
/api/login
/images/logo.png

服务器可能会：

直接返回静态文件；
查询数据库；
调用业务代码；
检查用户身份；
调用其他服务；
生成 JSON 数据；
返回错误信息。

6. 返回 HTTP 响应

服务器完成处理后，将结果返回给客户端：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1024

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

7. 浏览器解析和渲染

浏览器收到 HTML 后，会解析页面。

如果 HTML 中还引用了其他资源，例如：

浏览器还会继续请求：

/css/style.css
/js/app.js
/images/logo.png

因此，打开一个网页通常不只是发送一次 HTTP 请求，而是可能发送几十次甚至几百次请求。

五、HTTP 请求报文结构

HTTP 请求通常由四部分组成：

请求行
请求头
空行
请求体

完整示例如下：

POST /api/login HTTP/1.1
Host: www.example.com
Content-Type: application/json
Content-Length: 48
User-Agent: Mozilla/5.0

{
"username": "admin",
"password": "123456"
}

1. 请求行

请求行格式为：

请求方法请求路径 HTTP版本

例如：

GET /api/user HTTP/1.1

其中：

GET：请求方法；
/api/user：请求资源路径；
HTTP/1.1：HTTP 协议版本。

2. 请求头

请求头用于携带附加信息。

例如：

Host: www.example.com
Content-Type: application/json
Authorization: Bearer xxxxxx
User-Agent: Mozilla/5.0
Accept: application/json
Cookie: session_id=123456

常见请求头如下。

Host

表示目标服务器的域名：

Host: www.example.com

一台服务器上可能部署多个网站，服务器可以根据 Host 判断客户端访问的是哪个网站。

Content-Type

表示请求体的数据格式：

Content-Type: application/json

常见类型包括：

application/json
application/x-www-form-urlencoded
multipart/form-data
text/plain
text/html

Authorization

用于携带身份认证信息：

Authorization: Bearer eyJhbGciOi…

User-Agent

表示客户端类型、浏览器和操作系统信息：

User-Agent: Mozilla/5.0

Accept

表示客户端希望接收的数据类型：

Accept: application/json

Cookie

用于向服务器发送 Cookie：

Cookie: session_id=abc123

3. 空行

请求头和请求体之间必须存在一个空行。

这个空行用于告诉服务器：

请求头已经结束，后面是请求体。

4. 请求体

请求体用于携带提交给服务器的数据。

例如登录请求：

{
"username": "admin",
"password": "123456"
}

GET 请求一般不使用请求体，而 POST、PUT、PATCH 等请求经常携带请求体。

六、HTTP 响应报文结构

HTTP 响应通常由四部分组成：

状态行
响应头
空行
响应体

例如：

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 55
Server: nginx

{
"code": 200,
"message": "success"
}

1. 状态行

状态行格式如下：

HTTP版本状态码状态说明

例如：

HTTP/1.1 200 OK

其中：

HTTP/1.1：协议版本；
200：状态码；
OK：状态描述。

2. 响应头

响应头用于描述服务器返回的数据。

例如：

Content-Type: application/json
Content-Length: 55
Server: nginx
Set-Cookie: session_id=abc123
Cache-Control: no-cache

常见响应头包括：

Content-Type

表示响应体的数据类型：

Content-Type: application/json

Content-Length

表示响应体长度：

Content-Length: 1024

Set-Cookie

服务器通过该响应头向浏览器设置 Cookie：

Set-Cookie: session_id=abc123; HttpOnly; Secure

Cache-Control

用于控制浏览器缓存：

Cache-Control: max-age=3600

Location

通常用于重定向：

Location: https://www.example.com/login

3. 响应体

响应体是真正返回给客户端的数据。

可能是：

HTML；
JSON；
XML；
图片；
视频；
文件；
二进制数据。

例如：

{
"id": 1001,
"username": "zhangsan"
}

七、HTTP 常见请求方法

HTTP 定义了多种请求方法。

1. GET

GET 用于获取资源。

例如：

GET /api/users/1001 HTTP/1.1

浏览器访问：

https://www.example.com/api/users/1001

查询参数通常放在 URL 中：

https://www.example.com/search?keyword=http&page=1

GET 的特点：

主要用于查询数据；
参数通常位于 URL 中；
可以被浏览器缓存；
可以保存为书签；
不应该用于修改重要数据；
URL 长度可能受到客户端或服务器限制。

2. POST

POST 用于提交数据或创建资源。

例如：

POST /api/users HTTP/1.1
Content-Type: application/json

{
"username": "zhangsan",
"age": 20
}

POST 的特点：

数据通常位于请求体中；
适合提交表单；
适合上传文件；
常用于新增数据；
默认不会像普通 GET 请求一样直接被缓存。

需要注意：POST 并不等于安全。

在普通 HTTP 中，POST 请求体仍然可能被监听者直接看到。是否加密取决于是否使用 HTTPS，而不是取决于 GET 或 POST。

3. PUT

PUT 通常用于整体更新某个资源。

PUT /api/users/1001 HTTP/1.1
Content-Type: application/json

{
"username": "lisi",
"age": 25
}

4. PATCH

PATCH 通常用于局部更新资源。

PATCH /api/users/1001 HTTP/1.1
Content-Type: application/json

{
"age": 26
}

5. DELETE

DELETE 用于删除资源。

DELETE /api/users/1001 HTTP/1.1

6. HEAD

HEAD 与 GET 类似，但服务器只返回响应头，不返回响应体。

HEAD /download/file.zip HTTP/1.1

HEAD 可以用于：

检查文件是否存在；
获取文件大小；
查看资源是否更新；
检查服务器状态。

7. OPTIONS

OPTIONS 用于查询服务器支持的请求方法，也经常出现在浏览器跨域请求的预检过程中。

OPTIONS /api/users HTTP/1.1

八、常见 HTTP 状态码

HTTP 状态码由三位数字组成。

可以按照第一位数字进行分类。

1xx：信息响应

表示请求已收到，服务器正在继续处理。

例如：

100 Continue

2xx：请求成功

200 OK

请求成功：

HTTP/1.1 200 OK

201 Created

资源创建成功，常用于 POST 请求：

HTTP/1.1 201 Created

204 No Content

请求成功，但没有响应体：

HTTP/1.1 204 No Content

3xx：重定向

301 Moved Permanently

永久重定向。

例如将：

http://example.com

永久跳转到：

https://example.com

302 Found

临时重定向。

304 Not Modified

资源没有变化，客户端可以继续使用缓存。

4xx：客户端错误

400 Bad Request

请求格式错误或参数错误。

401 Unauthorized

用户没有完成身份认证。

403 Forbidden

服务器理解请求，但拒绝访问。

401 和 403 的区别可以简单理解为：

401：你还没有证明自己是谁。
403：服务器知道你是谁，但你没有权限。

404 Not Found

请求的资源不存在。

405 Method Not Allowed

请求方法不被允许。

例如接口只允许 POST，但客户端使用了 GET。

408 Request Timeout

请求超时。

429 Too Many Requests

请求过于频繁，服务器进行了限流。

5xx：服务器错误

500 Internal Server Error

服务器内部发生错误。

502 Bad Gateway

网关或代理服务器从上游服务器获得了无效响应。

503 Service Unavailable

服务暂时不可用，可能是服务器过载、维护或服务未启动。

504 Gateway Timeout

网关等待上游服务器响应超时。

九、HTTP 的主要特点

1. 请求和响应模式

HTTP 通常由客户端发起请求，服务器返回响应。

客户端请求 → 服务器处理 → 服务器响应

2. 无状态

HTTP 本身是无状态协议。

也就是说，服务器默认不会自动记住前一次请求。

例如，第一次请求：

用户登录

第二次请求：

查看个人信息

如果没有额外机制，服务器不知道这两个请求是不是来自同一个用户。

因此，实际开发中通常使用以下方式保持登录状态：

Cookie；
Session；
Token；
JWT；
OAuth 2.0。

3. 支持持久连接

早期 HTTP 通常一个请求建立一次 TCP 连接，请求完成后立即关闭。

HTTP/1.1 默认支持持久连接：

Connection: keep-alive

这样可以在同一个 TCP 连接中发送多个 HTTP 请求，减少重复建立连接的开销。

4. 灵活的数据格式

HTTP 可以传输：

HTML
JSON
XML
文本
图片
音频
视频
文件
二进制数据

数据格式通常由 Content-Type 指定。

5. HTTP 本身不提供加密

普通 HTTP 中，请求和响应内容通常以明文方式在网络中传输。

例如下面的登录信息：

{
"username": "admin",
"password": "123456"
}

如果使用普通 HTTP，在不安全网络环境下，攻击者可能通过抓包看到这些内容。

这就是 HTTPS 出现的重要原因。

十、HTTP 存在哪些安全问题

普通 HTTP 主要存在三个安全问题。

1. 窃听风险

HTTP 内容没有加密。

攻击者可能看到：

用户名；
密码；
Cookie；
Token；
聊天内容；
接口数据；
网页内容。

例如用户发送：

POST /login HTTP/1.1
Content-Type: application/json

{
"username": "admin",
"password": "123456"
}

在普通 HTTP 中，这些内容可能被直接读取。

2. 篡改风险

攻击者不仅可能读取数据，还可能修改数据。

例如服务器原本返回：

请下载官方软件。

攻击者可能将其替换为：

请下载恶意软件。

客户端很难判断数据是否在传输过程中被修改。

3. 冒充风险

普通 HTTP 无法可靠证明当前服务器就是用户想访问的服务器。

攻击者可能冒充真实服务器，向用户发送伪造页面。

例如，用户以为自己访问的是银行网站，实际上访问的是攻击者伪造的网站。

十一、HTTPS 是什么

HTTPS 的英文通常写作：

HTTP Secure

HTTPS 可以理解为：

HTTPS = HTTP + TLS

很多旧资料会写：

HTTPS = HTTP + SSL

SSL 是 TLS 的前身。现代 HTTPS 实际上主要使用 TLS，因此更准确的说法是：

HTTPS 是运行在 TLS 安全连接上的 HTTP。

HTTPS 并没有改变 HTTP 的基本请求和响应语义。

例如，在 HTTPS 中仍然使用：

GET；
POST；
PUT；
DELETE；
HTTP 状态码；
HTTP 请求头；
HTTP 响应头；
JSON；
Cookie。

HTTPS 主要是在 HTTP 数据进入网络传输之前，对通信内容进行加密和完整性保护。

十二、HTTPS 解决了哪些问题

HTTPS 主要提供三个安全能力。

1. 数据加密

HTTPS 会对传输内容进行加密。

网络中的第三方即使截获数据，通常也只能看到加密后的内容，无法直接读取原始数据。

例如原始内容是：

{
"password": "123456"
}

经过 TLS 加密后，网络中传输的是类似下面的不可读数据：

8A 3F 91 C2 76 4D 0E …

2. 身份认证

HTTPS 通过数字证书验证服务器身份。

浏览器会检查：

证书是否由受信任的证书机构签发；
证书是否过期；
证书中的域名是否与当前域名一致；
证书是否被撤销；
证书签名是否有效。

这样可以降低客户端连接到伪造服务器的风险。

3. 完整性保护

HTTPS 可以检测传输数据是否被篡改。

如果攻击者修改了密文，完整性校验通常会失败，接收方会拒绝接受被破坏的数据。

因此 HTTPS 解决的三个核心问题可以概括为：

加密：别人看不懂。
认证：确认服务器身份。
完整性：发现数据被修改。

十三、HTTPS 的整体通信流程

访问一个 HTTPS 网站时，整体过程如下：

1. 解析域名
2. 建立 TCP 连接
3. 进行 TLS 握手
4. 验证服务器证书
5. 协商加密算法和会话密钥
6. 建立安全连接
7. 发送加密后的 HTTP 请求
8. 接收加密后的 HTTP 响应
9. 解密并处理数据

通信结构如下：

客户端服务器

——– TCP 三次握手 ————->

<——- TLS 握手与证书 ————

——– 密钥协商 —————–>

<======= 加密 HTTP 数据 ============>

需要说明的是，现代 TLS 握手比这个示意过程更复杂，实际消息数量也会受到 TLS 版本、连接复用和会话恢复等因素影响。

十四、数字证书是什么

数字证书可以理解为服务器在互联网上的电子身份证。

证书中通常包含：

网站域名；
证书持有者信息；
证书颁发机构；
证书有效期；
服务器公钥；
签名算法；
证书颁发机构的数字签名。

例如，服务器证书中声明：

该公钥属于 www.example.com

同时由受信任的证书机构对这份信息进行数字签名。

浏览器通过验证签名，判断证书是否可信。

十五、CA 是什么

CA 的英文全称是：

Certificate Authority

中文称为：

证书颁发机构

CA 负责签发和管理数字证书。

浏览器和操作系统中预置了一组受信任的根证书。

服务器提供证书后，浏览器会沿着证书链进行验证：

网站证书
↓
中间证书
↓
根证书

只要证书链最终可以连接到受信任的根证书，并且证书满足相关校验条件，浏览器就会认为该证书可信。

十六、HTTPS 为什么同时使用非对称加密和对称加密

HTTPS 并不是简单地使用一种加密算法完成所有工作。

它通常结合使用：

非对称密码技术；
对称加密；
哈希和消息认证技术；
数字签名；
密钥交换算法。

1. 对称加密

对称加密使用同一个密钥完成加密和解密。

明文 + 密钥 → 密文
密文 + 同一密钥 → 明文

优点：

加密速度快；
适合大量数据传输；
性能开销相对较低。

缺点：

如何安全地将密钥交给通信双方，是一个问题。

HTTPS 建立连接后，大量 HTTP 数据主要通过对称加密保护。

2. 非对称密码技术

非对称密码系统使用一对相关密钥：

公钥
私钥

公钥可以公开，私钥需要由持有者秘密保存。

非对称密码技术常用于：

身份认证；
数字签名；
密钥交换；
安全建立共享密钥。

它的优点是更适合解决身份和密钥协商问题，但计算成本通常高于对称加密。

因此 HTTPS 不会简单地使用非对称加密来加密所有业务数据。

3. 两者结合

HTTPS 的核心思想可以简化为：

先通过 TLS 握手和非对称密码机制完成身份认证与密钥协商，
再使用协商出的对称密钥加密后续 HTTP 数据。

这样同时兼顾：

安全性；
身份认证；
传输性能。

十七、HTTPS 中的 TLS 握手过程

以现代 TLS 为例，可以将握手过程简化为以下步骤。

第一步：客户端发送握手信息

客户端告诉服务器：

支持哪些 TLS 版本；
支持哪些加密套件；
支持哪些密钥交换参数；
客户端随机数；
目标域名；
其他扩展能力。

第二步：服务器返回握手信息和证书

服务器选择双方都支持的参数，并返回：

选定的 TLS 参数；
服务器证书；
密钥交换相关参数；
服务器身份签名；
其他握手数据。

第三步：客户端验证证书

客户端检查：

证书是否过期；
域名是否匹配；
证书签名是否正确；
证书链是否可信；
证书是否存在明显异常。

如果验证失败，浏览器通常会显示类似提示：

您的连接不是私密连接

第四步：双方计算会话密钥

客户端和服务器通过密钥交换算法计算共享密钥材料。

双方各自根据握手信息生成相同的会话密钥，但密钥本身不需要直接以明文在网络中传输。

第五步：验证握手完整性

双方确认：

握手过程没有被篡改；
计算出的密钥一致；
对方掌握正确的密钥；
可以开始安全通信。

第六步：传输加密后的 HTTP 数据

之后的 HTTP 请求和响应都会受到 TLS 加密保护。

HTTP 请求
↓
TLS 加密
↓
网络传输
↓
TLS 解密
↓
服务器处理

十八、HTTP 和 HTTPS 的主要区别

对比项目HTTPHTTPS

完整名称	超文本传输协议	使用 TLS 保护的 HTTP
默认端口	80	443
数据传输	通常为明文	加密传输
服务器身份认证	默认没有	使用数字证书认证
数据完整性	缺少安全保护	可检测传输篡改
URL 开头	http://	https://
是否需要证书	不需要	需要服务器证书
安全性	较低	较高
性能开销	较小	存在 TLS 处理开销
现代网站适用性	不建议传输敏感数据	应作为默认选择
搜索引擎与浏览器体验	可能被标记为不安全	更符合现代 Web 要求

十九、HTTPS 会加密哪些内容

HTTPS 通常会保护 HTTP 层中的内容，例如：

请求路径；
查询参数；
请求头；
Cookie；
Authorization；
请求体；
响应头；
响应体；
JSON 数据；
表单内容。

例如：

https://example.com/search?keyword=password

其中路径和查询参数位于加密后的 HTTP 数据中，普通中间网络观察者通常无法直接看到其具体内容。

但是 HTTPS 并不能隐藏所有网络信息。

某些底层信息仍可能被观察到，例如：

通信双方 IP 地址；
连接时间；
数据量大小；
通信持续时间；
某些握手元数据；
DNS 查询信息，取决于是否使用加密 DNS；
在部分场景下可能推测出的目标站点信息。

因此，HTTPS 的作用是保护 HTTP 通信内容，并不等于完全隐藏所有网络行为。

二十、HTTPS 不代表网站绝对安全

这是一个常见误区。

浏览器显示小锁或 HTTPS，只能说明：

当前浏览器与该网站之间的网络通信受到 TLS 保护。

它不能保证：

网站一定是合法网站；
网站程序不存在漏洞；
网站数据库不会泄露；
网站不会保存明文密码；
网站运营者一定可信；
用户电脑没有病毒；
浏览器插件不会读取页面内容；
服务器不会主动记录用户数据。

钓鱼网站同样可以申请 HTTPS 证书。

例如：

https://fake-bank-example.com

这个网站可以拥有有效证书，但它仍可能是钓鱼网站。

因此，用户还需要检查：

域名是否正确；
网站主体是否可信；
页面内容是否异常；
是否要求提供不必要的敏感信息。

二十一、GET 和 POST 在 HTTP 与 HTTPS 中是否一样

GET 和 POST 都是 HTTP 请求方法，在 HTTPS 中仍然存在。

区别在于：

HTTP：GET 和 POST 内容通常未加密。
HTTPS：GET 和 POST 内容都会受到 TLS 加密保护。

需要特别注意，使用 POST 并不能代替 HTTPS。

错误理解：

POST 参数在请求体中，所以一定安全。

正确理解：

POST 只是将数据放在请求体中。
如果使用普通 HTTP，请求体仍可能被监听。

另外，GET 查询参数即使在 HTTPS 传输中受到加密，也可能出现在：

浏览器历史记录；
服务器访问日志；
代理日志；
分析系统；
Referer 信息；
用户复制的链接中。

因此密码、Token 等敏感数据不应该放在 URL 查询参数中。

二十二、HTTP/1.0、HTTP/1.1、HTTP/2 和 HTTP/3

1. HTTP/1.0

HTTP/1.0 的典型特点是：

一个 TCP 连接通常只处理一个请求；
请求完成后关闭连接；
重复建立 TCP 连接，开销较大。

2. HTTP/1.1

HTTP/1.1 的主要改进包括：

默认支持持久连接；
支持分块传输；
支持缓存控制；
Host 请求头成为关键机制；
一个 TCP 连接可以连续处理多个请求。

例如：

Connection: keep-alive

HTTP/1.1 仍然是非常常见的协议版本。

3. HTTP/2

HTTP/2 的主要特点包括：

使用二进制分帧；
支持多路复用；
支持头部压缩；
一个连接上可以并发传输多个请求；
减少 HTTP/1.1 多连接带来的开销。

HTTP/1.1 中，浏览器为了提高并发能力，通常需要建立多个 TCP 连接。

HTTP/2 可以在一个 TCP 连接中传输多个并发流：

一个 TCP 连接
├── 请求流 1
├── 请求流 2
├── 请求流 3
└── 请求流 4

不过，HTTP/2 底层仍然使用 TCP。当 TCP 层发生丢包时，连接中的多个流可能都会受到影响。

4. HTTP/3

HTTP/3 基于 QUIC，而 QUIC 基于 UDP。

结构如下：

HTTP/3
↓
QUIC
↓
UDP

HTTP/3 的主要目标包括：

减少连接建立延迟；
改善丢包情况下的多路复用表现；
更好地支持网络切换；
集成现代安全机制；
提升弱网和移动网络环境下的体验。

HTTP/3 并不意味着“不可靠”。

虽然 UDP 本身不提供 TCP 那样的可靠传输，但 QUIC 在 UDP 之上实现了：

可靠传输；
拥塞控制；
重传机制；
流量控制；
多路复用；
加密通信。

二十三、如何使用 HTTP 和 HTTPS

1. 使用浏览器访问

HTTP：

http://example.com

HTTPS：

https://example.com

现代网站应该优先使用 HTTPS。

2. 使用 curl 发送 GET 请求

curl https://jsonplaceholder.typicode.com/posts/1

显示响应头：

curl -i https://jsonplaceholder.typicode.com/posts/1

只查看响应头：

curl -I https://www.example.com

查看完整连接过程：

curl -v https://www.example.com

-v 参数可以查看：

DNS 解析结果；
连接地址；
TLS 握手信息；
证书信息；
HTTP 请求头；
HTTP 响应头。

3. 使用 curl 发送 POST 请求

curl -X POST https://example.com/api/login \\
-H "Content-Type: application/json" \\
-d '{"username":"admin","password":"123456"}'

其中：

-X POST 指定请求方法
-H "Content-Type: …" 设置请求头
-d 设置请求体

4. 使用 JavaScript 发送请求

fetch GET 请求

fetch("https://example.com/api/users/1001")
.then(response => {
if (!response.ok) {
throw new Error(`HTTP error: ${response.status}`);
}

return response.json();
})
.then(data => {
console.log(data);
})
.catch(error => {
console.error("请求失败：", error);
});

fetch POST 请求

fetch("https://example.com/api/login", {
method: "POST",
headers: {
"Content-Type": "application/json"
},
body: JSON.stringify({
username: "admin",
password: "123456"
})
})
.then(response => {
if (!response.ok) {
throw new Error(`HTTP error: ${response.status}`);
}

return response.json();
})
.then(data => {
console.log("服务器返回：", data);
})
.catch(error => {
console.error("请求失败：", error);
});

5. 使用 Python requests 发送 GET 请求

先安装 requests：

pip install requests

GET 示例：

import requests

url = "https://jsonplaceholder.typicode.com/posts/1"

try:
response = requests.get(url, timeout=10)
response.raise_for_status()

print("状态码：", response.status_code)
print("响应头：", response.headers)
print("响应数据：", response.json())
except requests.RequestException as exc:
print("请求失败：", exc)

6. 使用 Python 发送 POST 请求

import requests

url = "https://example.com/api/login"

payload = {
"username": "admin",
"password": "123456"
}

try:
response = requests.post(
url,
json=payload,
timeout=10
)

response.raise_for_status()

print("状态码：", response.status_code)
print("响应内容：", response.text)
except requests.RequestException as exc:
print("请求失败：", exc)

使用：

json=payload

时，requests 会自动：

将 Python 字典转换为 JSON；
设置合适的 Content-Type 请求头。

7. 启动一个简单 HTTP 服务器

在安装 Python 的目录中执行：

python -m http.server 8000

然后在浏览器中访问：

http://127.0.0.1:8000

或者：

http://localhost:8000

这适合临时测试静态文件，但不建议直接用于正式生产环境。

二十四、网站如何从 HTTP 升级为 HTTPS

网站启用 HTTPS 一般需要以下步骤。

第一步：准备域名

例如：

www.example.com

第二步：申请 TLS 证书

可以向证书服务商申请：

免费证书；
域名验证证书；
企业验证证书；
多域名证书；
通配符证书。

第三步：在服务器上安装证书

通常需要配置：

证书文件；
私钥文件；
中间证书链；
HTTPS 监听端口。

第四步：配置 Web 服务器

下面是一个简化的 Nginx HTTPS 配置示例：

server {
listen 443 ssl;
server_name www.example.com;

ssl_certificate /etc/nginx/cert/fullchain.pem;
ssl_certificate_key /etc/nginx/cert/private.key;

location / {
root /var/www/html;
index index.html;
}
}

需要注意：

私钥文件必须妥善保护；
不应该将私钥上传到公开代码仓库；
证书路径要根据实际环境修改；
正式环境还需要设置合理的 TLS 安全参数。

第五步：将 HTTP 重定向到 HTTPS

Nginx 示例：

server {
listen 80;
server_name www.example.com;

return 301 https://$host$request_uri;
}

这样用户访问：

http://www.example.com/test

会被重定向到：

https://www.example.com/test

第六步：修改网站内部资源地址

网页中的资源也应该使用 HTTPS：

不能在 HTTPS 页面中继续加载不安全的 HTTP 资源：

否则可能产生混合内容问题。

二十五、什么是混合内容

当一个 HTTPS 页面加载 HTTP 资源时，就会产生混合内容。

例如页面地址是：

https://www.example.com

但页面中引用：

此时页面本身通过 HTTPS 加载，但 JavaScript 文件通过 HTTP 加载。

攻击者可能篡改这个 JavaScript 文件，从而破坏整个页面的安全性。

浏览器可能会：

阻止资源加载；
显示安全警告；
将页面标记为不完全安全。

解决方法是确保所有资源统一使用 HTTPS：

二十六、证书常见错误

1. 证书过期

证书超过有效期后，浏览器会提示连接不安全。

因此服务器需要及时续期证书。

2. 域名不匹配

例如证书签发给：

www.example.com

但用户访问：

api.example.com

如果证书没有包含该域名，浏览器会提示证书域名不匹配。

3. 证书链不完整

服务器只配置网站证书，没有正确配置中间证书，部分客户端可能无法建立可信证书链。

4. 使用自签名证书

自签名证书由服务器自己签发，不是由浏览器信任的 CA 签发。

它可以提供加密，但浏览器默认无法确认其身份可信，因此会显示警告。

自签名证书适合：

本地开发；
测试环境；
内部网络；
已经手动安装信任证书的专用设备。

不适合直接用于普通公共网站。

5. 服务器时间错误

证书验证依赖系统时间。

如果客户端或服务器时间严重错误，可能导致证书被判断为：

尚未生效；
已经过期。

二十七、HTTPS 是否会降低性能

HTTPS 确实需要进行：

TLS 握手；
证书验证；
密钥协商；
数据加密；
数据解密；
完整性校验。

因此理论上会增加一定开销。

但在现代硬件、TLS 协议优化、连接复用、会话恢复、HTTP/2 和 HTTP/3 等技术支持下，这部分开销通常是可以接受的。

HTTPS 还可以配合：

HTTP/2；
HTTP/3；
CDN；
TLS 会话恢复；
OCSP Stapling；
长连接；
缓存；
压缩；
边缘节点。

因此，实际项目中不能因为担心少量性能损耗而放弃 HTTPS。

安全性通常比这部分性能开销更加重要。

二十八、HTTP 重定向到 HTTPS 是否已经足够安全

将 HTTP 重定向到 HTTPS 是必要操作，但还可以进一步启用 HSTS。

HSTS 的完整名称是：

HTTP Strict Transport Security

服务器可以返回：

Strict-Transport-Security: max-age=31536000; includeSubDomains

它告诉浏览器：

在指定时间内，该网站只能通过 HTTPS 访问。

这样可以减少用户误访问 HTTP 地址以及部分降级攻击风险。

需要谨慎配置 HSTS，尤其是：

max-age；
includeSubDomains；
预加载列表。

错误配置可能导致网站或子域名无法通过 HTTP 临时访问。

二十九、Cookie 在 HTTPS 中如何设置更安全

服务器设置登录 Cookie 时，可以使用：

Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax

其中：

Secure

表示 Cookie 只通过 HTTPS 发送。

HttpOnly

表示前端 JavaScript 不能直接读取该 Cookie，有助于降低部分 XSS 攻击导致的 Cookie 窃取风险。

SameSite

SameSite=Lax

用于限制跨站请求携带 Cookie，有助于降低 CSRF 风险。

需要注意，HTTPS 只是 Web 安全的一部分，还需要结合：

输入校验；
权限控制；
SQL 注入防护；
XSS 防护；
CSRF 防护；
密码哈希存储；
安全日志；
访问控制；
限流机制。

三十、如何判断网站是否使用 HTTPS

可以通过以下方式判断。

方法一：查看地址栏

HTTPS 地址以：

https://

开头。

方法二：查看浏览器安全信息

点击地址栏左侧的安全图标，可以查看：

当前连接是否加密；
证书颁发对象；
证书颁发机构；
证书有效期；
域名信息。

方法三：使用 curl

执行：

curl -v https://www.example.com

可以看到 TLS 连接和证书相关信息。

方法四：使用 OpenSSL

可以通过以下命令查看服务器证书：

openssl s_client -connect www.example.com:443 -servername www.example.com

其中：

-connect

指定服务器地址和端口；

-servername

用于发送 SNI 域名信息。

三十一、HTTP 抓包与 HTTPS 抓包的区别

HTTP 抓包

普通 HTTP 报文通常可以直接看到：

POST /login HTTP/1.1
Host: example.com
Content-Type: application/json

{
"username": "admin",
"password": "123456"
}

HTTPS 抓包

HTTPS 报文经过 TLS 加密后，抓包工具通常只能看到：

IP 地址；
端口；
TCP 或 QUIC 数据；
TLS 握手信息；
加密后的应用数据；
数据长度；
通信时间。

无法直接看到 HTTP 请求体和响应体。

在合法的本地调试环境中，可以通过客户端代理、开发者工具或导出会话密钥等方式分析 HTTPS 内容，但前提是客户端信任调试证书或掌握对应会话信息。

不得在未经授权的情况下截获他人的网络通信。

三十二、HTTP 和 HTTPS 的常见误区

误区一：POST 比 GET 安全

不一定。

GET 和 POST 是否加密，取决于是否使用 HTTPS。

普通 HTTP 下，GET 和 POST 都可能被监听。

误区二：有 HTTPS 就不会被攻击

错误。

HTTPS 主要保护传输过程，不能自动修复：

SQL 注入；
XSS；
CSRF；
弱密码；
越权访问；
文件上传漏洞；
服务器漏洞；
数据库泄露。

误区三：HTTPS 会让网站非常慢

现代 HTTPS 的性能开销通常可控。

合理使用连接复用、HTTP/2、HTTP/3、缓存和 CDN 后，HTTPS 完全可以满足高性能网站需求。

误区四：自签名证书没有加密作用

自签名证书仍然可以建立加密连接。

问题在于客户端默认无法确认该证书对应的身份是否可信，因此浏览器会显示安全警告。

误区五：HTTPS 可以隐藏服务器 IP

HTTPS 主要加密 HTTP 内容，通常不会隐藏通信双方的 IP 地址。

误区六：HTTPS 会加密浏览器地址栏和本地历史记录

HTTPS 会保护数据在网络传输过程中的内容，但浏览器本地仍可能保存：

历史记录；
下载记录；
自动填充数据；
缓存；
完整 URL。

因此不能把敏感数据放入 URL。

三十三、实际项目应该使用 HTTP 还是 HTTPS

可以临时使用 HTTP 的场景

本机开发；
完全隔离的测试网络；
临时静态文件服务器；
不涉及敏感数据的实验环境；
某些资源受限的封闭式设备通信。

即使在内网中，也需要评估是否存在监听、篡改和横向移动风险。

应该使用 HTTPS 的场景

用户登录；
支付系统；
电商网站；
管理后台；
App 接口；
小程序接口；
文件上传；
个人信息传输；
Cookie 和 Token 传输；
企业系统；
云服务接口；
物联网设备远程管理；
任何互联网公开服务。

对于现代互联网服务，可以将 HTTPS 视为默认选择。

三十四、HTTP 与 HTTPS 通信过程对比

HTTP 通信流程

客户端
│
│ 1. DNS 解析
▼
获得服务器 IP
│
│ 2. TCP 三次握手
▼
建立 TCP 连接
│
│ 3. 发送明文 HTTP 请求
▼
服务器处理
│
│ 4. 返回明文 HTTP 响应
▼
客户端显示结果

HTTPS 通信流程

客户端
│
│ 1. DNS 解析
▼
获得服务器 IP
│
│ 2. TCP 三次握手
▼
建立 TCP 连接
│
│ 3. TLS 握手
│ 4. 验证证书
│ 5. 协商会话密钥
▼
建立安全连接
│
│ 6. 发送加密 HTTP 请求
▼
服务器解密并处理
│
│ 7. 返回加密 HTTP 响应
▼
客户端解密并显示结果

三十五、总结

HTTP 是客户端和服务器之间进行数据交换的应用层协议，采用请求和响应模型。

HTTP 请求主要由以下部分组成：

请求行
请求头
空行
请求体

HTTP 响应主要由以下部分组成：

状态行
响应头
空行
响应体

HTTP 常见请求方法包括：

GET
POST
PUT
PATCH
DELETE
HEAD
OPTIONS

普通 HTTP 主要存在以下安全问题：

数据可能被窃听
数据可能被篡改
服务器身份难以可靠确认

HTTPS 本质上是：

HTTPS = HTTP + TLS

HTTPS 主要提供：

数据加密
服务器身份认证
数据完整性保护

HTTP 和 HTTPS 的核心区别不是请求方法不同，也不是传输数据格式不同，而是：

HTTPS 在 HTTP 通信外增加了 TLS 安全保护。

在现代 Web 开发中，只要系统涉及登录、Cookie、Token、个人信息、支付信息、文件上传或互联网公开访问，就应该优先使用 HTTPS。

最后可以用一句话总结：

HTTP 负责规定客户端和服务器如何交换数据，HTTPS 则在 HTTP 的基础上，通过 TLS 保护数据不被轻易窃听、篡改和冒充。