理解Session和Cookie

理解cookie

通俗地说就是当一个用户通过HTTP访问一个服务器时，这个服务器会将一些key/value键值对返回给客户端浏览器，并给这些数据加上一些限制条件， 在条件符合时这个用户下次访问这个服务器时，数据又被完整地带回给服务器。

这个作用就像你去超市购物时，第一次给你半张购物卡，在你这个购物卡里里存了一些你个人信息，下次你再来这个连锁超市时，超市会识别你的购物阿卡，直接购物就好了。

在一个很短的时间内，如果与用户相关的数据频繁访问，可以针对这个数据做缓存，这样可以大大提高数据的访问性能。 Cookie的作用正是如此，由于是同一客户端发出的请求，每次发出的请求都会带由i第一次访问时服务端设置的信息，这样服务端就可以根据Cookie值来划分访问的用户了。

理解Session

你已经知道Cookie可以让服务端程序跟踪每个客户端的访问，但是每次客户端的访问都必须传回这些Cookie，如果Cookie很多，则无形地增加了客户端与服务端的数据传输量，而Session的出现正式为了解决这个问题。

同一个客户端每次和服务端交互时，不需要每次偶读传回所有的Cookie值，而是只要传回一个ID，这个ID是客户端第一次访问服务器时生成的，而且每个客户端时候唯一的。这样每个客户端就有了一个唯一的ID，客户端只要传回这个ID就行了，这个ID通常是NAME为JSESSISONID的一个Cookie。

Seesion与Cookie

Session的三种工作方式

• 基于URL Path Parameter，默认支持
• 基于Cookie，如果没有修改Context容器的Cookies表示，则默认也支持
• 基于SSL，默认不支持，只有connector.getAttribute(“SSLEnabled”)为True时才支持。 如果客户端也支持Cookie，则Tomcat仍然会解析Cookie中的Session ID，并会覆盖URL中的Session ID。

Session如何工作

有了Session ID，服务端容器就可以创建Httpsession对象了，第一次触发时通过request.getSssion （）方法。如果当前的Session ID还没有对应的HTTPsession对象，那么就创建一个新的，并将这个对象加到org.apache.catalina.Manager的sessions容器中保存，Manager类将管理所有Session的声明周期，Session过去将被回收，服务器关闭，Session将被序列化到磁盘等。

Cookie安全问题

虽然Cookie和session都可以跟踪客户端的访问记录，但是它们的工作方式显然时不同的，Cookie 通过把所有要保存的数据通过HTTP的头部从客户端传递到服务端，又从服务端再传回到客户端，所有的数据都存储再客户端的浏览器里，所以这些Cookie数据可以被访问到，甚至可以通过浏览器的插件，，修改，删除Cookie，所以Cookie 的安全性受到了很大的挑战 。。相对而言的Session的安全性要高很多，因为Session是将数据保存再服务端，只是通过Cookie传递的一个SessionID而已，所以Session更适合存储用户隐私和重要的数据。

分布式Session框架

由于再大型互联网系统中，一个应用有上百台机器，而且有很多不同的应用系统协同工作，由于Cookie是将值存储在客户端的浏览器中，用户每次访问都会将最新的值待会给处理该请求的服务器，所以也就解决了同一个用户的请求不可能在同一台服务器处理而导致的Cookie不一致的问题。

Zookerper集群管理服务器可以统一统一管理所有服务器的配置文件。 由于应用是一个集群，所以不可能将创建的Sesson都保存在每台应用服务器的内存中，因为如果每台服务器都有几十万的访问用户，那么服务器的内存肯定是不够用的，即使内存够用，，这些session也无法同步到这个应用的所有服务器中，所以要共享这些Session必须将他们存储在一个分布式缓存中，可以随时写入或读取，而且性能能要很好才能满足要求，当前能满足这个要求的系统有MemCache。

解决了配置（zookeeper）和存储问题(memCache)，看一下如何存取session和cookie。 既然MemCahce是一个分布式Seesion的处理框架，必然会重新实现HTTPSESSION的操作接口，使得应用操作session的对象都是我们实现的InnerHttpSession对象，这个操作必须在进入应用之前完成，所以，可以配置一个filter拦截用户的请求。