为什么链接本机端口不需要https-CSDN博客

本文链接：https://blog.csdn.net/m0_74331272/article/details/149385507

为什么链接本机端口不需要https

✅ 一、HTTPS 是用来加密通信+身份认证的协议

HTTPS = HTTP + TLS
- 它通过 TLS/SSL 加密数据传输，防止中间人窃听和篡改。
- 同时也通过证书验证服务器身份，避免连接伪造。
- 推荐以下视频，讲的真的非常好。

白话 HTTPS，如何在全世界的眼皮子底下安全密谋？_哔哩哔哩_bilibili

✅ 二、访问「本机地址」为什么通常不需要 HTTPS

本机地址 = localhost / 127.0.0.1 / [::1]

🔒 1. 本地通信默认是“可信”的

浏览器或操作系统认为：你访问 localhost 的数据不会离开本机，不存在中间人风险。
因此，加密传输意义不大，除非你担心本机上其他进程窃听（这属于更高等级的本地威胁模型）。

🧾 2. 本地开发时通常没有合法 HTTPS 证书

HTTPS 需要「域名 + 证书」，而 localhost 无法申请到公网可信 CA 签发的证书。
虽然可以自签证书，但浏览器会提示不受信任，反而不便于开发。
因此开发服务器（如 Node.js, Flask, Vite 等）默认都是 HTTP + localhost:端口。

✅ 三、HTTP 和 HTTPS 的端口号也不同

协议	默认端口
HTTP	`80`
HTTPS	`443`
自定义	如 `3000`, `5000`, `8080` 等

比如你运行了一个服务监听 localhost:3000，它只监听 HTTP 请求，如果你用 https://localhost:3000 访问，它会：
- 尝试发起 TLS 握手
- 但服务端不支持 TLS，于是连接失败

✅ 四、总结：为什么本地开发通常使用 HTTP

原因	解释
✅ 本地通信默认是可信	数据不会出本机，没有中间人攻击风险
✅ 没有合法的 HTTPS 证书	`localhost` 无法申请 CA 证书
✅ HTTP 更方便调试	不涉及 TLS 握手、证书校验
✅ 端口默认绑定在 HTTP 上	常见的开发框架默认都是 HTTP 启动

🧪 如果你确实想让本地支持 HTTPS：

可以使用如下方式实现：

使用自签证书 + 配置本地 HTTPS 服务（例如使用 OpenSSL 生成证书）
配置 nginx 反向代理 + HTTPS
使用一些开发工具（如 mkcert、vite 的 https 选项）

但通常只推荐在你开发的内容涉及 Cookie 安全、OAuth 回调等强制需要 HTTPS 的场景下才启用。

HTTP 与 HTTPS 的区别可以从安全性、协议层、端口、性能等多个方面来理解。

✅ 一、基本定义

协议	全称	简要说明
HTTP	HyperText Transfer Protocol	超文本传输协议，明文传输
HTTPS	HTTP Secure 或 HTTP over SSL/TLS	加了 TLS 加密的 HTTP，更安全

✅ 二、核心区别对比

对比项	HTTP	HTTPS
安全性	❌ 明文传输，容易被窃听或篡改	✅ 加密传输，防止中间人攻击
加密机制	无	使用 TLS/SSL 加密通信
身份验证	无	使用数字证书验证服务器身份
默认端口	80	443
传输内容	明文，包括用户密码、表单内容	加密后内容，无法被直接解析
URL格式	`http://`	`https://`
性能（过去）	略快，无加密开销	略慢，但现代 TLS 加速优化后几乎一样
SEO 友好度	普通	✅ 谷歌等搜索引擎偏好 HTTPS 页面
浏览器标识	无安全锁，或提示不安全	显示“安全锁”🔒，若证书异常会报错

✅ 三、简单例子说明

HTTP 请求报文（明文）：

GET /login HTTP/1.1
Host: example.com
Username: alice
Password: 123456

