cookie和session

关注

原创最新推荐文章于 2026-07-09 13:46:51 发布 1k 阅读 AI 写同款· GEO 优化 ›

如何导入su_利用GIS快速生成SU场地模型 01｜前言：进入2021年了，希望大家也是一个新的开始。告诫自己多写文章多更新，多读点书多旅行。然而元旦由于出去玩了4天，积累了一些事情要处理，一直没有时间好好写点东西。今天给大家带来的分享主题叫“利用GIS快速生成SU场地模型”。相关的视频方法其实B站上也有，但我相信视频很多人都不会看，我自己也是。直接给大家上操作流程。主要的操作步骤是【获取场地的矢量shp文件】—【导入ArcScen... 阅读详情

Cookie 和 Session 的定义

Cookie
• 定义：由服务器生成并发送到客户端（浏览器）的一小段文本数据，存储在用户本地。每次请求时，浏览器自动将 Cookie 携带到服务器。
• 核心作用：跟踪用户身份（如登录状态）、记录个性化设置（如语言偏好）等。
Session
• 定义：服务器端创建的会话机制，用于存储用户会话期间的临时数据（如用户 ID、购物车信息）。客户端通过唯一的 Session ID（通常存储于 Cookie）与服务器端的 Session 关联。
• 核心作用：维护敏感或临时的用户状态（如登录凭证、多页面操作数据）。

Cookie 和 Session 的工作流程

1. 用户首次请求服务器（未登录）

• 流程：
① 用户访问网站（如 /login）时，浏览器发送请求到服务器。
② 服务器检查请求头 Cookie 中是否包含 SessionID。
③ 若未找到 SessionID，服务器会生成一个 唯一 SessionID（如 JSESSIONID=abc123），并创建对应的 Session 对象（存储在服务器内存或数据库）。
④ 服务器通过响应头 Set-Cookie 将 SessionID 返回给浏览器，例如：

Set-Cookie: JSESSIONID=abc123; Path=/; HttpOnly; SameSite=Lax

（HttpOnly 防止 JavaScript 窃取，SameSite 限制跨站请求）。

2. 用户登录认证

• 流程：
① 用户提交登录表单（如用户名和密码）。
② 服务器验证用户信息，若成功：
• 创建用户会话数据：将用户 ID、权限等信息存入 Session 对象。
• 更新 Session 有效期（如 30 分钟无操作后过期）。
③ 服务器返回响应，浏览器继续携带 SessionID 的 Cookie。

3. 用户后续请求

• 流程：
① 浏览器在请求头中自动携带 SessionID（通过 Cookie 字段）。
② 服务器解析 SessionID，从存储中查找对应的 Session 数据。
③ 若 Session 有效，服务器根据数据识别用户身份（如显示用户名的个人页面）；若无效（如已过期），重定向到登录页。

4. 会话终止

• 场景：
• 主动注销：服务器销毁 Session，并通过 Set-Cookie 清空 SessionID。
• 超时失效：服务器定期清理过期 Session（如默认 20 分钟）。
• 浏览器关闭：非持久化 Cookie 的 SessionID 丢失，但服务器 Session 可能仍存活直至超时。

关键协作机制

SessionID 的传递：
• 依赖 Cookie 默认实现，若浏览器禁用 Cookie，需通过 URL 重写（如 ?sessionid=abc123）或 隐藏表单字段 手动传递。
安全性设计：
• Cookie：使用 Secure（仅 HTTPS）、HttpOnly 防止 XSS 攻击。
• Session：敏感数据存于服务端，仅传输 ID。
分布式场景：
• 多服务器时，Session 需共享存储（如 Redis）以避免会话丢失。

流程示意图

用户请求 → 服务器检查 Cookie → 无 SessionID → 生成 SessionID → 返回 Set-Cookie  
          ↓                          ↑  
          携带 SessionID → 验证 Session → 返回用户数据  
          ↓  
  注销/超时 → 销毁 Session

Cookie 和 Session 的区别

对比维度	Cookie	Session
存储位置	客户端（浏览器）	服务器端（内存、数据库等）
数据容量	单 Cookie ≤4KB，且每个域名下最多存储约 20 个 Cookie	理论上无限制，但受服务器内存或存储限制
安全性	较低（数据明文存储于客户端，可能被窃取或篡改）	较高（数据存储于服务器，仅传递 Session ID）
生命周期	可设置过期时间（如“记住密码”功能）；默认随浏览器关闭失效	默认随会话结束（关闭浏览器）失效，也可设置超时时间（如 30 分钟无操作）
传输方式	自动通过 HTTP 请求头（如 `Cookie` 字段）发送	依赖 Cookie 或 URL 重写传递 Session ID
数据类型支持	仅支持字符串	支持任意类型（如对象、数组等）

Cookie 和 Session 的协作流程

用户首次访问：
• 服务器创建 Session，生成唯一的 Session ID。
• 通过响应头的 Set-Cookie 字段将 Session ID 发送给浏览器保存。
后续请求：
• 浏览器自动携带 Cookie（含 Session ID）发送到服务器。
• 服务器解析 Session ID，从存储介质中查找对应的 Session 数据，完成用户状态验证。
禁用 Cookie 的解决方案：
• URL 重写：将 Session ID 直接拼接在 URL 参数中（如 ?sessionid=123）。
• Token 机制：改用 Token（如 JWT）替代 Session ID，通过请求头传递。

典型应用场景

Cookie 的适用场景：
• 记住登录状态（如“下次自动登录”）。
• 记录用户偏好（如主题、语言）。
• 追踪用户行为（如广告点击统计）。
Session 的适用场景：
• 用户身份验证（存储用户 ID、权限）。
• 购物车信息（临时存储商品数据）。
• 跨页面表单数据共享（防止重复提交）。

安全性注意事项

Cookie 的安全风险：
• 避免存储敏感信息（如密码），需使用 HttpOnly（防 XSS 窃取）和 Secure（仅 HTTPS 传输）标记。
• 对敏感 Cookie 内容加密或签名。
Session 的安全风险：
• 防止 Session 劫持（如使用 HTTPS 加密传输 Session ID）。
• 分布式系统中需采用共享存储（如 Redis）解决 Session 一致性问题。

总结

Cookie 和 Session 的协作本质是：
• Cookie 作为“钥匙”（SessionID），由浏览器管理传输。
• Session 作为“保险箱”（用户数据），由服务器管理安全性。
两者共同解决了 HTTP 无状态协议的用户身份识别问题，平衡了便利性与安全性。

Cookie 和 Session 是互补的机制：Cookie 用于轻量级状态管理（客户端存储），Session 用于安全敏感数据（服务器端存储）。实际开发中，Session ID 常通过 Cookie 传递，但需结合业务需求和安全策略选择合适方案。例如，高并发场景可采用 Token 替代传统 Session 以降低服务器压力。