Cookie和Session的比较

Cookie和Session都可以进行会话跟踪，但是实现的原理不大一样。

• 从存取方式上比较

Cookie中只能保存ASCII字符串，如果需要存取Unicode（比如汉字）字符或者二进制数据（图片），需要进行UTF-8,GBK或者Base64等方式的编码。Cokkie中也不能直接存取Java对象。

Sesssion中可以存取任何类型的数据，包括而不限于String，Integer，List，Map等。Session中也可以直接存取Java Bean乃至任何Java类，对象等，使用起来非常方便。

• 从隐私安全上比较

Cookie存储在客户端浏览器中，对客户端是可见的，客户端的一些程序会窥探、复制甚至篡改Cokkie中的内容。而Session存储在服务器上，对客户端是透明的，不存在敏感信息泄露的风险。

如果选用Cookie，比较好的方法是，将敏感的信息如账号密码等尽量不要写到Cookie中。最好像Google，Baidu那样讲Cookie信息加密，提交到服务器之后再进行解密，保证Cookie中的信息只有自己能懂。

• 从有效期上比较

如果要设置一个长期有效的Cookie，Cookie只需要设置maxAge属性为一个很大很大的数字，或者Integer.MAX_VALUE就可以了。

Session理论上也可以实现这种效果。只要调用setMaxInactiveInterval(Integer.MAX_VALUE就可以了。但是由于Session依赖于名为JSESSIONID的Cookie，而Cookie JSESSIONID的maxAge默认为-1，只要关闭了浏览器该Session就会失效，因此Session不能实现信息永久有效的效果。使用URL地址重写也不能实现。

而且，如果设置Sesseion的超时时间过长，服务器累计的Session就会越多，越容易导致内存溢出。

• 从对服务器的负担上比较

Session是保存在服务器端的，每隔用户都会产生一个Session。如果并发访问的用户非常多，会产生非常多的Session，消耗大量的内存。因此像Google，Baidu这样并发访问量高的网站，不大可能使用Session来跟踪会话。

Cookie保存在服务的，不占用服务器资源。

• 从浏览器支持上比较

Cookie是需要浏览器支持的。如果客户端禁用了Cookie，或者不支持Cookie,则会话跟踪会失效。对于WAP上的应用，常规的Cookie就排不上用场了。

如果客户端浏览器不支持Cookie,需要使用Session以及URL地址重写。需要注意的是所有的用到Session程序的URL都要使用response.encodeURL(String URL)或者response.encodeRedirectURL(String URL)进行URL地址重写，否则会导致Session会话跟踪失败。对于WAP应用来说，Session+URL地址重写也许是唯一的额选择。

• 从跨域名上比较

Cookie支持跨域名访问，例如将domain属性设置为"test.com"，那么所有以“test.com”结尾的域名均可以访问该Cookie。Session不行。

• 总结对比

Cookie是早期的会话跟踪技术，它将信息保存到客户端浏览器中。 浏览器访问网站时会携带这些Cookie信息，达到鉴别身份的目的。

Session是在Cookie基础上建立的会话跟踪技术，它将信息保存在服务器端，Session中能够存储负责的Java对象，因此使用更加方便。Session依赖于名为JSESSIONID的Cookie。

如果客户端浏览器不支持Cookie，或者禁用了Cookie，仍然可以用过使用URL地址重写来使用Session.