HTTPS 请求（加密后）：

实际内容被 TLS 加密，攻击者无法看到用户名和密码，也不能伪造响应内容。

✅ 四、应用场景建议

场景	推荐协议
线上网站、电子商务、登录页	✅ 强烈建议 HTTPS
本地调试、无敏感信息服务	HTTP 可接受
API 接口、OAuth 授权、支付回调	必须使用 HTTPS

✅ 五、图示类比（便于记忆）

HTTP 就像明信片：邮递员可以看到你写了什么
HTTPS 就像密封信件：只有收件人能看到内容，别人看不懂

“三次握手”和 TLS 的“握手”是两个完全不同层级的概念，经常容易混淆。

✅ 一、什么是“三次握手”？（TCP三次握手）

🔧 所属层级：传输层协议 TCP

TCP 的三次握手用于建立可靠连接，流程如下：

Client                             Server
   | -------- SYN -------------> |   第一次握手：客户端发起连接请求
   | <------- SYN-ACK ---------- |   第二次握手：服务端确认并回应
   | -------- ACK -------------> |   第三次握手：客户端确认连接建立

建立完这个 TCP 连接之后，才可以在上面发送 HTTP/TLS 等数据
📦 TCP 确保数据有序、可靠、不丢包

✅ 二、那 TLS 的“握手”是干什么的？

🔐 所属层级：应用层协议 HTTPS（HTTP+TLS）

TLS 的握手是为了：

协商加密算法
交换密钥
验证身份（如服务器证书）

它是在 TCP 连接已经建立之后才开始 的！

✅ 三、为什么 TLS 不叫“三次握手？

因为它不是为了建立连接（connection），而是为了建立信任（security）
它的握手过程往往包含 多个消息来回（TLS 1.2 通常是 6 次报文，3 往返）
所以并不是只握三次，而是根据加密算法、证书、TLS 版本不同，可能有：
- 1 次往返（TLS 1.3）
- 2～3 次往返（TLS 1.2）

✅ 四、图示理解：整个过程关系图

# 这是完整的 HTTPS 连接过程的层级

[客户端发起连接]
        ↓
🔁 TCP 三次握手（建立连接）
        ↓
🔐 TLS 握手（协商加密、交换密钥、验证身份）
        ↓
📨 HTTP 请求（用 TLS 加密的实际业务数据）
        ↓
📨 HTTP 响应（加密传回）

TCP 三次握手确保了“可以通信”
TLS 握手确保了“通信是加密且可信的”
然后 HTTP 才真正开始“传数据”

TLS 握手（TLS Handshake）是 HTTPS 中确保通信安全的关键步骤，其作用是：

建立一条安全的加密通道
验证服务器（和可选的客户端）身份
协商加密算法与密钥

🧠 一图了解 TLS 握手流程（TLS 1.2 为主）

Client (浏览器)                   Server (服务器)
      |                                 |
 1️⃣  | ---- ClientHello -------------> |  
      |       - 支持的协议版本          |
      |       - 支持的加密套件列表      |
      |       - 随机数 ClientRandom     |
      |       - 可选：SNI域名扩展       |
      |                                 |
 2️⃣  | <---- ServerHello ------------- |  
      |       - 确定使用的协议版本      |
      |       - 选择的加密算法          |
      |       - 随机数 ServerRandom     |
      |                                 |
 3️⃣  | <---- Server Certificate ------ |  
      |       - 服务器证书（含公钥）     |
      |       - CA签名链（可验证身份）  |
      |                                 |
 4️⃣  | ---- ClientKeyExchange -------> |  
      |       - 用服务器公钥加密的对称密钥片段（PreMasterKey） |
      |                                 |
 5️⃣  | ---- ChangeCipherSpec --------> |  
      |       - 通知：之后用对称加密   |
      | ---- Finished ----------------> |  
      |       - 用对称密钥加密的摘要    |
      |                                 |
 6️⃣  | <---- ChangeCipherSpec --------|  
      | <---- Finished ---------------- |  
      |                                 |
