杨斌
发布于 2025-09-03 / 6 阅读
0
0

Session与Cookie的详细讲解

我们来详细、清晰地讲解 Session 和 Cookie 的概念、区别以及它们如何协同工作。

这是一个非常核心的 Web 开发基础概念。


一、Cookie

1. 是什么?

Cookie 是一小段文本信息(最大通常为 4KB),由服务器通过 HTTP 响应头的 Set-Cookie 字段发送给客户端(通常是浏览器)。浏览器会将其存储起来,并在后续的每一次对同一服务器的请求中,通过 HTTP 请求头的 Cookie 字段自动回传给服务器。

2. 为什么需要它?

因为 HTTP 协议是无状态的。这意味着服务器无法从网络连接本身知道两个请求是否来自同一个用户。Cookie 就像是服务器给客户端的一个“身份证”,客户端每次访问时出示它,服务器就能认出这是谁了。

3. 主要属性(控制Cookie的行为):

  • Name & Value:键值对,存储的实际数据。

  • Domain & Path:定义了Cookie的作用域,即哪些网址可以发送这个Cookie。

  • Expires/Max-Age:设置Cookie的过期时间。如果不设置,Cookie就是会话期Cookie,浏览器关闭后自动删除。设置了时间的就是持久性Cookie,会保留到过期。

  • HttpOnly:如果设置为true,客户端 JavaScript 将无法通过 document.cookie 访问此Cookie,这能有效防止XSS攻击窃取Cookie。

  • Secure:如果设置为true,Cookie只会在使用 HTTPS 安全连接时才会被发送。

  • SameSite:控制Cookie在跨站请求时是否被发送,是防御CSRF攻击的重要防线。值可以是 Strict, Lax, None

4. 工作原理(简化的步骤):

  1. 客户端首次访问服务器(例如,登录页面)。

  2. 服务器在验证用户身份后,在HTTP响应头中加入 Set-Cookie: session_id=abc123; HttpOnly

  3. 浏览器收到响应,将 session_id=abc123 这个Cookie保存起来。

  4. 此后,该浏览器对同一服务器每一次请求,都会自动在请求头中带上 Cookie: session_id=abc123

  5. 服务器收到请求,读取 Cookie 头中的 session_id 值,就知道这个请求来自之前登录的用户 abc123


二、Session

1. 是什么?

Session(会话)代表的不是客户端的东西,而是服务器端的一种机制,用于存储特定用户在一次会话期间(从登录到注销)所需要的数据(如用户ID、用户名、购物车物品等)。

服务器会为每一个会话创建一个唯一的标识符(称为 Session ID),并用这个ID来查找对应的用户数据。

2. 为什么需要它?

Cookie 虽然能标识用户,但不适合直接存储敏感数据(如密码、余额等),因为数据存储在客户端,有被查看和篡改的风险。Session 将敏感数据安全地存储在服务器端,客户端只保存一个无害的 Session ID。

3. 存储位置:

Session 数据可以存储在服务器的内存文件数据库(如Redis, Memcached)中。使用内存速度最快,但服务器重启会丢失,且不利于分布式扩展;使用Redis等内存数据库是现在最流行的方式,因为它既快又能持久化,还支持分布式。


它们不是二选一的关系,而是协同工作的伙伴。通常,Session 的实现依赖于 Cookie

经典工作流程(用户登录场景):

  1. 客户端:用户提交用户名和密码登录。

  2. 服务器:验证用户名和密码正确。

  3. 服务器:在服务器端(如Redis)创建一个新的 Session,并生成一个唯一的 Session ID(如 sess:abc123),并将用户信息(如 {user_id: 1, username: 'alice'})存入其中。

  4. 服务器:在HTTP响应头中通过 Set-Cookie,将这个 Session ID 发送给客户端。例如:Set-Cookie: session_id=abc123; HttpOnly

    • 这里,Cookie 仅仅是一个“钥匙”,而真正的“保险箱(用户数据)”在服务器上。

  5. 客户端:浏览器保存这个包含 Session ID 的 Cookie。

  6. 客户端:下次请求时(如访问个人主页),浏览器会自动带上这个 Cookie:Cookie: session_id=abc123

  7. 服务器:接收到请求,从 Cookie 中取出 session_id=abc123

  8. 服务器:用这个 ID 去自己的存储(Redis)中查找 sess:abc123 这个 Session 数据。

  9. 服务器:找到后,就知道当前用户是 user_id=1 的 Alice,然后返回她的个人主页数据。

如果客户端禁用了 Cookie 怎么办?
Session 并非只能靠 Cookie 传递 Session ID,还有其他方法,但都不如Cookie方便:

  • URL 重写:将 Session ID 作为URL的一个参数传递,例如:https://example.com/profile?session_id=abc123。这种方法不安全且很麻烦。

  • 隐藏表单域:将 Session ID 放在表单的隐藏字段中,但只适用于表单提交。


四、核心区别总结

特性

Cookie

Session

存储位置

客户端(浏览器)

服务器端(内存、数据库等)

数据类型/大小

只能是字符串,大小有限制(约4KB)

可以是任何数据结构(对象、数组等),大小取决于服务器

安全性

较低。数据存储在客户端,可能被查看或篡改。

较高。敏感数据存储在服务器,客户端只有一把“钥匙”(ID)。

生命周期

可设置长期有效(通过 ExpiresMax-Age

通常有效时间较短(如用户 inactivity 超时),依赖于Session ID的存活

性能影响

不占用服务器资源。但每次请求都会携带,增加带宽。

占用服务器资源。用户量巨大时,需要良好的存储方案(如Redis)来管理。

五、总结与比喻

一个很好的比喻是:

  • Cookie 就像你去健身房时前台给你的一张会员卡(Card ID)。你自己拿着这张卡。

  • Session 就像健身房电脑系统里存储的你的会员档案(姓名、次数、剩余金额等)。

  • Session ID 就是你的会员卡号

你每次去健身房,只需出示会员卡(Cookie),前台通过卡号(Session ID)电脑系统(服务器存储) 里查到你的会员档案(Session Data),然后为你服务。他们不需要把所有的会员信息都写在你的卡上。

结论: 现代Web开发中,Session 机制通常使用 Cookie 来传递一个安全的、HttpOnly 的 Session ID,以此在无状态的HTTP协议上实现用户状态的保持。


评论