Http与Https区别和联系
一、HTTP 详解
HTTP(HyperText Transfer Protocol) 是互联网数据通信的基础协议,用于客户端(浏览器)与服务器之间的请求-响应交互
核心特性:
1.无连接(Connectionless)
每次请求/响应后立即断开 TCP 连接(早期 HTTP/1.0)。HTTP/1.1 默认启用持久连接(
Connection: keep-alive
),但逻辑上仍视为独立的请求
2.无状态(Stateless)
核心问题:服务器不记录先前请求的任何信息(如用户登录状态)
协议层特性:HTTP 协议本身不保存任何请求上下文,每个请求相互独立
优点
-
服务器无需存储状态 → 降低内存占用
-
易扩展:适合负载均衡(请求可转发至任意后端服务器)
影响
每个请求都被视为全新请求,无法直接关联用户身份
有状态
为构建逻辑上的“有状态”,需在应用层添加额外机制
解决方案:
-
Cookie:服务器通过响应头
Set-Cookie
在客户端存储标识符 -
Session:服务器生成唯一 Session ID 绑定用户状态(依赖 Cookie 传递 ID)
-
Token(如 JWT):客户端在请求头携带加密令牌(
Authorization: Bearer <token>
)
方案 | 原理 | 示例 |
---|---|---|
Cookie | 服务器通过 |
|
Session | 服务器存储用户状态(内存/数据库),通过 Cookie 中的 Session ID 关联用户 | 服务端存储: |
Token | 客户端存储加密令牌(如 JWT),包含用户信息及签名,服务器无需存储状态 |
|
注意:
-
这些方案在 HTTP 上层构建状态,不改变 HTTP 无状态本质。
-
Session 依赖集中存储(如 Redis),高并发场景需解决分布式一致性
无状态vs有状态的对比与关联
维度 | 无状态(原生 HTTP) | 有状态(应用层实现) |
---|---|---|
协议设计 | 请求独立,无记忆性 | 通过 Cookie/Session/Token 关联用户 |
服务器复杂度 | 低 | 高(需管理 Session 存储、Token 验证) |
扩展性 | ⭐️⭐️⭐️ 优秀(无状态易水平扩展) | ⭐️⭐️ 中等(需共享 Session 存储机制) |
安全性 | 弱(明文传输) | 可叠加 HTTPS 增强安全 |
典型应用 | 静态资源请求、API 无状态调用 | 用户登录、购物车、个性化服务 |
核心联系:
-
状态管理建立在 HTTP 之上:所有状态方案需通过 HTTP 头(Cookie/Authorization)传递标识
-
HTTPS 是安全基石:Cookie/Session ID/Token 需通过 HTTPS 传输防止窃取
典型应用场景分析
无状态优先场景
-
RESTful API 设计:
GET /api/products/123 # 请求包含完整资源标识符,无需上下文
→ 符合 HTTP 无状态特性,易于缓存和扩展。
-
CDN 静态资源分发:图片、CSS 等文件通过无状态请求分发 → 支持边缘节点缓存
有状态必需场景
-
用户登录系统:
-
登录请求 → 服务器返回 Session ID(HTTPS + Cookie)
-
后续请求携带 Session ID → 服务器验证身份
-
-
电商购物车:用户添加商品 → 服务器通过 Session 关联用户存储购物车数据
-
金融交易:敏感操作需 Token(JWT)验证身份及权限,并强制 HTTPS 加密
HTTPS 强制场景
-
所有涉及隐私的场景:登录、支付、个人信息修改
-
防止中间人攻击:公共 Wi-Fi 下的网络请求
-
合规性要求:GDPR、PCI-DSS 等法规强制加密
关键结论
底层差异
-
HTTP 在 TCP 上明文传输。
-
HTTPS 通过 TLS/SSL 实现加密隧道。
状态管理真相
-
HTTP 协议天生无状态
-
“有状态服务”是应用层通过 Cookie/Session/Token 模拟的逻辑状态
应用选择原则
需求 | 技术选型 |
---|---|
公开静态资源 | HTTP + 无状态 |
用户身份验证 | HTTPS + Cookie/Session |
分布式 API | HTTPS + JWT(无状态 Token) |
高性能敏感操作 | HTTPS + 短时效 Token |
💡 终极架构建议:
全站 HTTPS:现代浏览器已标记 HTTP 站点为“不安全”
状态最小化:优先使用无状态 Token(JWT)降低服务器负担
分层设计:
[客户端] → HTTPS → [API 网关] → 无状态微服务(认证/业务分离)
3.请求/响应模型
-
请求方法:
GET
(获取资源)、POST
(提交数据)、PUT
/DELETE
(更新/删除)等 -
状态码:
-
200 OK
:成功 -
404 Not Found
:资源不存在 -
500 Internal Server Error
:服务器错误
-
4.URL 结构
http://host:port/path?query=value#fragment
-
明文传输所有数据(路径、参数、Cookie 可见)
HTTP 底层(TCP 协议栈)
|-----------------------|
| 应用层 (HTTP) | → 定义数据格式(请求头/响应体)
|-----------------------|
| 传输层 (TCP) | → 建立可靠连接(三次握手),保证数据完整
|-----------------------|
| 网络层 (IP) | → 路由寻址(IP 数据包传输)
|-----------------------|
| 数据链路层 (Ethernet) | → 物理设备间数据帧传输
|-----------------------|
关键过程
- 1.客户端通过 DNS 解析域名 → 获取目标服务器 IP
- 2.TCP三次握手建立连接(SYN → SYN/ACK → ACK)
- 3.HTTP 发送明文请求:
GET /index.html HTTP/1.1
- 4.服务器返回明文响应:
HTTP/1.1 200 OK
+ HTML 内容 - 5.TCP 四次挥手断开连接(FIN → ACK)
二、HTTPS 详解
HTTPS(HTTP Secure) = HTTP + SSL/TLS 加密层,解决 HTTP 的安全风险
核心机制:
1.加密(Encryption)
-
对称加密:传输数据时使用共享密钥(效率高)
-
非对称加密:交换对称密钥时使用公钥/私钥(防止窃听)
-
流程(简化):
- 客户端请求服务器公钥
- 用公钥加密随机生成的对称密钥并发送给服务器
- 双方使用对称密钥加密后续通信
2.身份验证(Authentication)
-
数字证书:由可信 CA(证书颁发机构) 签发,证明服务器身份
-
浏览器验证证书有效性(是否过期、域名匹配、CA 是否可信)
3.数据完整性(Integrity)
-
TLS 使用 MAC(消息认证码)防止数据篡改
优势
-
防窃听(加密数据)
-
防篡改(数据完整性校验)
-
防冒充(证书验证身份)
HTTPS 底层(TLS/SSL 加密层)
|-----------------------|
| HTTP |
|-----------------------|
| TLS/SSL | → 加密、身份验证、数据完整性保护
|-----------------------|
| TCP |
|-----------------------|
TLS 握手核心步骤
- Client Hello:客户端发送支持的加密算法 + 随机数
ClientRandom
- Server Hello:服务器选择加密算法,返回证书 + 随机数
ServerRandom
- 证书验证:客户端验证服务器证书合法性(CA 链校验)
- 密钥交换:
-
客户端生成 Pre-Master Key → 用证书公钥加密后发送给服务器
-
双方通过
ClientRandom + ServerRandom + Pre-Master Key
生成 Master Secret(对称加密密钥)
-
- 加密通信:后续所有 HTTP 数据使用对称加密传输
技术要点
-
非对称加密(RSA/ECC)用于安全交换对称密钥
-
对称加密(AES)用于高效加密应用层数据
-
数字签名(SHA256)保证数据未被篡改
三、HTTP 的“无状态” vs “有状态”方案
特性 | 无状态(Stateless) | 有状态(Stateful)方案 |
---|---|---|
协议本质 | HTTP 协议本身无状态 | 通过技术手段模拟状态 |
典型场景 | 基本 HTTP 请求 | 登录状态、购物车数据 |
实现方式 | 无额外处理 | Cookie + Session / JWT / Token |
服务器压力 | 低(无状态存储) | 高(需存储 Session 数据) |
扩展性 | 高(易于水平扩展) | 依赖 Session 共享机制(如 Redis 集群) |
注:HTTP 协议始终是无状态的,"有状态服务"指应用层通过技术(如Session)实现的逻辑状态
四、关键区别对比(HTTP vs HTTPS)
特性 | HTTP | HTTPS |
---|---|---|
端口 | 80 | 443 |
加密 | ❌ 明文传输 | ✅ TLS/SSL 加密 |
身份验证 | ❌ 无验证 | ✅ CA 证书验证服务器身份 |
数据安全 | 易被窃听/篡改 | 防窃听、防篡改、防冒充 |
性能 | ⚡ 更高(无加密开销) | ⚠️ 略低(加密/解密消耗资源) |
使用场景 | 不敏感信息(如静态页面) | 登录、支付、隐私数据 |
五、如何解决 HTTP 无状态?
1.Cookie 机制
-
服务器通过
Set-Cookie
响应头设置键值对 -
浏览器每次请求自动携带
Cookie
头
2.Session 机制
-
服务器创建 Session 存储用户状态(内存/数据库)
-
通过 Cookie 传递 Session ID 绑定用户
3.Token 机制(如 JWT)
-
服务器生成加密 Token 包含用户信息
-
客户端存储 Token 并在请求头(
Authorization
)中发送
注意:这些方案在应用层实现状态管理,不改变 HTTP 无状态本质
六.总结
-
HTTP:高效、无状态、明文传输,适用于非敏感场景
-
HTTPS:通过 SSL/TLS 实现加密、身份认证和数据完整性,必用于安全场景
-
状态管理:需依赖 Cookie/Session/Token 等方案构建逻辑状态
选择 HTTP/HTTPS 取决于数据敏感性,而状态管理是构建复杂应用的必然需求