🔐 ✅ 安全通信正式开始，使用对称密钥双向加密

🔍 每步细节说明

步骤	说明
1️⃣ ClientHello	客户端发送它支持的协议、加密算法、随机数
2️⃣ ServerHello	服务端回应选择的加密算法和自己的随机数
3️⃣ Server Certificate	发送 SSL 证书（含服务器公钥），由可信 CA 签发
4️⃣ ClientKeyExchange	客户端用公钥加密生成的 Pre-Master Key 发送给服务端
5️⃣/6️⃣ ChangeCipherSpec + Finished	双方通知：从现在开始正式使用对称加密进行通信

🔐 关键点总结

前期（握手阶段）使用非对称加密（RSA/EC）
- 客户端用公钥加密 PreMasterKey，保证只有服务器能解密
通信阶段使用对称加密（AES、ChaCha20等）
- 因为对称加密速度快，更适合传输大量数据
双方共享的会话密钥（Session Key）不是直接传输的，而是通过 Diffie-Hellman 或加密的 PremasterKey 生成的

🔁 TLS 1.3 有哪些变化？

TLS 1.3 对握手做了大量优化，主要变化包括：

项目	TLS 1.2	TLS 1.3
握手轮数	多次往返（2-RTT）	最少一次往返（1-RTT）
加密启动时间	握手结束后	更早就开始加密
加密算法	多种，包含过时的	禁用不安全算法（如 RSA 握手）
会话恢复	使用 Session ID	使用 Session Ticket 和 PSK
性能	相对较慢	更快更安全

🛡️ 为什么 TLS 握手这么重要？

TLS 握手过程：

保证了数据的 保密性（通过加密）
保证了服务器的 真实性（通过证书验证）
保证了数据的 完整性（通过 MAC 或 AEAD）

🌱 假设：

私钥：X（服务器自己私藏的）
公钥：B（服务器通过证书发给客户端的）
对称密钥：C（客户端随机生成的）

✅ 核心结论先说：

公钥 Y 不重要，一旦用它把“对称密钥 C”安全传过去了，后面就不再用了。真正负责数据加密的是对称密钥 C。

🧠 整个过程就像这样：

客户端拿到公钥 Y
- 它并不在乎 B 是不是机密，反正谁都能拿到
- 它只关心：“我用 B 加密的东西，只有你服务器能解开（你有 X）”
客户端随机生成一个对称密钥 C
- 它是临时的，只在这一轮会话中使用
客户端用公钥 Y 把 C 加密，发给服务器
- 因为只有服务器有私钥 X，只有它能解开
服务器用私钥 X 解密，得到了对称密钥 C
- 此时双方都拥有密钥 C
- 🔐 接下来真正用于加密 HTTP 内容的是：对称密钥 C

🎯 那为什么还需要公钥 Y？

它的唯一作用是：安全地把“对称密钥 C”送到服务器
就像你把机密装进一个「只有服务器能打开的保险箱」里，甚至你自己也打不开。

🧊 公钥和私钥的实际“生命周期”：

密钥	作用阶段	是否参与加密通信	是否长期存在
公钥 B	只在最开始传 C 时用	❌ 不用于数据加密	✅ 来自服务器证书，固定不变
私钥 A	只在解密 C 时用	❌ 不用于数据加密	✅ 安全保存于服务器内部
对称密钥 C	用于整个会话	✅ 真正加密所有数据	❌ 每次握手新生成

🧠 这么设计的好处？

非对称加密（A-B）安全但慢：只用于“传钥”
对称加密（C）速度快：用于“传数据”
✨ 两者结合，既安全又高效

✅ 在安全通信中，我们要解决三件事：

安全目标	作用
🔒 保密性	防止别人看到内容（加密）
🧾 完整性	防止别人篡改内容（消息认证）
🧑‍💼 认证性	确认身份是真实的（证书/密钥验证）