在现代 Web 技术栈中，HTTP、HTTPS、Session、JWT、WebSocket 是构成网络通信与身份认证的核心五要素。很多开发者对它们的认知停留在零散知识点层面，缺乏体系化的层级视角。本文先从全局关系切入，建立整体认知，再逐一拆解每项技术的完整生命周期与工作原理。
一、五者关系总览：层级与定位
这五项技术分属网络协议栈和身份认证两个维度，并非并列关系，而是存在明确的上下层承载关系：
- HTTP 与 WebSocket 是同层级的应用层通信协议，前者为请求 - 响应模式，后者为全双工长连接模式
- HTTPS /wss 不是独立协议，是「HTTP/WebSocket + TLS 加密层」的安全组合
- Session 与 JWT 是两种身份认证方案，均可运行在 HTTP 和 WebSocket 之上
核心结论：
- 协议栈从下到上：TCP → TLS → HTTP/WebSocket
- 认证机制运行于应用层之上，与具体协议解耦
- HTTPS = HTTP + TLS；wss = WebSocket + TLS
- Session 天然绑定 HTTP Cookie，JWT 更灵活，可在任意载体传输
二、HTTP：无状态的应用层基石
2.1 HTTP 协议本质
HTTP（HyperText Transfer Protocol）是基于 TCP/IP 的应用层协议，默认端口 80，核心特征是无状态、请求 - 响应模式。
- 无状态：服务器不保存任何客户端的历史请求信息，每次请求都是独立的
- 请求 - 响应：通信只能由客户端发起，服务器被动响应
- 连接模式：HTTP/1.0 默认短连接，HTTP/1.1 引入 Keep-Alive 支持长连接复用
2.2 HTTP 完整通信流程
- DNS 解析：客户端将域名解析为服务器 IP 地址
- TCP 三次握手：建立传输层可靠连接
- 发送 HTTP 请求：客户端构造请求行、请求头、请求体
- 服务器处理并响应：服务器返回状态行、响应头、响应体
- TCP 四次挥手：断开传输层连接（短连接模式下立即断开）
2.3 HTTP 请求时序图
三、HTTPS：在 HTTP 之上构建安全隧道
3.1 HTTPS 核心机制
HTTPS = HTTP + TLS/SSL，默认端口 443，解决了 HTTP 的三大安全风险：
- 窃听风险：明文传输易被拦截 → 对称加密传输数据
- 篡改风险：数据中途可被修改 → 消息摘要 + 数字签名保证完整性
- 冒充风险：服务器身份可伪造 → 数字证书认证服务器身份
3.2 TLS 握手全过程（TLS 1.2）
- 客户端问候：发送支持的 TLS 版本、加密套件、随机数 Random1
- 服务器问候：选定加密套件，返回随机数 Random2、服务器证书
- 客户端验签：使用 CA 公钥验证证书合法性，提取服务器公钥
- 密钥交换：客户端生成预主密钥，用服务器公钥加密后发送
- 会话密钥生成：双方基于随机数 + 预主密钥计算出对称会话密钥
- 握手完成：双方互发 Finished 消息，验证握手过程完整性
3.3 HTTPS 握手时序图
TLS 1.3 优化：将握手从 2-RTT 缩减为 1-RTT，支持 0-RTT 恢复，大幅降低握手延迟。
四、Session：服务端存储的会话认证
4.1 Session 工作原理
由于 HTTP 无状态，为了识别用户身份，Session 机制应运而生：
- 服务器为每个用户创建唯一的 Session 对象，存储用户状态
- 服务器生成唯一的 session_id，通过 Set-Cookie 返回给客户端
- 客户端后续请求自动携带 Cookie 中的 session_id
- 服务器通过 session_id 匹配对应的 Session 对象，识别用户身份
4.2 Session 完整生命周期
- 首次登录：客户端无 Cookie，服务器创建 Session 并返回 session_id
- 后续请求：客户端携带 session_id，服务器校验并恢复会话状态
- 会话过期：超过设定时长无活动，服务器销毁 Session
- 主动登出：用户触发登出，服务器删除对应 Session
4.3 Session 认证时序图
4.4 Session 优缺点
优点：安全性高，状态存储在服务端；可主动失效；支持丰富的会话数据
缺点：分布式环境下需解决 Session 共享问题；占用服务器内存；易受 CSRF 攻击
五、JWT：无状态的令牌认证
5.1 JWT 结构与原理
JWT（JSON Web Token）是一种自包含的令牌认证机制，核心思想是状态存在客户端，服务端只做验签。
JWT 由三部分组成，用.分隔：
- Header：声明算法与类型，如 {“alg”:“HS256”,“typ”:“JWT”}
- Payload：存储用户信息与过期时间等声明
- Signature：对前两部分的签名，防止篡改
5.2 JWT 认证全流程
- 登录获取令牌：用户提交凭证，服务器验证后生成 JWT 返回
- 请求携带令牌：客户端将 JWT 放入 Authorization: Bearer 请求头
- 服务端验签：服务器用密钥验证签名合法性，解析 Payload 获取用户信息
- 令牌过期：超过 exp 声明的时间，令牌自动失效
5.3 JWT 认证时序图
5.4 JWT vs Session 核心差异
六、WebSocket：全双工的长连接通信
6.1 WebSocket 核心特性
WebSocket 是 HTML5 引入的协议，默认端口 80（ws）/443（wss），解决了 HTTP 只能单向通信的痛点：
- 全双工：客户端和服务器可同时双向发送数据
- 长连接：一次握手后连接持续保持
- 低开销：数据帧格式轻量，头部开销小
- 协议升级：基于 HTTP 握手升级，兼容现有网络基础设施
6.2 WebSocket 完整生命周期
- 握手升级：客户端发送带 Upgrade 头的 HTTP 请求，服务器同意后协议升级
- 数据帧传输：双方以帧为单位双向传输数据，支持文本和二进制
- 心跳保活：通过 Ping/Pong 帧检测连接存活状态
- 连接关闭：任一方发送 Close 帧，双方优雅断开连接
6.3 WebSocket 通信时序图
6.4 WebSocket + JWT 认证
WebSocket 本身没有内置认证机制，最常用的方案是握手时在请求头或 Query 参数中携带 JWT：
七、工程实践选型建议
- 普通网页、SEO 场景：HTTP/HTTPS + Session 是经典组合，成熟稳定
- 前后端分离、微服务架构：HTTPS + JWT 是主流方案，便于跨域与水平扩展
- 实时聊天、协同编辑、行情推送：WebSocket + JWT 认证，实现低延迟双向通信
- 高安全级别系统：优先 Session + HttpOnly Cookie + HTTPS，降低 XSS 风险
- 移动端 API：JWT 更合适，避免移动端 Cookie 管理的兼容性问题
