cookie 和session 的区别

http://www.cnblogs.com/wangtao_20/archive/2011/02/16/1955659.html

http://www.cnblogs.com/shiyangxt/archive/2008/10/07/1305506.html

http://blog.csdn.net/fangaoxin/article/details/6952954

http://www.169it.com/article/3217120921.html

cookie 和session 的区别：

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
   考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
   考虑到减轻服务器性能方面，应当使用COOKIE。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

5、所以个人建议：
   将登陆信息等重要信息存放为SESSION
   其他信息如果需要保留，可以放在COOKIE中

1、session保存在服务器，客户端不知道其中的信息；cookie保存在客户端，服务器能够知道其中的信息。

2、session中保存的是对象，cookie中保存的是字符串。

3、session不能区分路径，同一个用户在访问一个网站期间，所有的session在任何一个地方都可以访问到。而cookie中如果设置 了路径参数，那么同一个网站中不同路径下的cookie互相是访问不到的。

4、session默认需要借助cookie才能正常工作。如果客户端完全禁止cookie，session，这种方法将失效。但是如果服务器端启用了url编码，也就是用URLEncoder.encode("index.jsp?id=3","UTF-8");..把所有的url编码了，则会在url后面出现如下类似的东西index.jsp:jsessionid=fdsaffjdlksfd124324lkdjsf?id=3服务器通过这个进行session的判断。

5 session在用户会话结束后就会关闭了，但cookie因为保存在客户端，可以长期保存

6 cookie:是服务端向客户端写入的小的片段信息。cookie信息保存在服务器缓存区，不会在客户端显现。当你第一次登陆一个网站，服务器向你的机器写得片段信息。你可以在Internet选项中找到存放cookie的文件夹。如果不删除，cookie就一直在这个文件夹中。

Cookie总是保存在客户端中，按在客户端中的存储位置，可分为内存Cookie和硬盘Cookie。内存Cookie由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。硬盘Cookie保存在硬盘里，有一个过期时间，除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。所以，按存在时间，可分为非持久Cookie和持久Cookie。

1.cookie的属性

一般cookie所具有的属性，包括：

Domain：域，表示当前cookie所属于哪个域或子域下面。

此处需要额外注意的是，在C#中，如果一个cookie不设置对应的Domain，那么在CookieContainer.Add(cookies)的时候，会死掉。对于服务器返回的Set-Cookie中，如果没有指定Domain的值，那么其Domain的值是默认为当前所提交的http的请求所对应的主域名的。比如访问 http://www.example.com，返回一个cookie，没有指名domain值，那么其为值为默认的www.example.com。

Path：表示cookie的所属路径。

Expire time/Max-age：表示了cookie的有效期。expire的值，是一个时间，过了这个时间，该cookie就失效了。或者是用max-age指定当前cookie是在多长时间之后而失效。如果服务器返回的一个cookie，没有指定其expire time，那么表明此cookie有效期只是当前的session，即是session cookie，当前session会话结束后，就过期了。对应的，当关闭（浏览器中）该页面的时候，此cookie就应该被浏览器所删除了。

secure：表示该cookie只能用https传输。一般用于包含认证信息的cookie，要求传输此cookie的时候，必须用https传输。

httponly：表示此cookie必须用于http或https传输。这意味着，浏览器脚本，比如javascript中，是不允许访问操作此cookie的。

2.服务器发送cookie给客户端

 从服务器端，发送cookie给客户端，是对应的Set-Cookie。包括了对应的cookie的名称，值，以及各个属性。

 例如：

Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Jan 2013 21:47:38 GMT; Path=/; Domain=.169it.com; HttpOnly

Set-Cookie: made_write_conn=1295214458; Path=/; Domain=.169it.com

Set-Cookie: reg_fb_gate=deleted; Expires=Thu, 01 Jan 1970 00:00:01 GMT; Path=/; Domain=.169it.com; HttpOnly

3.从客户端把cookie发送到服务器

 从客户端发送cookie给服务器的时候，是不发送cookie的各个属性的，而只是发送对应的名称和值。

 例如：

GET /spec.html HTTP/1.1  

Host: www.example.org  

Cookie: name=value; name2=value2  

