HTTP 和 HTTPS 是 Web 通信中最基础也最重要的两个协议。它们的核心区别在于 安全性，而这个“安全”主要体现在数据传输的加密、身份认证和完整性保护上。
下面从多个维度详细对比：
🔒 1. 核心区别：是否加密
| 特性 | HTTP | HTTPS |
|---|---|---|
| 全称 | HyperText Transfer Protocol | HyperText Transfer Protocol Secure |
| 安全性 | 明文传输（不安全） | 加密传输（安全） |
| 默认端口 | 80 | 443 |
| URL 前缀 | http:// | https:// |
✅ 关键结论：HTTPS = HTTP + SSL/TLS 加密层
🔐 2. 安全机制详解（HTTPS 如何做到安全？）
HTTPS 并不是新协议，而是在 HTTP 和 TCP 之间加入了一层 SSL/TLS（安全套接层/传输层安全） 协议。
（1）加密传输（Confidentiality）
- 所有数据（包括 URL、请求头、请求体、Cookie 等）在传输前都会被对称加密。
- 即使被中间人截获，也无法直接读取内容。
（2）身份认证（Authentication）
- 服务器必须提供由可信 CA（证书颁发机构） 签发的 数字证书。
- 浏览器会验证证书：
- 是否由可信 CA 签发？
- 域名是否匹配？
- 是否在有效期内？
- 防止你访问的是“假冒网站”（如钓鱼网站）。
（3）数据完整性（Integrity）
- 使用 MAC（消息认证码） 或 HMAC 技术。
- 确保数据在传输过程中未被篡改（比如被运营商插入广告）。
🔄 3. 握手过程（为什么 HTTPS 更“慢”？）
建立 HTTPS 连接比 HTTP 多了 TLS 握手 步骤（通常 1-2 个 RTT）：
- Client Hello：客户端发起连接，发送支持的加密套件等。
- Server Hello + 证书：服务器选择加密算法，并返回自己的公钥证书。
- 客户端验证证书：检查合法性。
- 生成会话密钥：客户端用服务器公钥加密一个随机生成的对称密钥，发送给服务器。
- 双方切换到对称加密通信：后续所有数据都用这个对称密钥加解密。
⚠️ 注意：虽然首次连接有开销，但现代 TLS（如 TLS 1.3）已大幅优化，支持 0-RTT 快速重连。
🌐 4. 对 SEO 和浏览器的影响
- Google 等搜索引擎优先收录 HTTPS 网站（SEO 友好）。
- 现代浏览器（Chrome/Firefox）会将 HTTP 网站标记为“不安全”，影响用户信任。
- 某些新 Web API（如 Geolocation、Service Worker）仅在 HTTPS 下可用。
🛡️ 5. 常见误区澄清
| 误区 | 正确理解 |
|---|---|
| “HTTPS 只是加密登录密码” | ❌ HTTPS 加密所有传输内容，包括 URL、Cookie、API 数据等 |
| “用了 HTTPS 就绝对安全” | ❌ HTTPS 只保证传输安全，不能防止 XSS、CSRF、服务器被黑等 |
| “HTTPS 会让网站变很慢” | ❌ 现代硬件和协议优化下，性能差距极小，且可通过 HTTP/2 进一步提升 |
✅ 总结：一句话记住区别
HTTP 是“明信片”，谁都能看；HTTPS 是“密封挂号信”，只有收件人能拆开，且能确认寄件人身份。
如今，所有网站都应使用 HTTPS，这已成为互联网基础设施的标准配置。Let’s Encrypt 等免费 CA 的出现也让部署 HTTPS 成本几乎为零。
TLS（Transport Layer Security）中的非对称加密，主要用于安全地协商出一个双方共享的对称密钥（称为“会话密钥”），而不是直接用来加密大量数据（因为非对称加密计算开销大）。
它的核心目标是：在不安全的网络上，让客户端和服务器安全地交换信息，最终达成一个只有它们俩知道的秘密（会话密钥）。
下面以最常见的 RSA 密钥交换 为例（虽然现代 TLS 更推荐使用前向安全的 ECDHE，但 RSA 更直观），一步步解释非对称加密是如何工作的：
🔑 核心前提：公钥与私钥
- 服务器有一对密钥：
- 公钥（Public Key）：可以公开给任何人。
- 私钥（Private Key）：必须严格保密，只有服务器自己持有。
- 数学特性：用公钥加密的数据，只能用对应的私钥解密；反之亦然（用于签名）。
🤝 TLS 握手中非对称加密的流程（以 RSA 为例）
步骤 1：客户端发起连接（Client Hello）
- 客户端告诉服务器：“我想建立安全连接”，并附上自己支持的协议版本、加密套件列表等。
步骤 2：服务器响应（Server Hello + 证书）
- 服务器选择一个双方都支持的加密套件（比如
TLS_RSA_WITH_AES_128_GCM_SHA256）。 - 关键一步：服务器将自己的 数字证书 发送给客户端。
- 这个证书里包含了服务器的 公钥、域名、有效期等信息，并由可信的 CA 签名。
步骤 3：客户端验证证书
- 客户端用操作系统/浏览器内置的 CA 公钥 验证证书的真实性（防伪造）。
- 如果验证通过，就信任这个公钥确实属于目标服务器。
步骤 4：客户端生成“预主密钥”并用公钥加密
- 客户端随机生成一个 48 字节的“预主密钥”（Pre-Master Secret）。
- 用服务器的公钥加密这个预主密钥。
- 将加密后的结果发送给服务器（
Client Key Exchange消息）。
✅ 这就是非对称加密的核心应用！
步骤 5：服务器用私钥解密
- 服务器收到加密的预主密钥后，用自己的私钥解密，得到原始的预主密钥。
- 只有持有私钥的服务器才能成功解密！
步骤 6：双方独立计算“会话密钥”
- 客户端和服务器现在都拥有了相同的 预主密钥。
- 它们再结合之前握手过程中交换的随机数（Client Random + Server Random），通过相同的 PRF（伪随机函数）算法，各自独立计算出完全相同的 主密钥（Master Secret），进而派生出用于实际通信的 对称会话密钥（如 AES 密钥）。
步骤 7：切换到对称加密通信
- 从现在开始，所有应用层数据（HTTP 请求/响应）都用这个对称密钥进行加密和解密。
- 对称加密效率高，适合大量数据传输。
🛡️ 非对称加密解决了什么问题？
密钥分发问题：
- 在不安全的信道上，如何安全地把一个秘密（会话密钥）传递给对方？
- 非对称加密让客户端可以用“公开的锁”（公钥）把秘密锁起来，只有服务器有“钥匙”（私钥）能打开。
身份认证（间接）：
- 因为只有真正的服务器才有私钥，能解密预主密钥。
- 如果攻击者冒充服务器，它没有私钥，无法完成后续步骤，连接会失败。
⚠️ 重要补充：现代 TLS 更常用 ECDHE（前向安全）
虽然 RSA 流程清晰，但它有一个致命缺点：没有前向安全性（Forward Secrecy）。
- 问题：如果服务器的私钥未来被泄露，攻击者可以用它解密所有过去截获的通信记录。
- 解决方案：使用 ECDHE（椭圆曲线迪菲-赫尔曼密钥交换）。
- 客户端和服务器各自生成临时的公私钥对。
- 通过交换公钥，双方能各自独立计算出相同的共享密钥（预主密钥），而无需直接传输它。
- 即使服务器长期私钥泄露，也无法推导出过去的会话密钥（因为临时密钥用完即弃）。
- 非对称加密的作用：在 ECDHE 中，服务器的证书和私钥用于对临时公钥进行数字签名，防止中间人篡改，而非直接加密预主密钥。
✅ 总结
| 作用 | 实现方式 |
|---|---|
| 安全传递会话密钥 | 客户端用服务器公钥加密 → 服务器用私钥解密（RSA 方式） |
| 身份认证 | 通过 CA 证书验证公钥归属，确保你连的是真服务器 |
| 现代最佳实践 | 使用 ECDHE 实现前向安全，非对称加密仅用于签名验证 |
💡 简单说：非对称加密是“开门的钥匙”，对称加密是“屋里干活的工具”。TLS 先用非对称加密安全地把“工具箱钥匙”交给对方，然后双方用这把钥匙打开工具箱，拿出高效的对称加密工具来干活。