web会话技术简单总结

Web 会话技术全面对比与选型

目前主流 Web 会话技术全汇总（Java / 前后端分离 / 微服务都涵盖）

按传统 Web → 现代前后端分离 → 分布式微服务分类，把所有 Web 会话技术讲清楚，各自原理、适用场景、优缺点一次性梳理完。

一、先明确：什么是 Web 会话技术

HTTP 无状态，每次请求服务器都不认识你； 会话技术 = 帮服务器记住客户端身份、保存用户状态，实现一次登录、多次免登交互。

二、传统 Web 会话技术（早期 Java Web、SSM、JSP 用的）

1. Cookie

• 存储：浏览器客户端
• 本质：服务器通过 Set-Cookie 下发，浏览器自动携带在请求头
• 用途：存少量文本，比如 SessionId、标识、简单配置
• 特点：
  • 大小有限、不安全（可篡改、可被盗）
  • 可以设置过期时间、HttpOnly、Secure、SameSite
• 局限：不能存敏感数据、跨域受限

2. Session（HttpSession）

• 存储：服务器端内存（Tomcat/Jetty）
• 依赖：底层靠 Cookie 存 JSESSIONID 实现关联
• 流程：登录创建 Session → 下发 JSESSIONID 到 Cookie → 后续请求带 ID 找会话
• 特点：Java 原生支持、开发简单、存用户信息 / 权限
• 局限：
  • 不适合分布式、集群（单机会话，另一台服务器没有）
  • 服务器重启会话丢失

3. URL 重写

• 原理：Cookie 被禁用时，把 SessionId 拼在 URL 后面 /index;jsessionid=xxxxxx
• 场景：老式浏览器禁用 Cookie 的兼容方案
• 现在基本淘汰，没人用了

4. 隐藏表单域

• 在页面 form 里放 <input type="hidden" name="sid" value="xxx">
• 每次提交表单带上会话标识
• 老旧项目遗留，现已淘汰

---

三、现代主流会话技术（前后端分离、Vue/React/ 小程序 / APP）

1. JWT（JSON Web Token）最常用

• 无状态会话，服务器不存会话
• 流程： 登录成功 → 生成加密 JWT 返回前端 → 前端存在 localStorage/sessionStorage → 每次请求头带 Authorization: Bearer token
• 特点：
  • 自带用户信息、签名校验，不用查服务器存储
  • 天然支持跨域、分布式、微服务
• 缺点：
  • 一旦签发，无法主动作废（只能等过期）
  • payload 不能存敏感明文

2. 自定义 Token（Redis 存令牌）

企业最常用方案，比纯 JWT 更安全

• 流程： 登录 → 生成随机唯一 token → 存 Redis（token→用户信息、过期时间） → 返回前端 每次请求带 token → 查 Redis 是否存在、是否过期
• 优点：
  • 可主动踢人（删除 Redis key）
  • 可控过期、可续期、安全可控
  • 完美适配集群 / 微服务
• 现在 Java 后端生产首选

3. SessionStorage / LocalStorage

不是会话认证技术，是前端存储载体

• SessionStorage：关闭浏览器标签就清空
• LocalStorage：持久化，手动清缓存才失效 用途：存 Token、用户简单信息，配合 JWT / 自定义 Token 使用

4. 第三方会话登录（OAuth2.0 / OpenID Connect）

• 微信登录、QQ、支付宝、GitHub、企业微信登录
• 核心协议：OAuth2.0、OIDC
• 本质：授权 + 身份认证，不用自己维护账号密码，由第三方帮你维持会话

5. SSO 单点登录会话

多用于公司内部系统、多系统互通

• 主流方案：
  • CAS 单点登录
  • Spring Security OAuth2 + JWT
  • Keycloak、Sa-Token、Casdoor 框架实现
• 效果：登录一次，所有子系统免登

---

四、分布式 / 微服务专用会话方案

