JavaWeb中的cookie和session

为什么要有cookie和session？

http协议是一种无状态的协议，web服务器不会识别出哪些请求来自谁，而且浏览器的每次请求都是孤立的。那如果我们需要知道上一次请求的用户信息该怎么办呢？web服务器应该采用一种机制来唯一地标识一个用户，同时记录这个用户的会话状态。Web服务器能够借助会话状态将属于同一会话的一系列请求和响应关联起来。
WEB服务器端程序要能从大量的请求消息中区分出哪些请求消息属于同一个会话，即能识别出来自同一个浏览器的访问请求，这需要浏览器对其发出的每个请求消息都进行标识：属于同一个会话中的请求消息都附带同样的标识号，而属于不同会话的请求消息总是附带不同的标识号，这个标识号就称之为会话ID（SessionID）。
实际开发中常用cookie和session来完成会话跟踪。

Cookie

1. cookie机制

• cookie机制采用的是在客户端保持 HTTP 状态信息的方案
• Cookie是在浏览器访问WEB服务器的某个资源时，由WEB服务器在HTTP响应消息头中附带传送给浏览器的一个小文本文件。
• 一旦WEB浏览器保存了某个Cookie，那么它在以后每次访问该WEB服务器时，都会在HTTP请求头中将这个Cookie回传给WEB服务器。
• 底层的实现原理： WEB服务器通过在HTTP响应消息中增加Set-Cookie响应头字段将Cookie信息发送给浏览器，浏览器则通过在HTTP请求消息中增加Cookie请求头字段将Cookie回传给WEB服务器。
• 一个Cookie只能标识一种信息，它至少含有一个标识该信息的名称（NAME）和设置值（VALUE）。
• 一个WEB站点可以给一个WEB浏览器发送多个Cookie，一个WEB浏览器也可以存储多个WEB站点提供的Cookie。
• 浏览器一般只允许存放300个Cookie，每个站点最多存放20个Cookie，每个Cookie的大小限制为4KB。

2. Cookie的发送

1. 创建cookie
2. 设置最大有效时长
3. 将cookie放入http响应报头

• 如果创建了一个cookie，并将他发送到浏览器，默认情况下它是一个会话级别的cookie; 存储在浏览器的内存中，用户退出浏览器之后被删除。若希望浏览器将该cookie存储在磁盘上，则需要使用maxAge，并给出一个以秒为单位的时间。将最大时效设为0则是命令浏览器删除该cookie。
• 发送cookie需要使用HttpServletResponse的addCookie方法，将cookie插入到一个 Set-Cookie　HTTP响应报头中。由于这个方法并不修改任何之前指定的Set-Cookie报头，而是创建新的报头，因此将这个方法称为是addCookie，而非setCookie。

4. 会话cookie和持久cookie的区别

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

5. cookie的读取

1. 调用request.getCookies
   要获取浏览器发送来的cookie，需要调用HttpServletRequest的getCookies方法，这个调用返回Cookie对象的数组，对应由HTTP请求中Cookie报头输入的值。
2. 对数组进行循环，调用每个cookie的getName方法，直到找到感兴趣的cookie为止

6. cookie的存储
在IE浏览器中，IE将各个站点的Cookie分别保存为一个XXX.txt这样的纯文本文件（文件个数可能很多，但文件大小都较小）；而Firefox和Chrome是将所有的Cookie都保存在一个文件中（文件大小较大），该文件的格式为SQLite3数据库格式的文件。

• IE浏览器Cookie数据位于：%APPDATA%\Microsoft\Windows\Cookies\ 目录中的xxx.txt文件 （里面可能有很多个.txt Cookie文件）
• Firefox的Cookie数据位于：%APPDATA%\Mozilla\Firefox\Profiles\ 目录中的xxx.default目录，名为cookies.sqlite的文件。
• Chrome的Cookie数据位于：%LOCALAPPDATA%\Google\Chrome\User Data\Default\ 目录中，名为Cookies的文件。

Session

Session指的是一类用来在客户端和服务端之间保持状态的解决方案。在WEB开发中，服务器可以为每个用户浏览器创建一个会话对象（session对象），注意：一个浏览器独占一个session对象(默认情况下)。因此，在需要保存用户数据时，服务器程序可以把用户数据写到用户浏览器独占的session中，当用户使用浏览器访问其它程序时，其它程序可以从用户的session中取出该用户的数据，为用户服务。

