回顾 Cookie

HTTP 协议自身是属于“无状态”协议

• 无状态：默认情况下，HTTP 协议的客户端和服务器之间的这次通信和下次通信之间没有直接的联系

但是在实际开发中，我们很多时候是需要知道请求之间的关联关系的

• 例如登录网站成功后，第二次访问的时候服务器就能知道该请求是否是已经登录过了

上述图片中的“令牌”通常就存储在 Cookie 字段中

比如去医院挂号：

• 看病之前先挂号，挂号时需要提供身份证号，同时得到一张“就诊卡”，这个就诊卡就相当于患者的“令牌”
• 后续去各个科室进行检查、诊断、开药等操作，都不必再出示身份证了，只要凭“就诊卡”就可以识别出当前患者的身份
• 看完病之后，不想要就诊卡了，就可以注销这个卡。此时患者的身份和就诊卡的关联关系就被销毁了（类似于网站的注销功能）
• 又来看病，可以办一张新的就诊卡，此时就得到了一个新的“令牌”

此时在服务器这边就需要记录“令牌”的信息，以及令牌对应的用户信息，这个就是 Session 机制所做的工作

---

理解 Session

会话就是对话的意思
在计算机领域，会话是一个客户与服务器之间的不中断的请求响应。对客户的每个请求，服务器能够识别出请求来自于同一个客户。当一个未知的客户向 Web 应用程序发送第一个请求时就开始了一个会话。当客户明确结束会话或服务器在一个时限内没有收到客户的任何请求时，会话就结束了

比如我们打客服电话

• 每次打客服电话，都是一个会话，挂断电话，会话就结束了
• 下次再打客服电话，就又是一个新的会话
• 如果我们长时间不说话，没有新的请求，会话也会结束

服务器同一时刻收到的请求时很多的。服务器需要清楚地区分每个请求时从属于哪个用户，也就是属于哪个会话，就需要在服务器这边记录每个会话以及与用户的信息的对应关系

Session 是服务器为了保存用户信息而创建的一个特殊的对象

---

Session 的本质就是一个“哈希表”，存储了一些键值对结构。Key 就是 Session，Value 就是用户信息（用户信息可以根据需求灵活设计）

---

• SessionId 是由服务器生成的一个“唯一性字符串”，从 Session 机制的角度来看，这个唯一性字符串称为“SessionId”。但是站在整个登录流程中看待，也可以把这个唯一性字符串称为“token”
• 上述例子中的令牌 ID，就可以看做是 SessionId，只不过令牌除了 ID 之外，还会带一些其他信息，比如时间、签名等

token 和 SessionId 是相似的，但是不一样。token 是身份的证明，SessionId 是其中一种实现方式

---

1. 当用户登录的时候，服务器在 Session 中新增一个新纪录，并把 SessionId 返回给客户端（通过 HTTP 响应中的 Set-Cookie 字段返回）
2. 客户端后续再给服务器发送请求的时候，需要在请求中带上 SessionId（通过 HTTP 请求中的 Cookie 字段带上）
3. 服务器收到请求之后，根据请求中的 SessionId 在 Session 信息中获取到对应的用户信息，再进行后续操作。若找不到，则重新创建 Session，并把 SessionId 返回

Session 默认是保存在内存中的。如果重启服务器，则 Session 数据就会丢失

---

Cookie 和 Session 的区别

• Cookie 是客户端保存用户信息的一种机制。Session 是服务器端保存用户信息的一种机制
• Cookie 和 Session 之间主要是通过 SessionId 关联起来的，SessionId 是 Cookie 和 Session 之间的桥梁
• Cookie 和 Session 经常会在一起配合使用，但不是必须配合
  • 完全可以用 Cookie 来保存一些数据在客户端。这些数据不一定是用户身份信息，也不一定是 SessionId
  • Session 中的 SessionId 也不需要非得通过 Cookie / Set-Cookie 来传递，比如通过 URL 来传递