Snow.
EN
全部文章 笔记与思考

HTTP 和 HTTPS 的区别：从明文到加密，一篇讲清楚

从请求响应、明文传输、TLS 握手、证书校验、性能影响和迁移实践几个角度，系统梳理 HTTP 与 HTTPS 的区别。

约 3 分钟
Read in English

HTTP 和 HTTPS 的区别：从明文到加密，一篇讲清楚

HTTP 和 HTTPS 的核心区别不是“能不能打开网页”，而是：网页数据在网络上传输时，是否有加密、身份认证和完整性保护。

HTTP 与 HTTPS 的整体区别

一句话先记住：

HTTPS = HTTP + TLS。

也就是说，HTTPS 并没有推翻 HTTP 的请求方法、状态码、Header、Cookie、缓存这些机制。它是在 HTTP 通信外面加了一层 TLS 安全通道，让浏览器和服务器先建立可信、加密的连接，然后再传 HTTP 数据。

先看最直接的区别

对比项 HTTP HTTPS
URL 前缀 http:// https://
默认端口 80 443
传输内容 明文 经过 TLS 加密
身份认证 无法证明服务器真实身份 通过证书证明服务器身份
完整性保护 容易被中间人篡改 篡改会被发现
浏览器提示 常显示“不安全” 显示安全连接标识
适合场景 本地开发、临时内网测试 生产网站、登录、支付、接口、后台系统

很多初学者会把 HTTPS 理解成“高级版 HTTP”。这个说法不算错，但更准确的理解是：HTTP 负责表达网页请求和响应，TLS 负责保护这段通信过程。

HTTP 做了什么

HTTP，全称是 HyperText Transfer Protocol，超文本传输协议。它定义了浏览器和服务器之间如何对话。

例如你访问一个页面时，浏览器可能会发出这样的请求：

1
2
3
4

GET /articles/http-vs-https HTTP/1.1
Host: example.com
User-Agent: Chrome
Accept: text/html

服务器再返回：

1
2
3
4
5
6

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

<html>
  <body>Hello HTTPS</body>
</html>

这套格式本身没有问题。HTTP 的价值在于简单、通用、可扩展，Web 上的请求方法、状态码、Header、Cookie、缓存控制，都是它的核心组成部分。

问题在于：如果只使用 HTTP，这些内容会以明文形式经过网络。

明文传输为什么危险

假设你在咖啡店 Wi-Fi 下登录一个只支持 HTTP 的网站，你输入的用户名、Cookie、请求路径和响应内容，都可能被同一网络里的攻击者看到。如果攻击者进一步做中间人攻击，还可能把服务器返回给你的页面内容替换掉。

HTTP 明文与 HTTPS 密文的区别

HTTP 明文带来的典型风险有三个：

风险 含义 例子
窃听 第三方可以读到传输内容 看到登录表单、Cookie、接口返回
篡改 第三方可以修改传输内容 注入广告、替换下载链接、改写脚本
冒充 用户无法确认对面是不是真服务器 被引导到伪造服务器却不容易察觉

所以，HTTP 最大的问题不是“协议设计得不好”，而是它默认不解决安全传输问题。

HTTPS 加上的 TLS 是什么

TLS，全称是 Transport Layer Security，传输层安全协议。HTTPS 使用 TLS 在浏览器和服务器之间建立安全通道。

TLS 主要提供三件事：

能力 解决的问题 可以怎么理解
加密 防止第三方看懂内容 即使抓到数据包，也只能看到密文
身份认证 防止连到假服务器 浏览器会检查服务器证书是否可信
完整性校验 防止内容被偷偷改掉 数据一旦被篡改，校验会失败

因此，HTTPS 传的仍然是 HTTP 请求和响应，只是这些 HTTP 数据会先被 TLS 加密，再放到网络里传输。

TLS 握手大致怎么发生

