HTTP 和 HTTPS 的区别

zhangyuguai2026/3/16大约 18 分钟约 5267 字

一、先说结论

很多人会用一句话概括：

HTTPS 就是在 HTTP 和 TCP 之间加了一层 TLS/SSL。

这句话方向没错，但如果只记这一句，其实还是不够。因为面试官真正想听到的，通常不是“多了一层加密”，而是下面这些点：

HTTP 和 HTTPS 在本质上到底是什么关系
HTTPS 具体比 HTTP 多解决了哪些安全问题
HTTPS 的证书到底在验证什么
HTTPS 是否意味着内容绝对安全
HTTPS 为什么会更安全，但现代浏览器又几乎都在强推它

如果把答案压缩成一句更完整的话：

HTTP 是明文传输的应用层协议；HTTPS 不是新语义协议，而是让 HTTP 运行在 TLS 之上，从而提供加密、完整性校验和身份认证能力。

二、HTTP 和 HTTPS 的本质关系

1. HTTP 是什么

HTTP，HyperText Transfer Protocol，超文本传输协议，是应用层协议。它规定了：

客户端如何发请求
服务端如何回响应
请求行、状态行、请求头、响应头、消息体如何组织

它关注的是“应用数据怎么表达和交换”，并不负责“数据在传输过程中是否被窃听、篡改、伪装”。

2. HTTPS 是什么

HTTPS，HyperText Transfer Protocol Secure，可以理解成：

HTTP 的语义
加上 TLS 的安全能力

所以 HTTPS 并不是把 HTTP 推翻重做了，而是：

请求方法还是 GET、POST
状态码还是 200、404
Header、Body 的组织方式本质上还是 HTTP 那套

变化在于，这些 HTTP 数据在真正上传输前，会先经过 TLS 加密保护。

3. 协议分层关系

可以用下面这张图理解：

HTTP:
应用层：HTTP
传输层：TCP
网络层：IP

HTTPS:
应用层：HTTP
安全层：TLS
传输层：TCP
网络层：IP

如果进一步对应到现代协议栈：

HTTP/1.1 + TLS + TCP = 常见 HTTPS
HTTP/2 + TLS + TCP = 现代浏览器常见 HTTPS
HTTP/3 + QUIC(TLS 1.3) + UDP = 新一代 HTTPS 体验

所以 HTTPS 的重点不是“换了 HTTP”，而是“给 HTTP 加了安全传输能力”。

三、HTTP 和 HTTPS 的核心区别总览

先看一张总表，再展开细讲。

维度	HTTP	HTTPS
全称	HyperText Transfer Protocol	HyperText Transfer Protocol Secure
默认端口	80	443
传输方式	明文	密文传输
安全层	无	TLS/SSL
是否能防窃听	不能	能，大幅降低被中间人直接读懂内容的可能
是否能防篡改	不能	能，通过完整性校验发现篡改
是否能验证身份	不能	能，通过证书验证服务端身份
证书要求	不需要	通常需要 CA 签发证书
性能开销	更低	有握手和加解密开销，但现代代价已显著降低
浏览器信任提示	可能提示不安全	显示锁标识或安全连接
SEO 和浏览器支持	较弱	更友好

上面这张表里，真正最核心的其实只有三点：

加密
完整性
身份认证

这三点正好对应 HTTPS 解决的三类问题。

四、HTTP 为什么不安全

要理解 HTTPS，最好的方式不是先看它怎么加密，而是先看 HTTP 的问题到底出在哪里。

1. HTTP 是明文传输

HTTP 请求和响应默认是明文的。也就是说，如果有人处在你的通信链路中间，比如：

公共 Wi-Fi 的运营者
局域网中的恶意设备
被劫持的路由器
不可信代理节点

那么它就有机会直接看到你的 HTTP 数据内容。

例如一个 HTTP 请求：

POST /login HTTP/1.1
Host: example.com
Content-Type: application/json

