---

前言

本文章主要介绍cookie、session、jwt，帮你快速了解它们的原理和区别，适合新手初步快速了解这部分的基础概念和知识。

---

一、首先了解http的cookie是什么？

Cookie 是一种在客户端（通常是浏览器）与服务器之间交换数据的方式，主要用于维持用户的状态信息。根据其用途和特性，Cookie 可以分为不同的类别，并且每个 Cookie 都可以设置多个属性来控制其行为。
可以用于跟踪用户与网站的互动、存储用户相关信息以及保持用户状态等，这样当请求携带 cookie 时，信息会被读取以帮助网站记住用户的访问信息和偏好设置，使得网站能够为用户提供个性化的浏览体验，并可以用于追踪用户在网站上的行为。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

cookie由于是客户端保存，所以一般不会保存敏感信息。

Cookie 属性及其含义

以下是设置 Cookie 时可以使用的常见属性：

1. Name=Value

描述：指定 Cookie 的名称和值。
示例：

Set-Cookie: sessionId=abc123

2. Expires

描述：指定 Cookie 过期的具体日期和时间（GMT 格式）。如果没有设置，则为 Session Cookie。
示例：

Set-Cookie: sessionId=abc123; Expires=Wed, 21 Oct 2025 07:28:00 GMT

3. Max-Age

描述：指定 Cookie 多少秒后过期。如果同时设置了 Expires 和 Max-Age，Max-Age 优先级更高。
示例：

Set-Cookie: sessionId=abc123; Max-Age=3600

4. Domain

描述：指定哪些域名可以访问该 Cookie。默认情况下，只能由设置它的域名访问。设置 Domain 属性后，不仅当前域名下的页面可以访问这个 Cookie，指定的域以及其子域也能访问。例如，如果一个Cookie 的 Domain 属性被设置为 example.com ，那么 www.example.com 和subdomain.example.com 等都可以访问这个 Cookie。这有助于跨子域共享 Cookie信息，但也需要谨慎使用以避免安全问题。
示例：

Set-Cookie: sessionId=abc123; Domain=.example.com

5. Path

描述：指定 Cookie 可用的路径。只有位于该路径下的页面才能访问此 Cookie。如果设置了 Path=/blog ，那么只有网址下的 /blog 目录及其子目录中的页面能够访问这个 Cookie。这有助于限制 Cookie 的访问范围，确保只有特定部分的网站可以使用该 Cookie，从而提高网站的安全性和数据的准确性。
示例：

Set-Cookie: sessionId=abc123; Path=/admin

6. Secure

描述：指示浏览器仅通过 HTTPS 协议发送此 Cookie。Secure 属性设置后，Cookie 只会在 HTTPS 请求中被发送。这有助于防止 Cookie 在数据传输过程中被窃听，增强了用户数据的安全性。
示例：

Set-Cookie: sessionId=abc123; Secure

7. HttpOnly

描述：防止 JavaScript 访问此 Cookie（通过 document.cookie），有助于防范 XSS 攻击。
示例：

Set-Cookie: sessionId=abc123; HttpOnly

8. SameSite

描述：控制是否允许跨站请求携带此 Cookie。有三个可能的值：
Strict：完全禁止跨站请求携带此 Cookie，只允许来自相同站点的请求发送 Cookie。
Lax：仅允许某些“安全”的跨站请求（如 GET 请求）携带此 Cookie，例如从其他网站导航到链接的情况。
None：允许跨站请求携带此 Cookie，但必须与 Secure 标志一起使用。

不设置SameSite属性和将SameSite设置为None在效果上不完全相同，未明确设置 SameSite 属性时，浏览器可能会使用默认行为，这在不同的浏览器和版本中可能有所不同。而明确将 SameSite 设置为 None 则指示浏览器在所有跨站请求中发送 Cookie，但这必须与 Secure 属性一起使用，以确保Cookie仅通过 HTTPS传输。因此，明确设置提供了更明确的控制和跨浏览器的一致性。

示例：

Set-Cookie: sessionId=abc123; SameSite=Lax

示例

假设你有一个网站需要设置一个 Cookie 来记住用户的语言偏好，并确保这个 Cookie 只能通过 HTTPS 发送且不能被 JavaScript 访问：

Set-Cookie: language=en-US; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Secure; HttpOnly; Path=/; SameSite=Lax

在这个例子中：

language=en-US 指定了 Cookie 的名称和值。
Expires 设置了 Cookie 的过期时间。
Secure 确保 Cookie 只能通过 HTTPS 发送。
HttpOnly 防止 JavaScript 访问此 Cookie。
Path=/ 表示此 Cookie 对整个站点都可用。
SameSite=Lax 控制跨站请求的行为。