在浏览器真正发送 HTTP 请求之前，HTTPS 会先进行 TLS 握手。握手的目的不是传业务数据，而是完成几件关键准备：

  1. 双方确认使用哪个 TLS 版本和加密算法。
  2. 浏览器验证服务器证书。
  3. 浏览器和服务器协商出后续通信使用的会话密钥。
  4. 握手完成后，HTTP 请求和响应都走加密通道。

HTTPS 建连时 TLS 握手的简化流程

可以把这个过程理解成：

两个人先确认对方身份，再商量一个只有双方知道的临时密码。之后真正聊天时，所有内容都用这个临时密码加密。

现代 HTTPS 通常使用 TLS 1.2 或 TLS 1.3。TLS 1.3 对握手流程做了简化，配合会话恢复、HTTP/2、HTTP/3 和 CDN，HTTPS 的性能成本已经远小于早期印象里的“很慢”。

证书到底证明了什么

很多人看到浏览器地址栏里的安全标识，会下意识理解成“这个网站一定是好网站”。这其实是误解。

HTTPS 证书主要证明的是：

你当前连接到的服务器，确实拥有这个域名对应证书中的私钥，并且这个证书能沿着可信 CA 链被浏览器验证。

它不保证网站内容一定真实、商家一定可靠、业务一定没有漏洞。钓鱼网站同样可以申请 HTTPS 证书，所以 HTTPS 只能说明“连接安全”，不能说明“网站本身可信”。

HTTPS 证书信任链和浏览器校验过程

浏览器通常会检查这些内容：

检查项 为什么重要
域名是否匹配 example.com 的证书不能拿去冒充 bank.com
证书是否过期 过期证书不应继续被信任
签名链是否可信 证书需要能追溯到浏览器信任的根 CA
证书是否被吊销 泄露或失效的证书应被拒绝

通过这些检查后，浏览器才会继续完成 TLS 握手，并把连接标记为安全。

HTTP 和 HTTPS 的关键差异

从开发和运维角度看，最值得关注的是下面这些差异。

维度 HTTP HTTPS
安全性 无加密、无认证、无完整性保护 有加密、认证和完整性保护
请求格式 HTTP 方法、Header、Body 逻辑上仍是 HTTP 方法、Header、Body
传输层 通常直接跑在 TCP 上 HTTP 先进入 TLS，再跑在 TCP 或 QUIC 上
证书 不需要证书 需要有效 TLS 证书
端口 默认 80 默认 443
SEO 和浏览器策略 搜索和浏览器体验不友好 更符合现代 Web 默认要求
Web 能力 一些能力受限 Service Worker、地理位置、剪贴板等能力通常要求安全上下文
迁移成本 配置简单 需要证书、跳转、混合内容修复和监控

这里有一个容易忽略的点：HTTPS 不会改变 HTTP 的语义。

GET 还是 GET，POST 还是 POST，404 还是 404，Cookie 还是 Cookie。它改变的是这些数据穿过网络时的保护方式。

HTTPS 会不会更慢

早期 HTTPS 的确会带来明显额外开销，因为 TLS 握手需要额外往返，还要做加解密。但今天不能简单地说“HTTPS 一定慢”。

原因主要有几个：

  1. TLS 1.3 减少了握手成本：建立连接需要的往返次数更少。
  2. 会话恢复可以复用安全参数：老用户再次访问时不必完整握手。
  3. HTTP/2 和 HTTP/3 改善了传输效率：多路复用减少了大量小请求的阻塞。
  4. 硬件和软件加密性能已经很高：常见服务器处理 TLS 的成本通常不是主要瓶颈。
  5. CDN 可以承担 TLS 终止：证书、握手和边缘节点优化可以由 CDN 处理。

更实际的结论是：

对现代生产网站来说，HTTPS 的安全收益远大于额外成本。性能优化应该建立在 HTTPS 之上，而不是为了省一点握手成本退回 HTTP。

HTTPS 能保护什么，保护不了什么

