Session、Cookie总结

什么是sessnion,session存在哪，能存多久，怎么设置他的存储时间

一、什么是session

1、session 被翻译为会话，当客户端（一般都是浏览器作为客户端）访问服务器，如果是第一次访问而且reqeust.getSession()则服务器端就能获取一个session 对象。我们可以调用session.getId()获取这个session的id也就是session 在服务器端的内存中的地址。

2、如果同一个浏览器窗口多次访问服务器，则之前的session是共享的，也就不会再创建session了，同样打开的是这个窗口的子窗口，子窗口和父窗口session也是共享的。

二、session 存在哪里

1、session 中的数据是存储在服务器端的内存中，而我们获取的那个sessionid就是这个session在服务器端的内存的地址。

2、sessionid 有了这个sessionid我们每次请求后，会到服务器端这个内存id中获取存储的数据。从面向对象的角度来说他就是一个对象的引用地址。获取了他就是获取了这个session对象。

3、这个session是在客户端第一次发送请求时在服务器端生成的，那我们第二次访问的时候怎么知道这个sessionid 那，这里就分两种情况，一种是cookie没有禁用，也就是cookie能使用： 当我们第一次访问服务器的时候服务器端会生成一个对应的session 并会自动的把这个sessionid添加到cookie中，也就是我们经常在响应信息中看到的 JSESSIONID=E377AAAA054D8F52CF7206F0A2BCEE95.tomcat1 这样我们第二次访问的时候浏览器会把这个cookie中的信息也带上，这样我们就能找到第一次访问时生成的那个session了。

第二种情况：cookie被禁用了： 这用情况我们第一种方式不行，也就是没法保存到cookie中，那么我们就重写url将JSESSIONID=XXXXX这个值添加到我们的请求路径中，这样做和添加到cookie中是同样的效果。url重写后的格式：http://localhost:18080/servlet/index.jsp;jsessionid=93C0C1C80DC217BBDA4E78BC2377359A.tomcat1

要注意这里是使用‘；’而不是‘？’链接的。

三、session能存多久

1、session的过期时间可以自己设定，当我们在创建session之后设置了session的有效时间后。即使我们关闭了浏览器窗口这个session 也不会立刻过期，他还是存在的直到他的过期时间。而过期时间是以该窗口最后一次访问服务器的时间为起始时间，而不是此一次的访问时间。

2、在web.xml 中我们可以设置这个web应用的所有session的过期时间：

<session-config>

 <session-timeout>23</session-timeout>

  </session-config>

3、设定这一个session的过期时间:    setMaxInactiveInterval(20);   设定时间单位为 秒！

什么是cookie、cookie存在哪里、cookie中的值能存多久

一、cookie类似于map集合存放数据是按照key=value的格式存储，如果我们使用的浏览器没有禁用cookie则我们添加到cookie中的信息会在发送请求时和请求信息一起提交到服务器。我们在服务器端可以获取这个cookie以及cookie 中存储的值。

二、cookie存在哪里，cookie对象或者说添加到cookie中的数据是保存到客户端。也就是保存到客户端自己机器的某个磁盘的临时文件中。

三、cookie 和session一样我们可以设置cookie的有效期，等过期后客户端的额cookie自动删除了。

来自网络上的总结 session生命周期：

Session的生命周期

以前在学习的时候没怎么注意，今天又回过头来仔细研究研究了一下Session的生命周期。

Session存储在服务器端，一般为了防止在服务器的内存中（为了高速存取），Sessinon在用户访问第一次访问服务器时创建，需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session，可调用request.getSession(true)强制生成Session。

Session什么时候失效？

1.服务器会把长时间没有活动的Session从服务器内存中清除，此时Session便失效。Tomcat中Session的默认失效时间为20分钟。

2.调用Session的invalidate方法。

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。JavaWeb提供了另一种解决方案：URL地址重写。

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

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

来自网络上的总结 cookie生命周期：

Cookie的生命周期问题

设置Cookie对象的有效时间，setMaxAge()方法便可以设置Cookie对象的有效时间，

例如：Cookie c = new Cookie("username","value");  // username 为这个cookie的名称而value 则为为这个cookie设置的值。

c.setMaxAge(60);//60秒的意思

如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。

这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。

如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方 式。

cookie.setmaxage设置为0时，会马上在浏览器上删除指定的cookie

cookie.setmaxage设置为-1时，代表关闭当前浏览器即失效。

来自网络上的cookie跨域问题：

Cookie跨域setDomain和setPath

正常的cookie只能在一个应用中共享，即一个cookie只能由创建它的应用获得。

1.可在同一应用服务器内共享方法：设置cookie.setPath("/");

本机tomcat/webapp下面有两个应用：cas和webapp_b，

