Session和Cookie在网站开发中是用来保存用户与后端服务器的交互状态。它们有各自的缺点和优点。而且，他们的优点和应用场景是对立的。
Cookie
完整地描述：当一个用户通过HTTP访问一个服务器时，这个服务器会将一些Key/Value键值返回给客户端浏览器，并给这些数据加上一些限制条件，在条件符合时，用户下次访问这个服务器时，数据又将完整地带回给服务器。
简短版描述：Cookie就像是访问服务器时服务器颁发给用户的“身份证”，下次访问的时候带回这身份证，服务器就能识别信息。
版本：当前的Cookie有两种版本，Version 0 和Version 1，它们分别对应两种设置相应头的标识，分别是“Set-Cookie”和“Set-Cookie2”。两种版本的属性项有些不一样。值得注意的是：Java Web的Servlet并不支持Set-Cookie2响应头，在实际应用中，Set-Cookie2的一些属性项可以设置在Set-Cookie中。
Cookie是如何工作的？
真正创建Cookie是在org.apache.catalina.connector.Response类中完成的，调用generateCookieString方法将Cookie对象构造成一个字符串，构造的字符串的格式如userName="junshan";Version="1";Max-Age=1000.然后将这个字符串命名为Set-Cookie添加到MimeHeaders中。值得注意的是：Cookie对象的名字不能和Header的项重复，不然将导致错误。
我们在创建Cookie时，都创建了一个以NAME为Set-Cookie的MimeHeaders。每次调用addCookie时，都会创建一个Header。同时，在HTTP返回字符流时，是将Header中的所有项顺序地写入，而没有经过任何地修改。所以浏览器在接受HTTP返回的数据时是分别解析Header项的。
当我们请求某个URL路径时，浏览器会根据这个URL将符合条件的Cookie放在Request请求头中传回服务器，服务器通过request.getCookies()来获取所有的Cookie。
使用Cookie的注意事项
1、如果不为Cookie设置它的生存周期的话，默认是关闭浏览器的时候就销毁Cookie。
2、Cookie默认情况下是不允许出现中文字符的，如果我们要添加具有中文内容的Cookie时，我们需要使用java.net.URLEncoder先对中文进行编码，随后在进行Cookie的添加。读取Cookie时，需要使用java.net.URLDecoder对其进行解码。
3、不同的浏览器对Cookie的存储都有一些限制，通常是Cookie数量和Cookie总大小的限制。像火狐对Cookie的限制是每个域名只能有50个Cookie值，总大小不能超过4097个字。
4、Cookie在HTTP的头部，所以通常的gzip和deflate针对HTTP Body的压缩不能压缩Cookie，如果Cookie的量非常大，要做Cookie做压缩，压缩方法是将Cookie的多个K/V看作是普通的文本，做文本压缩。值得注意的是，Cookie的规范中规定，Cookie仅能保存ASCII码为34~126的可见字符，所以压缩之后的结果再进行转码，可以进行Base32或者Base64编码。
Session
完整描述：从客户端浏览器连接服务器开始，到客户端浏览器与服务器断开为止，像这样的一次会话中，Session起到的作用是跟踪用户的会话信息。
简短版描述：Session在浏览器和服务器连接过程中跟踪用户信息。
Session是如何工作的？
服务器创建HttpSession对象的前提是拥有Session ID。第一次触发通过request.getSession()方法。当当前的Seesion ID还没有相应的HttpSession对象时，服务器会创建一个新的，并将这个对象加到org.apache.catalina.Manager的session容器中保存。
Manager类将管理所有Session的生命周期，Session过期就会被回收，服务器关闭，Session
将被序列化到磁盘等。
只要这个HttpSession对象存在，用户就可以根据Session ID来获取这个对象，也就做到了对状态的保持。
从Request中获得的Session对象保存在org.apache.catalina.Manager类中，它的实现类是StandardManager，通过requestedSessionId从StandardManager的session集合中取出SandardSession对象。一个客户端对应一个StandardSession对象，这个对象正是保存着我们创建的Session值。
当Servelt容器重启或者关闭的时候，StandardManager负责持久化没有过期的StandardSession对象，它将所有的StandardSession对象持久化到“SESSIONS.ser”为文件名的文件中，到Servlet重启的时候，它会重新读取这个文件，解析出所有的Session对象，并重新保存在session集合中。
说明
session范围内的属性可以在多个页面的跳转之间共享。一旦关闭浏览器，即session结束，session范围内的属性将全部失去。
session对象是HttpSession的实例，它有两个常见的方法：getAttribute（）和setAttribute（）。
session的属性值可以是任何可序列化的java对象。
安全性对比
Cookie：数据保存在客户端的中，所有这些数据可以被访问到的，甚至可以人为地进行修改和添加，所以在这方面的话，Cookie是不安全的。
Session：数据保存在服务器端，只是通过Cookie传递一个SessionID而已，所以Session更适合用来存储用户私密和重要信息。如登陆密码等。
安全性解决方案：分布式Session框架
使用Cookie可以很好地解决应用的分布式部署问题，由于Cookie是将值存储在客户端的浏览器里，用户每次访问都会将最新的值带回到处理该请求的服务器，所以不存在同一个用户的请求会在同一台服务器处理而导致Cookie不一致的问题。
但是，过多的使用Cookie也会造成一些麻烦：如客户端的限制、Cookie管理混乱、安全令人担忧等。
于是，分布式Session框架诞生。
统一使用订阅服务器推送配置可以有效地集中管理资源，所以省去了每个应用都来配置Cookie，简化Cookie的管理。用统一的一个服务订阅服务器，在应用启动的时候从该服务器订阅这个应用能够使用哪些Session和Cookie项，这些配置的Session和Cookie可以限制这个应用能够使用哪些Session和Cookie，甚至控制Session和Cookie可读或者可写。这样就可以精确地控制哪些应用可以操作哪些Session和Cookie，从而有效地控制Session的安全性和Cookie的数量。
还有一个非常重要的问题是：如何处理跨域名来共享Cookie的问题。Cookie是有域名限制的，一个域名下的Cookie不能再另外一个域名下访问，如果要在两个域名之间实现登陆有效，需要实现Session同步，需要另外一个跳转应用，这个应用可以被一个或多个域名访问。 它的主要功能是从一个域名下取得sessionID，然后将这个sessionID同步到另外一个域名下。这个sessionID其实就是一个Cookie，相当于JSESSIONID，所以，经过12步的操作，一个域名不用登陆就可以取到另外一个域名下的session。