1. 共享 Session（Session 复制 / 广播）

• Tomcat 集群 Session 复制、Redis 共享 Session
• 把单机 Session 抽到 Redis 统一存储，所有服务共用
• 代表框架：Spring Session

2. 基于 Header 传递 Token/JWT

微服务标准做法： 网关统一拦截 → 校验 Token → 解析用户信息 → 传给下游微服务 完全抛弃传统 Cookie+Session

3. 网关层会话认证

Spring Cloud Gateway / Nginx / APISIX

• 网关统一做登录校验、会话拦截
• 后端服务不用关心登录逻辑，只拿用户信息即可

---

五、极简分类总结（面试必背）

1. 传统老式：Cookie、HttpSession、URL 重写、隐藏表单域（后两个淘汰）
2. 前后端分离标配：JWT、Redis 自定义 Token
3. 前端存储载体：LocalStorage、SessionStorage
4. 第三方授权会话：OAuth2.0、OIDC
5. 单点登录 SSO：CAS、Keycloak、Sa-Token
6. 分布式会话：Spring Session (Redis)、网关 Token 鉴权

六、现在企业实际用什么？

• 传统老项目：Cookie + Session
• 普通前后端分离：Redis 存自定义 Token（首选）、JWT
• 微服务 / 多系统：网关 + Token/JWT + SSO 单点登录
• 第三方快捷登录：OAuth2.0

 

 

-------------------------------

Web 会话技术最全对比表（面试必背+企业实战版）

一、核心会话技术总表

会话技术	存储位置	有无状态	依赖载体	核心原理	优点	缺点	适用场景	目前流行度
Cookie	浏览器客户端	无状态	HTTP 请求头	服务器下发 Set-Cookie，浏览器自动携带	原生支持、轻量、无需服务器存数据	大小受限、可篡改、不安全、跨域弱	传统会话标识、存简单配置	⭐⭐⭐⭐ 基础必备
HttpSession	服务器内存	有状态	Cookie 存 JSESSIONID	登录创建 Session，通过 JSESSIONID 绑定用户	Java 原生、开发简单、安全可控	单机不支持集群、重启丢失、粘性会话麻烦	传统 JSP/SSM/ 单体 Web 项目	⭐⭐ 老项目在用
URL 重写	地址栏	有状态	URL 拼接 jsessionid	Cookie 禁用时，会话 ID 拼在 URL 后面	兼容禁用 Cookie 场景	不美观、不安全、维护麻烦	老旧浏览器兼容	⭐ 基本淘汰
隐藏表单域	页面隐藏 input	有状态	表单提交携带 sid	每次表单提交带隐藏会话 ID	无需 Cookie 依赖	只适用于表单、页面耦合高	远古遗留项目	⭐ 彻底淘汰
JWT	前端 LocalStorage/SessionStorage	无状态	请求 Header Authorization	加密令牌自带用户信息，签名校验真伪	跨域友好、天生分布式、无需服务器存储	无法主动注销、payload 不能存敏感数据、续签麻烦	前后端分离、小程序、APP	⭐⭐⭐⭐ 常用
Redis 自定义 Token	Redis + 前端存储	有状态	请求 Header 带 Token	生成随机唯一 Token，Redis 映射用户信息	可主动踢人、可续期、安全可控、适配集群微服务	需维护 Redis、多一次缓存查询	互联网项目、后端生产首选	⭐⭐⭐⭐⭐ 企业主流
Spring Session	Redis/Mongo	有状态	Cookie/Header	把原生 Session 迁移到 Redis，实现分布式共享	无缝兼容老 Session 写法、不用改业务代码	仍依赖会话机制、不如 Token 轻量	老项目改造集群、单体转微服务	⭐⭐⭐ 过渡方案

二、前端存储载体对比（配合会话使用，不算认证技术）

