Session和cookie超级详细介绍

Session介绍:

//言外之意是：我们可以使用 Cookie 保存东西，但是 如果要保存一个 很大的对象呢？ 那么cookie就很有限。

//指明了： 针对 Cookie我们可以 将他保存在 客户端， 也就是本地 浏览器 所在的 电脑上的 当前浏览器指定的 保存路径中。
//而 Session ， 是 保存在 服务器端的， 具体保存在服务器的 内存中 。 因此 一旦意外断电 内存就被 清理掉。此时的session对象 就会消失。
下面是在反复测试中发现 浏览器 和 tomcat服务器 存在的 特性：
01：谷歌 360 极速 等等浏览器 会保存 我们持久化的 cookie对象。 且这些对象 被浏览器 保存在 各自浏览器 指定的 文件系统中， 各自的浏览器 使用 各自的 ， 彼此之间 不共用。
02：火狐 开发版 浏览器， 即便是 我们 在程序中设置了 持久化的 cookie，依然无济于事，我们在代码中 设置了 持久化的 cookie，意味着 我们向把这个 cookie通过 火狐浏览器 保存在 他指定的 文件系统中，但是 我们发现 一旦浏览器 关闭之后 这个被保存的 cookie就立马被删除了， 导致 关闭之后 再打开 他并不会携带 之前 我们保存的 cookie.
03:针对 突然断电的情况 ， 我们无法处理， 但是 针对 每次tmcat引擎 关闭 或者重启， 此时针对里面的 session,此时tomcat会在关闭 后者重启之前 持久化，关于持久化的 东西 后面讲到。

针对 cookie 和 session的 特性， 我们 依次可以 配合 使用 Session 和 cookie。将session的信息【JSESSION】 通过cookie持久化到 本地文件系统中， 每次访问的时候 ，浏览器 自动携带上 。

//此处 我们要明确一点 ， 平时 我们使用jsp的时候， jsp页面 会默认给我们 创建一个 Session的：
01： jsp会默认给我们 创建 一个 session .
02: 我们 可以 通过显示 的 写法 避免 这个情况：<%@ page session=“false”%> 当为false的时候 表示 当前访问的jsp并不会 给我们 自动创建一个 session.
03:jsp 给我们 默认给我们创建的 session情况的 逻辑：
A:假定 此时 我们的浏览器 没有携带 任何关于当前的 网站站点 的 任何 cookie信息， 此时 访问 当前web站点的 一个 首页 或者 其他页面的时候， 我们并么有在 当前的 jsp页面中 写 <%@ page session=“false”%> ,那么此时 的jsp页面会自动帮我们创建一个 session, 此时 这个session对象 会被 tomcat引擎返回的 response对象所携带 ， 保存在 response对象中 ， 当被 浏览器 接到的 时候 形式如下:

在响应头中 : Set-Cookie JSESSIONID=68FEF9843C41D113A84…DD095DB9676; Path=/; HttpOnly

B:当我们第二次 再次 访问这个 页面 或者首页的时候（并没有关闭 浏览器） 此时的情况：

此时 的情况 ， 响应消息中 不在 携带 Set-Cookie响应头了， 请求头中携带 Cookie消息头。

C: 此时要注意 创建的 这个session对象 ， 他的名字 固定为JSESSION, 值是 sessionid标识号， 当第一次请求被响应的时候，被浏览器解析， 此时 响应头中会自动带上 Set-Cookie头字段 ， 而请求头 没有cookie字段，因为第一次请求的时候 没有带上 。

D:当第二次 刷新 或者 再次访问 同一个页面 或者 访问其他 资源的时候， 浏览器 会将上次 响应头中的 Set-Cookie转化为 本次 访问的 请求头中的Cookie头字段。这是浏览器 做的操作 ，不是程序员做的。

这里 有必要说一下 服务器 和 浏览器 对Session 和 Cookie的处理情况。
01：当我们在 访问 一个 设置有：<%@ page session=“false”%> 的jsp页面的时候， 服务器 执行完servlet代码 做出响应， 此时浏览器 拿到 响应实体，显示到 浏览器页面上。
页面上 在request 请求头中 没有任何关于 Cookie 的任何 信息 ， 在response响应头中 也没有任何 Set-Cookie的任何消息。因为 当前我们 访问这个页面的 时候 ， 没有 携带 cookie信息所以 在请求中 就不会携带。因为这个jsp没有产生 session 所以 在response 中 也不会携带 任何 Set-Cookie的任何 信息。

02：当我们 访问了 要给 servlet程序的时候， 这个程序中 仅写了 :HttpSession session = request.getSession(true); 的时候 ， 这个方法的执行逻辑是 ， 以及此时的执行逻辑：
1： 这个方法 首先 通过 检查 请求头中 是否携带 Cookie头字段， 以及请求头中的Cookie请求头字段 中的 JSESSION中是否有session的标识号 ， 以及携带的Session标识号 是否有效。