{"username":"alice","password":"123456"}

如果这是纯 HTTP，那么中间节点理论上就可以直接读到账号密码。

2. HTTP 数据很容易被篡改

HTTP 没有内建的加密和完整性保护，因此中间人不仅能看，还可能改。

例如：

把网页里的下载链接换成木马地址
在页面中注入广告脚本
修改接口返回内容
将正常跳转改到钓鱼网站

这也是早年很多公共网络劫持广告、运营商插入脚本的技术基础。

3. HTTP 不能验证对方身份

客户端发起 HTTP 请求时，无法严格确认自己连接的服务器到底是不是目标服务器。

也就是说：

你以为自己访问的是银行官网
实际可能是一个伪造页面

只要 DNS 被污染、网络被劫持、链路中有人中间代理，HTTP 自身并没有可靠机制证明“对面就是你想访问的那台服务器”。

4. HTTP 无法防中间人攻击

HTTP 场景下，中间人可以很轻松地：

截获请求
查看内容
修改内容
再转发给真正服务器

客户端和服务器甚至都可能感觉“流程没问题”，但实际上通信已经被偷偷代理和操控了。

五、HTTPS 到底多做了什么

HTTPS 的核心目标，就是针对 HTTP 的三个痛点补上能力：

防窃听
防篡改
防伪装

这三个目标对应 TLS 提供的三种能力。

1. 加密性：防窃听

HTTPS 会在真正发送 HTTP 数据前，通过 TLS 协商出一组会话密钥。后续客户端和服务端传输的数据，会用这组密钥进行对称加密。

这样即使中间人截获了报文，也只能看到一堆看不懂的密文，而不是原始的请求头、Cookie、表单内容、接口响应。

这就是 HTTPS 最直观的收益。

2. 完整性：防篡改

TLS 不只是“加密一下”，它还会对传输数据做完整性保护。也就是说，接收方可以验证：

数据是否在传输过程中被改过
密文是否被拼接、替换、重放或伪造

如果发现报文被篡改，TLS 校验会失败，连接可能直接中断，而不是把错误数据静默交给应用层。

3. 认证性：防伪装

HTTPS 中服务端一般会提供数字证书，客户端会验证：

证书是不是受信任机构签发的
证书是不是给当前域名用的
证书是否在有效期内
证书是否已被吊销或存在风险

只有通过这些校验，浏览器才会认为“你连到的很大概率真的是目标站点，而不是伪造站点”。

这一点非常重要，因为：

加密只能保证“别人看不懂”，认证才能保证“我没连错人”。

六、HTTPS 不是什么

很多人学到这里会产生一个误区：以为用了 HTTPS，所有安全问题都没了。其实远远不是。

HTTPS 解决的是传输链路安全，不是所有安全问题。

1. HTTPS 不等于网站本身安全

一个网站即使部署了 HTTPS，也仍然可能：

本身就是钓鱼网站
后端代码有漏洞
存在 SQL 注入、XSS、CSRF
泄露用户数据

HTTPS 只能说明“你和它之间的通信更安全”，不代表“这个网站值得信任”。

2. HTTPS 不等于完全匿名

HTTPS 能保护很多内容，但并不会隐藏所有元信息。例如通常仍可能暴露：

目标 IP 地址
你在访问哪个域名的一部分线索
通信时间、流量大小、连接次数

传统场景下，DNS 查询本身如果没有进一步保护，也可能是明文的。

所以 HTTPS 主要保护的是通信内容，而不是彻底隐藏你的网络行为痕迹。

3. HTTPS 不能防客户端中毒

如果用户电脑本身已经中了木马，或者浏览器插件本身就是恶意的，那么：

数据在加密前就可能被偷走
或者在解密后被窃取

HTTPS 保护的是“链路中间”的风险，不是“端点自己出问题”的风险。

七、HTTP 和 HTTPS 的通信流程区别