Cookie 分类

1. Session Cookies

定义：这些 Cookie 在用户的会话期间存在，当浏览器关闭时通常会被删除（除非设置了过期时间）。它们不包含 Expires 或 Max-Age 属性。
用途：主要用于短期存储用户状态信息，如登录状态或临时购物车内容。
特点：依赖于浏览器会话，没有持久化存储。

2. Persistent Cookies

定义：这些 Cookie 具有明确的有效期，即使关闭浏览器后仍然存在。通过 Expires 或 Max-Age 属性设置过期时间。
用途：用于长期保存用户偏好设置、跟踪信息等。
特点：可以在多次会话之间保持有效，直到达到设定的过期时间。

3. First-Party Cookies

’定义：由用户正在访问的网站直接设置的 Cookie。
用途：主要用于个性化体验、记住用户偏好、维持会话状态等。
特点：只能被设置它的域名访问。

4. Third-Party Cookies

定义：由第三方域（如广告网络或社交媒体插件）设置的 Cookie。
用途：常用于跨站追踪用户行为、提供个性化广告等。
特点：可能会引发隐私问题，许多现代浏览器默认限制或阻止此类 Cookie。

二、 Session

session在网络应用中称为“会话控制”，是服务器为了保存用户状态而创建的一个特殊的对象。简而言之，session就是一个对象，用于存储信息。 服务器会为每一个游览器(客户端)创建一个唯一的session。这个session是服务器端共享，每个游览器(客户端)独享的。我们可以在session存储数据，实现数据共享。
Session 是一种用于在 Web 应用程序中维持用户状态的机制。尽管 Cookie 通常被用来存储和传输与会话相关的标识符，但 Session 本身是由服务器端管理的，并且可以包含比 Cookie 更多、更复杂的数据。

Session 工作机制

原理：

session是每一个游览器(客户端)所唯一的，这个是怎么实现的呢？其实，在访问一个网站时，在HTTP请求中往往会携带一个cookie，这个cookie的名字是JSESSIONID，这个JSESSIONID表示的就是session的id，这个是由服务器创建的，并且是唯一的。服务器在使用session时，会根据JSESSIONID来进行不同操作。

创建 Session：

当用户首次访问网站并需要开始一个会话时（例如登录），服务器会创建一个新的 Session 并生成一个唯一的 Session ID。
这个 Session ID 通常通过 HTTP 响应头中的 Set-Cookie 发送到客户端，并保存为一个 Cookie。

存储 Session 数据：

服务器将与该用户会话相关的所有数据存储在服务器端。这可能包括用户的身份验证信息、购物车内容、偏好设置等。
存储位置可以是内存、文件系统、数据库或分布式缓存（如 Redis）。

使用 Session：

在后续请求中，客户端会在每个请求中自动发送包含 Session ID 的 Cookie。
服务器接收到来自客户端的请求后，通过解析 Cookie 头中的 Session ID 来查找对应的 Session 数据，并恢复用户的会话状态。

销毁 Session：

当用户注销或会话超时时，服务器会删除相应的 Session 数据，并可能指示客户端删除对应的 Cookie。

session常用方法

resquest.getSession()： 得到请求游览器(客户端)对应的session。如果没有，那么就创建应该新的session。如果有那么就返回对应的session
setAttribute(String s, Object o)： 在session存放属性
getAttribute(String s)： 从session中得到s所对应的属性
removeAttribute(String s)： 从session中删除s对应的属性
getId()： 得到session所对应的id
invalidate()： 使session立即无效
setMaxInactiveInterval(int i)： 设置session最大的有效时间。注意，这个有效时间是两次访问服务器所间隔的最大时间，如果超过最大的有效时间，那么这个session就失效了。

Session 和 Cookie 的关系

Session ID 通过 Cookie 传输：虽然 Session 数据存储在服务器端，但为了识别用户并恢复其会话状态，服务器依赖于客户端发送的 Session ID。这个 Session ID 通常是通过 Cookie 从服务器传递到客户端并在每次请求中返回给服务器的。
Cookie 和 Session 本质上是两种不同的技术，用于解决 HTTP 无状态协议下的状态管理问题，但它们的实现方式和适用场景有显著差异：

1. Cookie（客户端存储）

定义：

Cookie 是由服务端生成并发送给客户端的一小段数据（键值对），由客户端（如浏览器）保存，并在后续请求中自动携带回服务端。

特点：

数据存储在客户端（浏览器本地）。

每次请求自动附加到请求头的 Cookie 字段中。

用途：

记录简单、非敏感的状态（如用户主题偏好、追踪ID）。

仅用 Cookie 的场景（无 Session）
假设服务端不使用 Session 技术，直接通过 Cookie 管理状态：

示例：

