session&cookie

Sesssion && Cookie && Token 理解

问题

• Q1. 为何会同时有Cookie、Seesion、Token概念
• Session、Cookie工作流程

A1:当用户向浏览器发送一个请求，web系统需要确定该用户请求接口的合法性。接口请求之前，可以通过用户名，密码向后台数据库进行校验来判断；如果通过这种方式，不仅繁琐，账号信息通过网络传输。有很大危险。

那么更好的处理方式是每次访问，客户端能携带过来能证明身份的信息即可，即Cookie。Cookie首次通过用户名密码登录系统，服务端会响应的时候会通过set-cookie响应头将生成的认证信息带给客户端，下次浏览器即可携带Cookie信息来证明身份。

有Cookie 可以进行认证，为何又出现session技术，相对比与客户端Cookie的解决方案，服务器的session方案更安全。原因：1.cookie 存在客户端，可以获得，容易篡改。2.客户端不宜存储敏感信息如，用户名、密码等。Sessio存储在服务器端，客户端只需存储sessionId即可，其他信息可以通过sessionId从服务器读取

Token的出现是为了解决服务扩展、无法存储大量session信息。当用户激增，每个用户，服务器会保存一份seesion信息，这样服务器会消耗大量资源。比如有服务A，服务B，需要负载均衡，用户A请求了服务A，sessionId保存在服务A上，又如何能负载到B服务上呢，可以做session 的复制，

把sessionId在两个机器之间复制，这样显然不是一个好的解决方案。也有个其他方案，利用Memcached把sessionId 集中存储到一个地方， 所有的机器都来访问这个地方的数据， 这样就不用复制了,但是增加了单点故障可能性.

既然服务器扩展，session不好处理，那么可不可以不保存session呢，有其他的认证方式呢？token（令牌），记入用户A登录系统， 系统发一个令牌(token)给用户A， 里边包含了A用户 user id，下次用户A再次通过Http 请求访问系统时， 把这个token 通过Http header 带过来就可以。
那么如何防止token伪造呢？可以对数据做一个签名， 比如用HMAC-SHA256算法，加上一个私钥， 对数据做一个签名， 把这签名和数据一起作为token ，由于私钥别人不知道， 就无法伪造token了.token 值系统不保存.

当用户A把这个token 给携带过来时，系统用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名，和token 中签名比较， 如果相同，说明请求合法，如果不同， 数据部分肯定被人篡改过，系统发送认证失败。这样的方式避免了服务器端存储认证数据。机器集群就可以轻松地做水平扩展， 当用户访问量增大， 直接加机器就行

• 基于Token的验证原理

基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。这种概念解决了在服务端存储信息时的许多问题

NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

• 基于Token的身份验证的过程如下:

1. 用户通过用户名和密码发送请求。

2. 程序验证。

3. 程序返回一个签名的token 给客户端。

4. 客户端储存token,并且每次用于每次发送请求。

5. 服务端验证token并返回数据。

Q2 1.ookie执行流程

用户访问系统时候,服务器设置一个cookie，在做响应的时候会通过set-cookie响应头将cookie带给浏览器。
浏览器会将此数据保存起来,然后再次去访问服务器的时候,浏览器通过cookie将数据带到到服务器,服务器通过这些数据便得知用户是谁了，这些数据一般都是token。
2. session执行流程

浏览器发起一个请求到服务器,服务器先检查是否携带了一个叫做JSESSIONID的cookie。
如果有携带，会将此cookie的值取出来（比如为aaa123），然后从服务器的session池中找到ID为aaa123的session返回给调用者。
如果没有携带这个JSESSIONID的cookie，那么服务器将会自动创建一个session对象并且生成一个随机字符串（如aaa123）作为此session的ID保存到session池中。在服务器为客户端浏览器作响应的时候自动创建一个键为“JSESSIONID” 值为“aaa123”的cookie对象让浏览器储存起来以便下次再访问的时候带过来。

引用：

https://blog.csdn.net/IT_zhang81/article/d
https://www.cnblogs.com/moyand/p/9047978.html