HTTP vs HTTPS：从明文到加密的演进与必要性

1. HTTP 协议的发展历程

HTTP/0.9（1991）— 最初的简单版本

HTTP 协议由蒂姆·伯纳斯·李（Tim Berners-Lee）在 1991 年创建，用于在万维网上传输超文本文档。HTTP/0.9 是最初版本，极其简单：只支持 GET 方法，没有请求头，没有持久连接。每个 HTTP 请求都是明文的，任何人都可以轻易截获和阅读。在那个时代，互联网主要用于学术和政府机构之间的信息共享，安全不是首要考虑。

HTTP/1.0（1996）— 功能扩展

1996 年的 HTTP/1.0 引入了请求头、响应头、状态码、POST 方法和多种内容类型支持。这个版本开启了现代网络的序幕，允许浏览器和服务器之间更灵活的通信。然而，每个请求仍需建立新的 TCP 连接，效率低下。明文传输的问题开始凸显——电子商务的兴起让数据安全成为必要。

HTTP/1.1（1997）— 持久连接与标准化

HTTP/1.1 在 1997 年推出，引入了持久连接（Keep-Alive）、管道化、Host 头、缓存机制等关键特性。这个版本统治了网络 20 年，仍是许多系统的基础。但 HTTP/1.1 的明文特性依然保留，HTTPS（HTTP + SSL/TLS）的需求日益迫切。

HTTP/2（2015）— 多路复用

HTTP/2 在 2015 年标准化，基于 Google 的 SPDY 协议。它引入了二进制分帧、多路复用（在单个连接上并行传输多个请求）、头部压缩等优化。HTTP/2 可以通过 HTTP 或 HTTPS 传输，但大多数浏览器仅在 HTTPS 上支持 HTTP/2，进一步推动了 HTTPS 的普及。

HTTP/3（2022 稳定）— QUIC 协议

HTTP/3 基于 QUIC 协议（由 Google 开发），完全基于 UDP 而非 TCP。QUIC 内置了 TLS 1.3 加密，改进了握手延迟和丢包恢复。HTTP/3 天生强制加密，进一步巩固了 HTTPS 的地位。

2. HTTPS 与 TLS 加密原理

HTTPS = HTTP + TLS/SSL

HTTPS（HTTP Secure）就是在 HTTP 协议的基础上加入了 TLS（Transport Layer Security）加密层。TLS 是 SSL（Secure Sockets Layer）的现代继承者，提供了三个关键安全特性：

• 保密性（Confidentiality） — 通过加密确保第三方无法读取通信内容
• 完整性（Integrity） — 通过消息认证码（MAC）确保数据未被篡改
• 身份验证（Authentication） — 通过数字证书确保服务器身份真实

TLS 握手过程

TLS 握手是 HTTPS 连接的第一步，通常分为以下阶段：

在 TLS 1.2 中，握手需要 2 个往返时间（RTT）。TLS 1.3 优化了这个过程，只需 1 个 RTT，甚至支持 0-RTT 恢复（用于已建立过连接的客户端）。

非对称 vs 对称加密

TLS 混合了两种加密方式：

• 非对称加密（RSA、ECDHE） — 握手时用公钥加密，只有私钥持有者能解密。用于密钥交换和身份验证。
• 对称加密（AES、ChaCha20） — 握手后双方共享一个密钥，用于加密实际的 HTTP 数据。速度更快。

这种组合充分利用了两者的优点：非对称加密解决密钥分配问题，对称加密提供高效的数据传输。

数字证书与证书链

服务器在握手时向客户端出示数字证书，证明自己的身份。证书由受信的证书颁发机构（CA）签发，包含服务器的公钥、域名和 CA 的数字签名。

浏览器维护一份根 CA 证书列表（Root Certificates），可以验证任何由这些 CA 签发的证书的有效性。大多数证书形成一条链：

根证书 → 中间证书 → 叶子证书（服务器证书）

3. 浏览器安全标准的演变

Chrome 的"不安全"标记（2018）

2018 年，Google Chrome 开始在地址栏显示"不安全"警告，标记任何 HTTP 网站（未使用 HTTPS 的网站）。这个决策看似激进，但具有深远意义：

• 明确告知用户他们的数据在明文传输
• 给网站所有者压力，促进全网 HTTPS 迁移
• 成为业界标准，其他浏览器随之跟进

今天，大多数浏览器对 HTTP 网站都有某种形式的警告。Firefox、Safari、Edge 都采取了类似的立场。

强制 HTTPS 的范围扩展

Chrome 的强制 HTTPS 政策不仅限于地址栏警告。随着时间推移，更多特性被限制在 HTTPS：