这一部分是最适合真正理解两者差异的地方。

1. HTTP 的访问流程

访问一个普通 HTTP 网站，简化后流程大致是：

浏览器解析 URL
通过 DNS 查询域名对应 IP
与服务器建立 TCP 连接
直接发送 HTTP 请求
服务端返回 HTTP 响应
浏览器解析页面内容

你会发现，这里面没有任何“身份校验”和“加密协商”步骤。

2. HTTPS 的访问流程

访问 HTTPS 网站，流程会多出一个关键阶段：TLS 握手。

简化后流程大致是：

浏览器解析 URL
通过 DNS 查询域名对应 IP
与服务器建立 TCP 连接
开始 TLS 握手
服务端返回证书
客户端校验证书合法性
双方协商加密算法并生成会话密钥
TLS 握手完成后，才开始真正发送 HTTP 请求
服务端返回加密后的 HTTP 响应
浏览器解密并渲染内容

最核心的区别就在第 4 到第 8 步。

3. HTTP 与 HTTPS 流程对比图

HTTP:
DNS -> TCP 三次握手 -> HTTP 明文请求/响应

HTTPS:
DNS -> TCP 三次握手 -> TLS 握手 -> HTTP 密文请求/响应

如果是 HTTP/3，那么会进一步变成：

DNS -> QUIC/TLS 建连 -> HTTP/3 密文请求/响应

八、TLS 握手到底在做什么

很多人知道“HTTPS 比 HTTP 多了 TLS”，但不知道 TLS 握手到底在忙什么。实际上它主要在做四件事：

协商协议版本
协商加密套件
验证服务端身份
生成后续通信使用的会话密钥

1. 客户端发起问候

客户端会发送 ClientHello，告诉服务端：

我支持哪些 TLS 版本
我支持哪些加密套件
我生成了一个随机数
我这次要访问的域名信息
我是否支持某些扩展能力，比如 ALPN

2. 服务端回应能力

服务端返回 ServerHello，告诉客户端：

最终选择哪个 TLS 版本
选择哪个加密套件
返回服务端随机数
发送数字证书

3. 客户端验证证书

客户端会检查服务端证书：

证书里的域名是否匹配当前访问域名
是否由受信任 CA 签发
是否在有效期内
签名链是否完整

如果这一步失败，浏览器就会提示“证书不安全”“连接不受信任”等警告。

4. 双方生成会话密钥

验证通过后，双方会通过密钥交换过程生成同一组会话密钥。后面的 HTTP 数据就用这组密钥加密。

注意这里也有一个常见误区：

HTTPS 并不是每个数据包都用证书里的公钥直接加密。

真正大规模传输数据时，主要使用的是对称加密，因为速度更快；而非对称加密和证书机制主要用于身份验证和安全协商。

5. 握手完成后开始发送 HTTP 数据

直到这一步，客户端和服务端才真正开始传输：

请求头
Cookie
表单数据
接口响应
页面内容

这些数据在链路中看到的都不再是可读明文。

九、证书到底是什么，有什么用

证书是 HTTPS 非常重要的一环。没有证书，就很难做到可信身份认证。

1. 证书的核心作用

证书的作用不是“加密文件”，而是：

证明某个公钥属于某个域名
证明这个绑定关系得到了可信第三方背书

也就是说，证书解决的是：

这个公钥到底是不是 www.example.com 的，而不是攻击者伪造的？

2. 证书里通常包含什么

一个证书通常会包含：

证书持有者信息
域名信息
公钥
签发机构信息
有效期
数字签名

3. CA 是什么

CA，Certificate Authority，证书颁发机构。浏览器和操作系统内部会内置一批受信任 CA 的根证书。

如果某个站点的证书是由这些受信任 CA 签发的，浏览器就可以顺着证书链去验证：

站点证书
中间证书
根证书

最终判断这张证书是否可信。

4. 为什么自签证书会报警

自签证书的问题不是“不能加密”，而是：