2：如果 没有Cookie头字段 ， 或者 Cookie请求头字段 中 没有 JSSESSION 的名值对的任何 东西，或者 JSESSION 是一个空字符串 ， 那么 这个方法， 就会 立马 在内存中 创造一个session对象。且将这个 session对象 的 标识号 和 JSESSION（固定写法） 名字联系到一块 构成 名值对 ， 传递给 响应对象 ， 让响应对象 携带上 这个 东西 ， 作 为 Set-Cookie 的 值。 ---->这个过程很重要。
当 servlet程序执行完毕之后， 此时 浏览器 执行的动作 仅仅是解析， 解析出 请求头中 没有Cookie头字段， 而响应头中 有一个 Set-Cookie头字段 ， 反馈给 用户。
再次 访问这个 servlet程序的时候 ， 请求头 会自动 携带上 上次 响应头中设置 的Set-Cookie头字段 中设置的JSESSION信息 ，将他们转化为 请求头中 Cookie头字段。 此时 响应信息 具体看 servlet程序的 代码如何写的。

3：如果 请求头中 有 cookie头字段 ， 且 具备 JSESSION 名值对， 此时 这个方法 会 首先拿到这个JSESSION的值， 通过这个值（session的标识号），在内存中 找 找 是否 内存中 有这个 标识号 对应的session对象。
如果没有 找到的话 就创建一个 session 对象， 且再次 重复 2 的过程， 且将 新产生的 JSESSION 以及新的标识号 作为 响应头的 Set-Cookie返回。
当 再次 访问这个 servlet程序的时候 ， 请求头 会自动 携带上 上次 响应头中设置 的Set-Cookie头字段 中设置的JSESSION信息 ，将他们转化为 请求头中 Cookie头字段。 此时 响应信息 具体看 servlet程序的 代码如何写的。，

4:如果 请求头中 有 cookie头字段 ， 且 具备 JSESSION 名值对， 此时 这个方法 会 首先拿到这个JSESSION的值， 通过这个值（session的标识号），在内存中 找 找 是否 内存中 有这个 标识号 对应的session对象。
如果 有 的话 就 拿到 现已经存在的 Session对象， 此时 这个方法并不会 再次创建一个SEssion对象。
且 不会 在响应头 中 设置 Set-Cookie 相应头字段。

—>：我们仅仅在 servlet代码中 写一个 request.getSession(true)方法的时候 就是上边的执行逻辑：
01：当tomcat服务器 在内存中 创建一个 Session对象的时候 ， 也给这个 对象 了 一个唯一标识符。
02：我们仅仅调用 这个 了 这个方法， 并没有 通过 response.addCookie()方法 而添加 这个session对象 对应的 JSESSION = session唯一标识符 的形式 添加到 响应头中 ， 此处是 tomcat 根据这个方法的时候的使用情况。 自动 帮我们添加的 ，而不需要 我们 显示 调用 response.addCookie()方法。 很重要。---->:前提是 我们 怎么判断 ， 最终 需要 创建session对象的时候 会这么做。
03：当 执行 servlet程序的时候， 这个方法 是通过 请求头中 是否携带 JSESSION 名值对 的Cookie 的 值（名值对）来查找 当前内存中 是否有 对应的 session对象的， 具体查找的 思路， 这个是 tomcat 封装好的，我也不知道 人家是 怎么写的。
04： 每次执行完 servlet程序之后 ， 返回给 浏览器， 此时 如果 浏览器 要访问当前项目中 的 其他servlet或者 其他jsp页面的时候， 会自动将 上次的 response对象 中的响应头 的Set-Cookie ， 添加到 当前的 请求头字段的Cookie 中。 这个是 浏览器 帮我们干的工作， 并不是 程序员 做的。

服务器 会在 服务器内存中 产生一个 session对象，且给这个 session对象 一个 唯一的 标识号
另外服务器 会 将这个 session对象 的 标识号 和 JSESSION（固定写法） 名字联系到一块 构成 名值对 ， 传递给 响应对象，让响应对象 携带上 这个 东西， 作为 Set-Cookie 的 值。 ---->这个过程很重要。
此时 并没有 给 请求对象 设置什么内容。
当 servlet的 方法执行完了之后 就要返回 ， 此时 浏览器 拿到了 请求对象 和 响应对象 ，开始 在 浏览器 中解析。
解析 将 请求头 和 响应头中的 东西 解析出来 ， 我们程序员就可以看到了。

03：我们并没有 关闭浏览器 ， 再次 刷新浏览器 来 访问这个servlet程序的时候 ， 请求头 会自动 将上一次 响应头中 的 Set-Cookie 中的 名值对 ， 转移到 当前的 请求头字段 的 Cookie中， 这个不是 程序员做的 ， 而是 浏览器 做的 ， 我知道这个规律 ， 如何实现 我并不知道。

