cookie，session，localStorage，SessionStorage

Cookie技术是客户端的解决方案，主要保存在客户端

Cookie就是由服务器发给客户端的特殊信息（之后我们通过这个cookie来识别这个客户端，就不用每次把账户密码作为参数传过去了），而这些信息以key-value的方式存放在客户端，value就是一个cookie对象，当然这些cookie还包括其他信息，包括过期时间，所属域名等，像这个domain就是指cookie不能跨域名性，访问百度就只能用百度的cookie。

 

然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。

具体的流程就是在我们做登录的时候，用户使用浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器；接着，服务器在向客户端回传相应的超文本的同时也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体（Response Body）中的，而是存放于HTTP响应头（Response Header）；

 

设置cookie的具体过程就是：

客户端发送一个http请求到服务器端

服务器端发送一个http响应到客户端，其中包含Set-Cookie头部

客户端发送一个http请求到服务器端，其中包含Cookie头部

服务器端发送一个http响应到客户端

java服务器端对于cookie的处理：

通过request.getCookie()获取客户端提交的所有Cookie（以Cookie[]数组形式返回）

，通过response.addCookie(Cookie cookie)向客户端设置Cookie。

 

localStorage，SessionStorage和cookie功能挺相似的，都是在客户端保存一些信息

三者异同：

 

三者应用场景

因为考虑到每个 HTTP 请求都会带着 Cookie 的信息，所以 Cookie 当然是能精简就精简啦，比较常用的一个应用场景就是判断用户是否登录。针对登录过的用户，服务器端会在他登录时往 Cookie 中插入一段加密过的唯一辨识单一用户的辨识码，下次只要读取这个值就可以判断当前用户是否登录啦。曾经还使用 Cookie 来保存用户在电商网站的购物车信息，如今有了 localStorage可以替代cookie，像我自己做项目，一般都是服务端根据账户密码生成一个token保存在localstorage里面。

在我们填一些信息的时候，我们需要在同一个页面切换表单，我们可能要把表单页面拆分成多个子页面，然后按步骤引导用户填写。这时候 sessionStorage 的作用就发挥出来了，他就可以保存我们前面步骤填的东西，在全部填完submit的时候就可以很容易把前面的表单数据获取到。

 

对于何时使用token：

Token ，如果指的是OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App 。其目的是让 某App有权利访问 某用户 的信息。这里的 Token是唯一的。不可以转移到其它 App上，也不可以转到其它 用户 上。 转过来说Session 。Session只提供一种简单的认证，即有此 SID，即认为有此 User的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方App。 所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。

个人理解，对于app通过restful api和server打交道，就不需要用cookie和session来保存信息，用token就行了

https://www.cnblogs.com/wxinyu/p/9154178.html

 

Session机制：

Session来记录客户端状态，它是一种HTTP存储机制，目的是为无状态的HTTP提供持久机制。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

java中操作session：

HttpSession session = request.getSession();        // 获取Session对象
session.setAttribute("loginTime", new Date());     // 设置Session中的属性
out.println("登录时间为：" +(Date)session.getAttribute("loginTime"));      // 获取Session属性

Session生命周期：

为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。

Session在用户第一次访问服务器的时候自动创建，然后会把sessionid以cookie的形式写会客户端。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。

Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。

Session的有效期

由于会有越来越多的用户访问服务器，因此Session也会越来越多。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了，关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。

通过HttpSession.invalidate()来删除超时的session

除了在内存中存储session，我们还可以在文件中存储序列化后的session

如何去识别Session：

虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为SESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session依据该Cookie来识别是否为同一用户。

如果浏览器禁用cookie，那么我们就不能用cookie来存sessionId了，URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写。

 

分布式Session管理解决方案：分布式情况下，只有一台机器保留所需要的session

1.Session复制

在支持Session复制的Web服务器上，通过修改Web服务器的配置，可以实现将Session同步到其它Web服务器上，达到每个Web服务器上都保存一致的Session。
优点：代码上不需要做支持和修改。
缺点：需要依赖支持的Web服务器，一旦更换成不支持的Web服务器就不能使用了，在数据量很大的情况下不仅占用网络资源，而且会导致延迟。
适用场景：只适用于Web服务器比较少且Session数据量少的情况。
可用方案：开源方案tomcat-redis-session-manager，暂不支持Tomcat8。

2.Session粘滞

将用户的每次请求都通过某种方法强制分发到某一个Web服务器上，只要这个Web服务器上存储了对应Session数据，就可以实现会话跟踪。
优点：使用简单，没有额外开销。
缺点：一旦某个Web服务器重启或宕机，相对应的Session数据将会丢失，而且需要依赖负载均衡机制。
适用场景：对稳定性要求不是很高的业务情景。

3.Session集中管理（session集群处理方案）

在单独的服务器或服务器集群上使用缓存技术，如Redis存储Session数据，集中管理所有的Session，所有的Web服务器都从这个存储介质中存取对应的Session，实现Session共享，用redis的hash表进行存储，sessionid作为key，session对象作为value。
优点：可靠性高，减少Web服务器的资源开销。
缺点：实现上有些复杂，配置较多。
适用场景：Web服务器较多、要求高可用性的情况。
可用方案：开源方案Spring Session，也可以自己实现，主要是重写HttpServletRequestWrapper中的getSession方法，博主也动手写了一个，github搜索joincat用户，然后自取。

4.基于Cookie管理

这种方式每次发起请求的时候都需要将Session数据放到Cookie中传递给服务端。
优点：不需要依赖额外外部存储，不需要额外配置。
缺点：不安全，易被盗取或篡改；Cookie数量和长度有限制，需要消耗更多网络带宽。
适用场景：数据不重要、不敏感且数据量小的情况。

总结：Session集中管理使用最多