HTTPS 和 HTTP 的区别：TLS、证书和加密连接怎么建立

很多人第一次学 HTTPS，会把它想成 HTTP 的高级替代品。这样理解有一半对，一半容易跑偏。HTTPS 里的请求方法、状态码、Header、Body 这些 HTTP 语义还在，真正多出来的是 HTTP 和 TCP 之间的一层安全协议，也就是 SSL/TLS。

文中讲得很直接：HTTP 是超文本传输协议，信息以明文传输，存在安全风险；HTTPS 在 TCP 和 HTTP 之间加入 SSL/TLS 安全协议，让报文能够加密传输。所以 HTTPS 可以先理解成“HTTP + TLS”。

这篇文章不急着堆算法名。先把三个问题讲清楚：为什么 HTTP 明文不安全，TLS 帮 HTTPS 做了什么，浏览器和服务器是怎么从陌生连接变成加密通信的。

HTTP 连接建立相对简单。TCP 三次握手完成之后，就可以直接传 HTTP 请求和响应。这个过程速度快，结构清楚，但它默认没有加密。请求路径、部分参数、Header、响应内容，都可能以明文形式在网络链路上流动。

明文传输带来两个明显风险。第一是被窃听：中间链路上的攻击者可能读到账号、Token、Cookie、接口响应。第二是被篡改：攻击者可能把返回内容改掉，或者插入恶意脚本。HTTP 本身并不能证明“对面真的是我要访问的服务器”，也不能证明“数据中途没有被改过”。

所以只说“不要把密码放 URL”还不够。如果整个连接是 HTTP 明文，请求体里的敏感信息同样有风险。真正要保护传输过程，就要让 HTTP 报文进入加密通道，这就是 HTTPS 要解决的事。

TLS/SSL 的目标可以先记三件事：加密、身份验证、完整性。文中也按这三个方向解释：加密用来防止第三方截取和读取敏感信息；身份验证通过数字证书验证通信方身份；完整性通过摘要或校验机制确认数据没有被篡改。

加密解决“别人看不懂”的问题。即使网络包被截获，攻击者也只能看到加密后的数据。身份验证解决“我连的是不是正确服务器”的问题。浏览器需要确认服务器证书可信、没过期、域名匹配。完整性解决“数据有没有被中途改过”的问题。

这三件事合在一起，才是 HTTPS 的价值。只加密但不验证身份，可能连到了假的服务器；只验证身份但不保护内容，数据仍然可能泄露；只保护内容但不校验完整性，中间人仍可能尝试篡改。

HTTP 默认端口是 80，HTTPS 默认端口是 443。这个区别很基础，但排查问题时很有用。服务监听错端口、负载均衡没放行 443、防火墙策略不对，都可能导致 HTTPS 访问失败。

连接过程也不一样。HTTP 在 TCP 三次握手之后，就能开始传 HTTP 报文。HTTPS 在 TCP 三次握手之后，还要进行 TLS 握手。只有 TLS 握手完成，双方协商出安全通信所需的信息，后面的 HTTP 报文才会被加密传输。

所以 HTTPS 往往比 HTTP 多一些握手成本。现代协议和连接复用会尽量减少这部分开销，但理解问题时要知道：HTTPS 慢的不是 HTTP 语义，而是它在传输前多做了身份和密钥协商。

HTTPS 需要数字证书。文中说，HTTPS 协议需要向 CA，也就是证书权威机构，申请数字证书，用来保证服务器身份可信。证书里通常包含服务器公钥、证书颁发者、有效期、域名等信息。

浏览器拿到服务器证书后，不是看见证书就信。它会检查证书签名是否可信，证书是否过期，访问的域名是否和证书匹配。如果这些检查失败，浏览器就会给出证书错误提示。

这也是为什么 HTTPS 站点有时会出现“证书不受信任”“证书过期”“域名不匹配”。这类问题通常不是接口代码错了，而是证书链、域名、时间或部署配置出了问题。

文中把对称加密称为私钥加密：加密和解密使用同一把密钥。它的好处是速度快，适合加密大量通信数据。HTTPS 连接真正传输 HTTP 数据时，主要依赖的就是对称密钥。