1）原来在cas下面设置的cookie，在webapp_b下面获取不到，path默认是产生cookie的应用的路径。

2）若在cas下面设置cookie的时候，增加一条cookie.setPath("/");或者cookie.setPath("/webapp_b/");就可以在webapp_b下面获取到cas设置的cookie了。

3）此处的参数，是相对于应用服务器存放应用的文件夹的根目录而言的(比如tomcat下面的webapp)，因此cookie.setPath("/");之后，可以在webapp文件夹下的所有应用共享cookie，而cookie.setPath("/webapp_b/");是指cas应用设置的cookie只能在webapp_b应用下的获得，即便是产生这个cookie的cas应用也不可以。

4）设置cookie.setPath("/webapp_b/jsp")或者cookie.setPath("/webapp_b/jsp/")的时候，只有在webapp_b/jsp下面可以获得cookie，在webapp_b下面但是在jsp文件夹外的都不能获得cookie。

5）设置cookie.setPath("/webapp_b");，是指在webapp_b下面才可以使用cookie，这样就不可以在产生cookie的应用cas下面获取cookie了

6）有多条cookie.setPath("XXX");语句的时候，起作用的以最后一条为准。

2.跨域共享cookie的方法：设置cookie.setDomain(".jszx.com");

A机所在的域：home.langchao.com,A有应用cas

B机所在的域：jszx.com，B有应用webapp_b

1）在cas下面设置cookie的时候，增加cookie.setDomain(".jszx.com");，这样在webapp_b下面就可以取到cookie。

2）这个参数必须以“.”开始。

3）输入url访问webapp_b的时候，必须输入域名才能解析。比如说在A机器输入：http://lc-bsp.jszx.com:8080/webapp_b,可以获取cas在客户端设置的cookie，而B机器访问本机的应用，输入：http://localhost:8080/webapp_b则不可以获得cookie。

4）设置了cookie.setDomain(".jszx.com");，还可以在默认的home.langchao.com下面共享。

cookie于session的区别和联系：

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

   cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。

   cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式

   session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

   当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的sessionid，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

   保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SESSIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。

   经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如：

    <form name="testform" action="/xxx">

    <input type="hidden" name="jsessionid"value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">

    <input type="text">

    </form>

实际上这种技术可以简单的用对action应用URL重写来代替。

Cookie、Session 实例：

一、cookie 获取和设置，这里是demo所以cookie的value没有进行加密，而在实际开发中进行加密

// 调用request.getCookie()方法获取的是cookie数组，我们通过getname获取我们想要的那个cookie

Cookie[] cookies= request.getCookies();

if(null!=cookies&&cookies.length>0){

for(inti =0;i<cookies.length;i++){

// 如果获取到了我们想要的cookie则我们就获取这个cookie中存储的值即.getValue()

if("cookie".equals(cookies[i].getName())){

System.out.println("cookie 名称"+cookies[i].getName());

System.out.println("cookie 的值"+cookies[i].getValue());

}else{

// 新建一个cookie 名称cookie  value hellocookie

Cookiecook= new Cookie("cookie","hellocookie");

// 域名localhost域名下的应用可以共享这个cookie

cook.setDomain("localhost");

// 这个路劲下的应用才可以使用这个cookie

cook.setPath("/");

// cookie 有效期60秒*6= 6分钟

cook.setMaxAge(60*6);

// 将这个cookie保存到客户端

response.addCookie(cook);

response.sendRedirect("index.jsp");

}

}

}else{

// 新建一个cookie 名称cookie  value hellocookie

Cookiecook= new Cookie("cookie","hellocookie");

// 域名localhost域名下的应用可以共享这个cookie

cook.setDomain("localhost");

// 这个路劲下的应用才可以使用这个cookie

cook.setPath("/");

// cookie 有效期60秒*6= 6分钟

cook.setMaxAge(60*6);

// 将这个cookie保存到客户端

response.addCookie(cook);

response.sendRedirect("index.jsp");

}

二、当禁用了cookie后我们的sessionid就不会自动保存到cookie中，也不可能保存到cookie中，所以我们在服务端要重写url

protected voiddoPost(HttpServletRequest request, HttpServletResponse response) throwsServletException, IOException {

// cookie 被警用之后我们可以使用url 重写来向服务器提交sessionid

// 注意如果禁用了cookie要重写url则首先要获取session对象，也就是为了获取sessionid

request.getSession().setAttribute("age",10);

// 这只了这个session的生命周期

request.getSession().setMaxInactiveInterval(20);

// 调用encodeRedirectURL重写跳转的url

Stringurl=response.encodeRedirectURL("index.jsp");

// 输出测值  重写url： index.jsp;jsessionid=3E4D0191A7850A057C164334A8997D8A.tomcat1

System.out.println("重写url："+url);

// 跳转

response.sendRedirect(url);

}