存储方式	存储位置	生命周期	大小限制	是否自动随请求携带	用途
LocalStorage	浏览器本地	永久，手动清除才失效	约 5MB	否，需手动放 Header	长期存 Token、免登录
SessionStorage	浏览器标签	关闭标签页自动清空	约 5MB	否，需手动放 Header	临时存会话、关闭即失效
Cookie	浏览器本地	可设置过期 / 会话级	约 4KB	是，浏览器自动带	存 JSESSIONID、简易标识

三、分布式 / 微服务专属会话方案对比

方案	实现方式	优点	缺点	适用场景
共享 Session（Redis）	Spring Session + Redis 统一存 Session	老项目零改造兼容	有状态、占用缓存、扩展性一般	传统项目集群改造
网关统一鉴权	Gateway/APISIX 拦截校验 Token	业务服务无感知、统一认证收口	网关有单点压力、需做好高可用	微服务、中台系统
SSO 单点登录	CAS / OAuth2.0 / Keycloak	一次登录多系统通行	架构复杂、接入成本高	企业多后台、内部系统互通

四、面试高频考点总结（背这几句就够用）

1. Cookie：客户端存储，容量小、不安全、自动随请求携带，用来存会话标识。
2. Session：服务端存储，依赖 Cookie 的 JSESSIONID，有状态、不适合分布式集群。
3. JWT：无状态令牌，不用服务器存会话，跨域友好、微服务适配，但不能主动注销。
4. Redis 自定义 Token：企业最优解，可控过期、可踢下线、支持集群微服务。
5. 淘汰技术：URL 重写、隐藏表单域，现在开发基本不用。
6. 前后端分离不再用原生 Session，主流：Redis Token > JWT。

五、项目选型一句话口诀

• 老旧单体 JSP/SSM → 还用 Cookie + Session
• 前后端分离、Vue / 小程序 → Redis 自定义 Token 优先
• 简单项目、不想搭 Redis → 用 JWT
• 老项目转集群不改造代码 → Spring Session + Redis
• 多系统统一登录 → SSO 单点登录

 

 

--------------------------------------

Cookie-Session、JWT、Redis-Token 登录会话完整对比流程图

一、Cookie-Session 流程图（传统单体项目）

1. 流程图示

2. 核心流程说明

这是Java传统Web项目最基础的会话方案，服务端存状态，客户端只存储会话ID。首次登录成功后服务器在Tomcat内存创建会话，绑定用户信息，通过Cookie将会话ID返回浏览器保存。后续所有请求浏览器自动携带Cookie，服务器匹配会话完成身份校验，实现免登录。该方案依赖服务器内存，仅适用于单体项目，集群场景会失效。

二、JWT 流程图（无状态简易前后端分离项目）

1. 流程图示

2. 核心流程说明

JWT 是纯无状态会话方案，服务器全程不存储任何用户会话数据，所有用户信息加密存储在令牌本身。登录成功后生成带签名的JWT返回前端，前端自主存储。每次请求手动在请求头携带令牌，服务器仅通过算法校验签名真伪和有效期，无需查询数据库/缓存。缺点是令牌签发后无法主动作废，仅适合简单轻量项目。

三、Redis-Token 流程图（企业主流生产方案）

1. 流程图示

2. 核心流程说明

Redis-Token 是目前企业最优通用会话方案，结合了有状态、高可控、适配分布式的特点。服务器生成随机无意义令牌，用户信息统一存储在Redis缓存中。不仅支持跨域、微服务、集群部署，还可以手动销毁令牌实现用户踢下线、会话续期、单点登录，完美解决了原生Session集群失效、JWT无法作废的痛点。

四、三种方案核心差异总结（面试精简）

• Cookie-Session：服务端存状态、依赖Cookie、仅单体可用、架构简单、扩展性差
• JWT：全程无状态、无需缓存、轻量化、无法主动注销、安全性一般
• Redis-Token：缓存存状态、可控性强、适配所有架构、企业生产首选