之前遇到一位老面试官，问我的问题真的有点东西

这篇文章其实源于一次我的面试经历。

那次我面对是一位老面试官，真的很有东西。

那次面试我和他叨叨了两小时....我滴妈我嘴巴都干了真的。

他的提问都很有深度，可以说对我的学习之路有很大的帮助。

我记得有个问题，差不多是面了一个小时的时候他问我：Cookie、Session、Token知道的吧？

我说：知道。

那你从演进的角度来讲讲 Cookie 、Session、Token？

我当时就懵了，单独的说我都清楚，这演进的角度让我一下不知从何说起。

这个面试官会从各个角度去感受我对一个知识点到底是背的，还是有自己理解的。

他提问的方式真的很有东西，他也给我反馈了很多他的理解，相谈甚欢，真的。

就这个问题他从 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 。

不是的，这几个东西都很有用，文章只是单从认证这一方面来看罢了。