浏览器不默认信任你自己给自己签发的身份声明

所以自签证书在内网测试环境能用，但默认会有安全警告。

5. 证书通过了，说明什么

说明：

你当前连到的服务端，持有与这张证书绑定的私钥
证书链校验通过
当前域名匹配

但这仍不代表：

网站业务一定合法
网站内容一定无恶意

所以证书验证的是“身份链路可信”，不是“业务逻辑绝对可信”。

十、HTTP 和 HTTPS 在报文层面的直观区别

1. HTTP 抓包时能看到什么

在 HTTP 场景中，如果你抓包，通常可以直接看到：

请求方法
URL 路径
Header
Cookie
Body
响应内容

例如：

GET /api/order?id=1001 HTTP/1.1
Host: shop.example.com
Cookie: token=abc123

这几乎就是“裸奔”。

2. HTTPS 抓包时能看到什么

在 HTTPS 场景中，抓包一般首先看到的是：

TCP 或 QUIC 建连过程
TLS 握手信息
之后的大量加密应用数据

如果没有中间人证书代理能力，抓包者通常无法直接看到真实的：

请求路径
请求头内容
Cookie 内容
请求体和响应体

3. 一个关键细节

这里要注意一个容易误解的地方：

HTTPS 保护的是 HTTP 内容，不等于所有外围信息都不可见。

例如在很多情况下：

你连接到了哪个 IP
连接持续多久
总共发了多少字节

这些网络层和流量特征信息仍可能被观察到。

十一、HTTPS 具体能防哪些攻击

1. 防止链路窃听

例如你连咖啡馆 Wi-Fi 登录邮箱，如果是 HTTPS，旁路监听者难以直接看到你的账号密码和邮件内容。

2. 防止内容被偷偷篡改

中间节点很难在不被发现的情况下修改返回页面、注入脚本或替换下载文件。

3. 防止中间人伪装正规站点

因为浏览器会校验证书，攻击者如果没有合法证书和对应私钥，很难无痕伪造真正站点。

4. 防止会话信息被明文窃取

如果 Cookie、Token、接口返回内容都在 HTTPS 下传输，那么链路中窃听者更难直接复用这些数据。

十二、HTTPS 不能防哪些问题

1. 不能防钓鱼网站本身

钓鱼网站也可以部署 HTTPS，也可以拥有合法证书。

所以“有小锁标识”不等于“这个网站一定可信”。

2. 不能防服务端自己泄露数据

如果服务端数据库被拖库，或者接口本身设计错误，HTTPS 并不能阻止数据泄露。

3. 不能防前端代码自身漏洞

例如：

XSS
业务逻辑缺陷
Token 存储不安全

这些都不是 HTTPS 能直接解决的问题。

4. 不能防终端设备被控制

如果客户端设备本身已被入侵，攻击者完全可以在“加密前”或“解密后”拿到明文数据。

十三、HTTPS 的性能开销到底大不大

这个问题在面试里也很常见。

1. 为什么 HTTPS 会比 HTTP 多一点开销

主要多在两部分：

TLS 握手需要额外往返
加密和解密需要 CPU 计算

早期设备性能较弱时，这个成本比较明显。

2. 为什么今天 HTTPS 已经成为主流

因为现代网络和浏览器环境下，这些成本已经被大幅优化：

TLS 1.3 降低握手时延
会话复用和会话恢复减少重复握手
硬件和系统对加密有更好支持
CDN 和反向代理能很好承担 TLS 终止工作

所以今天大多数业务场景里，HTTPS 的收益远远大于它的额外开销。

3. 一个容易被忽略的现实

现代浏览器生态里，很多能力本来就更偏向 HTTPS，例如：

HTTP/2 在浏览器侧通常几乎都和 HTTPS 绑定使用
HTTP/3 更是天然和现代安全传输体系深度耦合
Service Worker、某些新 Web API 往往要求安全上下文

