Cookie

Cookie是一个http请求首部，当服务端响应头上标记着setCookie时，可以设置此cookie到当前域名下。浏览器端会将此cookie以kv的形式存储到内陆文件中

Session

session现实上是一种观点，示意每次会话服务器存储的用户信息

实现：

常见的手段是使用cookie来实现session。以java为例，客户端首次请求服务端后（例如登录），服务端通过setCookie 设置jsessionid （不设置cookie超时时间，浏览器对于不设置cookie超时间的cookie会在浏览器标签页关闭时自动清空这些cookie）。服务端存储这个sessionid。当客户端第二次请求服务端时，浏览器会自动将属于该域名下的cookie通过http请求首部带到后端服务器中，后端服务器跟内陆存储的sessionid举行验证来比对是否是准确用户。
既然session是个观点，那么也一定有其他的实现方式。另有一种需要前端配合的实现方式是通过页面的url中携带session信息。来实现客户端和服务端session之间的通报，不外对照贫苦与过时，这里不详细先容。

瑕玷：

1. 每次认证用户提议请求时，服务器需要去建立一个纪录来存储信息。当越来越多的用户发请求时，内存的开销也会不停增添。
2. 当用户过多时，在服务端的内存中存储的大量session信息会严重影响内存，不利便扩展。比方说当你计划用两台电脑存储session时，session的同步就很不利便。也可以使用单独的服务器使用redis来存放session信息。然则万一这一台数据库服务器宕机后，让所有正在上岸的用户重新上岸当然会让用户很不爽。

Token：

token是一种身份验证的机制，初始时客户端携带用户信息接见服务器（比如说登录），服务端接纳一定的加密计谋天生一个字符串（token）返回给客户端，客户端保留token的信息，并在接下来请求的过程中将token信息及用户信息通过httpHeader来发送给服务端。客户端跟据相同的加密算法对用户信息举行比对，天生新的token和用户发过来的token举行比对，来判断是否是准确且过时的用户。
这个时刻我们就可以考虑到其适用服务器的session也可以实现类似于token的功效，那么为什么一定要用token。我在网上找到一个值得信服的理由是：若是是开发api接口，前后端星散，更好使用token，为什么这么说呢，由于session+cookies是基于web的。然则针对 api接口，可能会考虑到移动端，app是没有cookies和session的。

实现：

1. 使用cookie来实现。使用cookie实现的话就和session差不多。这里不多加赘述。

2. 使用其他的httpHeader来实现。这就需要前端的一定配合。完整方案如下：

   • 随便设定一个响应头与请求头，比方说userToken，Authorization，前端接见后台登录接口获取到token后，将token存储在 Cookie 里或者 Local Storage中。
   • 在前端的请求ajax加一个过滤，再向后端发送请求时，先再beforSend函数中设置这个请求头。后端收到请求后也先检测划定请求头中是否携带了token而且验证token是否过时（现实开发中照样对照少用这种情形，由于直接设置一个过时时间对照长的token即可，当发现过时是就直接返回token过时即可）
   • 在前端的响应中加一个过滤，检测后端发回的token是否更新，若是更新则更新持久化的token信息（目的是token续期）

通过上面的这一套流程我们能发现使用token照样很贫苦的。需要大量的前端配合，以是这种方案真的很适合前后端星散的项目（由于前后端星散，那么前端大概率是SPA单页面应用，这种应用基本都会在ajax中加过滤，利便对统一的ajax返回的错误信息举行统一处置等）
对于服务端来说，有统一的尺度来实现token，叫JWT（ *** ON WEB TOKEN）有兴趣深入领会的话可以看下面的参考文章。

token的优势

1. 利便横向拓展 比方说我们有不用语言构建的服务，比方说java node php等等。那么我们若何做到统一登录呢，这个时刻就需要统一的验证机制。
2. 由于不再依赖cookie，以是不再有CSRF问题
3. 支持移动装备

有状态Token

现实开发过程中，我们现实上照样会把token存入服务器，这样就跟web中session基本没什么区别。由于token中内容照样对照长的，每次客户端接见服务器都带着这么长的信息，而且每次在服务器还要重新盘算举行比对照样对照花费时间和流量的。
以是我们照样要用有状态token，我们可以想象下传统session的实现：客户端频仍接见服务器只携带session_id，然后服务器通过session_id去session中查找对应的存储信息。有状态token也是使用这个逻辑：在用户之一次上岸乐成后，服务器天生token，由于token对照长，遂将其存在了服务器，然后返回客户端一个加密的tokenid，客户端每次通过这个加密的tokenid接见服务器，原理就跟session_id的流程是一样的了。
我们知道服务器的session是存储在内存中的，为了高效。同理我们将token信息也存储在服务器的内存，通用的解决方案是存储到redis中，我们知道redis的存储是基于内存的。速率会比数据库快一些，同时redis是可以设置数据的有校时间的，如果有效期为30天，在插入数据时，就可以设置该条数据的有效期为30天，30天后，redis就会自动删除该数据。那么30天后，用户携带tokenid来接见服务器，服务器去redis中查询不到信息，代表验证失败。（当搭建集群后redis显得尤为重要，分布式session就是通过redis解决的）。

感悟

手艺只是手段，差别的使用场景用差别的手艺。