HTTPS 很重要，但不要把它当成万能安全方案。

问题 HTTPS 能否解决 说明
第三方读取请求路径、Cookie、请求体 能 这些内容会被 TLS 加密
第三方篡改页面、脚本、接口响应 能 篡改通常会导致校验失败
证明服务器身份 能 前提是证书链和域名校验通过
隐藏访问的网站 IP 不能 IP 层仍需要知道连接到哪里
完全隐藏访问域名 不一定 DNS、SNI 等环节在不同配置下可能暴露域名信息
防止网站自身泄露数据 不能 服务端漏洞、日志泄露、数据库泄露仍需单独治理
防止用户访问钓鱼网站 不能完全防止 钓鱼网站也可以有 HTTPS 证书

因此，HTTPS 是 Web 安全的地基，但不是整栋楼。登录鉴权、权限控制、输入校验、XSS 防护、CSRF 防护、日志脱敏、密钥管理，这些仍然要单独做好。

从 HTTP 迁移到 HTTPS

给网站加 HTTPS，不只是把证书装上去。生产环境里，最常见的问题反而出在跳转、混合内容和缓存策略上。

从 HTTP 迁移到 HTTPS 的关键步骤

一个比较稳妥的迁移清单如下：

步骤 要做什么 常见坑
申请证书 使用 Let’s Encrypt、云厂商证书或企业 CA 忘记配置自动续期
配置 HTTPS 站点 监听 443，并绑定证书和私钥 证书链不完整
HTTP 跳转 HTTPS 80 端口统一 301 到 443 跳转循环、代理头配置错误
修复混合内容 页面里的图片、脚本、接口都改成 HTTPS 浏览器拦截 http:// 脚本和接口
设置 Cookie 属性 登录 Cookie 加 Secure、HttpOnly、SameSite HTTPS 下 Cookie 策略不一致
谨慎开启 HSTS 确认全站和子域名都支持 HTTPS 后再开启 一旦配置过猛，回滚会很麻烦
更新外部入口 CDN、反向代理、站点地图、canonical、监控 搜索引擎和监控还在访问旧地址

Nginx 里一个非常简化的跳转配置类似这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

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

    ssl_certificate /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass http://app;
    }
}

真实线上配置还要结合负载均衡、CDN 回源、证书续期、日志、监控、灰度和回滚策略一起看。

常见误区

误区一：HTTPS 网站一定安全。

不对。HTTPS 只能说明连接被加密且证书校验通过，网站是否有漏洞、业务是否可信，是另一回事。

误区二：有 HTTPS 就不会泄露任何信息。

不对。HTTPS 保护的是应用层内容，但 IP 地址、流量大小、访问时间等元数据仍可能被观察到。域名是否暴露还取决于 DNS、SNI、ECH、代理等具体配置。

误区三：接口在内网就不用 HTTPS。

不一定。内网也可能有越权访问、旁路抓包、错误代理、日志泄露等风险。涉及账号、Token、用户数据、后台管理的接口，即使在内网也建议使用 HTTPS 或等价的传输层保护。

误区四：HTTPS 配好一次就结束。

不对。证书会过期，TLS 配置会老化，依赖的加密套件也可能不再推荐。证书续期、过期告警和安全扫描都应该纳入运维流程。

总结

HTTP 和 HTTPS 的关系可以用三句话收束：

  1. HTTP 负责“怎么表达请求和响应”，例如方法、状态码、Header、Body。
  2. HTTPS 负责“安全地传这些 HTTP 数据”，核心靠 TLS 提供加密、认证和完整性保护。
  3. 生产环境默认应该使用 HTTPS，HTTP 最多作为跳转入口，或者用于受控的本地开发和临时测试。

所以，下次再看到 http:// 和 https://，不要只把它们当成 URL 前缀的差异。真正的区别在于：你的数据是裸奔在网络里，还是走在一条经过身份校验和加密保护的通道里。