【session的简单介绍】
【session的简单介绍】
文章目录
- 【session的简单介绍】
- 前言
- 一、什么是session？
- 基本机制
- 二、常用API
- 三、session的生命周期
- 四、session与cookie的对比
- 1. 概念
- 2.工作流程
- 3.安全性
- 4.管理难度
- 5.性能方面
- 总结
前言
`
书接上文cookie，本次的任务是简单的介绍与cookie有关的session。既然都了解了cookie，那为何不了解一下session呢？
（下次的任务即是与这两者也有关的token了，别问为什么这三个分开写，问就是投机取巧，水博客罢了=w=）
一、什么是session？
- . Session 就一个接口（HttpSession）。
- Session 就是会话。它是用来维护一个客户端和服务器之间关联的一种技术。
- 每个客户端都有自己的一个 Session 会话。
- Session 会话中，我们经常用来保存用户登录之后的信息。
基本机制
session机制采用的是在服务器端保持 HTTP 状态信息的方案。为了加速session的读取和存储，web服务器中会开辟一块内存用来保存服务器端所有的session，每个session都会有一个唯一标识sessionid，根据客户端传过来的jsessionid(cookie中)，找到对应的服务器端的session。为了防止服务器端的session过多导致内存溢出，web服务器默认会给每个session设置一个有效期—30分钟,若有效期内客户端没有访问过该session，服务器就认为该客户端已离线并删除该session。
二、常用API
- getId()方法：得到sessionid。
- invalidate()方法：让session立刻失效。
- getAttribute(String key)：根据key获取该session中的value。
- setAttribute(String key,Object value)：往session中存放key-value。
- removeAttribute(Stringkey)：根据key删除session中的key-value。
- getServletContext()：得到ServletContext。
- setMaxInactiveInterval(long timeout)/getMaxInactiveInterval：设置/获取session的最大有效时间。
- getCreationTime方法：获取session的创建的时间。
- getLastAccessedTime方法：获取session最后一次访问的时间。
- getSession()：从HttpServletRequest中获取session。
三、session的生命周期
-
public void setMaxInactiveInterval(long timeout)
设置 Session 的超时时间（以秒为单位），超过指定的时长，Session 就会被销毁。
值为正数的时候，设定 Session 的超时时长
负数表示永不超时（极少使用，因为如果不销毁就会一直占用内存空间） -
public int getMaxInactiveInterval()
获取 Session 的超时时间 -
public void invalidate()
让当前 Session 会话马上超时无效 -
Session 默认的超时时间长为 30 分钟。
因为在 Tomcat 服务器的配置文件 web.xml 中
默认有以下的配置，它就表示配置了当前 Tomcat 服务器下所有的 Session 超时配置
1. <session-config>
2. <session-timeout>30</session-timeout>
3. </session-config>
默认时长为：30 分钟。
可以通过修改30为其他值可修改web工程下所有session的默认超时时长。
如果想修改个别session的超时时长，可通过setMaxInactiveInterval(long timeout) 来进行单独的设置；
session.setMaxInactiveInterval(long timeout)单独设置超时时长。
四、session与cookie的对比
1. 概念
session和cookie都是用户登录状态数据
2.工作流程
cookie由服务器生成，通过响应头Set-Cookie传递给浏览器，cookie由浏览器保存，每次请求服务器时，浏览器都会通过请求头Cookie将对应的cookie传递给服务器，服务器基于请求头Cookie信息进行身份认证。
session由服务器生成，并且保存在服务器，服务器在生成session的同时会生成与之一一对应的sessionid，sessionid有两个作用，一是在服务器端作为查找session的索引，二是作为登录凭据通过响应头Set-Cookie传递给浏览器，并保存在浏览器端。浏览器每次请求服务器都会通过请求头Cookie将sesionid传递给服务器，服务器通过sessionid查询到服务器端保存的session，并基于session进行身份认证。
3.安全性
在身份认证实践中，session比cookie更加安全，因为session机制会将用户登录状态数据保存在服务器端，浏览器端只有一个无意义字串sessionid。而cookie机制将用户登录状态数据保存在浏览器端。黑客盗取浏览器保存的cookie，要比盗取服务器保存的session，容易的多。
同时，cookie机制中，服务器无法验证cookie有效期，cookie有效期完全由浏览器管理，同时浏览器具备多种入口篡改cookie有效期，这可能导致cookie有效期被故意篡改导致长期有效。
而session机制中，服务器端可以在生成session时，保持session的有效期和作为cookie的sessionid的有效期一致，并且以服务器端保存的session的有效期为准，这保障了即使cookie:sessionid在浏览器端被篡改的长期有效，但是服务器端session的有效期却无法被篡改。
4.管理难度
cookie保存在浏览器端，浏览器已经有了一套成熟的管理机制：
- 保存：自动将服务器HTTP响应头中Set-Cookie信息保存在浏览器内存或硬盘中
- 获取：自动将保存在浏览器内存或硬盘中的cookie取出作为HTTP请求头Cookie发生给服务器
- 清除：自动清除内存或硬盘中失效的cookie
而session保存在服务器端，服务器本身没有内置管理session的机制，需要第三方工具或者人为开发管理代码
5.性能方面
另外cookie是将每个用户的登录状态数据分散保存在用户个人电脑上，对于服务器来说内存友好，性能友好。
session是将每个用户的登录状态数据集中保存在服务器内存或服务器连接的数据库中，对于服务器来说内存不友好，性能也不友好。
总结
本文只是空洞地讲解了一堆概念，缺乏实例的支持，有实例会更好地便于我们的理解，这次准备过于仓促了，而且浏览器与session的关联及其表现形式我暂时没有找到很好的实例所以也没有提出（参考此处Session（超详细）文章末尾有详细谈到，最后的那张图也是非常的到位）。文章参考了许多，但是自己却很少动手实践去观察整个流程，我这懒狗真是该死啊! ! !；文章若有错误还望指出，各种实例及其补充将在后续的文章中补出。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！