1. session和cookie 的区别

• Cookie是把用户的数据写给用户的浏览器。Session技术把用户的数据写到用户独占的session中。
• Session对象由服务器创建，开发人员可以调用request对象的getSession方法得到session对象。

2. 保存sessionid的方式

• 保存session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。
• 服务器创建session出来后，会把session的id号，以cookie的形式回写给客户机，这样，只要客户机的浏览器不关，再去访问服务器时，都会带着session的id号去，服务器发现客户机浏览器带session id过来了，就会使用内存中与之对应的session为之服务。
• 由于cookie可以被人为的禁用，必须有其它的机制以便在cookie被禁用时仍然能够把session id传递回服务器，经常采用的一种技术叫做URL重写，就是把session id，既必须在每个客户端可能请求的路径后面都包含这附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终保持状态个session id。
• session通过SessionID来区分不同的客户, session是以cookie或URL重写为基础的，默认使用cookie来实现，系统会创造一个名为JSESSIONID的输出cookie，这称之为session cookie,以区别persistent cookies(也就是我们通常所说的cookie),session cookie是存储于浏览器内存中的，并不是写到硬盘上的，通常看不到JSESSIONID，但是当把浏览器的cookie禁止后，web服务器会采用URL重写的方式传递Sessionid，这时地址栏看到
• session cookie针对某一次会话而言，会话结束session cookie也就随着消失了，而persistent cookie只是存在于客户端硬盘上的一段文本。
• 关闭浏览器，只会是浏览器端内存里的session cookie消失，但不会使保存在服务器端的session对象消失，同样也不会使已经保存到硬盘上的持久化cookie消失。

Session 的持久化：
   <%
          Cookie cookie = new  Cookie("JSESSIONID",session.getId());
          cookie.setMaxAge(20);
          response.addCookie(cookie);
   %>

3. HttSsession的生命周期

1. 创建
   ①. 对于 JSP: 是否浏览器访问服务端的任何一个 JSP, 服务器都会立即创建一个 HttpSession 对象呢？不一定。若当前的 JSP 是客户端访问的当前 WEB 应用的第一个资源，且 JSP 的 page 指定的 session 属性值为 false, 则服务器就不会为 JSP 创建一个 HttpSession 对象; 若当前 JSP 不是客户端访问的当前 WEB 应用的第一个资源，且其他页面已经创建一个 HttpSession 对象，则服务器也不会为当前 JSP 页面创建一个 HttpSession 对象，而回会把和当前会话关联的那个 HttpSession 对象返回给当前的 JSP 页面.

   ②. 对于 Serlvet: 若 Serlvet 是客户端访问的第一个 WEB 应用的资源,
   则只有调用了 request.getSession() 或 request.getSession(true) 才会创建 HttpSession 对象

2. 销毁
   ①. 直接调用 HttpSession 的 invalidate() 方法: 该方法使 HttpSession 失效
   ②. 服务器卸载了当前 WEB 应用.
   ③. 超出 HttpSession 的过期时间.
   ④. 并不是关闭了浏览器就销毁了 HttpSession.

3. URL重写
   Servlet规范中引入了一种补充的会话管理机制，它允许不支持Cookie的浏览器也可以与WEB服务器保持连续的会话。这种补充机制要求在响应消息的实体内容中必须包含下一次请求的超链接，并将会话标识号作为超链接的URL地址的一个特殊参数。 将会话标识号以参数形式附加在超链接的URL地址后面的技术称为URL重写。如果在浏览器不支持Cookie或者关闭了Cookie功能的情况下，WEB服务器还要能够与浏览器实现有状态的会话，就必须对所有可能被客户端访问的请求路径（包括超链接、form表单的action属性设置和重定向的URL）进行URL重写。 HttpServletResponse接口中定义了两个用于完成URL重写方法：encodeURL方法和encodeRedirectURL方法encodeURL () 及 encodeRedirectedURL () 方法首先判断 cookies 是否被浏览器支持；如果支持，则参数 URL 被原样返回，session ID 将通过 cookies 来维持。