简单的Session共享

   httpGet.setHeader("Content-Type", "application/json;charset=utf-8");

1. 为什么需要Cookie？

 

    HTTP是一种无状态的协议，客户端与服务器建立连接并传输数据，数据传输完成后，连接就会关闭。再次交互数据需要建立新的连接，因此，服务器无法从连接上跟踪会话，也无法知道用户上一次做了什么。这严重阻碍了基于Web应用程序的交互，也影响用户的交互体验。如：在网络有时候需要用户登录才进一步操作，用户输入用户名密码登录后，浏览了几个页面，由于HTTP的无状态性，服务器并不知道用户有没有登录。

    Cookie是解决HTTP无状态性的有效手段，服务器可以设置或读取Cookie中所包含的信息。当用户登录后，服务器会发送包含登录凭据的Cookie到用户浏览器客户端，而浏览器对该Cookie进行某种形式的存储（内存或硬盘）。用户再次访问该网站时，浏览器会发送该Cookie（Cookie未到期时）到服务器，服务器对该凭据进行验证，合法时使用户不必输入用户名和密码就可以直接登录。

    本质上讲，Cookie是一段文本信息。客户端请求服务器时，如果服务器需要记录用户状态，就在响应用户请求时发送一段Cookie信息。客户端浏览器保存该Cookie信息，当用户再次访问该网站时，浏览器会把Cookie做为请求信息的一部分提交给服务器。服务器检查Cookie内容，以此来判断用户状态，服务器还会对Cookie信息进行维护，必要时会对Cookie内容进行修改。

 

 

 

2. Cookie的类型

 

    Cookie总时由用户客户端进行保存的（一般是浏览器），按其存储位置可分为：内存式Cookie和硬盘式Cookie。

    内存式Cookie存储在内存中，浏览器关闭后就会消失，由于其存储时间较短，因此也被称为非持久Cookie或会话Cookie。

    硬盘式Cookie保存在硬盘中，其不会随浏览器的关闭而消失，除非用户手工清理或到了过期时间。由于硬盘式Cookie存储时间是长期的，因此也被称为持久Cookie。

 

 

3. Cookie的实现原理

 

    Cookie定义了一些HTTP请求头和HTTP响应头，通过这些HTTP头信息使服务器可以与客户进行状态交互。

    客户端请求服务器后，如果服务器需要记录用户状态，服务器会在响应信息中包含一个Set-Cookie的响应头，客户端会根据这个响应头存储Cookie信息。再次请求服务器时，客户端会在请求信息中包含一个Cookie请求头，而服务器会根据这个请求头进行用户身份、状态等较验。

 

 

下面是一个实现Cookie机制的，简单的HTTP请求过程：

 

1. 客户端请求服务器

    客户端请求IT笔录网站首页，请求头如下：

    GET / HTTP/1.0

    HOST: itbilu.com

2. 服务器响应请求

    Cookie是一种key=value形式的字符串，服务器需要记录这个客户端请求的状态，因此在响应头中包一个Set-Cookie字段。响应头如下：

    HTTP/1.0 200 OK

    Set-Cookie: UserID=itbilu; Max-Age=3600; Version=1

    Content-type: text/html

    ……

3. 再次请求时，客户端请求中会包含一个Cookie请求头

客户端会对服务器响应的Set-Cookie头信息进行存储。再次请求时，将会在请求头中包含服务器响应的Cookie信息。请求头如下

    GET / HTTP/1.0

    HOST: itbilu.com

    Cookie: UserID=itbilu

cookie 

Cookie实际上考虑的是为了记录用户在一段时间内访问web应用服务的行为路径

弊端：Cookie大小和个数有限制 Cookie安全型比较低，容易被攻击

Session

Session是另一种记录客户状态的机制，客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了

不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。

 

session的三种工作方式。   

 1.基于URL Path Parameter，默认支持    

 2.基于Cookie，默认没有修改Context容器的Cookies标识，默认也是支持的。( 如果客户端支持cookies，tomcat也会解析Cookie中的JSESSIONID，并覆盖URL中JSESSIONID)

 

1）new Request

2）解析path,parameters 拿到Session ID 设置到Request对象中

3）如果支持Cookie，从Cookie中拿到Session ID并覆盖之前的

4）getSession  

5）findSession 根据Session ID在session集合中查找已经存在的Session对象

6） new 不存在将创建一个新的对象

7）add to sessions 集合中

8）返回Standard Session对象  根据这个Session ID新增一个Cookie，并将这个Cookie设置到Http协议头中

9）session.getSession 返回StandardSessionFacade对象

10）Servlet中可以在HttpSession对象中操作，包括修改删除等，Session的生命周期由Manager来空值，客户端无需关注

 

HttpServletRequest定义了获取session的方法，该方法有两种重载形式：  

   request.getSession(Boolean  boo)；  

               request.getSession(true)：若存在会话则返回该会话，否则新建一个会话。    

                 request.getSession(false)：若存在会话则返回该会话，否则返回NULL   

                  request.getSession()默认为true方式

 Session声明周期     

 创建：第一次执行request.getSession（）时创建    

  销毁： 1）服务器（非正常）关闭时 2）session过期/失效（默认30分钟，从不操作服务器端的资源开始计时） 3）手动销毁session：session.invalidate（）

 

问题：单服务器web应用中，session信息只需存在该服务器中。但随着分布式系统的流行，单系统已经不能满足用户的需求，集群方式部署服务器已在很多公司运用起来，当高并发量的请求到达服务端的时候通过负载均衡的方式分发到集群中的某个服务器，这样就有可能导致同一个用户的多次请求被分发到集群的不同服务器上，就会出现取不到session数据的情况，于是session的共享就成了一个问题。

 

假设用户包含登录信息的session都记录在第一台web-server上，反向代理如果将请求路由到另一台web-server上，可能就找不到相关信息，而导致用户需要重新登录。

 

1.session复制（同步）多个web-server之间相互同步session，这样每个web-server之间都包含全部的session 优点：web-server支持的功能，应用程序不需要修改代码 缺点： session的同步需要数据传输，占内网带宽，有时延 所有web-server都包含所有session数据，数据量受内存限制，无法水平扩展,有更多web-server时要歇菜

 

 

2.客户端存储法 服务端存储所有用户的session，内存占用较大，可以将session存储到浏览器cookie中，每个端只要存储一个用户的数据了 优点：服务端不需要存储 缺点： 每次http请求都携带session，占外网带宽； 数据存储在端上，并在网络传输，存在泄漏、篡改、窃取等安全隐患 session存储的数据大小受cookie限制，“端存储”的方案虽然不常用，但确实是一种思路。

 

 

 

3.反向代理hash一致性        让同一个用户的请求落在一台web-server上（ip-hash） 优点： 只需要改nginx配置，不需要修改应用代码 负载均衡，只要hash属性是均匀的，多台web-server的负载是均衡的 可以支持web-server水平扩展（session同步法是不行的，受内存限制） 不足： 如果web-server重启，一部分session会丢失，产生业务影响，例如部分用户重新登录 如果web-server水平扩展，rehash后session重新分布，也会有一部分用户路由不到正确的session

 

 

4.后端统一集中存储        存储到数据库或者存储到缓存 优点： 没有安全隐患 可以水平扩展，数据库/缓存水平切分即可 web-server重启或者扩容都不会有session丢失 不足： 增加了一次网络调用，并且需要修改应用代码