//浏览器 开始解析 我们在 程序中 给 response设置的 所有的cookie信息， 不管是否有效，是否重复，全部显示
然后 根据这些 Set-Cookie头字段， 将他们放置到 假象的 cookie文件夹中，此时会处理 重复 无效的Cookie文本

//当第二次 浏览器 访问的时候 ，会携带上 符合 当前域名 访问路径的 所有的cookie文本，且将他们作为 请求的 头字段。

//由此 我们可以知道一个规律， 当 浏览器 无论是 第一次 还是 第二次 第三次 … 访问一个 web域 中的 一个 处理程序的时候， 首先浏览器要做的是： 搜索 浏览器 指定的 cookie文件夹，选择出 有效的 cookie文本 作为 当前 请求的请求头 来访问。

//我们没有持久化的 cookie在浏览器 关闭的时候 ， 并没有持久化到 本地 计算机硬盘中， 会立马销毁掉 ， 那些没有持久化的 cookie只是 存在于 浏览器 的内存中，浏览器一旦关闭 就会消失掉。

//当 我们 在已经打开 的 浏览器中 点击加号 或者 再次点击 桌面按钮 或者是 按CTR + N 打开一个页面，此时要注意 他们 都是 首次打开页面的子页面， 共享 session 和 cookie的。

//服务器 可以根据 请求头中 携带的JSESSION 名值对的值 ， 来查找 服务器内存中 是否有 这个session对象，具体查找方式 我们不得而知。 但是 我们却可以利用这个特性 配合使用 session 和 cookie.

//此时要注意 请求头中的 JSESSION的值 ， 因为服务器是 通过 JSESSION的值 来找到 session对象的
//session的setAttribute() / getAttribute()
//同一个 客户端请求（跟人没有关系）， 来访问 的 时候通过 在请求中 携带JSESSION 我们 就可以拿到 服务器端的 session对象。
//我们可以 使用 setAttribute getAttribute 来给 这个session对象 中 封装的 那个session域对象（请允许我这个称呼） ， 添加 名值对 。 此时 我们可以认为 这个session域对象 是一个HashMap数据结构。
// 这里我们 一共知道 上下文域 请求域 session域 ， 可是 没有响应域


//纠正一下 错误的 认知

// 这种情况是在 内存中的 session时间到了 被清理掉了 ， 或者 我们 的请求头中 没有 cookie头字段 ， 所以 需要 在内存中 重建一个session对象。

//我们 可以在 tomcat/conf/Web.xml中 配置 所有的tomcat引擎中 保存的 项目的 session有效时间。 此处的有效时间是 以分钟为单位

30


//我们也可以 在自己的 项目的 web.xml中设置 一个 针对当前的 session的 超时时间。
//设置为 0 或者是 负数 的时候 ，表示永远不会超时。
//session对象的 getId()

//session 的 getCreationTime()方法 ， 返回的是 当前 创建的 session的时间 ， 而不是 每次没访问的 时间。

//session对象的 getLashAccessedTime方法 ， 返回的 是 这个session上一次 被访问的时间。
// 啥叫作 访问呢：
01：我们通过 a标签 访问另一个 jsp或者 servlet的时候 ， 叫做访问。
02：通过 form表单 的时候叫做 访问。
03： 当我们 打开一个页面的时候 ， 并没有做什么 ， 此时 就表示 没被访问。
//session的 setMaxInactiveInterval() 方法， 可以 使用 这个方法 来给 session设置 时间间隔， 而不是依靠 web.xml中的设置。

//session的 getMaxInactiveInterval()方法

//isNew()方法 ： 返回的是 是否 这个session是新创建的 如果是 则返回true , 否则返回false。

//session的 invalidate()方法 ， 可以 显示的调用这个方法 ， 强制让这个 session销毁带。

//真实 有意思 我们也可以 通过 session的 getServletContext()方法 返回 上下文对象。

//首先要知道 session域的 概念， 这个session域 针对的是 session对象 中 封装的 对象 的形式。

//setAttribute()方法 可以 添加 名值对 ， 可以 修改名值对， 将 名值对的值 设置为null的时候 可以删除 名值对。

//session的 getAttribute()方法 ，我们拿到session域中的 名值对的值 ， 如果 不存在的话 就返回null.

//session的 removeAttribute()方法 。 作用跟 setAttribute() 将值 设置为null 是一样的。

//session的 getAttributeNames()方法， 可以返回 对应的 session中的 所有名值对的 名字。

---

至此 总结一下：
Request ServletContext session 对应的 域中 都具备 四种方法：
getAttribute setAttribute removeAttribute getAttributeNames

---