HTTP 与 HTTPS 有什么区别？

核心回答

HTTPS 是使用 TLS 保护的 HTTP 通信。 HTTP 定义请求方法、状态码、头字段等应用层语义；TLS 为通信增加机密性、完整性和对端身份认证。

普通明文 HTTP 中，链路上的攻击者可能读取内容、修改报文或冒充服务端。HTTPS 在正确验证证书、使用安全协议配置的前提下，可以保护传输中的 HTTP 请求和响应，并确认连接的服务端是否有权代表目标域名。常见网站主要认证服务端，需要时也可以通过双向 TLS 认证客户端。

两者还有这些常见区别：

• 地址与默认端口：使用 http:// 和 https://，默认端口分别为 80 和 443；显式配置其他端口也可以使用相应协议。
• 连接建立：HTTPS 需要建立安全连接，包含算法协商、身份认证和密钥建立，带来一定的握手、证书与计算开销；连接复用、会话恢复可以摊薄这些成本。
• 传输方式：HTTP/1.1、HTTP/2 的常见 HTTPS 部署使用 TCP 上的 TLS；HTTP/3 使用基于 UDP 的 QUIC，并把 TLS 1.3 集成为安全组件，不能把 HTTPS 永远限定成 TCP 上的一层 TLS。

HTTPS 如何同时做到加密和身份认证？

可以把首次使用证书的握手理解成三个任务：协商参数、证明身份、建立双方的流量密钥。下面以常见的 TLS 1.3 证书认证和 ECDHE 密钥协商为例：

1. 客户端与服务端交换支持的参数和临时密钥协商信息，选择协议与算法，分别计算共享秘密，并从中派生密钥。
2. 服务端提供证书链，并通过握手签名证明自己持有对应私钥。客户端验证信任链、目标主机名、有效期等条件，还要验证握手中的证明；拿到一张证书本身并不足以建立可信连接。
3. 双方确认握手结果，使用派生出的对称流量密钥保护后续数据。TLS 1.3 使用 AES-GCM、ChaCha20-Poly1305 等认证加密算法，同时提供内容保密和篡改检测。

这里有几组概念不能混淆：证书绑定身份与公钥，数字签名用于证明和验证，ECDHE 用于密钥协商，对称密码用于高效保护大量数据。不是所有 HTTPS 都把一把随机密钥用证书公钥加密发送；那是旧式 RSA 密钥传输的思路，TLS 1.3 已移除这种方式，会话恢复还可能使用预共享密钥。

用登录请求举例

如果用户名、密码通过明文 HTTP 提交，能观察该链路的人可能直接读到这些字段。改用 HTTPS 后，请求路径、头和请求体都受到安全连接的保护，链路攻击者不能像读取明文报文那样读取这些内容，也不能修改后还让完整性校验正常通过。

保护范围也有边界：通信端点仍能看到明文，IP 地址、流量长度和时序等信息并不会全部隐藏。如果 TLS 在网关终止，那么网关就是这一段安全连接的端点，网关到后端是否加密，需要单独配置。HTTPS 也不会自动修复越权、SQL 注入或服务端泄露。

常见追问

为什么只有加密还不够？

如果没有可靠的身份认证，攻击者可能替换公钥，与两端分别建立加密连接，再转发和修改数据。客户端必须确认自己协商密钥的对象确实对应目标服务，不能把“链路加密了”等同于“对端可信”。

HTTPS 一定比 HTTP 慢很多吗？

不能只按协议名称判断。首次建立安全连接有成本，但总耗时还取决于网络往返、TLS 版本、连接是否复用、会话是否恢复和应用处理时间。不同 HTTP 版本也会影响结果，应在相同业务与网络条件下比较，不能给固定倍数。0-RTT 也有适用条件和重放风险，不能把它当作所有请求都能使用的免费加速。

参考资料