所以从工程实践角度看，HTTPS 已经不是“可选优化”，而是“默认标准配置”。

十四、为什么浏览器越来越不鼓励 HTTP

1. 地址栏安全提示

以前浏览器对 HTTP 常常只是“不提示”；现在很多浏览器会直接标记：

Not Secure
不安全连接

也就是说，HTTP 已经从“默认正常”变成了“默认风险更高”。

2. SEO 更友好

搜索引擎长期倾向于把 HTTPS 视为更优的站点质量信号之一。

3. 更适合现代功能

很多现代 Web 平台特性默认要求安全上下文，也就是通常必须在 HTTPS 下运行。

4. 用户信任感更高

电商、支付、登录、后台管理、开放平台回调等场景，如果还跑 HTTP，用户几乎一定会产生不信任。

十五、HTTP 和 HTTPS 的常见误区

1. 误区一：HTTPS 就是“加密版 HTTP”

这句话不算错，但太浅。更准确地说：

HTTPS = HTTP + TLS 提供的加密、完整性和认证能力。

2. 误区二：HTTPS 就一定绝对安全

不是。它只是让传输链路更安全，并不能替代业务安全、代码安全、终端安全。

3. 误区三：有证书的网站就一定可信

不是。合法证书只能证明这个网站持有某个域名对应的私钥，并不证明网站内容一定善意。

4. 误区四：HTTP 只是“不加密”，其他都一样

也不对。HTTP 和 HTTPS 的差别不只在“内容是否被加密”，还在于：

是否能发现篡改
是否能验证身份
是否更容易遭受中间人攻击

5. 误区五：HTTPS 会把所有信息都隐藏掉

不是。很多流量元信息仍可能被观察到，HTTPS 主要保护的是应用层内容。

十六、什么时候必须使用 HTTPS

实际上，今天几乎所有公网业务都应该优先使用 HTTPS，尤其是以下场景：

登录注册
支付交易
用户中心
管理后台
API 接口
文件下载
涉及 Cookie、Token、隐私数据的任何页面

更现实一点说：

现在真正适合继续使用纯 HTTP 的场景，通常只剩内网测试、临时调试、本地开发、某些极端受限环境。

十七、HTTP 和 HTTPS 的面试式总结

如果面试官问你“HTTP 和 HTTPS 的区别”，一个比较完整且简洁的回答可以是：

HTTP 是应用层的明文传输协议，默认使用 80 端口；HTTPS 本质上是运行在 TLS 之上的 HTTP，默认使用 443 端口。HTTPS 比 HTTP 多了三类关键能力：第一是加密，防止链路中被窃听；第二是完整性校验，防止数据被篡改；第三是通过数字证书验证服务端身份，降低中间人伪装风险。它的代价是多了 TLS 握手和加解密开销，但现代 TLS 1.3、会话恢复和硬件加速已经让这部分成本显著降低，所以现在 HTTPS 基本已经成为公网通信的默认标准。

如果面试官继续追问，你再补下面几点就很完整：

HTTPS 不是新语义协议，本质还是 HTTP
HTTPS 通过证书链和 CA 信任体系验证服务端身份
HTTPS 解决的是传输链路安全，不等于网站本身绝对安全
HTTPS 仍然不能防钓鱼站、XSS、服务端漏洞和终端中毒

十八、速查表

问题	HTTP	HTTPS
是否加密	否	是
是否能防窃听	否	是
是否能防篡改	否	是
是否能验证服务端身份	否	是
是否需要证书	否	是
默认端口	80	443
是否适合公网正式环境	不推荐	推荐
是否还可能有安全问题	会	也会，但链路安全更强

十九、一句话收尾

HTTP 和 HTTPS 的本质区别，不是“多了一个 S”，而是：

HTTP 只负责传数据
HTTPS 既传数据，也尽量保证这份数据不被偷看、不被篡改、不是假人发来的

这才是它们最核心的差异。