session , token , sign

---

 

首先，我们知道session和token都是为了协助用户访问web服务器的一种介质。那么先看一下web的发展史吧，为什么我们要使用session或者token，然后他们两有什么区别呢？

早期我们的web访问都是单纯文本类容，例如新闻，没有用户交互，不过后来我们有了购物网站这样的web应用，那么想想如果张三第一次访问购物网站添加了一个商品到购物车，然后第二次访问的时候如何找到这个购物车的商品，是不是服务器要通过第二次的访问参数知道这个人就是张三，才能查询出他购物车的商品。那么你们会想，这很简单，我们在张三登录的时候给他一个用户id，那么下次访问的时候浏览器通过特定的参数让服务器拿到这个用户id就可以了，第一种最简单暴力的方法，那么就是服务器端登录的时候在返回结果的时候直接设置cookie保存这个用户id，下次访问的时候传递过来就行了，还有就是利用session。

session是怎么实现的呢？首先session是服务器端存储信息的一个容器，每个session就像一个单独的个体，有自己唯一的名字（sessionId），登录的时候生成一个sessionid传给浏览器，因为session实际是一个容器，那么我们就可以把用户的id存进这个容器之中，那么用户访问的时候传递sessionid给服务器端，服务器端根据这个sessionid找到具体的session，再取出该session之中的用户id。有点抽象，我这边画个图吧。

 

 

    刚刚说了，session是服务器产生的，那么肯定也是存在于生成它的服务器内存中，那么如果服务端是集群，那么你如果用服务器一生成的sessionid去访问服务二的数据，那么就会出现找不到数据的情况。那么怎么办呢，要么就是在集群中进行session的相互同步，或者单独用一个服务器或者其他存储介质（mysql，redis等）。

第一种方法，集群服务器之间相互同步，工作很繁琐，每台服务器都需要占用资源；

第二种方法，存在单点问题，如果存放session的那台服务器或者存储介质故障了，就导致无法获取session，那么就要对这个服务器或存储介质做集群做高可用，又回到了方法一中，工作繁琐，占用资源多。当然如果本身项目中的redis就已经是高可用了，就直接存进去使用也是可以的。

---

那么除了session有没有更好的可以记住用户的方法呢，那么这个博客的第二个主角上场了，那就是token，什么是token？咱先不用想得那么复杂，咱就把它当做是一个名字，然后具体内容我们自己说的算。

还是带着问题来看吧，首先token的产生就是为了解决session的不便与问题，上面session的工作繁琐或者占用资源问题，说到底是不是就是session为了能识别用户，它必须要提前把用户的id存进服务器端。那么有没有可能我们服务器端不存用户id，而是通过客户端传递过来的参数直接获取用户id呢？

答案当然是可以的。

比如用户登录的时候，我们封装一个token，内容是一个json字符串“{“userid”：1}” ；传递给客户端，客户端保存下来，以后每次访问的时候把这个token都放进header传递给服务器端不就可以了吗。

想法很好也很单纯，那么是不是坏人可以在header里面只要放入这个token，就可以访问对应人的信息了呢，可能你会说那简单啊，我把这个token加密不就好了，好，咱们先加密，但是我们要想知道这个userid具体是什么值的时候，是不是得解密，那是不是说你使用的加密方法是可逆的可解密的，你可以解密别人也可以解密，聪明一点的坏人还是可以推导出你的加密算法。从而修改里面的信息重新加密传递过来。

那么怎么办才是好呢，不加密不安全，机密也不安全，这里就涉及到另外一个概念了，那就是签名。

这里我先画个图吧，好理解一点

上图，客服端进行第二次访问的时候，服务器端的动作就是，拿到这个token和sign之后，利用自己保存的secret和加密算法对token进行加密，得到的加密结果然后和传过来的sign进行比对，如果比对成功了，那么说明改token没有没串改，所以可以放心的使用该token了。我们想一下为什么可以说这样就是安全的，因为如果客户端改变了token，要想通过我的验证，必须也要相对的把sign改变，但是他不知道secret，即使他推导出了加密算法他也改变不对sign，所以说是安全的。