问题在于，这把密钥怎么安全地让客户端和服务器都知道？如果直接把密钥明文发过去，中间人截获后就能解密后续通信。对称加密本身很适合传数据，但不适合单独解决“第一次怎么交换密钥”的问题。

所以 HTTPS 握手里需要结合非对称加密。客户端生成一个随机会话密钥，再借助服务器证书里的公钥，把会话密钥加密后发给服务器。服务器用自己的私钥解密，双方就有了同一把会话密钥。

非对称加密使用一对密钥：公钥和私钥。公钥可以公开，私钥由服务器自己保存。用公钥加密的数据，只有对应私钥才能解开。文中也提到，非对称加密除了加密和解密，还可用于数字签名，用来验证消息来源和完整性。

它的好处是解决了密钥传递问题。客户端不需要提前知道服务器私钥，只要拿到可信证书里的公钥，就可以把会话密钥安全地发过去。服务器私钥不离开服务器，外部拿不到，就无法解开这个会话密钥。

但非对称加密计算成本比对称加密高，不适合把所有 HTTP 数据都用它来加密。所以 HTTPS 通常是组合使用：握手阶段用非对称加密和证书解决身份与密钥交换，正式传输阶段用对称加密提高效率。

资料 把 HTTPS 建立连接分成七步：客户端向服务器 443 端口发起连接请求；服务器返回 CA 数字证书；客户端验证证书合法性；客户端生成随机会话密钥；客户端用服务器公钥加密会话密钥并发送；服务器用私钥解密得到会话密钥；双方用同一把会话密钥进行加密通信。

这套流程的关键不在于死背每一步，而是看懂它在解决什么问题。证书校验解决服务器身份问题；公钥加密会话密钥解决密钥传递问题；会话密钥解决后续大量数据的加密效率问题。

握手完成后，HTTP 请求和响应仍然是那些内容，只是它们被放进了加密通道里。抓包时，你能看到连接目标和部分握手信息，但看不到明文的请求体和响应体内容。

HTTPS 保护的是传输链路。它能降低窃听、篡改和中间人攻击风险，但它不能替你设计权限系统，也不能防止用户自己泄露密码，更不能让后端接口自动变安全。

比如接口没有鉴权，HTTPS 只能保证别人不容易在链路上偷看请求，但有权限的人仍然可以访问接口。再比如 XSS 把用户页面里的 Token 读走，HTTPS 也挡不住，因为攻击发生在浏览器页面内部，不是在传输链路上。

所以 HTTPS 是基础设施，不是全部安全方案。登录、鉴权、权限校验、Cookie 安全属性、CSRF 防护、输入校验、日志脱敏，这些仍然要单独设计。

如果 HTTPS 打不开，先看域名是否解析到正确 IP，再看 443 端口是否通，再看证书是否有效。证书相关错误一般可以从浏览器提示里看出方向：过期、不受信任、域名不匹配、证书链不完整。

如果浏览器提示混合内容，通常是 HTTPS 页面里加载了 HTTP 图片、脚本或接口。现代浏览器会拦截一些不安全资源，页面可能表现为样式丢失、脚本不执行或接口失败。

如果接口在 HTTP 下正常、HTTPS 下异常，要看反向代理是否正确转发协议头，比如 `X-Forwarded-Proto`，也要看后端是否根据协议、Host、Cookie 的 Secure 属性做了不同处理。HTTPS 问题不一定在 TLS 本身，也可能在网关和应用之间的协作。

可以这样理解：HTTP 是明文传输，HTTPS 在 HTTP 和 TCP 之间加入 TLS/SSL，通过证书验证服务器身份，通过非对称加密安全交换会话密钥，再用对称加密保护后续 HTTP 数据。

这句话里有三层意思。第一，HTTPS 没有改掉 HTTP 的语义。第二，证书不是摆设，它解决“服务器是谁”的问题。第三，对称加密和非对称加密不是二选一，而是在 HTTPS 里各做各的事。

把这三点讲清楚，比只背“HTTPS 更安全，端口 443”更稳。后面如果继续学 TLS 1.2、TLS 1.3、证书链、CA、SNI，就能从这条主线继续往下接。