1.1 Cookie机制程序员
在程序中，会话跟踪是很重要的事情。理论上，一个用户的全部请求操做都应该属于同一个会话，而另外一个用户的全部请求操做则应该属于另外一个会话，两者不能混淆。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不管是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。web
而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的链接就会关闭，再次交换数据须要创建新的链接。这就意味着服务器没法从链接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经没法判断该购买行为是属于用户A的会话仍是用户B的会话了。要跟踪该会话，必须引入一种机制。数据库
Cookie就是这样的一种机制。它能够弥补HTTP协议无状态的不足。在Session出现以前，基本上全部的网站都采用Cookie来跟踪会话。跨域
2. 思考一下服务端如何识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次建立Session的时候，服务端会在HTTP协议中告诉客户端，须要在 Cookie 里面记录一个Session ID，之后每次请求把这个会话ID发送到服务器，我就知道你是谁了。有人问，若是客户端的浏览器禁用了 Cookie 怎么办？通常这种状况下，会使用一种叫作URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。
3. Cookie其实还能够用在一些方便用户的场景下，设想你某次登录过一个网站，下次登陆的时候不想再次输入帐号了，怎么办？这个信息能够写到Cookie里面，访问网站的时候，网站页面的脚本能够读取这个信息，就自动帮你把用户名给填了，可以方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。
因此，总结一下：
Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据能够保存在集群、数据库、文件中；
Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。
1.1.3 Cookie的不可跨域名性浏览器
不少网站都会使用Cookie。例如，Google会向客户端颁发Cookie，Baidu也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Baidu颁发的Cookie呢？或者Google能不能修改Baidu颁发的Cookie呢？缓存
答案是否认的。Cookie具备不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操做Google的Cookie，而不能操做Baidu的Cookie。安全
Cookie在客户端是由浏览器来管理的。浏览器可以保证Google只会操做Google的Cookie而不会操做Baidu的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操做另外一个网站Cookie的依据是域名。Google与Baidu的域名不同，所以Google不能操做Baidu的Cookie。服务器
须要注意的是，虽然网站images.google.com与网站www.google.com同属于Google，可是域名不同，两者一样不能互相操做彼此的Cookie。cookie
注意：用户登陆网站www.google.com以后会发现访问images.google.com时登陆信息仍然有效，而普通的Cookie是作不到的。这是由于Google作了特殊处理。本章后面也会对Cookie作相似的处理。session
1.2.3 Session的生命周期
Session保存在服务器端。为了得到更高的存取速度，服务器通常把Session放在内存里。每一个用户都会有一个独立的Session。若是Session内容过于复杂，当大量客户访问服务器时可能会致使内存溢出。所以，Session里的信息应该尽可能精简。
Session在用户第一次访问服务器的时候自动建立。须要注意只有访问JSP、Servlet等程序时才会建立Session，只访问HTML、IMAGE等静态资源并不会建立Session。若是还没有生成Session，也可使用request.getSession(true)强制生成Session。
Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，不管是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。
1.2.4 Session的有效期
因为会有愈来愈多的用户访问服务器，所以Session也会愈来愈多。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。若是超过了超时时间没访问过服务器，Session就自动失效了。
Session的超时时间为maxInactiveInterval属性，能够经过对应的getMaxInactiveInterval()获取，经过setMaxInactiveInterval(longinterval)修改。
Session的超时时间也能够在web.xml中修改。另外，经过调用Session的invalidate()方法可使Session失效。
1.2.6 Session对浏览器的要求
虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然须要客户端浏览器的支持。这是由于Session须要使用Cookie做为识别标志。HTTP协议是无状态的，Session不能依据HTTP链接来判断是否为同一客户，所以服务器向客户端浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session依据该Cookie来识别是否为同一用户。
该Cookie为服务器自动生成的，它的maxAge属性通常为–1，表示仅当前浏览器内有效，而且各浏览器窗口间不共享，关闭浏览器就会失效。
所以同一机器的两个浏览器窗口访问服务器时，会生成两个不一样的Session。可是由浏览器窗口内的连接、脚本等打开的新窗口（也就是说不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的Cookie，所以会共享一个Session。
注意：新开的浏览器窗口会生成新的Session，但子窗口除外。子窗口会共用父窗口的Session。例如，在连接上右击，在弹出的快捷菜单中选择“在新窗口中打开”时，子窗口即可以访问父窗口的Session。
若是客户端浏览器将Cookie功能禁用，或者不支持Cookie怎么办？例如，绝大多数的手机浏览器都不支持Cookie。Java Web提供了另外一种解决方案：URL地址重写。
客户端存储：
一、cookie
二、ie提供了一种叫作用户数据的行为，能够应用到页面的某个元素上。
三、DOM存储
DOM存储定义了两种存储数据的对象：sessionStorage和localstorage前者严格用于在一个浏览器会话中存储数据，由于数据在浏览器关闭后马上删除，后者用于用于跨越会话持久化数据并给予跨域名安全策略。
还有第三个对象globalStorage,firefox实现了她
在后来的版本中localstorage对象替代了globalStorage
DOM存储目的是克服由cookie带来的一些限制，当数据须要严格控制在客户端上时，无需持续地将数据发回服务器，dom存储的两个主要目标是：
1）提供一种在cookie以外存储会话数据的途径
2）提供一种存储大量能够跨越会话存在的数据的机制
2. 本地存储
两个storage其余属性方法都同样
| 特性 | Cookie | localStorage | sessionStorage |
|---|---|---|---|
| 数据的生命期 | 通常由服务器生成，可设置失效时间。若是在浏览器端生成Cookie，默认是关闭浏览器后失效 | 除非被清除，不然永久保存 | 仅在当前会话下有效，关闭页面或浏览器后被清除 |
| 存放数据大小 | 4K左右 | 通常为5MB | - |
| 与服务器端通讯 | 每次都会携带在HTTP头中，若是使用cookie保存过多数据会带来性能问题 | 仅在客户端（即浏览器）中保存，不参与和服务器的通讯 | - |
| 易用性 | 须要程序员本身封装，源生的Cookie接口不友好 | 源生接口能够接受，亦可再次封装来对Object和Array有更好的支持 | - |