关于Session

Session

Session:在计算机中，尤其是在网络应用中，称为"会话控制"。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web 页时，如果该用户还没有会话，则 Web 服务器将自动创建一个 Session 对象。当会话过期或被放弃后，服务器将终止该会话。Session 对象最常见的一个用法就是存储用户的首选项。例如，如果用户指明不喜欢查看图形，就可以将该信息存储在 Session 对象中。有关使用 Session 对象的详细信息，请参阅"ASP 应用程序"部分的"管理会话"。注意 会话状态仅在支持 cookie 的浏览器中保留。

为什么需要Session

首先，我大致的知道，session是一次浏览器和服务器的交互的会话，会话是啥呢？就是我问候你好吗？你回恩很好。就是一次会话，那么对话完成后，这次会话就结束了，还有我也知道，我们可以将一个变量存入全部的$_SESSION[‘name’]中，这样php的各个页面和逻辑都能访问到，所以很轻松的用来判断是否登陆。

在说session是啥之前，我们先来说说为什么会出现session会话，它出现的机理是什么？我们知道，我们用浏览器打开一个网页，用到的是HTTP协议，学过计算机的应该都知道这个协议，它是无状态的，什么是无状态呢？就是说这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。但是这种无状态的的好处是快速。

所以就会带来一个问题就是，我希望几个请求的页面要有关联，比如：我在www.a.com/login.php里面登陆了，我在www.a.com/index.php 也希望是登陆状态，但是，这是2个不同的页面，也就是2个不同的HTTP请求，这2个HTTP请求是无状态的，也就是无关联的，所以无法单纯的在index.php中读取到它在login.php中已经登陆了！

那咋搞呢？我不可能这2个页面我都去登陆一遍吧。或者用笨方法这2个页面都去查询数据库，如果有登陆状态，就判断是登陆的了。这种查询数据库的方案虽然可行，但是每次都要去查询数据库不是个事，会造成数据库的压力。

所以正是这种诉求，这个时候，一个新的客户端存储数据方式出现了：cookie。cookie是把少量的信息存储在用户自己的电脑上，它在一个域名下是一个全局的，只要设置它的存储路径在域名www.a.com下 ，那么当用户用浏览器访问时，php就可以从这个域名的任意页面读取cookie中的信息。所以就很好的解决了我在www.a.com/login.php页面登陆了，我也可以在www.a.com/index.php获取到这个登陆信息了。同时又不用反复去查询数据库。

虽然这种方案很不错，也很快速方便，但是由于cookie 是存在用户端，而且它本身存储的尺寸大小也有限，最关键是用户可以是可见的，并可以随意的修改，很不安全。那如何又要安全，又可以方便的全局读取信息呢？于是，这个时候，一种新的存储会话机制：session 诞生了。

使用方法

Session 是 用于保持状态的基于 Web服务器的方法。Session 允许通过将对象存储在 Web服务器的内存中在整个用户会话过程中保持任何对象。

Session 通常用于执行以下操作

存储需要在整个用户会话过程中保持其状态的信息，例如登录信息或用户浏览 Web应用程序时需要的其它信息。

存储只需要在页面重新加载过程中或按功能分组的一组页之间保持其状态的对象。

Session 的作用就是它在 Web服务器上保持用户的状态信息供在任何时间从任何设备上的页面进行访问。因为浏览器不需要存储任何这种信息，所以可以使用任何浏览器，即使是像 Pad 或手机这样的浏览器设备。

持久性方法的限制

随着越来越多用户登录，Session 所需要的服务器内存量也会不断增加。

访问 Web应用程序的每个用户都生成一个单独的 Session 对象。每个 Session 对象的持续时间是用户访问的时间加上不活动的时间。

如果每个 Session 中保持许多对象，并且许多用户同时使用 Web应用程序(创建许多 Session)，则用于 Session 持久性的服务器内存量可能会很大，从而影响了可伸缩性。

理解Session机制

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

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

保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SEEESIONID，而。比如weblogic对于web应用程序生成的cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是JSESSIONID。

由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://…/xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一种是作为查询字符串附加在URL后面，表现形式为http://…/xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。
为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单：

<form name="testform" action="/xxx"> 
    <input type="text"> 
    </form> 
在被传递给客户端之前将被改写成： 
<form name="testform" action="/xxx"> 
<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764"> 
<input type="text"> 
</form> 

这种技术现在已较少应用，笔者接触过的很古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。
实际上这种技术可以简单的用对action应用URL重写来代替。

在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实可以想象一下会员卡的例子，除非顾客主动对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保留，程序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用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来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保留，程序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。

在Jsp中使用

