Session?Cookies?token?

发展历程

1. session 的出现

在遥远的以前，WEB 据说只是用来作为浏览的手段存在的。所以当时并不需要存储是哪个客户端和服务器进行了交互，并不需要管理这堆客户端，完全可以把每一次请求当成是新的请求来处理。

可是好景不长，随着时代发展，WEB 不仅是用于浏览了，也开始用于一些简单的交互场景。这个时候，没有记录是哪个客户端访问的服务器没有办法在这样的时代混下去了。于是有人就想出了一个方法，利用一个 id 来记录谁是谁。而这个 id 就是现在的 session id。

是的，只有这个也不够用。于是 session 并不只是一个只有唯一标识的存在。它用来保持了整个会话的状态，也就是说能从 session 里取到会话需要的信息。

2. Cookies 的出现

可是问题来了，服务器用这个 id 来标识是哪个客户端可以，可是这个 id，能存哪呢？

据说一开始有人提议把这个 session id 存放在服务器上，然后每次有客户端是第一次发请求过来的时候就给它分配一个，让客户端自己想办法存起来。

时代不缺聪明鸡贼的人，然后有人就根据上面的思想创造了一种叫做 Cookies 的东西，作为客户端，也就是浏览器，的存储机制。

通过利用 Cookies 存储 session id，就解决了一半的问题了。只要保证客户端每次发送请求的时候都携带上这个 Cookies 里的内容，就能告知服务器这个客户端上次的会话内容，也就是能取到对应的 session 了。

是的，该转折还是要转折的。

3. 番外——集群与负载均衡

其实不用想也知道，每一个客户端和服务器进行交互，服务器都需要存储起这个 session id，当用户量或者说访问量变大的时候，服务器就撑不住了。

服务器也是服务器啊，它也是有压力的。

所以就开始出现两种技术，分别是集群和负载均衡。

由于重点不是这个，所以只是说一下出现的原因，有兴趣的强烈建议自行 google。

但是这样也太麻烦了，如果有一个新的请求，服务器需要将这个 session 共享到每个服务器上，太麻烦了。

是的，转折又来了，而且我还不换点。

为了避免这种情况，有人就提出了能不能把所有的 session 记录在一个地方，然后每次都利用这个服务器去进行操作。这样一来减轻了服务器的压力同时也减轻了开发者的压力。

想法确实很美好，不过仔细想想就能明白，他这套方案为什么不好。

一段时间后，某台存 session 的服务器突然宕机。整个世界都寂静了，逐渐这个想法回归了只是个想法。

4. token 的出现

这里应该接到第二点去看，因为第三点是番外，请把番外理解成一个广告，这样就能懂为什么不续着了。

人总是爱折腾，不折腾怎么去创造新东西呢？所以 token 出现了，当然，还是要说一下它为什么出现的。

还记得 Cookies存在哪吗？是浏览器。浏览器这种东西，谁能保证它安全呢？甚至我作为一个开发者都不敢保证服务器安全，又怎么能寄希望于浏览器会很安全呢？

为什么说安全问题，是因为浏览器存储了 session id，也就是说攻击者只要取到客户端的 Cookies 就能拿到对应的 session id，能想象吗？拿到 session id 之后，攻击者只要伪造一下请求，发送给服务器，傻乎乎的服务器是没办法知道这个 session id 居然是盗取的！

由于服务器只能够通过这个 id 来判断客户端是谁，所以没有办法，只能被骗。开发者辛辛苦苦制造出一个性能好的 WEB 应用，哪能这么简单就被攻破了？程序员不要面子哒？

所以人们就开始想各种办法，其中有一个也是现在最常用的就是 token。token 机制解决了 session 的状态问题，使客户端发来的请求可以被检验，这也就意味着当请求不合法的时候服务器有主动权了，不再是被动的只能被骗了。

token 的机制可以通过下一篇文章或者自行 google 了解。

5. 终章

是的，终章逃不过转折。

其实只是单纯的转个折。

每一个东西的发展都是有它的缘故的，了解了它是为什么被广泛应用后，才能熟练运用这个东西。

希望故事能帮到你，发展大概就是这样发展的，至于那些有个人全是编的，看看就好。