Accept: */*  

4.关于修改，设置cookie

 除了服务器发送给客户端（浏览器）的时候，通过Set-Cookie，创建或更新对应的cookie之外，还可以通过浏览器内置的一些脚本，比如javascript，去设置对应的cookie，对应实现是操作js中的document.cookie。

5.Cookie的缺陷

(1)cookie会被附加在每个HTTP请求中，所以无形中增加了流量。

(2)由于在HTTP请求中的cookie是明文传递的，所以安全性成问题。（除非用HTTPS)

(3)Cookie的大小限制在4KB左右。对于复杂的存储需求来说是不够用的。

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。

本章将系统地讲述Cookie与Session机制，并比较说明什么时候不能用Cookie，什么时候不能用Session。

1.1  Cookie机制

在程序中，会话跟踪是很重要的事情。理论上，一个用户的所有请求操作都应该属于同一个会话，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不论是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。

而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。

Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

1.1.1  什么是Cookie

Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。目前Cookie已经成为标准，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

查看某个网站颁发的Cookie很简单。在浏览器地址栏输入javascript:alert (document. cookie)就可以了（需要有网才能查看）。JavaScript脚本会弹出一个对话框显示本网站颁发的所有Cookie的内容，如图1.1所示。

图1.1  Baidu网站颁发的Cookie

图1.1中弹出的对话框中显示的为Baidu网站的Cookie。其中第一行BAIDUID记录的就是笔者的身份helloweenvsfei，只是Baidu使用特殊的方法将Cookie信息加密了。

注意：Cookie功能需要浏览器的支持。

如果浏览器不支持Cookie（如大部分手机中的浏览器）或者把Cookie禁用了，Cookie功能就会失效。

不同的浏览器采用不同的方式保存Cookie。

IE浏览器会在“C:\Documents and Settings\你的用户名\Cookies”文件夹下以文本文件形式保存，一个文本文件保存一个Cookie。

1.1.2  记录用户访问次数

Java中把Cookie封装成了javax.servlet.http.Cookie类。每个Cookie都是该Cookie类的对象。服务器通过操作Cookie类对象对客户端Cookie进行操作。通过request.getCookie()获取客户端提交的所有Cookie（以Cookie[]数组形式返回），通过response.addCookie(Cookiecookie)向客户端设置Cookie。

Cookie对象使用key-value属性对的形式保存用户状态，一个Cookie对象保存一个属性对，一个request或者response同时使用多个Cookie。因为Cookie类位于包javax.servlet.http._*下面，所以JSP中不需要import该类。

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。

注意：用户登录网站www.google.com之后会发现访问images.google.com时登录信息仍然有效，而普通的Cookie是做不到的。这是因为Google做了特殊处理。本章后面也会对Cookie做类似的处理。

1.1.4  Unicode编码：保存中文

中文与英文字符不同，中文属于Unicode字符，在内存中占4个字符，而英文属于ASCII字符，内存中只占2个字节。Cookie中使用Unicode字符时需要对Unicode字符进行编码，否则会乱码。

提示：Cookie中保存中文只能编码。一般使用UTF-8编码即可。不推荐使用GBK等中文编码，因为浏览器不一定支持，而且JavaScript也不支持GBK编码。

1.1.5  BASE64编码：保存二进制图片

Cookie不仅可以使用ASCII字符与Unicode字符，还可以使用二进制数据。例如在Cookie中使用数字证书，提供安全度。使用二进制数据时也需要进行编码。

%注意：本程序仅用于展示Cookie中可以存储二进制内容，并不实用。由于浏览器每次请求服务器都会携带Cookie，因此Cookie内容不宜过多，否则影响速度。Cookie的内容应该少而精。

1.1.6  设置Cookie的所有属性

除了name与value之外，Cookie还具有其他几个常用的属性。每个属性对应一个getter方法与一个setter方法。Cookie类的所有属性如表1.1所示。

表1.1  Cookie常用属性

属  性  名	描    述
String name	该Cookie的名称。Cookie一旦创建，名称便不可更改
Object value	该Cookie的值。如果值为Unicode字符，需要为字符编码。如果值为二进制数据，则需要使用BASE64编码
int maxAge	该Cookie失效的时间，单位秒。如果为正数，则该Cookie在maxAge秒之后失效。如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。如果为0，表示删除该Cookie。默认为–1
boolean secure	该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false
String path	该Cookie的使用路径。如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”
String domain	可以访问该Cookie的域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.”
String comment	该Cookie的用处说明。浏览器显示Cookie信息的时候显示该说明
int version	该Cookie使用的版本号。0表示遵循Netscape的Cookie规范，1表示遵循W3C的RFC 2109规范

1.1.7  Cookie的有效期

Cookie的maxAge决定着Cookie的有效期，单位为秒（Second）。Cookie中通过getMaxAge()方法与setMaxAge(int maxAge)方法来读写maxAge属性。

如果maxAge属性为正数，则表示该Cookie会在maxAge秒之后自动失效。浏览器会将maxAge为正数的Cookie持久化，即写到对应的Cookie文件中。无论客户关闭了浏览器还是电脑，只要还在maxAge秒之前，登录网站时该Cookie仍然有效。下面代码中的Cookie信息将永远有效。

Cookie cookie = new Cookie("username","helloweenvsfei");   // 新建Cookie

cookie.setMaxAge(Integer.MAX_VALUE);           // 设置生命周期为MAX_VALUE

response.addCookie(cookie);                    // 输出到客户端

如果maxAge为负数，则表示该Cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效，关闭窗口后该Cookie即失效。maxAge为负数的Cookie，为临时性Cookie，不会被持久化，不会被写到Cookie文件中。Cookie信息保存在浏览器内存中，因此关闭浏览器该Cookie就消失了。Cookie默认的maxAge值为–1。

如果maxAge为0，则表示删除该Cookie。Cookie机制没有提供删除Cookie的方法，因此通过设置该Cookie即时失效实现删除Cookie的效果。失效的Cookie会被浏览器从Cookie文件或者内存中删除，

例如：

Cookie cookie = new Cookie("username","helloweenvsfei");   // 新建Cookie

cookie.setMaxAge(0);                          // 设置生命周期为0，不能为负数

response.addCookie(cookie);                    // 必须执行这一句

response对象提供的Cookie操作方法只有一个添加操作add(Cookie cookie)。

要想修改Cookie只能使用一个同名的Cookie来覆盖原来的Cookie，达到修改的目的。删除时只需要把maxAge修改为0即可。

注意：从客户端读取Cookie时，包括maxAge在内的其他属性都是不可读的，也不会被提交。浏览器提交Cookie时只会提交name与value属性。maxAge属性只被浏览器用来判断Cookie是否过期。

1.1.8  Cookie的修改、删除

Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。

如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数代表其他的意义。读者可以通过上例的程序进行验证，设置不同的属性。

注意：修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

1.1.9  Cookie的域名

Cookie是不可跨域名的。域名www.google.com颁发的Cookie不会被提交到域名www.baidu.com去。这是由Cookie的隐私安全机制决定的。隐私安全机制能够禁止网站非法获取其他网站的Cookie。

正常情况下，同一个一级域名下的两个二级域名如www.helloweenvsfei.com和images.helloweenvsfei.com也不能交互使用Cookie，因为二者的域名并不严格相同。如果想所有helloweenvsfei.com名下的二级域名都可以使用该Cookie，需要设置Cookie的domain参数，例如：

Cookie cookie = new Cookie("time","20080808"); // 新建Cookie

cookie.setDomain(".helloweenvsfei.com");           // 设置域名

cookie.setPath("/");                              // 设置路径

cookie.setMaxAge(Integer.MAX_VALUE);               // 设置有效期

response.addCookie(cookie);                       // 输出到客户端

读者可以修改本机C:\WINDOWS\system32\drivers\etc下的hosts文件来配置多个临时域名，然后使用setCookie.jsp程序来设置跨域名Cookie验证domain属性。

注意：domain参数必须以点(".")开始。另外，name相同但domain不同的两个Cookie是两个不同的Cookie。如果想要两个域名完全不同的网站共有Cookie，可以生成两个Cookie，domain属性分别为两个域名，输出到客户端。

1.1.10  Cookie的路径

domain属性决定运行访问Cookie的域名，而path属性决定允许访问Cookie的路径（ContextPath）。例如，如果只允许/sessionWeb/下的程序使用Cookie，可以这么写：

Cookie cookie = new Cookie("time","20080808");     // 新建Cookie

cookie.setPath("/session/");                          // 设置路径

response.addCookie(cookie);                           // 输出到客户端

设置为“/”时允许所有路径使用Cookie。path属性需要使用符号“/”结尾。name相同但domain相同的两个Cookie也是两个不同的Cookie。

注意：页面只能获取它属于的Path的Cookie。例如/session/test/a.jsp不能获取到路径为/session/abc/的Cookie。使用时一定要注意。

1.1.11  Cookie的安全属性

HTTP协议不仅是无状态的，而且是不安全的。使用HTTP协议的数据不经过任何加密就直接在网络上传播，有被截获的可能。使用HTTP协议传输很机密的内容是一种隐患。如果不希望Cookie在HTTP等非安全协议中传输，可以设置Cookie的secure属性为true。浏览器只会在HTTPS和SSL等安全协议中传输此类Cookie。下面的代码设置secure属性为true：

Cookie cookie = new Cookie("time", "20080808"); // 新建Cookie

cookie.setSecure(true);                           // 设置安全属性

response.addCookie(cookie);                        // 输出到客户端

提示：secure属性并不能对Cookie内容加密，因而不能保证绝对的安全性。如果需要高安全性，需要在程序中对Cookie内容加密、解密，以防泄密。

1.1.12  JavaScript操作Cookie

Cookie是保存在浏览器端的，因此浏览器具有操作Cookie的先决条件。浏览器可以使用脚本程序如JavaScript或者VBScript等操作Cookie。这里以JavaScript为例介绍常用的Cookie操作。例如下面的代码会输出本页面所有的Cookie。

由于JavaScript能够任意地读写Cookie，有些好事者便想使用JavaScript程序去窥探用户在其他网站的Cookie。不过这是徒劳的，W3C组织早就意识到JavaScript对Cookie的读写所带来的安全隐患并加以防备了，W3C标准的浏览器会阻止JavaScript读写任何不属于自己网站的Cookie。换句话说，A网站的JavaScript程序读写B网站的Cookie不会有任何结果。

1.1.13  案例：永久登录

如果用户是在自己家的电脑上上网，登录时就可以记住他的登录信息，下次访问时不需要再次登录，直接访问即可。实现方法是把登录信息如账号、密码等保存在Cookie中，并控制Cookie的有效期，下次访问时再验证Cookie中的登录信息即可。

保存登录信息有多种方案。最直接的是把用户名与密码都保持到Cookie中，下次访问时检查Cookie中的用户名与密码，与数据库比较。这是一种比较危险的选择，一般不把密码等重要信息保存到Cookie中。

还有一种方案是把密码加密后保存到Cookie中，下次访问时解密并与数据库比较。这种方案略微安全一些。如果不希望保存密码，还可以把登录的时间戳保存到Cookie与数据库中，到时只验证用户名与登录时间戳就可以了。

这几种方案验证账号时都要查询数据库。

本例将采用另一种方案，只在登录时查询一次数据库，以后访问验证登录信息时不再查询数据库。实现方式是把账号按照一定的规则加密后，连同账号一块保存到Cookie中。下次访问时只需要判断账号的加密规则是否正确即可。本例把账号保存到名为account的Cookie中，把账号连同密钥用MD1算法加密后保存到名为ssid的Cookie中。验证时验证Cookie中的账号与密钥加密后是否与Cookie中的ssid相等。相关代码如下：

代码1.8 loginCookie.jsp

<%@ page language="java"pageEncoding="UTF-8" isErrorPage="false" %>

<%!                                                  // JSP方法

    private static final String KEY =":[email protected]";
                                                     // 密钥 

    public final static String calcMD1(Stringss) { // MD1 加密算法

       String s = ss==null ?"" : ss;                  // 若为null返回空

       char hexDigits[] = { '0','1', '2', '3', '4', '1', '6', '7', '8', '9',
       'a', 'b', 'c', 'd', 'e', 'f' };                        // 字典

       try {

        byte[] strTemp =s.getBytes();                          // 获取字节

        MessageDigestmdTemp = MessageDigest.getInstance("MD1"); // 获取MD1

       mdTemp.update(strTemp);                                // 更新数据

        byte[] md =mdTemp.digest();                        // 加密

        int j =md.length;                                 // 加密后的长度

        char str[] = newchar[j _* 2];                       // 新字符串数组

        int k =0;                                         // 计数器k

        for (int i = 0; i< j; i++) {                       // 循环输出

         byte byte0 =md[i];

         str[k++] =hexDigits[byte0 >>> 4 & 0xf];

         str[k++] =hexDigits[byte0 & 0xf];

        }

        return newString(str);                             // 加密后字符串

       } catch (Exception e){return null; }

    }

%>

<%

   request.setCharacterEncoding("UTF-8");             // 设置request编码

    response.setCharacterEncoding("UTF-8");        // 设置response编码

   

    String action =request.getParameter("action"); // 获取action参数

   

    if("login".equals(action)){                       // 如果为login动作

        String account =request.getParameter("account");
                                                     // 获取account参数

        String password =request.getParameter("password");
                                                     // 获取password参数

        int timeout = newInteger(request.getParameter("timeout"));
                                                     // 获取timeout参数

              

        String ssid =calcMD1(account + KEY); // 把账号、密钥使用MD1加密后保存

       

        CookieaccountCookie = new Cookie("account", account);
                                                     // 新建Cookie

       accountCookie.setMaxAge(timeout);              // 设置有效期

       

        Cookie ssidCookie =new Cookie("ssid", ssid);   // 新建Cookie

       ssidCookie.setMaxAge(timeout);                 // 设置有效期

       

       response.addCookie(accountCookie);             // 输出到客户端

       response.addCookie(ssidCookie);            // 输出到客户端

       

        // 重新请求本页面，参数中带有时间戳，禁止浏览器缓存页面内容

       response.sendRedirect(request.getRequestURI() + "?" + System.
        currentTimeMillis());

        return;

    }

    elseif("logout".equals(action)){                  // 如果为logout动作

       

        CookieaccountCookie = new Cookie("account", "");
                                                 // 新建Cookie，内容为空

       accountCookie.setMaxAge(0);                // 设置有效期为0，删除

              

        Cookie ssidCookie =new Cookie("ssid", ""); // 新建Cookie，内容为空

       ssidCookie.setMaxAge(0);                   // 设置有效期为0，删除

       response.addCookie(accountCookie);         // 输出到客户端

       response.addCookie(ssidCookie);         // 输出到客户端

        //重新请求本页面，参数中带有时间戳，禁止浏览器缓存页面内容

       response.sendRedirect(request.getRequestURI() + "?" + System.
        currentTimeMillis());

        return;

    }

    boolean login = false;                        // 是否登录

    String account = null;                        // 账号

    String ssid = null;                           // SSID标识

   

    if(request.getCookies() !=null){               // 如果Cookie不为空

        for(Cookie cookie :request.getCookies()){  // 遍历Cookie

           if(cookie.getName().equals("account"))  // 如果Cookie名为
                                                    account

               account = cookie.getValue();       // 保存account内容

           if(cookie.getName().equals("ssid")) // 如果为SSID

               ssid = cookie.getValue();          // 保存SSID内容

        }

    }

    if(account != null && ssid !=null){    // 如果account、SSID都不为空

        login =ssid.equals(calcMD1(account + KEY));
                                      // 如果加密规则正确, 则视为已经登录

    }

%>

       

<%= login ? "欢迎您回来" : "请先登录"%>

        <% if(login){%>

            欢迎您, ${ cookie.account.value }.   

           
            注销

        <% } else {%>

                method="post">

           

              

                  

              

              

                  

              

              

                  

                  

              

                  

              

           

账号：
密码：
有效期：	checked> 关闭浏览器即失效                    name="timeout" value="<%= 30 *24 * 60 * 60 %>"> 30天                    内有效                    "<%= Integer.MAX_VALUE %>"> 永久有效
	"button">

       

        <% } %>

登录时可以选择登录信息的有效期：关闭浏览器即失效、30天内有效与永久有效。通过设置Cookie的age属性来实现，注意观察代码。运行效果如图1.7所示。

图1.7  永久登录

提示：该加密机制中最重要的部分为算法与密钥。由于MD1算法的不可逆性，即使用户知道了账号与加密后的字符串，也不可能解密得到密钥。因此，只要保管好密钥与算法，该机制就是安全的。

1.2  Session机制

除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

1.2.1  什么是Session

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

1.2.2  实现用户登录

Session对应的类为javax.servlet.http.HttpSession类。每个来访者对应一个Session对象，所有该客户的状态信息都保存在这个Session对象里。Session对象是在客户端第一次请求服务器的时候创建的。Session也是一种key-value的属性对，通过getAttribute(Stringkey)和setAttribute(String key，Objectvalue)方法读写客户状态信息。Servlet里通过request.getSession()方法获取该客户的Session，

例如：

HttpSession session = request.getSession();       // 获取Session对象

session.setAttribute("loginTime", new Date());     // 设置Session中的属性

   

out.println("登录时间为：" +(Date)session.getAttribute("loginTime"));      // 获取Session属性

request还可以使用getSession(boolean create)来获取Session。区别是如果该客户的Session不存在，request.getSession()方法会返回null，而getSession(true)会先创建Session再将Session返回。

Servlet中必须使用request来编程式获取HttpSession对象，而JSP中内置了Session隐藏对象，可以直接使用。如果使用声明了<%@page session="false" %>，则Session隐藏对象不可用。下面的例子使用Session记录客户账号信息。

源代码如下：

代码1.9  session.jsp

<%@ page language="java" pageEncoding="UTF-8"%>

<%!

    DateFormat dateFormat = newSimpleDateFormat("yyyy-MM-dd");         // 日期格式化器

%>

<%

    response.setCharacterEncoding("UTF-8");        // 设置request编码

    Person[] persons =

    {           

       // 基础数据，保存三个人的信息

        new Person("Liu Jinghua","password1", 34, dateFormat.parse
        ("1982-01-01")),

        new Person("Hello Kitty","hellokitty", 23, dateFormat.parse
        ("1984-02-21")),

        new Person("Garfield", "garfield_pass",23, dateFormat.parse
        ("1994-09-12")),

     };

   

    String message = "";                      // 要显示的消息

   

    if(request.getMethod().equals("POST"))

    { 

        // 如果是POST登录       

        for(Person person :persons)

        {           

            // 遍历基础数据，验证账号、密码

            // 如果用户名正确且密码正确

           if(person.getName().equalsIgnoreCase(request.getParameter("username"))&&person.getPassword().equals(request.getParameter("password")))

           {              

               // 登录成功，设置将用户的信息以及登录时间保存到Session

               session.setAttribute("person", person);                   // 保存登录的Person

               session.setAttribute("loginTime", new Date());          // 保存登录的时间              

               response.sendRedirect(request.getContextPath() + "/welcome.jsp");

               return;

            }

        }      

        message = "用户名密码不匹配，登录失败。";       // 登录失败

    }

%>

    // ... HTML代码为一个FORM表单，代码略，请看随书光盘

登录界面验证用户登录信息，如果登录正确，就把用户信息以及登录时间保存进Session，然后转到欢迎页面welcome.jsp。welcome.jsp中从Session中获取信息，并将用户资料显示出来。

welcome.jsp代码如下：

代码1.10  welcome.jsp

<%@ page language="java" pageEncoding="UTF-8"%>

<%!

    DateFormat dateFormat = newSimpleDateFormat("yyyy-MM-dd");         // 日期格式化器

%>

<%

    Person person =(Person)session.getAttribute("person");                       // 获取登录的person

    Date loginTime =(Date)session.getAttribute("loginTime");                     // 获取登录时间

%>

    // ... 部分HTML代码略

           

              

                  

              

              

                  

              

              

                  

              

              

                  

              

           

您的姓名：	<%= person.getName()%>
登录时间：	<%= loginTime%>
您的年龄：	<%= person.getAge()%>
您的生日：	<%=dateFormat.format(person.getBirthday()) %>

程序运行效果如图1.8所示。

图1.8  使用Session记录用户信息

注意程序中Session中直接保存了Person类对象与Date类对象，使用起来要比Cookie方便。

当多个客户端执行程序时，服务器会保存多个客户端的Session。获取Session的时候也不需要声明获取谁的Session。Session机制决定了当前客户只会获取到自己的Session，而不会获取到别人的Session。各客户的Session也彼此独立，互不可见。

提示：Session的使用比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.5  Session的常用方法

Session中包括各种方法，使用起来要比Cookie方便得多。Session的常用方法如表1.2所示。

表1.2  HttpSession的常用方法

方  法  名	描    述
void setAttribute(String attribute, Object value)	设置Session属性。value参数可以为任何Java Object。通常为Java Bean。value信息不宜过大
String getAttribute(String attribute)	返回Session属性
Enumeration getAttributeNames()	返回Session中存在的属性名
void removeAttribute(String attribute)	移除Session属性
String getId()	返回Session的ID。该ID由服务器自动创建，不会重复
long getCreationTime()	返回Session的创建日期。返回类型为long，常被转化为Date类型，例如：Date createTime = new Date(session.get CreationTime())
long getLastAccessedTime()	返回Session的最后活跃时间。返回类型为long
int getMaxInactiveInterval()	返回Session的超时时间。单位为秒。超过该时间没有访问，服务器认为该Session失效
void setMaxInactiveInterval(int second)	设置Session的超时时间。单位为秒
void putValue(String attribute, Object value)	不推荐的方法。已经被setAttribute(String attribute, Object Value)替代
Object getValue(String attribute)	不被推荐的方法。已经被getAttribute(String attr)替代
boolean isNew()	返回该Session是否是新创建的
void invalidate()	使该Session失效

Tomcat中Session的默认超时时间为20分钟。通过setMaxInactiveInterval(int seconds)修改超时时间。可以修改web.xml改变Session的默认超时时间。例如修改为60分钟：

   60     

注意：参数的单位为分钟，而setMaxInactiveInterval(int s)单位为秒。

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地址重写。

1.2.7  URL地址重写

URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写，例如：

    "> 
    Homepage

该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。如果客户端不支持Cookie，则会将用户Session的id重写到URL中。重写后的输出可能是这样的：

        1&wd=Java">Homepage

即在文件名的后面，在URL参数的前面添加了字符串“;jsessionid=XXX”。其中XXX为Session的id。分析一下可以知道，增添的jsessionid字符串既不会影响请求的文件名，也不会影响提交的地址栏参数。用户单击这个链接的时候会把Session的id通过URL提交到服务器上，服务器通过解析URL地址获得Session的id。

如果是页面重定向（Redirection），URL地址重写可以这样写：

<%

    if(“administrator”.equals(userName))

    {

       response.sendRedirect(response.encodeRedirectURL(“administrator.jsp”));

        return;

    }

%>

效果跟response.encodeURL(String url)是一样的：如果客户端支持Cookie，生成原URL地址，如果不支持Cookie，传回重写后的带有jsessionid字符串的地址。

对于WAP程序，由于大部分的手机浏览器都不支持Cookie，WAP程序都会采用URL地址重写来跟踪用户会话。比如用友集团的移动商街等。

注意：TOMCAT判断客户端浏览器是否支持Cookie的依据是请求中是否含有Cookie。尽管客户端可能会支持Cookie，但是由于第一次请求时不会携带任何Cookie（因为并无任何Cookie可以携带），URL地址重写后的地址中仍然会带有jsessionid。当第二次访问时服务器已经在浏览器中写入Cookie了，因此URL地址重写后的地址中就不会带有jsessionid了。

1.2.8  Session中禁止使用Cookie

既然WAP上大部分的客户浏览器都不支持Cookie，索性禁止Session使用Cookie，统一使用URL地址重写会更好一些。Java Web规范支持通过配置的方式禁用Cookie。下面举例说一下怎样通过配置禁止使用Cookie。

打开项目sessionWeb的WebRoot目录下的META-INF文件夹（跟WEB-INF文件夹同级，如果没有则创建），打开context.xml（如果没有则创建），编辑内容如下：

代码1.11 /META-INF/context.xml

或者修改Tomcat全局的conf/context.xml，修改内容如下：

代码1.12  context.xml

   

部署后TOMCAT便不会自动生成名JSESSIONID的Cookie，Session也不会以Cookie为识别标志，而仅仅以重写后的URL地址为识别标志了。

注意：该配置只是禁止Session使用Cookie作为识别标志，并不能阻止其他的Cookie读写。也就是说服务器不会自动维护名为JSESSIONID的Cookie了，但是程序中仍然可以读写其他的Cookie。

之前在学校的时候，只知道session与cookie的区别在于：session是保存在服务器端，cookie保存在客户端。session怎么样保存的？以文件的形式保存。自己去测试过。有的忘记了。对应session的id号模糊不清。在开发中，非常有必要弄明白具体细节。不能停留在使用session_start()函数了，然后获取session值。不知道里面的机制，在开发中遇到了新的问题，解决起来比较费心。

一、session是怎么保存的？怎么去查看其内容？

session是以文件的形式保存的。php.ini中有个配置项--session.save_path= "";这个里面填写的路径，将会使session文件保存在该路径下。session文件的命名格式是："sess_[PHPSESSID的值]"。每一个文件，里面保存了一个会话的数据。其实只要使用代码$_SESSION['user_id'] = $value;就会促发php的session机制，结果往对应的session文件中写入一个值。

二、session.save_path路径下这么多的session文件，php是如何确定要调用哪个session文件的？

php是依据，一个名为PHPSESSID的cookie，根据它的值，确定要调用哪个session文件的。去浏览器中，可以看到一个cookie名为PHPSESSID，假如它的值为"sess_adbjsf2q1ass26oootd163sf84"，那么，当访问服务器的时候，就会调用session目录下名为"sess_sess_adbjsf2q1ass26oootd163sf84"的文件。其实，PHPSESSID就是一个会话id，以此来确定，哪个是你的会话数据。

以下是在浏览器查看cookie所看到的

 

cookie的名字PHPSESSID是可以改的，在php.ini中 session.name = PHPSESSID就是设置该cookie的名字。

结合自己实际开发中遇到的问题，总结一下：要说session跟cookie有关联的地方，就是跟PHPSESSID这个cookie有绑定关系。其他，不管你设置什么cookie，使用session的时候是不会用到这些值的。也无法获取到。比如同步登陆，设置即使设置了cookie，而你的应用是依据session判断是否为登陆状态的(事实上也必须如此，因为session保存在服务器端，安全性更高，哪个依据cookie认为你已经登陆，那么很惨)。

所以，这样的情况就会出现，即使成功设置了cookie。也还是不能同步登陆。

 

三、经常遇到的现象：为什么删除一个session文件，之后生成一个session文件，新的文件名字还是与原来一样？

理解到session文件的命名规则是：“sess_PHPSESSID值“。那么，就很容易明白了。因为，客户端存在cookie：PHPSESSID。客户端发送请求后，会将该cookie发送给服务器(php可以使用$_COOKIE['PHPSESSID']看到其内容)，这样的话，还是会根据PHPSESSID生成一个session文件的。

四、如何查看session文件中的session值？

我在开发中发现，如果仅仅依靠session_start()和$_SESSION['user_id']这样的代码，去调试，还不够全面的了解问题所在。比如，我想知道，session_start()到底在完成哪些操作？如果，想动态，实时知道session的值是如何被改写的，打开一个session文件，查看是很了然的。原来，里面就是保存的是一些被序列化后的值。也明白一个知识点，"php圣经"中讲解session的时候，提到session值做被序列化了。下面看到的session内容就是被序列化了。

打开一个session文件，内容如下：

cityID|i:0;cityName|s:3:"all";fanwe_lang|s:5:"zh-cn";fanwe_currency|a:4:{s:2:"id";s:1:"1";s:6:"name_1";s:9:"人民币";s:4:"unit";s:3:"￥";s:5:"radio";s:6:"1.0000";}_fanwe_hash__|s:32:"77c18770c6cb5d89444c407aaa3e8477";

 

 

总结出读取规则：

1、每一个session的值是以分号";"分开的。比如“cityID|i:0;cityName|s:3:"all";”就是一个完整的session值结束

2、里面的读取规则：符号“|”前面表示session名称。符号后面是该session的具体信息。包括：数据类型，字符长度，内容。上面第一个就相当于使用如下php代码访问:$_SESSION['cityID']

 

后面的s表示数据值的长度，3表示字符长度。比如这一段：fanwe_lang|s:5:"zh-cn";  fanwe_lang是变量的名称，变量值是"zh-cn",长度刚好是5，就是”s:5“标明的。

最后"all"就表示session的具体值了。就是使用代码$_SESSION['cityID']后会得到的结果。

 

3.一个session可以保存一个数组。符号{}表示数组的内容。上面的花括号{}是$_SESSION['fanwe_currency']所保存的内容。要想查看id的值，就使用代码：$_SESSION['fanwe_currency']['id']

 

五、怎么样理解session_start等函数所做的实际操作是什么？

 

我是这样理解的：session_start，可以看成是创建一个session文件。假如有原来的session文件，或许没有创建。引入一个。往session文件中写值，那是代码“$_SESSION['']=" ";  赋值所完成的操作。
session_start()生成一个新的session文件名时。会判断是否存在cookie名为PHPSESSID的值。如果存在，那么就会按照它的值，组合成一个文件名"sess_[phpcookie值]"。所以，在目录下，老是能够看到之前删除过的session文件名。如果将浏览器中对应的cookie(PHPSESSID)删掉。那么就不会生成同样的名字了。如果不存在名为PHPSESSID的cookie。php所做的估计为：先发送一个cookie，然后按照cookie的值生成一个(我可以在浏览器中马上看到一个名为PHPSESSID的cookie)

其实，现在也更加深刻地理解了一个知识：在调用session_start()之前不能有任何输出。有输出就会报错。

session_start()已经封装了发送cookie的操作(发送一个名称为PHPSESSID的cookie到浏览器)。涉及到http的一个原理:头部信息必须在内容之前发送才行。所以，使用echo '内容';

header('Content-type: text/xml; charset=gb2312');//头部信息，不算内容

可以这样认为：session_start()内部已经进行了一次发送头部动作。所以之前不能有任何输出内容。
手册中的英文大致是这样说的：创建一个session，或者恢复当前一个session(基于request请求传递的session id,这里应该值的就是http请求时传递的名为PHPSESSID的cookie)

 

实际开发应用总结：

只要是同一个用户的操作。导航程序访问记录和团购程序访问的记录都是保存在同一个session文件中

如果是不同的域呢？假如用户访问cs.test.com和daohang.test.com，两方程序都设置了session。那么session的结果保存在同一个session文件中吗？

因为：服务器是统一管理session文件的存放的。而php引擎是根据phpsessionid的值确定要操作哪个session文件。session

文件名的格式是："sess_[phpcookie值]"。依次寻找对应的session文件(于是在浏览器查看名为PHPSESSIONID的cookie，过期时间是在会话结束后)
所以，只要cs.test.com和daohang.test.com使用的是同一台服务器。
这样的话，假如是多台服务器的情况。那么就不得不将session保存在数据库中去。这样实现session共享。跟具体的服务器是无关的。

 

（2013年更新：实际上共享session不局限于数据库中保存，关于session共享方案，根据自己的理解一年后写了一篇总结文章，http://www.cnblogs.com/wangtao_20/p/3395518.html）

session文件是某个用户整个会话过程中数据。那么，假如cs.test.com和daohang.test.com下的两个程序运行在同一个服务器上。就意味着，访问cs.test.com与访问daohang.test.com是同一个会话。也就意味着，这两边访问后设置的session数据是保存在同一个session文件中的。

可以将名为PHPSESSIONID的cookie，其值看成是一个会话的id。会话结束后，该cookie过期或者被删。那么，服务器对应的session文件(名为"sess_[phpcookie值]")会被删掉吗？查看发现并不会被删掉。所以才会有session文件很多，出现读取性能的问题。session文件比较多的情况下，产生I/Q读写性能问题。了解到可以将session文件分多个目录保存(参考http://www.jb51.net/article/27941.htm)。php.ini中的配置项session.save_path,前面一个值M可以指定目录的深度级别。这个没测试过。需要用到的时候，再去测试一下。

待解决疑问

一、session的过期时间是怎么确定的？
查看session文件内容，发现里面有个值设置了session文件的过期时间：__HTTP_Session_Expire_TS|i:1297750868;

已掌握的信息：
PHPSESSID该cookie的过期时间在浏览器中显示：会话结束后过期

所有的session文件没有被自动删掉，只是有个过期时间，以此决定：是新生成一个session文件还是使用原来的。

原来：服务器定期session清理机制估计会用到这个东西

二、如果没有设置php.ini中的参数。php默认会将session文件保存到什么位置？

附网文：php.ini中配置session参数的说明。

【Session】

 

[服务端]

session.save_handler = files

默认为file，定义session在服务端的保存方式，file意为把sesion保存到一个临时文件里，如果我们想自定义别的方式保存

（比如用数据库），则需要把该项设置为user；

 

session.save_path = "D:/APMServ5.2.0/PHP/sessiondata/"

定义服务端存储session的临时文件的位置。

 

session.auto_start = 0

如置1，则不用在每个文件里写session_start(); session自动start ：）

 

session.gc_probability = 1

session.gc_divisor    = 100

session.gc_maxlifetime = 1440

这三个配置组合构建服务端session的垃圾回收机制

session.gc_probability与session.gc_divisor构成执行session清理的概率，理论上的解释为服务端定期有一定的概率调用gc函数来对session进行清理，清理的概率为：gc_probability/gc_divisor 比如：1/100  表示每一个新会话初始化时，有

1%的概率会启动垃圾回收程序，清理的标准为session.gc_maxlifetime定义的时间。

 

[客户端]

session.use_cookies = 1

sessionid在客户端采用的存储方式，置1代表使用cookie记录客户端的sessionid，同时，$_COOKIE变量里才会有$_COOKIE[

‘PHPSESSIONID’]这个元素存在；

 

session.use_only_cookies = 1

也是定义sessionid在客户端采用的存储方式，置1代表仅仅使用 cookie 来存放会话 ID。一般来说，现在客户端都会支持

cookie，所以建议设置成1，这样可以防止有关通过 URL 传递会话 ID 的攻击。

 

session.use_trans_sid = 0

相对应于上面那个设置，这里如果置1，则代表允许sessionid通过url参数传递，同理，建议设置成0；

 

session.referer_check = 

这个设置在session.use_trans_sid = 1的时候才会生效，目的是检查HTTP头中的"Referer"以判断包含于URL中的会话id是否

有效，HTTP_REFERER必须包含这个参数指定的字符串，否则URL中的会话id将被视为无效。所以一般默认为空，即不检查。 

 

session.name = PHPSESSID

定义sessionid的名称，即变量名，所以通过浏览器http工具看到的http头文件里的PHPSESSID=##############；

 

session.hash_function = 0

选择session_name的加密方式，0代表md5加密，1代表sha1加密，默认是0，但是据说用sha1方式加密，安全性更高；

 

session.hash_bits_per_character = 4

指定在session_name字符串中的每个字符内保存多少位二进制数，这些二进制数是hash函数的运算结果。

4   bits:   0-9,   a-f 

5   bits:   0-9,   a-v 

6   bits:   0-9,   a-z,   A-Z,   "-",   ","

 

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="

指定重写哪些HTML标签来包含sid(session_id)（仅在"session.use_trans_sid"打开的情况下有效），URL重写器将添加一个

隐藏的""，它包含了本应当额外追加到URL上的信息。 

 

session.cookie_lifetime = 0

保存sessionid的cookie文件的生命周期，如置0，代表会话结束，则sessionid就自动消失，常见的强行关闭浏览器，就会丢

失上一次的sessionid；

 

session.cookie_path = /

保存sessionid的cookie文件在客户端的位置；

 

session.cookie_domain = /

保存sessionid的cookie的域名设置，这跟cookie允许的域名的访问权限设置有关，一般来说想让自己网站所有的目录都能访

问到客户端的cookie，就应该设置成“/”如需要详细了解，可以看下setcookie()函数的domain参数相关设置和使用方法；

 

session.bug_compat_42 = 1

session.bug_compat_warn = 1

这两个可以说几乎是快要被废弃的设置，是为了老版本的php服务的，主要是针对 session_register函数，因为php5的

register_global默认是关闭状态，所以在php5里根本用不到 session_register这个函数；并且php6就要废除这个设置，直接定义为关闭，所以没必要研究这两个了；

 

2015.6.14

今天无意中看php手册，注意到这句话：

在某些操作系统上，建议使用可以高效处理 大量小尺寸文件的文件系统上的路径来保存会话数据。 例如，在 Linux 平台上，对于会话数据保存的工作而言，reiserfs 文件系统会比 ext2fs 文件系统能够提供更好的性能。

这个是好的方向。session的数据一般很小。适合小文件的文件系统来使用，而我们的传统的文件系统不太适合。

一、cookie机制和session机制的区别

具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。
同时我们也看到，由于才服务器端保持状态的方案在客户端也需要保存一个标识，所以session
机制可能需要借助于cookie机制来达到保存标识的目的，但实际上还有其他选择

二、会话cookie和持久cookie的区别

如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。
存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。

三、如何利用实现自动登录

当用户在某个网站注册后，就会收到一个惟一用户ID的cookie。客户后来重新连接时，这个
用户ID会自动返回，服务器对它进行检查，确定它是否为注册用户且选择了自动登录，从而使用户务需给出明确的用户名和密码，就可以访问服务器上的资源。

四、如何根据用户的爱好定制站点

网站可以使用cookie记录用户的意愿。对于简单的设置，网站可以直接将页面的设置存储在cookie中完成定制。然而对于更复杂的定制，网站只需仅将一个惟一的标识符发送给用户，由服务器端的数据库存储每个标识符对应的页面设置。

五、cookie的发送

1.创建Cookie对象
2.设置最大时效
3.将Cookie放入到HTTP响应报头
如果你创建了一个cookie，并将他发送到浏览器，默认情况下它是一个会话级别的cookie:存储在浏览器的内存中，用户退出浏览器之后被删除。如果你希望浏览器将该cookie存储在磁盘上，则
需要使用maxAge，并给出一个以秒为单位的时间。将最大时效设为0则是命令浏览器删除该cookie。
发送cookie需要使用HttpServletResponse的addCookie方法，将cookie插入到一个Set-Cookie　HTTP请 求报头中。由于这个方法并不修改任何之前指定的Set-Cookie报头，而是创建新的报头，因此我们将这个方法称为是addCookie，而非 setCookie。同样要记住响应报头必须在任何文档内容发送到客户端之前设置。

六、cookie的读取

1.调用request.getCookie
要获取有浏览器发送来的cookie，需要调用HttpServletRequest的getCookies方法，这个调用返回Cookie对象的数组，对应由HTTP请求中Cookie报头输入的值。
2.对数组进行循环，调用每个cookie的getName方法，直到找到感兴趣的cookie为止
cookie与你的主机(域)相关，而非你的servlet或JSP页面。因而，尽管你的servlet可能只发送了单个cookie，你也可能会得到许多不相关的cookie。
例如：
String cookieName = “userID”;
    Cookie cookies[] = request.getCookies();
    if (cookies!=null){
        for(int i=0;i     Cookie cookie = cookies[i];
    if (cookieName.equals(cookie.getName())){
        doSomethingWith(cookie.getValue());
}
}
}

七、如何使用cookie检测初访者

A.调用HttpServletRequest.getCookies()获取Cookie数组
B.在循环中检索指定名字的cookie是否存在以及对应的值是否正确
C.如果是则退出循环并设置区别标识
D.根据区别标识判断用户是否为初访者从而进行不同的操作

八、使用cookie检测初访者的常见错误

不能仅仅因为cookie数组中不存在在特定的数据项就认为用户是个初访者。如果cookie数组为null，客户可能是一个初访者，也可能是由于用户将cookie删除或禁用造成的结果。
但是，如果数组非null,也不过是显示客户曾经到过你的网站或域，并不能说明他们曾经访问过你的servlet。其它servlet、JSP页面以及非Java Web应用都可以设置cookie，依据路径的设置，其中的任何cookie都有可能返回给用户的浏览器。
正确的做法是判断cookie数组是否为空且是否存在指定的Cookie对象且值正确。

九、使用cookie属性的注意问题

属性是从服务器发送到浏览器的报头的一部分；但它们不属于由浏览器返回给服务器的报头。　
因此除了名称和值之外，cookie属性只适用于从服务器输出到客户端的cookie；服务器端来自于浏览器的cookie并没有设置这些属性。　
因而不要期望通过request.getCookies得到的cookie中可以使用这个属性。这意味着，你不能仅仅通过设置cookie的最大时效，发 出它，在随后的输入数组中查找适当的cookie,读取它的值，修改它并将它存回Cookie，从而实现不断改变的cookie值。

十、如何使用cookie记录各个用户的访问计数

1.获取cookie数组中专门用于统计用户访问次数的cookie的值
2.将值转换成int型
3.将值加1并用原来的名称重新创建一个Cookie对象
4.重新设置最大时效
5.将新的cookie输出

十一、session在不同环境下的不同含义

session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话是从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。
然而当session一词与网络协议相关联时，它又往往隐含了“面向连接”和/或“保持状态”这样两个含义。
session在Web开发环境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器端之间保持状态的解决方案。有时候Session也用来指这种解决方案的存储结构。

十二、session的机制

session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。
但程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否包含了一个session标识－称为session id,如果已经包含一个session id则说明以前已经为此客户创建过session，服务器就按照session id把这个session检索出来使用(如果检索不到，可能会新建一个，这种情况可能出现在服务端已经删除了该用户对应的session对象，但用户人为 地在请求的URL后面附加上一个JSESSION的参数)。
如果客户请求不包含session id，则为此客户创建一个session并且生成一个与此session相关联的session id，这个session id将在本次响应中返回给客户端保存。

十三、保存session id的几种方式

A．保存session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
B．由于cookie可以被人为的禁止，必须有其它的机制以便在cookie被禁止时仍然能够把session id传递回服务器，经常采用的一种技术叫做URL重写，就是把session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终 保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。
C．另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。

十四、session什么时候被创建

一个常见的错误是以为session在有客户端访问时就被创建，然而事实是直到某server端程序(如Servlet)调用HttpServletRequest.getSession(true)这样的语句时才会被创建。

十五、session何时被删除

session在下列情况下被删除：
A．程序调用HttpSession.invalidate()
B．距离上一次收到客户端发送的session id时间间隔超过了session的最大有效时间
C．服务器进程被停止

再次注意关闭浏览器只会使存储在客户端浏览器内存中的session cookie失效，不会使服务器端的session对象失效。

十六、URL重写有什么缺点

对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL。每个引用你的站点的URL，以及那些返回给用户的URL(即使通过间接手段，比如服务器重定向中的Location字段)都要添加额外的信息。
这意味着在你的站点上不能有任何静态的HTML页面(至少静态页面中不能有任何链接到站点动态页面的链接)。因此，每个页面都必须使用servlet或 JSP动态生成。即使所有的页面都动态生成，如果用户离开了会话并通过书签或链接再次回来，会话的信息都会丢失，因为存储下来的链接含有错误的标识信息－ 该URL后面的SESSION ID已经过期了。　　

十七、使用隐藏的表单域有什么缺点

    仅当每个页面都是有表单提交而动态生成时，才能使用这种方法。单击常规的超文本链接并不产生表单提交，因此隐藏的表单域不能支持通常的会话跟踪，只能用于一系列特定的操作中，比如在线商店的结账过程

十八、会话跟踪的基本步骤

1．访问与当前请求相关的会话对象
2．查找与会话相关的信息
3．存储会话信息
4．废弃会话数据

十九、getSession()/getSession(true)、getSession(false)的区别

getSession()/getSession(true)：当session存在时返回该session，否则新建一个session并返回该对象
getSession(false)：当session存在时返回该session，否则不会新建session，返回null

二十、如何将信息于会话关联起来

setAttribute会替换任何之前设定的值；如果想要在不提供任何代替的情况下移除某个值，则应使用removeAttribute。这个方法会触发所有实现了HttpSessionBindingListener接口的值的valueUnbound
方法。

二十一、会话属性的类型有什么限制吗

通常会话属性的类型只要是Object就可以了。除了null或基本类型，如int,double,boolean。
如果要使用基本类型的值作为属性，必须将其转换为相应的封装类对象

二十二、如何废弃会话数据

A．只移除自己编写的servlet创建的数据：
   调用removeAttribute(“key”)将指定键关联的值废弃
B．删除整个会话(在当前Web应用中)：
   调用invalidate，将整个会话废弃掉。这样做会丢失该用户的所有会话数据，而非仅仅由我们
servlet或JSP页面创建的会话数据
C．将用户从系统中注销并删除所有属于他(或她)的会话
   调用logOut，将客户从Web服务器中注销，同时废弃所有与该用户相关联的会话(每个Web应用至多一个)。这个操作有可能影响到服务器上多个不同的Web应用

二十三、使用isNew来判断用户是否为新旧用户的错误做法

public boolean isNew()方法如果会话尚未和客户程序(浏览器)发生任何联系，则这个方法返回true，这一般是因为会话是新建的，不是由输入的客户请求所引起的。
但如果isNew返回false，只不过是说明他之前曾经访问该Web应用，并不代表他们曾访问过我们的servlet或JSP页面。
因为session是与用户相关的，在用户之前访问的每一个页面都有可能创建了会话。因此isNew为false只能说用户之前访问过该Web应用，session可以是当前页面创建，也可能是由用户之前访问过的页面创建的。
正确的做法是判断某个session中是否存在某个特定的key且其value是否正确

二十四、Cookie的过期和Session的超时有什么区别

会话的超时由服务器来维护，它不同于Cookie的失效日期。首先，会话一般基于驻留内存的cookie
不是持续性的cookie，因而也就没有截至日期。即使截取到JSESSIONID cookie，并为它设定一个失效日期发送出去。浏览器会话和服务器会话也会截然不同。

二十五、session cookie和session对象的生命周期是一样的吗

当用户关闭了浏览器虽然session cookie已经消失，但session对象仍然保存在服务器端

二十六、是否只要关闭浏览器，session就消失了

程序一般都是在用户做log off的时候发个指令去删除session，然而浏览器从来不会主动在关闭之前通知服务器它将要被关闭，因此服务器根本不会有机会知道浏览器已经关闭。服务器会一直保留这个会话对象直到它处于非活动状态超过设定的间隔为止。
之所以会有这种错误的认识，是因为大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接到服务器时也就无法找到原来的session。
如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求报头，把原来的session id发送到服务器，则再次打开浏览器仍然能够找到原来的session。
恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为session设置了一个失效时间，当距离客户上一次使用session的时间超过了这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。
由此我们可以得出如下结论：
关闭浏览器，只会是浏览器端内存里的session cookie消失，但不会使保存在服务器端的session对象消失，同样也不会使已经保存到硬盘上的持久化cookie消失。

二十七、打开两个浏览器窗口访问应用程序会使用同一个session还是不同的session

通常session cookie是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的session id，这样我们信息共享的目的就达不到了。
此时我们可以先把session id保存在persistent cookie中(通过设置session的最大有效时间)，然后在新窗口中读出来，就可以得到上一个窗口的session id了，这样通过session cookie和persistent cookie的结合我们就可以实现了跨窗口的会话跟踪。

二十八、如何使用会话显示每个客户的访问次数

由于客户的访问次数是一个整型的变量，但session的属性类型中不能使用int，double，boolean等基本类型的变量，所以我们要用到这些基本类型的封装类型对象作为session对象中属性的值
但像Integer是一种不可修改(Immutable)的数据结构：构建后就不能更改。这意味着每个请求都必须创建新的Integer对象，之后使用setAttribute来代替之前存在的老的属性的值。例如：
HttpSession session = request.getSession();
SomeImmutalbeClass value = (SomeImmutableClass)session.getAttribute(“SomeIdentifier”);
if (value= =null){
    value = new SomeImmutableClass(…);　// 新创建一个不可更改对象
}else{
    value = new SomeImmutableClass(calculatedFrom(value)); // 对value重新计算后创建新的对象
}
session.setAttribute(“someIdentifier”,value); // 使用新创建的对象覆盖原来的老的对象

二十九、如何使用会话累计用户的数据

使用可变的数据结构，比如数组、List、Map或含有可写字段的应用程序专有的数据结构。通过这种方式，除非首次分配对象，否则不需要调用setAttribute。例如

HttpSession session = request.getSession();
SomeMutableClass value = (SomeMutableClass)session.getAttribute(“someIdentifier”);
if(value = = null){
    value = new SomeMutableClass(…);
    session.setAttribute(“someIdentifier”,value);
}else{
    value.updateInternalAttribute(…);     // 如果已经存在该对象则更新其属性而不需重新设置属性
}

三十、不可更改对象和可更改对象在会话数据更新时的不同处理

不可更改对象因为一旦创建之后就不能更改，所以每次要修改会话中属性的值的时候，都需要
调用setAttribute(“someIdentifier”,newValue)来代替原有的属性的值，否则属性的值不会被更新
可更改对象因为其自身一般提供了修改自身属性的方法，所以每次要修改会话中属性的值的时
候，只要调用该可更改对象的相关修改自身属性的方法就可以了。这意味着我们就不需要调
用setAttribute方法了