Token , Cookie , Session

HTTP 的无状态

HTTP协议是无状态的，这与HTTP协议本来的目的是相符的，客户端只需要简单的向服务器请求下载某些文件，无论是客户端还是服务器都没有必要纪录彼此过去的行为，每一次请求之间都是独立的，好比一个顾客和一个自动售货机或者一个普通的（非会员制）大卖场之间的关系一样。 但是如果能够提供一些按需生成的动态信息会使web变得更加有用，就萌发了cookie 和session 等客户端与服务器之间保持状态的解决方案。

Session -- 创建，保存在服务器中的会话

• 当用户打开某个web应用时，便与web服务器产生一个session。服务器使用session把用户的信息临时保存在了服务器上， 存放于内存。
• session是由服务器创建的，跟浏览器没有半毛钱关系，浏览器只是拿到一个session 的 ID。
• session是消耗服务器内存的，所以要合理使用session。
  缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

Cookie -- 服务器上生成，保存于客户端

• cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。
• 一个cookie的设置以及发送过程分为以下四步：
  客户端发送一个http请求到服务器端
  服务器端发送一个http响应到客户端，其中包含Set-Cookie头部
  客户端发送一个http请求到服务器端，其中包含Cookie头部
  服务器端发送一个http响应到客户端
• 局限：由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的 ； cookie 不是很安全 ， 别人可以利用储存的本地的cookie 。

Token -- 验证用户身份的令牌

• 唯一的 ，比较安全
• token 验证流程 ：
  客户端使用用户名跟密码请求登录。
  服务端收到请求，去验证用户名与密码。
  验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端。
  客户端收到 Token 以后可以把它存储起来。
  客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
  服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据。

cookie 和session

• cookie数据存放在客户的浏览器上，session数据放在服务器上。

2. cookie不是很安全，考虑到安全应当使用session。
3. session会在一定时间内保存在服务器上。当访问增多，会比较占用服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
4. 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5. 将登陆信息等重要信息存放为session,其他信息如果需要保留，可以放在cookie中
   6 . 由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择 --由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器.

token 和session

• session只提供一种简单的认证，即有此 session ID ，即认为有此 User的全部权力 ； token Token是唯一的。提供的是认证 和 授权 ，认证是针对用户，授权是针对app， 不可以转移到其它 app上，也不可以转到其它 用户上。
• 所以,如果用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 token 。如果只是自己的网站，自己的 app，用session也可以。