自认为对session、token与jwt理解还能够，此次来说讲这个话题。javascript
session翻译过来是会话，但在WEB领域经常是指会话数据：“同一客户端与服务端进行沟通时的上下文信息”，session的做用，我用一个例子来作比喻：html
假设我在滴滴平台上叫车被司机拒载后，拨通了滴滴客服电话进行投诉，通话开始，我是客户端，滴滴客服则是服务端，我每一次讲话就是发送一个请求，她每一次回复则是响应java
如下是一种可能的沟通情形：node
我：你好，我在大家平台上叫了一个车被司机拒载，我如今想投诉他。
客服MM：您好，给您带来不便很是抱歉，请问您的滴滴帐号是多少？
我：185xxxx8888。
客服MM：您好，请问您要投诉哪个行程订单？
我：今天下午3点，从南山星巴克到北山星巴克，司机车牌尾号xxx。
…web
在我与滴滴客服的此次沟通中，session数据就是沟经过程中的信息上下文（滴滴帐号、行程信息、司机车牌…），它的做用不言而喻，没有这些信息客服就不知道谁由于什么在投诉谁，因此session在这的做用是能帮助我完成这个投诉。json
经过例子，咱们能对session有一个简单理解，但对于HTTP应该如何记住session的内容却又是另一回事，也许这个案例中客服接通个人电话时便撕出了一张便签纸，便签纸的页码是ignore-sb，随后过程当中我与她沟通的信息她便记录在这张便签纸上。跨域
在一对一的客服例子中，客服一直知道是与“我”在对话，但针对HTTP的状况是：“一个客服（服务端）同时处理成百上千的投诉（客户端）”，客服面临的挑战是在串线的状况下，将投诉过程当中每个有效信息记录到对应的便签纸上。因为串线，客服没法肯定与她沟通的是哪一个投诉用户，也就不能将用户发言中的有效信息记录到对应的便签纸上，在技术上这称为HTTP协议的无状态性：“没有来电显示的多路复用通信”。浏览器
针对HTTP通讯，若是同一个客户端前后发出两个请求，在服务端，若是不借用一些特殊手段是没法得知这两个请求来自同一个客户端，这就是HTTP协议的无状态性，它致使没法追踪会话，cookie的出现就是为了解决这个问题。服务器
cookie是HTTP协议中定义的一个请求头部字段，浏览器针对这个头部字段会有一些额外处理逻辑，如自动携带、跨域检查与过时删除等，与之对应的响应头部是set-cookie，用于服务器向客户端写入cookie数据。cookie
咱们须要克服HTTP协议的无状态性，让服务端可以识别同一客户端，这样才能记录并利用session信息，针对上述例子，滴滴公司为此制订了一个投诉规则：
投诉用户若是知道本身的便签ID，则在每一次发言中必须先说：“个人便签是xxx”（cookie），而后再讲述内容，而客服则判断用户有没有讲出本身的便签ID，有则在已存在中寻找，无则从便签本中撕取，若是是撕取须要在回答的时候告知（set-cookie）用户此次撕取便签的ID，投诉用户会记住该ID并在后续的每次发言中优先说出：“个人便签是xxx”
若是你们严格遵照该规则，客服针对全部的用户发言都可以找到相应的便签并查看或更新便签上的信息，这样客服在串线状况下也能识别用户（假设串线不会打断用户的单次发言）。
在HTTP通讯中，客户端请求在特定位置讲出服务端曾经给予本身的某些信息，浏览器的这个特定位置就是cookie，这是浏览器中最多见的作法。
cookie只是一个特定位置，但session并不依赖这个特定位置，条件容许的状况下咱们能够更换成另一个位置，从而咱们知道session并不依赖cookie，若是激进一点，甚至能够说：“session与cookie没有关系”。
session也许能够脱离cookie存在，但cookie是为session而生，多年前网景公司为了解决HTTP无状态的问题而引进cookie这个HTTP头部，就是为了定义浏览器行业传输session的标准，如今全部的浏览器都支持cookie的一系列特性，如自动携带、跨域检查与过时删除等。不过随着HTTP应用场景的发展，现今不少HTTP场景也都再也不受限于浏览器内，因此认识session与cookie的关系就颇有必要，当处于在非浏览器环境下咱们能够选择扩展HTTP头部等方式携带session信息。
这一小节，我用Node.js实现了一个最简单的cookie/session的example。
session与cookie主要涉及两个HTTP头部：set-cookie与cookie，前者是一个响应头部，用来告知客户端须要记住的信息，后者是一个请求头部，用来告知服务端本身曾经记住的信息。
Talk is cheap show you the code：
// index.js const http = require('http'); const _ = require('lodash'); const session = {}; const server = http.createServer((req, res) => { let cookie = {}; // 从req.headers上获取cookie并解析为对象 _.each((req.headers.cookie || '').split(';'), item => { let [name, value] = item.split('='); cookie[name] = value; }); // 经过cookie找到session数据，这里使用's'做为sessionId的在cookie中的名称 if (cookie.s) { req.session = session[cookie.s] || {}; } // 用户首次访问（没有sessionId或者session是空） // 设置cookie并初始化session if (!cookie.s || _.isEmpty(req.session)) { req.session = { firstVisit: Date.now() }; let sessionId = Math.random().toString(16).substr(2); session[sessionId] = req.session; // 经过`set-cookie`向客户端设置cookie // 此处没有考虑多个cookie状况 res.setHeader('set-cookie', `s=${sessionId}`); } res.end(`your first visit was ${req.session.firstVisit}.`); }); server.listen(10000);// index.js const http = require('http'); const _ = require('lodash'); const session = {}; const server = http.createServer((req, res) => { let cookie = {}; // 从req.headers上获取cookie并解析为对象 _.each((req.headers.cookie || '').split(';'), item => { let [name, value] = item.split('='); cookie[name] = value; }); // 经过cookie找到session数据，这里使用's'做为sessionId的在cookie中的名称 if (cookie.s) { req.session = session[cookie.s] || {}; } // 用户首次访问（没有sessionId或者session是空） // 设置cookie并初始化session if (!cookie.s || _.isEmpty(req.session)) { req.session = { firstVisit: Date.now() }; let sessionId = Math.random().toString(16).substr(2); session[sessionId] = req.session; // 经过`set-cookie`向客户端设置cookie // 此处没有考虑多个cookie状况 res.setHeader('set-cookie', `s=${sessionId}`); } res.end(`your first visit was ${req.session.firstVisit}.`); }); server.listen(10000);经过node index.js运行server，在浏览器中访问http://localhost:10000屡次，每次显示的信息都是相同的，这就是由于根据cookie识别了同一用户，取到的session数据是相同的。
上面代码因为把session放在内存中，故不能支持水平扩展，进程重启也会致使全部session丢失，解决这两个问题的通常选择是将session数据存储在Redis中。
token，翻译过来是令牌的意思，通常用于请求须要权限校验的接口，提供一个有效token就容许访问，不然拒绝访问。
token，正常是经过身份认证而获取的一个字符串凭证，这个凭证可用于在必定时间内请求一些权限须要才能获取的资源，其中最多见的认证方式是用户名+密码。
由于认证的方式多种多样，进行身份验证后发放token做为受权，相比每次都进行身份验证显得更为灵活。好比手机号＋验证码认证与证书认证所需成本相对较大，难以在每个须要身份校验的地方都进行这种认证，因此使用token就显得很是有必要。另外，经过认证发放token的方式能相对减小原始认证要素被盗的概率，同时认证所发放的token通常具备有效期（越敏感有效期越短），也能下降被盗后的可能损失。
token之因此会跟session与cookie扯上关系，须要从用户场景进行解释，一个web服务提供者面对的用户一般分为两种：游客与登陆用户，对于游客咱们通常不存储session，而登陆用户至少须要记住其登陆状态。对于如何记住用户登陆状态，常见作法是在用户登陆时，在其对应session中记录用户ID，而对于须要登陆权限的操做，咱们能够检查用户的session中是否存在用户ID，不然拒绝操做。
上述这种借助session识别用户是否登陆的方式，客户端cookie中用于追踪session的那个值（sessionId）可被称为token，这个token一般是用户名+密码认证成功后所获得的。因而可知session与cookie跟token产生联系，是由于token的概念刚好有一个用session+cookie实现的场景。
token就是token，只是在特定场景利与session、cookie产生了联系，所以咱们彻底能够选择不借助session与cookie而使用token，好比在HTTP请求头中使用x-token头部传输token的值，又或者是在URL中携带token，这二者在现在都是较常见的作法。
json形式的网站令牌，英文全称json web token，其实与token没多大区别，无非是使用json格式传输token罢了。
jwt是token的一种，但它与传统session-token的核心区别并非由于jwt使用json格式，而是在使用方式上有所区别。前面讲到token与session及cookie的关系时，sessionId就是token，而sessionId对应的session数据保存在服务器端，通常须要持久化才能知足应用水平扩展须要。
当用户量足够大的时候，考虑到session数据的存储是单点，可能遭遇瓶颈，因而jwt出现了，它的最大优点就是能够消灭session存储这个单点。jwt的具体作法并不复杂，只是把以前存储在服务端的session数据用json格式转移到客户端存储，同时为了避免被破解和窜改会使用加密和签名两个手段。
上述描述过程当中我将session与jwt所携带的数据等同了，严格意义上他们并不等同，由于jwt携带的数据更多的是关注与受权验证有关的，而全部与会话相关的数据均可以称为session，好比我认为cookie中的全部数据均可以算是session的一部分。
综合前文，这里再对token、jwt、session、cookie作一个简述：
token是一个独立的概念，是经过认证后发放的某个“凭证”，这个凭证能够经过cookie、自定义http头部，URL的query进行传递
jwt是token的子集，采用json格式以及附带一些规范约束
session，经常用来表示会话数据，笼统点讲就是全部跟会话有关系的数据，具体点就是服务端为会话所存储的数据
cookie，浏览器下最方便传递session数据的方式
过了几天，在app内看到滴滴的投诉处理完成了，故打电话向客服询问处理结果：
我：你好，我在app内看到上次的投诉处理完成了，请问处理结果是啥？
客服MM：您好，您的投诉咱们相关部门已经处理，可是处理结果不对外公布。
我：处理结果不对外公布，那我如何知道大家已经处理？
客服MM：先生，您的投诉咱们相关部门已经处理，可是没法告知您。
我：…
客服MM：先生，处理结果是咱们相关部门已经处理。
我：…
客服MM：先生，您好，咱们公司规定处理结果不对外公布。
我：…
客服MM：先生，真的很是抱歉，咱们已经处理，可是处理结果不对外公布。
…
这是一个真实的故事，派单给司机时离我大概600米，可能不想跑了就打电话找借口让我取消，我没有答应，随后，司机把车从我眼前开走并在APP内操做已到达，5分钟后算我超时被取消，气炸了后投诉司机，最终也没能知道有没有处理以及怎么处理，这种投诉结果不对外公布是谁TM想出来的？