这篇文章其实源于一次个人面试经历。java
那次我面对是一位老面试官，真的颇有东西。web
那次面试我和他叨叨了两小时....我滴妈我嘴巴都干了真的。面试
他的提问都颇有深度，能够说对个人学习之路有很大的帮助。跨域
我记得有个问题，差很少是面了一个小时的时候他问我：Cookie、Session、Token知道的吧？浏览器
我说：知道。安全
那你从演进的角度来说讲 Cookie 、Session、Token？服务器
我当时就懵了，单独的说我都清楚，这演进的角度让我一下不知从何提及。微信
这个面试官会从各个角度去感觉我对一个知识点究竟是背的，仍是有本身理解的。网络
他提问的方式真的颇有东西，他也给我反馈了不少他的理解，相谈甚欢，真的。session
就这个问题他从 HTTP 无状态开始慢慢的引导我.....
他的这波引导其实就串联起了这一系列的知识点，零散的东西就被他整理的明明白白。
因此后来的学习我都喜欢找原因，也就是为何。
也是我一直强调的要知道：为何会有这个东西的存在，这个的东西是为了解决什么痛点。
起初是由于我怕面试官再问我这样的问题。
如今是由于就应该这样学。
今儿就来捋捋以前面试官问个人这个题的。
正文
1990 年。
蒂姆·伯纳斯·李建立了 HTTP 协议。
李老的想法是把文档存储在服务器中，谁须要这个文档直接从服务器获取便可。
按照这个思想，当时的需求只有 GET。
而且按照拿文档的思路：拿完了链接就能够断了，也不须要什么交互。
因此 HTTP 起初的设计就是无状态的。
也就是请求和请求之间是没有关联的。
而随着互联网的发展，交互开始兴起。
人们再也不知足简单的静态文件获取，各类购物、社交接踵而至。
这意味着服务器须要判断每一个请求的发起者是谁，也就是须要状态。
你聊天总得代表你是谁，而且和谁聊吧？否则服务器可不知这聊天信息得发给谁。
你购物总得让服务器知道是谁买了这玩意吧？
总不能你买完了下线，再上线发现你买的东西没了。
这时候就是须要一种技术让请求与请求之间创建起联系，让请求变得有状态。
这技术叫 Cookie，就是一个以 Key-Value 格式存储的小文件，保存在客户端本地。
好比登陆以后，服务器就能设置 Cookie 返回给浏览器，而后保存在本地。
随便截了个百度的，列出来的就是 key，下拉箭头打开里面就有 value。
以后对百度的请求就能够带着 Cookie 去访问服务器，这里假设 BAIDUID 是用户 ID。
百度的服务器一看原来是这个 ID 啊，就知道是“我”请求了，这就有状态了。
简单地说 Cookie 就是存储在本地的一份文件，每次请求都会带上 Cookie 去访问服务器。
因此把一些用户信息塞到 Cookie 里，这样服务器就能判别是哪一个用户的请求了。
注意 Cookie 是有域的划分的，来看下这个图：
也就是每一个域下面都有各自的 Cookie ，访问不一样的网站带属于这个网站的 Cookie ，不会带别人的 Cookie ，否则就乱套了。
可是 Cookie 是明文存储在用户本地，并且带有大量的用户信息这不太安全。
而且每次请求都须要带这么多 Cookie 对带宽来讲也不太划算。
Session 就解决了这个问题，Session 就是会话，它有更加普遍的含义，在和 Cookie 这些一块儿谈论的场景，咱们把它狭义化。
Session 就是把用户的会话信息存储在服务端。
而后颁发给客户端一个 sessionId，让客户端以后带着 sessionId 来请求。
这样服务端就能够经过 sessionId 去找到这个用户的信息，从而识别请求。
那客户端是如何带上 sessionId 的？
这个 sessionId 仍是按照 Cookie 的形式存储在用户的本地，发起请求的时候带上便可。
可是把这种状态信息存储到服务器中使得服务器就有状态了。
通常咱们部署在线上的服务器会有多台来作负载均衡，也互相做为 backup。
因此若是 Session 的信息存在某一台机器上，那么当下一次请求被负载分到另外一台机器那就找不到这个 Session 信息了。
也就不认得这个请求了，可能的现象就是告诉用户没登陆，那用户不就傻了。
我这刚还登陆着呢，这就告诉我没登陆了？
因此处理方式有 session 复制，就是服务器之间互相同步 session，这样不论请求到哪一个服务器都有用户的信息。
不过这复制就冗余了，有额外的开销。
还有一种就是 session sticky，其实就是把你的请求一直粘在某一个服务器上，若是你请求的一开始被指派的是 A 服务器，那么以后的全部请求都只会被指派到 A 服务器上。
可是若是 A 服务器挂了，你的请求仍是会被指派到别的服务器上，这样一来用户登陆信息仍是会丢了。
能够看到复制和 sticky 都有缺陷，因此能够把 session 放到第三方存储，好比 Redis 里。
这样服务器等于又没状态了。
而服务器的无状态意味着能够随意伸缩，服务集群根据流量加几台减几台，很方便。
可是把 session 放第三方存储上只是把这个维护从服务器转嫁到第三方身上。
第三方得保证它的高可用，否则用户登陆信息又会丢了。
不过通常而言咱们的系统原本就要维护的第三方存储，因此影响不大。
小结一下：Cookie 明文存储在本地不太安全，因此想着把用户状态存在服务端，而 Session 就是将用户状态信息保存在服务端。
就暴露 sessionId 给客户端，这样相对而言安全些，而且也减小了网络流量。
但这样服务端就有状态了，难以扩展。
所以能够把 Session 放到第三方存储上，可是等于状态仍是由服务端维护。
Token
其实仔细想一想，是否是不须要在服务端存储用户的信息？
只须要一个能表明身份的凭证便可，一个服务端颁发给用户凭证，以后的请求让用户带着这个凭证就行。
就像咱们的身份证，就表明咱们。
这个凭证里面就包含了用户的信息，有人可能怕凭证被伪造。
没事，把凭证给签名了，这样咱们服务器就能验证凭证的真伪。
和别人作不得假身份证同样。
这种凭证叫 Token。
若是一个用户登陆了系统，我就返回一个 Token 给他，以后每次请求他带着这个 Token 来就行。
服务器验证了真伪以后拿到 Token 里面的用户信息就知道这个请求是谁发的了。
这样服务器就无状态了，是真的无状态了，固然客户端有状态了。
由客户端来保存 Token ，这样是最合理的，不须要在服务端冗余数据。
有了 Token 以后服务器由于无状态因此可扩展，而且 Token 还能跨应用使用。
好比同一个公司不一样应用之间的调用，全部应用只要能识别这个 Token 就都能登陆。
一个 Token 就搞定了，不用每一个网站都登陆一遍，这就是单点登陆。
若是是第三方服务提供方也更容易地提供服务，只须要颁发一个 Token 给调用者便可。
Token 简单的说就是一个含有凭证信息的令牌，只要服务器能识别这个令牌就能根据令牌的身份进行相应的响应。
其实这还蕴含了时间换空间的思想，把存储在服务器的用户信息暴露出去，利用签名来验证 Token 的真伪。
这样每次请求都须要耗费时间去验签，不过好处就是不须要存储信息，也就是时间换空间。
最后
其实像 Cookie + Session 除了可扩展还有跨域啊、跨站伪造请求等问题。
像 Token 更加灵活，在移动端等场景也更加的适用。
有关文章所讲的演进看起来好像就是 Cookie => Session =>Token 。
不是的，这几个东西都颇有用，文章只是单从认证这一方面来看罢了。
欢迎加我好友进行深刻地交流，备注「进群」，拉你进交流&内推群。
平日的面试题遇到难处，或者看某个知识点翻遍全网的资料仍是感受很模糊、不透彻，能够私聊我，给我留言。
遇到合适的我会整理写出一篇文章，注意这个前提我认为合适的。
那种工做遇到很细节的场景的仍是别了，这种问你上司比较合适:)。
我是 yes，从一点点到亿点点，欢迎在看、转发、留言，咱们下篇见。
本文分享自微信公众号 - yes的练级攻略（yes_java）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。