服务端设置 Cookie：Set-Cookie: username=Alice; theme=dark。

客户端保存 Cookie，后续请求自动携带：Cookie: username=Alice; theme=dark。

服务端逻辑：直接读取请求头中的 Cookie 值（如 username=Alice）。无需在服务端存储任何信息，直接基于 Cookie 的值处理请求（例如显示“欢迎 Alice”）。

局限性：

安全性低：Cookie 存储在客户端，可被篡改（如用户手动修改 username=Admin）。

无法存储敏感数据：密码、权限等信息不应通过 Cookie 直接传递。

2. Session（服务端存储）

定义：

Session 是服务端存储的用户会话数据（如登录状态、购物车内容），通常通过一个 Session ID 标识客户端身份，而 Session ID 一般通过 Cookie 传递。

特点：

数据存储在服务端（如内存、Redis、数据库）。

通过 Session ID 关联客户端（客户端只需保存 Session ID）。

用途：管理敏感或复杂的状态（如用户登录凭证）。

关键点：

服务端仅存储 Session ID 与会话数据的映射，不存储客户端 Cookie 本身。

Session ID 是客户端和服务端之间的“钥匙”，确保安全性的核心在于保护 Session ID（如使用 HTTPS、设置 HttpOnly 标志）。

三、认识JWT

1.什么是JWT呢？

JWT 是一种 开放标准（RFC 7519） 的 Token 格式，用于在各方之间安全传输 JSON 数据。它通过签名或加密确保数据的完整性和可信性，常用于身份验证和授权。

2.JWT 的核心结构

JWT 由三部分组成，以 . 分隔：

Header.Payload.Signature

Header（头部）

描述 Token 类型和签名算法（如 HMAC、RSA）。

示例：

{"alg": "HS256",  // 签名算法"typ": "JWT"     // Token 类型
}

Payload（负载）

包含需要传输的 声明（Claims），分为三类：

• 预定义声明：如 exp（过期时间）、sub（用户ID）。

• 公开声明：可自定义，但需避免冲突（参考 IANA JWT Registry）。

• 私有声明：应用自定义的数据（如 user_role）。

示例：

{"sub": "1234567890","name": "Alice","admin": true,"exp": 1717029200  // 过期时间戳
}

Signature（签名）

将 Header 和 Payload 用 Base64Url 编码后拼接，再通过 密钥（Secret） 或 公私钥 进行签名，防止数据篡改。

示例（HMAC-SHA256 算法）：

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret_key
)

3.JWT 的工作流程

用户登录

客户端提交用户名密码。

服务端验证通过后，生成 JWT 并返回给客户端（通常通过 Authorization: Bearer 头或 Cookie）。

客户端存储 JWT

客户端保存 JWT（如浏览器 LocalStorage、Cookie 或移动端本地存储）。

后续请求

客户端在请求头中携带 JWT：

GET /api/profile HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

服务端验证签名和有效期，直接解析 Payload 获取用户信息，无需查询数据库。

Token 过期或失效

客户端需重新登录或使用 Refresh Token 获取新 JWT。

4.JWT 与 Session 的核心区别

5.JWT 的优缺点

优点

• 无状态：适合微服务、分布式系统，服务端无需维护会话。
• 减少数据库压力：用户信息直接包含在 Token 中。
• 跨域支持：可轻松用于跨域认证（如 OAuth2）。
• 灵活性：可携带自定义数据（如用户角色、权限）。

缺点

• 无法即时失效：Token 一旦签发，在过期前始终有效（需结合黑名单机制）。
• 数据膨胀：Token 大小随 Payload 增加而增大，可能影响性能。
• 安全性依赖客户端存储：Token 存储在客户端，易受 XSS 攻击窃取。
• 敏感数据暴露：Payload 默认仅 Base64 编码（非加密），需避免存储敏感信息。

注意（JWT 安全实践）：

使用 HTTPS：防止 Token 在传输中被窃听。

短期有效：设置较短的过期时间（如 15 分钟），配合 Refresh Token 续期。

HttpOnly + Secure Cookie：若通过 Cookie 存储，启用安全属性。

签名算法：使用强算法（如 HS256、RS256），避免 none 算法。

黑名单机制：针对需主动失效的 Token，维护一个短期的黑名单。

5.JWT 与 Session 的选择场景

总结

本文首先介绍了http中的cookie，然后随着技术和业务场景的发展，进一步介绍了session和jwt，可以帮初学者快速了解这方面的知识，比较他们的优缺点和实用场景

引用参考：

HTTP Cookie 你了解多少？
【HTTP完全注解】一文重新认识Cookie
Session详解，学习Session，这篇文章就够了(包含底层分析和使用)
JWT详细教程与使用