• Geolocation API — 需要 HTTPS 或 localhost
• Microphone/Camera 权限 — HTTPS only
• Service Workers — 强制 HTTPS（除 localhost）
• Payment Request API — 强制 HTTPS
• Web Crypto API — 某些操作需要安全上下文

这种分层的强制策略确保了高风险功能始终运行在加密连接上。

4. HTTPS 对 SEO 的影响

HTTPS 作为排名因素

2014 年，Google 官方宣布 HTTPS 是排名信号。虽然权重相对较小，但作为一个长期优化信号，HTTPS 网站获得微弱的排名优势。更重要的是，HTTPS 是现代网络的默认标准——不迁移到 HTTPS 会逐步失去竞争力。

转移 HTTP 流量的正确方法

如果网站从 HTTP 迁移到 HTTPS，必须正确处理转向，避免丢失 SEO 权重：

• 使用 301（永久重定向）或 308 从 HTTP 重定向到 HTTPS
• 在 Google Search Console 中验证新的 HTTPS 版本
• 更新 sitemap.xml 中的 URL 为 HTTPS
• 在爬虫规则（robots.txt）中指向 HTTPS 版本
• 监控 Google Search Console 的覆盖率报告，确保迁移平稳

用户信任与转化率

除了搜索排名，HTTPS 对用户行为有直接影响。用户看到地址栏的锁形图标（表示安全连接）时，信任度提高。特别是对于电商网站、登录页面和支付页面，HTTPS 能显著提升转化率。用户更愿意在看似"安全"的网站上输入敏感信息。

5. Let's Encrypt 与证书民主化

证书成本的历史

在 2016 年之前，SSL 证书通常需要付费。一张域名证书每年需要 $50-$200，通配符证书更贵。这对小网站、个人项目和非营利组织造成了障碍。证书成本变成了部分网站拒绝采用 HTTPS 的借口。

Let's Encrypt 的出现（2016）

Let's Encrypt 是一个非营利认证机构（CA），于 2016 年推出免费的自动化证书颁发服务。其使命很清晰：让 HTTPS 成为互联网标准，而不是特权。

• 完全免费 — 无需支付任何费用
• 自动化 — 通过 ACME 协议自动化证书颁发和续期
• 证书有效期短 — 通常只有 90 天，鼓励自动化
• 广泛支持 — 所有主流浏览器都信任 Let's Encrypt 颁发的证书

Let's Encrypt 的安全性

Let's Encrypt 颁发的证书在加密强度上与付费 CA 完全等同，都使用 2048 位或 4096 位 RSA，或更现代的椭圆曲线（ECDSA）。区别在于验证级别：

• DV（Domain Validation） — 只验证域名所有权，Let's Encrypt 属于这一类
• OV（Organization Validation） — 还需验证组织身份，付费 CA 提供
• EV（Extended Validation） — 最高级别，包括法律验证，提供更多用户信任指标

对于大多数网站，DV 证书足够。EV 证书的额外验证对安全没有实质帮助，更多是品牌和信任的表现。

Let's Encrypt 的影响

Let's Encrypt 的出现加速了全球 HTTPS 普及。根据 SSL Labs 的数据，HTTPS 网站的比例从 2016 年的约 30% 增长到 2024 年的 95% 以上。Let's Encrypt 不仅提供免费证书，其自动化框架（Certbot、acme.sh 等）让续期变得无需手动干预，进一步降低了维护成本。

6. HSTS：强制 HTTPS 的安全头

HTTPS Stripping 攻击

即使网站采用了 HTTPS，仍存在一个弱点：攻击者可以拦截用户的初始请求。当用户在浏览器中输入 "example.com" 而非 "https://example.com" 时，浏览器先发送 HTTP 请求。攻击者可以在此时进行中间人攻击（MITM），将 HTTPS 请求降级为 HTTP，用户浑然不觉。

HSTS 的工作机制

HSTS（HTTP Strict-Transport-Security）是一个 HTTP 响应头，告诉浏览器："未来 N 秒内，所有访问这个域名的请求都必须使用 HTTPS。" 一旦浏览器收到 HSTS 头，它会记住这个规则，在指定的时间内自动将任何 HTTP 请求升级为 HTTPS。

参数解释：

• max-age=31536000 — 持续 1 年（31536000 秒）
• includeSubDomains — 规则也应用于所有子域名
• preload — 申请列入浏览器预加载列表（preload list），甚至第一次访问也强制 HTTPS

HSTS 预加载列表

HSTS 预加载列表是由 Google 维护的一个列表，包含数万个域名，要求浏览器对这些域名始终使用 HTTPS，即使是第一次访问也不例外。网站可以在 hstspreload.org 申请加入。

