Cookie、Session、Token的区别

有人或许还停留在它们只是验证身份信息的机制，但是它们之间的关系你真的弄懂了么？

发展史：

Coolie:

       Netscape Communications 公司引入了 Cookie 概念，作为在客户端存储状态信息的一种方法。初始目的是为了解决 HTTP 的无状态性，使网站能够记住用户并保持状态。

Session:

HTTP 1.0 引入了基本的会话管理，通过在请求头中添加 "Cookie" 字段来传递会话标识符。

Token:

       随着移动应用和 API 的兴起，基于 Token 的身份验证得到了更多关注和应用。OAuth 2.0 的标准化推动了令牌在 web 开发中的应用，支持无状态的身份验证和授权。

---

       在以前，你去登录一个网站，没有个人的分别，所以也区不区分也无关紧要，但是随着互联网的发展，互联网越来越重视你是谁？所以cookie就诞生了，它是一个存储在客户端的一小段数据，当用户登录的时候，由服务端发送给客户端并存储在客户端本地，这样就可以验证用户信息

但是这样岂不对程序员美滋滋，我们假设有一个小穷（程序员）还有一个老富（顶级富豪）

账户转钱：

老富：

 小穷：

 有一天，小穷通过技术手段搞到了老富的cookie，结果小穷差点吃公家饭 

 

       基于cookie这种不安全性，session逐渐问世，它是一种会话机制，用户信息存储在服务器上，这样就相对于cookie比较安全

 小穷这时候留下了悔恨的眼泪！！！

       但是随着时代的发展，由于用户越来越多，一台服务器已经扛不住了，单体架构逐渐被淘汰，分布式逐渐登上了历史的舞台，这时候，问题又来了，由于分布式是采取负载均衡的方式采取服务器请求的，所以我们不能仅限于一台服务器进行存储session，总不能每次发送请求的时候都要进行一次身份验证，那么当时就有两种情况可以解决这个问题：

1.单独拎出来一个服务器，专门作为session的验证

2.在每个服务器上都存储一份session

       这两种方式显然对资源的一种浪费，数以千万计的用户的session占用的内存可不是一个小数目，所以我们的下一个主角又登场了——Token

         Token是一种轻量级的身份验证和授权机制，一般是一小段字符串，当每次用户成功登录或请求时，服务器会生成一个Token（用户ID、角色、权限以及一些元数据），通过使用密钥对其进行加密和签名确保安全性，下一次客户端访问时携带Token，服务器用相同的密钥进行解密和检验签名，确保安全性

 使用Token的效果既保障了安全问题又避免了资源浪费

 Token的优点真的数不胜数，列几点：

• 安全性：经过了层层加密（加密和签名）确保完整性和安全性
• 无状态：服务器不需要在本地存储会话数据，不需要维护会话状态，更加容易扩展与分布式部署
• 跨域支持：Token可以通过HTTP请求头、URL参数或者Cookie发送
• 灵活性：携带自定义的用户信息
• 性能：无需服务器存储和查询会话状态，提供服务器的性能和响应速度
• 轻量级：比传统的会话更加轻量级（不需要在服务器上存储状态信息）
• 可扩展性：方便的扩展以及适应不同的需求
• 单点登录：登录一次访问多个关联应用
• 可移植性：不依赖于特定的编程语言

---

Cookie:

       Cookie是存储在用户浏览器中的小段数据，由服务器发送给客户端并存储在客户端本地。它通常用于持久性存储一些用户相关的信息，如登录凭证、用户偏好设置等，Cookie可以设置过期时间，可以是会话级别的（在用户关闭浏览器后过期）或者是长期的（设置特定的过期时间），由于存储在客户端，Cookie可以在用户访问不同页面时被浏览器自动发送到服务器

Session:

       会话是一种服务器机制，用于跟踪用户在网站上的活动，服务器在用户访问网站时为每个用户创建一个唯一的会话标识（Session ID）,这个标识存储在Cookie中或者通过URL参数传递，然后，服务器可以根据会话标识来识别特定的用户，并在服务器端存储用户状态信息，以便跟踪用户的状态和数据，会话数据通常在服务器上存储，因此相对安全

Token:

       Token是一种轻量级的身份验证和授权机制，广泛用于构建于API的 应用和单点登录系统，用户登录后，服务器会颁发一个Token，包含有关用户身份的信息和一些元数据，这个Token被用户保存，并在每次向服务器发送请求时随请求一起发送，服务器可以验证Token的有效性，并根据Token中的信息执行身份验证和授权，Token可以是短期的，也可以是长期的，但是为了安全性通常会有过期时间