Jsp的session是使用bean的一个生存期限,一般为page,session意思是在这个用户没有离开网站之前一直有效，如果无法判断用户何时离开，一般依据系统设定，tomcat中设定为30分钟.
我们使用session功能，可以达到多个jsp程序从操作同一个java bean,那么这个java bean可以作为我们传统意义上的"全局变量池".(在java中我们可以使用static静态化一个变量和方法，使用singleton唯一化对象.)
在项目实践中，我们Jsp程序中很多参数需要从数据库中读取，有的参数实际读取一次就可以，如果设计成每个用户每产生一个页面都要读取数据库，很显然，数据库的负载很大，同时也浪费时间,虽然可能有数据库连接池优化，但是尽量少使用数据库是我们编程的原则.
JSP使用一个叫HttpSession的对象实现同样的功能。HTTPSession 是一个建立在cookies 和URL-rewriting上的高质量的界面。Session的信息保存在服务器端，Session的id保存在客户机的cookie中。事实上，在许多服务器上，如果浏览器支持的话它们就使用cookies，但是如果不支持或废除了的话就自动转化为URL-rewriting，session自动为每个流程提供了方便地存储信息的方法。
Httpsession具有如下API：
getId　此方法返回唯一的标识，这些标识为每个session而产生。当只有一个单一的值与一个session联合时，或当日志信息与先前的sessions有关时，它被当作键名用。
GetCreationTime　返回session被创建的时间。最小单位为千分之一秒。为得到一个对打印输出很有用的值，可将此值传给Date constructor 或者GregorianCalendar的方法setTimeInMillis.
GetLastAccessedTime　返回session最后被客户发送的时间。最小单位为千分之一秒。
GetMaxInactiveInterval　返回总时间（秒），负值表示session永远不会超时。
getAttribute　取一个session相联系的信息。（在jsp1.0中为 getValue）
Integer item = （Integer） session.getAttribute（“item”）　//检索出session的值并转化为整型
setAttribute　提供一个关键词和一个值。会替换掉任何以前的值。（在jsp1.0中为putValue）
session.setAttribute（“ItemValue”， itemName）；　// ItemValue 必须不是must简单类型
在应用中使用最多的是getAttribute和setAttribute.现以一个简单的例子来说明session的应用，test1.jsp（信息写入session），test2.jsp（从session读出信息）。
test1.jsp

<% session.setAttribute("str",new String(“this is test”)); %> test2.jsp <% String ls_str=null; ls_str=(String)session.getAttribute("str"); out.println(“从session里取出的值为：”+ls_str); %>

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

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

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

在同个浏览器

可见在同个浏览器下sessionID都是相同的。

在不同浏览器

不同的浏览器下，可以看到SessionID是不一样的。

Session的共享

Java中多个使用Nginx+Tomcat进行负载均衡时，希望使用轮询方式进行负载。但是如果使用轮询方式的话，可能会访问不同的Tomcat，此时如果不进行Session共享，则相当于是一个新的Session。就比如现有系统都是需要认证登录的系统，如果没有Session共享，则会导致用户退出登录。
方案1：使用Tomcat内置的Session复制方案
SimpleTcpCluster 优点：内置
缺点：只适合Tomcat小集群，不适合大集群，因为session复制是all to all的方式
方案2：使用第三方（个人）基于Tomcat实现的Session管理
tomcat-session-manager 优点：已经实现对tomcat7的支持
缺点：第三方支持，支持力度不够，尤其是不能提供对Tomcat8的支持
方案3：使用Spring Session实现
基于redis存储实现 优点：不依赖于特定容器，官方支持
缺点：暂未发现

Session的缺点总结

任何事情都有二面性，优缺点都是兼有的。在评价一个事物时，我们应该要全面地分析它的优缺点，否则评价也就失去了意义。 今天我们还是在批评Session的缺点前，先看看它的优点：只需要一行代码就可以方便的维持用户的会话数据。这其实是个伟大的实现！

但是，现在为什么还是有人会不使用它呢？比如我就不用它，除非做点小演示，否则我肯定不会使用它。为什么？

我个人认为这个伟大的实现，还是有些局限制性，或者说是一些缺点吧。现在我们再来看看Session的缺点：

1. 当mode="InProc"时，也就是默认设置时，容易丢失数据，为什么？因为网站会因为各种原因重启。
2. 当mode="InProc"时，Session保存的东西越多，就越占用服务器内存，对于用户在线人数较多的网站，服务器的内存压力会比较大。
3. 当mode="InProc"时，程序的扩展性会受到影响，原因很简单：服务器的内存不能在多台服务器间共享。
4. 虽然Session可以支持扩展性，也就是设置mode="SQLServer"或者mode=“StateServer”，但这种方式下，还是有缺点： 在每次请求时，也不管你用不用会话数据，都为你准备好，这其实是浪费资源的。
5. 如果你没有关闭Session，SessionStateModule就一直在工作中，尤其是全采用默认设置时，会对每个请求执行一系列的调用。浪费资源。
6. 并发问题，前面有解释，也有示例。
7. 当你使用无 Cookie 会话时，为了安全，Session默认会使用 重新生成已过期的会话标识符 的策略， 此时，如果通过使用 HTTP POST 方法发起已使用已过期会话 ID 发起的请求， 将丢失发送的所有数据。这是因为 ASP.NET 会执行重定向，以确保浏览器在 URL 中具有新的会话标识符。

不可否认的是，或许有些人认为这些缺点是可以接受的，他们更看中Session的简单、易使用的优点，那么，Session仍然是完美的。

Session优化

（1）redis或memcache等内存缓存数据库
（2）还有一种方式是通过加密的cookie来实现，用户在A服务器上登录成功，在用户的浏览器上种上一个加密的cookie，当用户访问B服务器时，检查有无 session，如果有当然没问题，如果没有，就去检验cookie是否有效，cookie有效的话就在B服务器上重建session。这种方法其实很有 用，如果网站有很多个子频道，服务器也不在一个机房，session没办法同步又想做统一登录那就太有用了。
（3）当然还有一种方法就是在负载均衡那一层保持会话，把访问者绑定在某个服务器上，他的所有访问都在那个服务器上就不需要session同步了（比如负载均衡中的ip_hash）。

资料参考：
1、https://www.cnblogs.com/lonelydreamer/p/6169469.html
2、https://baike.baidu.com/item/session/479100?fr=aladdin
3、https://blog.csdn.net/u012383839/article/details/79756368
4、https://www.cnblogs.com/fish-li/archive/2011/07/31/2123191.html
5、https://blog.csdn.net/m_nanle_xiaobudiu/article/details/81074446