摘抄并整理后查web
cookie 和 session 通常用来跟踪浏览器的用户身份ajax
Session的存储方式数据库
1. 使用cookie:保存 session id 的方式能够采用 cookie,这样在交互过程当中浏览器能够自动的把 JSESSIONID 发给服务器。浏览器
若是客户端请求的 cookie 中不包含 JSESSIONID,服务端调用request.getSession() 时就会生成并传递给客户端,这次响应头会包含设置 cookie 的信息,若是客户端请求的 cookie 中包含 JSESSIONID,服务端调用 request.getSession() 时就会根据 JSESSIONID 进行查找对象,若是能查找到返回,不然就跟没传递 JSESSIONID 同样,从新生成。不管是直接浏览 url 仍是 ajax 请求都会在客户端 cookie 生成 JSESSIONID。缓存
2. URL重写:因为 cookie 能够被认为的禁用,必须有其余的机制以便在 cookie 被禁用时仍然可以把 session id 传回给服务器,常常采用的一种技术叫作 URL 重写,就是把 session id 附加在 URL路径的后面,附加的方式也有两种,一种是做为 URL 路径的附加信息,另外一种是做为查询字符串附加在 URL后面。网络在整个交互过程当中始终保持状态,就必须在每一个客户端可能请求的路径后面都包含这个 session id。安全
jsessionid 跟通常的 url 参数传递的方式是不一样的,不是做为参数跟在 “?” 后面,而是紧跟在 url 后面用 “;” 来分隔。这样在用户禁用cookie的时候咱们也能够传递 jsessionid 来使用 session 了,只不过须要每次都把 jsessionid 做为参数跟在 url 后面传递。这样很麻烦,sun给咱们提供了 2 个方法来使事情变得很简单:response.encodeURL() 和 response.encodeRedirectURL()。这 2 个方法会判断 cookie 是否可用,若是禁用了会解析出 url 中的 jsessionid,并链接到指定的 url 后面,若是没有找到 jsessionid ,会自动帮咱们生成一个。服务器
这两个方法的区别,是在判断是否要包含 jsessionid 的逻辑上稍有不一样。在调用 response.sendRedirect() 前,应该先调用 encodeRedirectURL() 方法,不然可能会丢失 session 信息。这两个方法的使用方法如:response.sendRedirect(response.encodeURL("/xx/xx.jsp"));。若是 cookie 没有禁用,咱们在浏览器地址栏上看到的地址是 /xx/xx.jsp,若是禁用了 cookie,咱们会看到 /xx/xx.jsp;jsessionid=L7bZL7bZL7bZL7bZL7bZ。因此,为慎重,应该在程序里的每个跳转 url 上都使用这2个方法,来保证 session 的可用性。cookie
Session的建立和删除网络
Session的建立session
1)对于Jsp,若当前页面为浏览器访问 web 应用的第一个资源页面且 jsp 的 Page指定的 Session 属性的值为 true
2)对于 Servlet,若当前 Servlet 为浏览器访问 web 应用的第一个资源时,使用 request.getSession() 或者 request.getSession(true) 建立
Session的删除
1)调用 session.invalidate() 方法
2)卸载 web 应用
3)超过了 HttpSession 的过时时间
Session 的超时管理
WEB服务器没法判断当前的客户端浏览器是否还会继续访问,也没法检测客户端浏览器是否关闭,因此,即便客户已经离开或关闭了浏览器,WEB服务器还要保留与以前对应的 HttpSession 对象。
随着时间的推移而不断增长新的访问客户端,WEB服务器内存中将会所以积累大量的再也不被使用的 HttpSession 对象,并将最终致使服务器内存耗尽。
WEB服务器采用 “超时限制”的办法来判断客户端是否还在继续访问,若是某个客户端在必定的时间内没有发出后续请求,WEB服务器则认为客户端已经中止了活动,结束与该客户端的会话并将与之对应的 HttpSession 对象变成垃圾。
若是客户端浏览器超时后再次发出访问请求,WEB服务器则认为这是一个新的会话的开始,将为之建立新的 HttpSession 对象和分配新的会话标识号。
会话超时间隔能够在 web.xml (Tomcat服务器或者 web应用程序)文件中设置,其默认值由 Servlet 容器定义。
<session-config>
<session-timeout>30</session-timeout>
</session-config>
Session 缺点
Cookie概述
Cookie 译为小型文本文件或者小甜饼,web 应用程序利用 Cookie 在客户端缓存服务器端文件。Cookie 是以键值对形式存储在客户端主机硬盘中,由服务器端发送给客户端,客户端在下一次访问服务器端时,服务器端能够获取到客户端 cookie 缓存文件。
cookie 能够由服务器端建立的,而后由服务器端发送给客户端,客户端以键值对形式存储 cookie。客户端再次访问服务端时,存储的 cookie 会保存在请求协议中,服务端能够获取上次存储的缓存文件内容。
Cookie能够经过浏览器和服务器端生成, 存储在 http 请求头里面。
Cookie 的缺点
sessionStorage 和 localStorage
HTML5中与本地存储相关的两个重要内容:web storage 与本地数据库。其中,web storage 存储机制是对 HTML4 中 cookie 存储机制的一个改善。因为 cookie 存储机制有不少缺点,HTML5再也不使用它,转而使用改良后的 web storage 存储机制。本地数据库是 HTML5 新增的一个功能,使用它能够在客户端本地创建一个数据库,本来必须保存在服务端数据库中的内容如今能够直接保存在客户端本地,这大大减轻了服务器端的负担,同时也加快了访问数据的速度。
咱们知道,在HTML4 中可使用 cookie 在客户端保存像用户名等简单的用户信息,可是经过长期的使用,你会发现,用cookie存储永久数据存在一些问题:
大小(cookie大小在4KB),带宽(cookie是随HTTP事务一块儿被发送的,所以会浪费一部分带宽),复杂性(要正确操纵cookie很困难)
针对这些问题,在 HTML5 中,从新提供了一种在客户端本地保存数据的功能 Web Storage
具体说,Web Storage 又分为两种:
1. sessionStorage:将数据保存在 session 对象中。
2. localStorage:将数据保存在客户端本地的硬件设备中,即便浏览器被关闭了,该数据仍然存在,下次打开浏览器访问网站时仍然能够继续使用。
这二者的区别在于,sessionStorage 为临时保存,而 localStorage 为永久保存。
WebStorage 的目的是克服由 cookie 带来的一些限制,当数据须要被严格控制在客户端时,不须要持续的将数据发回服务器。
WebStorage 两个主要目标:1)提供一种在 cookie 以外存储会话数据的路径 2)提供一种存储大量能够跨会话存在的数据的机制
HTML5 的 WebStorage 提供了两种 API:localStorage 和 sessionStorage
1. 生命周期:localStorage 的生命周期是永久的,关闭页面或浏览器后数据也不会消息,除非主动删除数据。sessionStorage 的生命周期是仅在当前会话下有效。sessionStorage 引入一个浏览器窗口概念,sessionStorage 是在同源的窗口中始终存在的数据。只要这个浏览器窗口没有关闭,即便刷新页面或者进入同源的另个页面,数据依然存在。可是 sessionStorage 在关闭了浏览器窗口后就会被销毁。同时独立的打开同一个窗口同一页面,sessionStorage 在是不同的(由于,不一样源了)。
2. 存储大小:localStorage 和 sessionStorage 的存储数据大小通常都是 5MB
3. 存储位置:localStorage 和 sessionStorage 都保存在客户端,不与服务器进行互相通讯
4. 存储内容类型:localStorage 和 sessionStorage 只能存储字符串类型,对于复杂的对象可使用 ECMAScript 提供的 JSON 对象来处理
5. 获取方式:window.localStorage 和 window.sessionStorage
6. 应用场景:localStorage 经常使用于长期登陆(+判断用户是否已登陆),适合长期保存在本地的数据。 方法:
setItem(key, value) —— 保存数据,以键值对的方式存储信息
getItem(key) —— 获取数据,将键值传入,便可获取到对应的 value 值
removeItem(key) —— 删除单个数据
clear() —— 删除全部数据
key(index) —— 获取某个索引的 key