一旦列入预加载列表，该域名和所有子域名都被强制 HTTPS。这提供了最高级别的保护，但也意味着一旦列入，想要移除也需要时间（浏览器要更新列表）。

7. HTTP/3 与 QUIC 的未来

QUIC 协议简介

QUIC（Quick UDP Internet Connection）是 Google 在 2012 年开发的传输层协议，目标是改进 TCP/TLS 的性能和可靠性。与 TCP 不同，QUIC 基于 UDP，但在应用层重新实现了可靠性和流控制。关键特性包括：

• 0-RTT 握手 — 已连接过的客户端无需额外延迟即可发送应用数据
• 多路复用 — 无队头阻塞（Head-of-Line Blocking），一个数据包丢失不会影响其他流
• 连接迁移 — 客户端切换网络（如从 WiFi 到 4G）时无需重新连接
• 内置加密 — TLS 1.3 加密集成在 QUIC 本身

HTTP/3 的加密强制

HTTP/3 是基于 QUIC 的 HTTP 协议版本，于 2022 年正式标准化。不同于 HTTP/1.1 和 HTTP/2 可以通过 HTTP（明文）或 HTTPS（加密）传输，HTTP/3 天生强制加密。这意味着：

• 没有 HTTP/3 over 明文 UDP 的概念
• 所有 HTTP/3 连接都是加密的
• 进一步巩固了 HTTPS 作为网络标准的地位

浏览器支持状况

截至 2026 年，主流浏览器都支持 HTTP/3：Chrome、Firefox、Safari、Edge 都已默认启用。许多 CDN（如 Cloudflare、Fastly）和大型网站（Google、Facebook、Netflix）也已启用 HTTP/3。虽然占流量的比例仍在 10-30% 范围（因用户和设备差异），但增长势头明显。

8. 抓包工具演示：HTTP vs HTTPS

使用 Wireshark 观察 HTTP

当使用 HTTP 访问网站时，抓包工具（如 Wireshark）可以完整地捕获数据包。例如，在 HTTP 请求中：

所有信息——请求头、Cookie、Authorization Token——都以明文形式出现在网络上。任何在同一网络（公共 WiFi、运营商网络）的人都可以轻易读取。攻击者可以：

• 盗取 Session Cookie，冒充用户
• 获取 API Token，执行未授权操作
• 监视用户浏览的页面和访问的数据
• 修改服务器响应（中间人攻击），注入恶意脚本

使用 Wireshark 观察 HTTPS

当使用 HTTPS 访问同一网站时，抓包结果完全不同。即使捕获了数据包，也只能看到加密的数据流：

攻击者只能看到：

• TLS 握手过程（客户端、服务器、证书交换）
• 数据包的大小和方向
• 域名（通过 SNI — Server Name Indication 可见，但也可通过 ESNI 隐藏）
• 无法看到具体内容

实践建议

如果想体验这种差异，可以：

1. 下载并安装 Wireshark（免费，开源）
2. 启动数据包捕获
3. 访问某个 HTTP 网站，观察明文数据包
4. 访问对应的 HTTPS 网站，观察加密数据流
5. 注意浏览器地址栏的差异（绿色锁形 vs 感叹号）

这个实验强烈展示了为什么 HTTPS 是必要的。

9. 移动应用 ATS 强制 HTTPS

App Transport Security（ATS）简介

Apple 在 iOS 9（2015 年）引入了 App Transport Security（ATS）。ATS 是一种安全政策，默认情况下强制所有网络连接使用 HTTPS 和现代 TLS 版本。任何违反 ATS 要求的连接都会被阻止，除非应用在 Info.plist 中显式豁免。

ATS 的要求

连接必须满足：

• 使用 HTTPS（TLS 1.2 或更高）
• 证书必须有效且来自受信 CA
• 禁用弱加密套件（如 MD5、RC4）
• 支持前向保密（Forward Secrecy）— 使用 ECDHE 等现代密钥交换
• 不允许自签名或过期证书

Google Play 的政策

Google Play 虽然没有像 Apple ATS 那样强制的系统级限制，但自 2017 年起要求所有新应用使用 HTTPS。2020 年，Google 进一步要求所有更新的应用都必须目标 API Level 29+，这实际上强制了现代的安全实践。Android 9（API Level 28）及以上默认禁用明文流量。

开发者的影响

对移动应用开发者来说，这意味着：

• 后端 API 必须使用 HTTPS
• 不能使用自签名证书（除非在 Info.plist 中豁免，但 App Store 审核严格）
• 第三方 API 集成也必须使用 HTTPS
• 开发/测试环境应该设置合适的 ATS 异常处理

这些政策加强了 HTTPS 在整个移动生态中的地位，用户的数据安全得到了更系统的保护。