Cookie和Session 知识总结
由于 HTTP 是无状态协议每次请求独立服务器无法“记住”用户身份。Cookie 和 Session 正是为了解决“会话跟踪”问题而诞生的两大核心技术。简单来说Cookie 是客户端的“身份证”Session 是服务端的“档案室”。一、 什么是 Cookie客户端的“通行证”Cookie 是服务器生成、存储在用户浏览器客户端中的小型文本文件通常 4KB由键值对组成。 浏览器每次发起 HTTP 请求时会自动将符合规则的 Cookie 携带在请求头Cookie字段中发送给服务器。1.核心特征存储位置客户端浏览器。生命周期分为会话级 Cookie浏览器关闭即失效和持久化 Cookie设置了Expires或Max-Age存储在硬盘上。2.关键属性安全相关HttpOnly禁止 JavaScript 读取有效防御XSS跨站脚本攻击。Secure仅允许通过 HTTPS 加密传输防止中间人窃听。SameSite限制跨站请求携带用于防御CSRF跨站请求伪造。3.Cookie 的典型应用场景记住用户登录状态存 SessionID、记录浏览偏好主题色、语言、电商购物车非登录态等。二、什么是 Session服务端的“档案室”Session 是服务器端为解决身份认证而开辟的内存/缓存空间。当用户首次访问时服务器创建一个唯一的 Session 对象对应一个SessionID并利用 Cookie 将SessionID返回给客户端存储。1.核心特征存储位置服务器端内存、Redis、数据库。数据容量无大小限制受服务器内存/存储限制适合存储复杂的用户信息如用户对象。生命周期通常设置超时时间如 30 分钟无操作则失效主动调用invalidate()可立即销毁。2.工作机制流程用户登录成功 → 服务器创建 Session 并存入用户信息 → 服务器生成SessionID并通过Set-Cookie发给浏览器 → 浏览器后续请求自动携带该 Cookie → 服务器根据SessionID取出对应 Session 数据即完成身份识别。三、核心区别对比面试高频维度CookieSession存储位置浏览器客户端服务器端内存/Redis存储容量小单个约 4KB大几乎无限制安全性低明文存储易被篡改和窃取高数据在服务端客户端只存 ID性能消耗低不占用服务器资源高并发用户多时占用大量内存分布式支持天然支持客户端自动携带困难需解决多台服务器 Session 共享问题跨域/跨设备支持浏览器自动管理依赖 Cookie 传递 ID需额外处理四、为什么 Session 依赖 Cookie例外情况绝大多数 Web 框架如 Java HttpSession、PHP SESSION默认使用 Cookie 来传输SessionID。如果客户端禁用 Cookie 怎么办采用URL 重写将SessionID作为 URL 参数附加在地址后面如url?jsessionidxxx但这种方式极不安全且影响 SEO现代应用中很少使用。五、分布式场景下的痛点与解决方案进阶单机 Session 无法在集群中共享。假设用户第一次请求落在服务器 A存储了 Session第二次请求被负载均衡到服务器 B没有该 Session用户就会被踢下线。主流解决方案Session 粘滞Sticky Session负载均衡器将同一用户的请求始终转发到同一台服务器不推荐容灾差。Session 集中式存储推荐将 Session 统一存放到Redis或Memcached中。所有服务器去同一个缓存中读写实现 Session 共享例如 Spring Session Redis 方案。六、现代技术演进Session 的挑战与 JWT 的兴起在前后端分离和微服务架构下传统 Session 面临跨域、移动端不支持 Cookie 自动管理、CSRF 攻击等问题。因此无状态的 JWTJSON Web Token越来越流行。Session有状态。服务器必须存储 Session 数据查询 I/O 耗时且注销时必须清除服务端数据。JWT无状态。用户信息加密在 Token 字符串中服务器只需验证签名无需存储天然支持分布式且支持跨域和移动端。注意JWT 虽然解决了存储问题但其存在无法主动失效签发后有效期内无法销毁和体积较大每次请求携带的缺点。在需要实时踢人、修改权限立即生效的场景下Redis Session依然是更可控的选择。