什么是sessnion,session存在哪，能存多久。怎么设置他的存储时间
一、什么是session
1、session 被翻译为会话。当client（一般都是浏览器作为client）訪问server。假设是第一次訪问并且reqeust.getSession()则server端就能获取一个session 对象。
我们能够调用session.getId()获取这个session的id也就是session 在server端的内存中的地址。
2、假设同一个浏览器窗体多次訪问server，则之前的session是共享的，也就不会再创建session了。相同打开的是这个窗体的子窗体。子窗体和父窗体session也是共享的。
二、session 存在哪里
1、session 中的数据是存储在server端的内存中。而我们获取的那个sessionid就是这个session在server端的内存的地址。
2、sessionid 有了这个sessionid我们每次请求后，会到server端这个内存id中获取存储的数据。
从面向对象的角度来说他就是一个对象的引用地址。获取了他就是获取了这个session对象。
3、这个session是在client第一次发送请求时在server端生成的，那我们第二次訪问的时候怎么知道这个sessionid 那。这里就分两种情况。一种是cookie没有禁用，也就是cookie能使用： 当我们第一次訪问server的时候server端会生成一个相应的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 也不会立马过期。他还是存在的直到他的过期时间。而过期时间是以该窗体最后一次訪问server的时间为起始时间，而不是此一次的訪问时间。
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中的信息会在发送请求时和请求信息一起提交到server。我们在server端能够获取这个cookie以及cookie 中存储的值。
二、cookie存在哪里，cookie对象或者说加入到cookie中的数据是保存到client。也就是保存到client自己机器的某个磁盘的暂时文件里。
三、cookie 和session一样我们能够设置cookie的有效期，等过期后client的额cookie自己主动删除了。
来自网络上的总结 session生命周期：
曾经在学习的时候没怎么注意。今天又回过头来细致研究研究了一下Session的生命周期。
Session存储在server端，一般为了防止在server的内存中（为了快速存取），Sessinon在用户訪问第一次訪问server时创建，须要注意仅仅有訪问JSP、Servlet等程序时才会创建Session，仅仅訪问HTML、IMAGE等静态资源并不会创建Session，可调用request.getSession(true)强制生成Session。
Session什么时候失效？
1.server会把长时间没有活动的Session从server内存中清除，此时Session便失效。Tomcat中Session的默认失效时间为20分钟。
2.调用Session的invalidate方法。
Session对浏览器的要求：
尽管Session保存在server，对client是透明的，它的正常执行仍然须要client浏览器的支持。这是由于Session须要使用Cookie作为识别标志。
HTTP协议是无状态的，Session不能根据HTTP连接来推断是否为同一客户。因此server向client浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session根据该Cookie来识别是否 为同一用户。
该Cookie为server自己主动生成的，它的maxAge属性一般为-1，表示仅当前浏览器内有效，而且各浏览器窗体间不共享。关闭浏览器就会失效。因此同一机器的两个浏览器窗体訪问server时，会生成两个不同的Session。可是由浏览器窗体内的链接、脚本等打开的新窗体（也就是说不是双击桌面浏览器图标等打开的窗体）除外。这类子窗体会共享父窗体的Cookie，因此会共享一个Session。
注意：新开的浏览器窗体会生成新的Session，但子窗体除外。
子窗体会共用父窗体的Session。
比如，在链接上右击，在弹出的快捷菜单中选择"在新窗体中打开"时，子窗体便能够訪问父窗体的Session。
假设client浏览器将Cookie功能禁用，或者不支持Cookie怎么办？比如。绝大多数的手机浏览器都不支持Cookie。JavaWeb提供了还有一种解决方式：URL地址重写。
URL地址重写是对client不支持Cookie的解决方式。
URL地址重写的原理是将该用户Session的id信息重写到URL地址中。
server可以解析重写后的URL获取Session的id。这样即使client不支持Cookie，也可以使用Session来记录用户状态。
HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写。该方法会自己主动推断client是否支持Cookie。
假设client支持Cookie。会将URL原封不动地输出来。假设client不支持Cookie，则会将用户Session的id重写到URL中。
注意：TOMCAT推断client浏览器是否支持Cookie的根据是请求中是否含有Cookie。
虽然client可能会支持Cookie。可是由于第一次请求时不会携带不论什么Cookie（由于并无不论什么Cookie能够携带），URL地址重写后的地址中仍然会带有jsessionid。当第二次訪问时server已经在浏览器中写入Cookie了。因此URL地址重写后的地址中就不会带有jsessionid了。
来自网络上的总结 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仅仅能在一个应用中共享，即一个cookie仅仅能由创建它的应用获得。
1.可在同一应用server内共享方法：设置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）此处的參数，是相对于应用server存放应用的目录的根目录而言的(比方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在client设置的cookie，而B机器訪问本机的应用。输入：http://localhost:8080/webapp_b则不能够获得cookie。
4）设置了cookie.setDomain(".jszx.com");，还能够在默认的home.langchao.com以下共享。
cookie于session的差别和联系：
详细来说cookie机制採用的是在client保持状态的方案。而session机制採用的是在server端保持状态的方案。同一时候我们也看到，因为採用server端保持状态的方案在client也须要保存一个标识，所以session机制可能须要借助于cookie机制来达到保存标识的目的，但实际上它还有其它选择。
cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，server通过在HTTP的响应头中加上一行特殊的指示以提示浏览器依照指示生成对应的cookie。
然而纯粹的client脚本如JavaScript或者VBScript也能够生成cookie。而cookie的使用是由浏览器依照一定的原则在后台自己主动发送给server的。浏览器检查全部存储的cookie，假设某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给server。
cookie的内容主要包含：名字，值。过期时间。路径和域。
路径与域一起构成cookie的作用范围。
若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗体，cookie就消失。这样的生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这样的行为并非规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上。关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie能够在不同的浏览器进程间共享，比方两个IE窗体。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式
session机制。session机制是一种server端的机制，server使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
当程序须要为某个client的请求创建一个session时，server首先检查这个client的请求里是否已包括了一个session标识（称为session id）。假设已包括则说明曾经已经为此client创建过session，server就依照sessionid把这个session检索出来使用（检索不到，会新建一个）。假设client请求不包括session id，则为此client创建一个session而且生成一个与此session相关联的sessionid。session id的值应该是一个既不会反复。又不easy被找到规律以仿造的字符串，这个session id将被在本次响应中返回给client保存。
保存这个session id的方式能够採用cookie。这样在交互过程中浏览器能够自己主动的依照规则把这个标识发挥给server。一般这个cookie的名字都是类似于SESSIONID。但cookie能够被人为的禁止，则必须有其它机制以便在cookie被禁止时仍然能够把session id传递回server。
常常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。
另一种技术叫做表单隐藏字段。
就是server会自己主动改动表单，加入一个隐藏字段，以便在表单提交时可以把session id传递回server。
比方：
<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保存到client
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保存到client
response.addCookie(cook);
response.sendRedirect("index.jsp");
}
二、当禁用了cookie后我们的sessionid就不会自己主动保存到cookie中，也不可能保存到cookie中，所以我们在服务端要重写url
protected voiddoPost(HttpServletRequest request, HttpServletResponse response) throwsServletException, IOException {
// cookie 被警用之后我们能够使用url 重写来向server提交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);
}