Cookie 和 Session 是 Web 应用程序中用于保持用户状态的两种常见机制，它们之间既有联系也有区别。

Cookie 是由服务器在 HTTP 响应中发送给客户端（通常是浏览器）的一小段数据。客户端将这些信息保存在本地，并在后续的请求中自动将其发送回服务器。

而 Session 是在服务器端创建的一种机制，用于跟踪用户的会话状态。服务器会给每个用户分配一个唯一的会话 ID，并将该 ID 通过 Cookie 或其他方式传递给客户端。客户端随后在请求时携带会话 ID，服务器根据这个 ID 从内存或数据库中检索与该用户相关的会话数据。

1、Cookie和Session的关系

严格意义上来说，Cookie 和 Session 是没有任何关系的，但 Session 的实现中借助了 Cookie 机制。

通过以下 Session 执行的机制，我们就能知道 Session 是如何借助 Cookie 完成自己的执行流程的：

• 会话创建：通常情况下，当用户登录成功后，服务器会为该用户创建一个新的会话。在创建会话过程中，服务器会为该会话生成一个唯一的标识符，通常称为 Session ID。
• Session ID 传递：服务器将生成的 Session ID 通过响应的方式发送给客户端，使用 SetCookie 命令，将用户的 Session ID 保存在 Cookie 中，通常是一个名为 JSESSIONID 的 Cookie。
• Session 数据存储：在服务器端，Session 数据会被存储在一个能够关联 Session ID 的数据结构中（例如内存、数据库或者文件存储等）。常用的方式是将 Session ID 作为键，与对应的 Session 用户身份数据进行关联。
• Session ID 验证与检索：当用户发送一个新的请求时，客户端会将之前存储的 Session ID 携带在请求的 Cookie 或请求头中发送给服务器。服务器会根据 Session ID 找到对应的 Session 数据，从而获得用户的状态信息。
• Session 数据使用：服务器在获取到 Session 数据后，可以根据具体需求读取、修改或删除其中保存的状态信息。服务器可以通过 Session 来管理用户的登录状态、购物车内容、用户配置等。
• Session 过期与销毁：Session 有一个有效期限，一般通过设置一个固定的时间，或者在一定时间内没有用户活动时会将 Session 标记为过期。当 Session 过期时，服务器会销毁对应的 Session 数据，释放内存或其他资源。

所以默认情况下，Session 是借助 Cookie 来完成身份标识的传递的，这样服务器端才能根据 Session ID 和保存的会话信息进行关联，用于找到某个具体登录的用户，所以说：默认情况下，Session 机制是依赖 Cookie 实现的。

2、禁用Cookie后Session还能用吗？

那么问题来了，禁用 Cookie 后 Session 还能用吗？

答案是：默认情况下禁用 Cookie 后，Session 是无法正常使用的。

“

这是因为大多数 Web 服务器都是依赖于 Cookie 来传递 Session 的会话 ID 的。客户端浏览器禁用 Cookie 时，服务器将无法把会话 ID 发送给客户端，客户端也无法在后续请求中携带会话 ID 返回给服务器，从而导致服务器无法识别用户会话。

”

但是，默认情况下禁用 Cookie 后，Session 就不能用了，但可以通过一些手段来解决这个问题。

3、解决方案

以下的两种解决方案可以绕过 Cookie 继续运行 Session：

• URL 中携带 SessionID：可以通过 URL 重写的方式将 Session ID 添加到所有的 URL 中。服务器生成 Session ID 后，将其作为 URL 的一部分传递给客户端，客户端在后续的请求中将 Session ID 带在 URL 中。服务器端需要相应地解析 URL 来获取 Session ID，并维护用户的会话状态。
• 隐藏表单字段传递 SessionID：将 Session ID 添加到 HTML 表单的隐藏字段中。在每个表单中添加一个隐藏的字段，保存 Session ID，客户端提交表单时会将 Session ID 随表单数据一起发送到服务器，服务器通过解析表单数据中的 Session ID 来获取用户的会话状态。

这些方法虽然可以在禁用 Cookie 的情况下继续使用 Session，但需要在服务器端进行相应的代码修改和配置。但同时这些手段也带来了以下几个新问题：

• 增加了编码复杂度：需要改前端和后端代码才能继续使用 Session 机制，增加了编码复杂度。
• 增加了安全风险：这些替代方法可能会增加一些安全风险，因为 Session ID 将以明文形式出现在 URL 或表单中，很容易被第三方劫持和获取。

小结

Session 实现是依赖 Cookie 来存储会话 ID 的，所以默认情况下，如果禁用了 Cookie，Session 就不能使用了。

但是我们可以通过特殊的手段，例如在 URL 中传递 SessionID 或表单中使用隐藏字段传递 SessionID 的方式，配合服务器端代码的修改，是 Session 机制继续使用，但这样使用增加了编码的复杂度，和带来了一定的安全风险。