1.理解Cookie

一般当一个用户第一次访问一个服务器时，这个服务器会将一些Key/Value键值对返回给客户端浏览器，并给这些数据加上一些限制条件，在条件符合时这个用户下次访问这个服务器时，数据又被完整地待会给服务器。

Http是一种无状态协议，当用户的一次访问请求结束后，后端服务器就无法知道下一次来访问的还是不是上次访问的用户。在设计应用程序时，两次访问就不能知道是不是同一个人这对提升系统性能和用户体验不利。于是Cookie就被设计为记录用户在一段时间内访问Web应用的行为路径。这样服务器就能根据Cookie值来划分访问用户了。

2.Cookie如何工作

真正构建Cookie是在org.apache.catalina.connector.Response类中完成的，调用generateCookieString方法将Cookie对象构造成一个字符串，构造成一个字符串，构造的字符串格式如userName＝“junshan”；Version＝“1”。然后将这个字符串命名为Set-Cookie添加到MimeHeaders中。最后在Tomcat最终构造Http响应头的代码，在构建HTTP返回字节流时是将Header中所有的项顺序地写出，而没有进行任何修改，所以可以想象浏览器在接收HTTP返回数据时是分别解析每一个Header项的。

3.使用Cookie的限制

Cookie是HTTP头中的一个字段，虽然HTTP本身对这个字段并没有多少限制，但是Cookie最终还是储存在浏览器里，所以不同的浏览器对Cookie的存储都有自己的限制。

IE6   20个/每个域名   4095个字节

IE7   50个/每个域名   4095个字节

IE8   50个/每个域名   4095个字节

IE9   50个/每个域名   4095个字节

Chrome     50个/每个域名   大于80000个字节

FireFox     50个/每个域名   4097个字节

理解Session

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

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

1.Session与Cookie

有三种方式可以让Session正常工作。

  －基于URL Path Parameter，默认支持。

  －基于Cookie，如果没有修改Context容器的Cookie标识，则默认也是支持的。

  －基于SSL，默认不支持，只有connector.getAttribute("SSLEnabled")为TRUE时才支持。

2.Session如何工作

有了SessionID，服务端就可以创建HttpSession对象了，第一次触发通过request.getSession()方法。如果当前的Session ID还没有对应的HttpSession对象，那么就创建一个新的，并将这个对象加到org.apache.catalina.Manager的session容器中保存。Manager类将管理所有Session的生命周期，Session过期将被回收，服务器关闭，Session将被序列化到磁盘等。只要这个HttpSession对象存在，用户就可以根据SessionID来获取这个对象，也就做到了对状态的保持。

3.Cookie安全问题

虽然Cookie和Session都可以跟踪客户端的访问记录，但是他们的工作方式显然是不同的，Cookie通过把所有要保持的数据通过HTTP的头部从客户端传递到服务器，从服务器再传回到客户端，所有的数据都存储在客户端的浏览器里，所以这些Cookie数据可以被访问到，甚至还可以修改。

4.分布式Session框架

实现思路：需要一个服务订阅服务器，在应用启动时可以从这个订阅服务器订阅这个应用需要的可写Session项和可写Cookie项，这些配置的Session和Cookie可以限制这个应用能够使用哪些Session和Cookie，甚至可以控制Session和Cookie可读或者可写。这样可以精确地控制哪些应用可以操作哪些Session和Cookie，可以有效控制Session的安全性和Cookie的数量。

统一通过订阅服务器推送配置可以有效地集中管理资源，所以可以省去每个应用都来配置Cookie，简化Cookie的管理。如果应用要使用一个新增的Cookie，则可以通过一个统一的平台来申请，申请通过才将这个配置项增加到订阅服务器。如果是一个所有应用都要使用的全局Cookie，那么只需将这个Cookie通过订阅服务器统一推送过去就行了，省去了要在每个应用中手动增加Cookie的配置。

关于这个订阅服务器现在有很多开源的配置服务器，如Zookeeper集群管理服务器，可以统一管理所有服务器的配置文件。