cookie和session

1 cookie

• http是一个无状态协议，这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。

• 人们需要更复杂的互联网交互活动，就必须同服务器保持活动状态（简称：保活）。于是，在浏览器发展初期，为了适应用户的需求技术上推出了各种保持 Web 浏览状态的手段，其中就包括了 Cookie 技术。

  用浏览器打开一个网页，用到的是HTTP协议，它是无状态的，这种无状态的的好处是快速。但是会带来一个问题，我们希望几个请求的页面要有关联，比如：我在www.a.com/login.php里面登陆了，我在www.a.com/index.php 也希望是登陆状态，但是，这是2个不同的页面，也就是2个不同的HTTP请求，这2个HTTP请求是无状态的，也就是无关联的，所以无法单纯的在index.php中读取到它在login.php中已经登陆了！
  怎么办呢？不可能这2个页面都去登陆一遍吧。或者用笨方法这2个页面都去查询数据库，如果有登陆状态，就判断是登陆的了。这种查询数据库的方案虽然可行，但是每次都要去查询数据库不是个事，会造成数据库的压力。 所以正是这种诉求，这个时候，一个新的客户端存储数据方式出现了：cookie。cookie是把少量的信息存储在用户自己的电脑上，它在一个域名下是一个全局的，只要设置它的存储路径在域名www.a.com下 ，那么当用户用浏览器访问时，php就可以从这个域名的任意页面读取cookie中的信息。所以就很好的解决了在www.a.com/login.php页面登陆了，也可以在www.a.com/index.php获取到这个登陆信息了。同时又不用反复去查询数据库。

  • 为了使某个域名下的所有网页能够共享某些数据，session和cookie出现了。

• Cookie 在计算机中是个存储在浏览器目录中的文本文件。当浏览器运行时，存储在 RAM 中发挥作用 （此种 Cookies 称作 Session Cookies）。一旦用户从该网站或服务器退出，Cookie 可存储在用户本地的硬盘上 （此种 Cookies 称作 Persistent Cookies）。

• 在客户端，一个浏览器能创建的 Cookie 数量最多为 300 个，并且每个不能超过 4KB，每个 Web 站点能设置的 Cookie 总数不能超过 20 个。

• Cookie具有不可跨域名性。Cookie在客户端是由浏览器来管理的。浏览器能够保证Google只会操作Google的Cookie而不会操作 Baidu的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Baidu的域名 不一样，因此Google不能操作Baidu的Cookie。

• 客户端访问服务器的流程：

  • 首先，客户端会发送一个http请求到服务器端。
  • 服务器端接受客户端请求后，建立一个session，并发送一个http响应到客户端，这个响应头，其中就
    包含Set-Cookie头部。该头部包含了sessionId。Set-Cookie格式如下，具体请看Cookie详解
    Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
  • 在客户端发起的第二次请求，假如服务器给了set-Cookie，浏览器会自动在请求头中添加cookie
  • 服务器接收请求，分解cookie，验证信息，核对成功后返回response给客户端

2 session

• Session是对于服务端来说的，客户端是没有Session一说的。Session是服务器在和客户端建立连接时添加客户端连接标志，一般存于服务器内存或硬盘中。最终会在服务器软件（Apache、Tomcat、JBoss）转化为一个临时Cookie发送给给客户端，当客户端第一请求时服务器会检查是否携带了这个Session（临时Cookie），如果没有则会添加Session，如果有就拿出这个Session来做相关操作。

  虽然使用cookie这种方案很不错，也很快速方便，但是由于cookie 是存在用户端，而且它本身存储的尺寸大小也有限，最关键是用户可以是可见的，并可以随意的修改，很不安全。那如何又要安全，又可以方便的全局读取信息呢？于是，这个时候，一种新的存储会话机制：session 诞生了。
  Session 就是在一次会话中解决2次HTTP的请求的关联，让它们产生联系，让2两个页面都能读取到找个这个全局的session信息。session信息存在于服务器端，所以也就很好的解决了安全问题。

3 token

• 令牌，是用户身份的验证方式。

• token在客户端一般存放于localStorage，cookie，或sessionStorage中。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。

• 流程与cookie相似：

  • 当用户首次登录成功（注册也是一种可以适用的场景）之后, 服务器端就会生成一个 token 值，将这个token值返回给客户端。
  • 客户端拿到 token 值之后,进行本地保存。
  • 当客户端再次发送网络请求(一般不是登录请求)的时候,就会将这个 token 值附带到参数中发送给服务器.
  • 服务器接收到客户端的请求之后，首先验证Token，之后返回数据。

• 服务端不需要保存Token，只需要对Token中携带的信息进行验证即可。无论客户端访问后台的那台服务器，只要可以通过用户信息的验证即可。

4 联系

• session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。这种方法中session依赖cookie。
• cookie就是写在客户端的一个txt文件，里面包括登录信息之类的，这样下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也需要在客户端写入cookie文件，客户端只有session id。
• cookie只是实现session的其中一种方案。虽然是最常用的，但并不是唯一的方法。禁用cookie后还有其他方法存储，比如放在url中。

5 区别

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

• cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。

• session会在一定时间内保存在服务器上。当访问增多，会比较占用服务器的性能，考虑到减轻服务器性能方面，应当使用cookie。

• 建议：将登陆信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中。

• session和 token并不矛盾，作为身份认证token安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击，而session就必须靠链路层来保障通讯安全了。

• token可以抵抗csrf（跨站请求伪造），cookie+session不行。

  假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单，该表单提交src为http://www.bank.com/api/transfer，body为count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击。

• session时有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。而token是无状态的，token字符串里就保存了所有的用户信息（无状态是指服务器端不存储用户信息，每次对用户token解密读取信息进行验证）。

  • 负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享session。这个问题也可以将session存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。当今的几种解决session负载均衡的方法。
  • 客户端登陆传递信息给服务端，服务端收到后把用户信息加密（token）传给客户端，客户端将token存放于localStroage等容器中。客户端每次访问都传递token，服务端解密token（不需要存储），就知道这个用户是谁了。通过cpu加解密，服务端就不需要存储session占用存储空间，就很好的解决负载均衡多服务器的问题了。这个方法叫做JWT(Json Web Token)

【参考文档】
Cookie、Session、Token那点事儿
彻底弄懂session，cookie，token
服务器验证——token
cookie和session详解