【简记】Java Web 内幕——Cookie与Session深度解析

最新推荐文章于 2021-05-12 11:20:26 发布

qqqqq1993qqqqq

最新推荐文章于 2021-05-12 11:20:26 发布

阅读量353

点赞数

分类专栏： java web

java web 专栏收录该内容

27 篇文章 0 订阅

订阅专栏

本文内容：

Cookie与Session相关问题解析
进阶

两者在本地存储上的区别

Cookie存在硬盘中
Session存在浏览器内存中中，进程完全死亡后即消失

浏览器如何选择要发送哪些Cookie到服务器端？

浏览器在发送请求之前，首先会根据请求url中的域名在cookie列表中找所有与当前域名一样的cookie，然后再根据指定的路径进行匹配，如果当前请求在域匹配的基础上还与路径匹配，那么就会将所有匹配的cookie发送给服务器。

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是保存在浏览器内存中的，在浏览器关闭后自动释放，因此把session翻译成会话是很贴切的。此次会话结束后，session就不见了。

Cookie被禁止时怎么传Session

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

Session的作用周期

大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

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

如何做到在浏览器关闭时删除session（服务器端）

严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。

三大域对象比较

1.request
request是表示一个请求，只要发出一个请求就会创建一个request，它的作用域：仅在当前请求中有效。

用处：常用于服务器间同一请求不同页面之间的参数传递，常应用于表单的控件值传递。

2.session
服务器会为每个会话创建一个session对象，所以session中的数据可供当前会话中所有servlet共享。

会话：用户打开浏览器会话开始，直到关闭浏览器会话才会结束。一次会话期间只会创建一个session对象。

用处：常用于web开发中的登陆验证界面（当用户登录成功后浏览器分配其一个session键值对）。

3.Application（ServletContext）
作用范围：所有的用户都可以取得此信息，此信息在整个服务器上被保留。Application属性范围值，只要设置一次，则所有的网页窗口都可以取得数据。ServletContext在服务器启动时创建，在服务器关闭时销毁，一个JavaWeb应用只创建一个ServletContext对象。

tomcat中如何管理session

从Request中获取的Session对象保存在org.apache.catalina.Manager类中，它实现的类是org.apache.catalina.session.StandardManager，通过requestedSessionId从StandardManager的sessions集合中取出StandardSession对象。由于一个requestedSessionId对应一个访问的客户端，所以一个客户端也对应一个StandardSession对象。

HttpSession的源码在org.apache.catalina.session.StandardSession.java文件中，部分源码如下：

public class StandardSession implements HttpSession, Session, Serializable {
    // ----------------------------------------------------- Instance Variables
    /**
     * The collection of user data attributes associated with this Session.
     */
    protected Map<String, Object> attributes = new ConcurrentHashMap<>();

   /**
     * Return the object bound with the specified name in this session, or
     * <code>null</code> if no object is bound with that name.
     *
     * @param name Name of the attribute to be returned
     *
     * @exception IllegalStateException if this method is called on an
     *  invalidated session
     */
    @Override
    public Object  getAttribute(String name) {

        if (!isValidInternal())
            throw new IllegalStateException
                (sm.getString("standardSession.getAttribute.ise"));

        if (name == null) return null;

        return (attributes.get(name));

    }

   /**
     * Bind an object to this session, using the specified name.  If an object
     * of the same name is already bound to this session, the object is
     * replaced.
     * <p>
     * After this method executes, and if the object implements
     * <code>HttpSessionBindingListener</code>, the container calls
     * <code>valueBound()</code> on the object.
     *
     * @param name Name to which the object is bound, cannot be null
     * @param value Object to be bound, cannot be null
     * @param notify whether to notify session listeners
     * @exception IllegalArgumentException if an attempt is made to add a
     *  non-serializable object in an environment marked distributable.
     * @exception IllegalStateException if this method is called on an
     *  invalidated session
     */

    public void setAttribute(String name, Object value, boolean notify) {

        // Name cannot be null
        if (name == null)
            throw new IllegalArgumentException
                (sm.getString("standardSession.setAttribute.namenull"));

        // Null value is the same as removeAttribute()
        if (value == null) {
            removeAttribute(name);
            return;
        }
        // ... ...
        // Replace or add this attribute
        Object unbound = attributes.put(name, value);
       // ... ...
   }
   /**
     * Release all object references, and initialize instance variables, in
     * preparation for reuse of this object.
     */
    @Override
    public void recycle() {
        // Reset the instance variables associated with this Session
        attributes.clear();
        // ... ...
    }
    /**
     * Write a serialized version of this session object to the specified
     * object output stream.
     * <p>
     * <b>IMPLEMENTATION NOTE</b>:  The owning Manager will not be stored
     * in the serialized representation of this Session.  After calling
     * <code>readObject()</code>, you must set the associated Manager
     * explicitly.
     * <p>
     * <b>IMPLEMENTATION NOTE</b>:  Any attribute that is not Serializable
     * will be unbound from the session, with appropriate actions if it
     * implements HttpSessionBindingListener.  If you do not want any such
     * attributes, be sure the <code>distributable</code> property of the
     * associated Manager is set to <code>true</code>.
     *
     * @param stream The output stream to write to
     *
     * @exception IOException if an input/output error occurs
     */
    protected void doWriteObject(ObjectOutputStream stream) throws IOException {
        // ... ...
        // Accumulate the names of serializable and non-serializable attributes
        String keys[] = keys();
        ArrayList<String> saveNames = new ArrayList<>();
        ArrayList<Object> saveValues = new ArrayList<>();
        for (int i = 0; i < keys.length; i++) {
            Object value = attributes.get(keys[i]);
            if (value == null)
                continue;
            else if ( (value instanceof Serializable)
                    && (!exclude(keys[i]) )) {
                saveNames.add(keys[i]);
                saveValues.add(value);
            } else {
                removeAttributeInternal(keys[i], true);
            }
        }

        // Serialize the attribute count and the Serializable attributes
        int n = saveNames.size();
        stream.writeObject(Integer.valueOf(n));
        for (int i = 0; i < n; i++) {
            stream.writeObject(saveNames.get(i));
            try {
                stream.writeObject(saveValues.get(i));  
                // ... ...            
            } catch (NotSerializableException e) {
                // ... ...               
            }
        }
    }
}

我们看到每一个独立的HttpSession中保存的所有属性，是存储在一个独立的ConcurrentHashMap中的：

protected Map<String, Object> attributes = new ConcurrentHashMap<>();

所以我可以看到 HttpSession.getAttribute()， HttpSession.setAttribute() 等等方法就都是线程安全的。

session操作的线程安全问题

尽管session本身的set和get操作是线程安全的，但在编写业务逻辑时，还是有可能出现线程不安全的情况。

如下代码：

session.setAttribute("user", user);

User user = (User)session.getAttribute("user", user);

不是线程安全的！因为User对象不是线程安全的，假如有一个线程执行下面的操作：

User user = (User)session.getAttribute("user", user);

user.setName("xxx");

那么显然就会存在并发问题。

分布式Session框架

使用Cookie可以很好地解决应用的分布式部署问题，大型互联网应用系统的一个应用有上百台机器，而且有不同的应用系统系统工作。由于Cookie是将值存储在客户端的浏览器里，用户每次访问都会将最新的值待会给处理该请求的服务器，所以也就解决了同一用户的请求可能不在同一台服务器处理而导致的Cookie不一致的问题。

但使用Cookie也存在如下问题：
1、客户端存储限制，Cookie个数限制在50个
2、Cookie管理的混乱，每个应用都有自己的Cookie
3、安全担忧

Session与Cookie的结合——分布式Session框架
1、Session配置的统一管理
2、Cookie使用的监控和统一规范管理
3、Session存储的多元化
4、Session配置的动态修改
5、Session加密Key的定期修改
6、充分的容灾机制，保持框架的使用稳定性
7、Session各种存储的监控和报警支持
8、Session框架的可扩展性，兼容更多的session机制如wapSession
9、跨域名Session与Cookie共享

====

这里写图片描述

我们需要一个服务订阅服务器，在应用启动时可以从这个订阅服务器订阅这个应用需要的可写 Session 项和可写 Cookie 项，这些配置的 Session 和 Cookie 可以限制这个应用能够使用哪些 Session 和 Cookie，甚至可以控制 Session 和 Cookie 可读或者可写。这样可以精确地控制哪些应用可以操作哪些 Session 和 Cookie，可以有效控制 Session 的安全性和 Cookie 的数量。

由于应用是一个集群，所以不可能将创建的 Session 都保存在每台应用服务器的内存中，因为如果每台服务器有几十万的访问用户，服务器的内存肯定不够用，即使内存够用，这些 Session 也无法同步到这个应用的所有服务器中。所以要共享这些 Session 必须将它们存储在一个分布式缓存中，可以随时写入和读取，而且性能要很好才能满足要求。当前能满足这个要求的系统有很多，如 MemCache 或者淘宝的开源分布式缓存系统 Tair 都是很好的选择。

这里写图片描述

我们可以在应用的 web.xml 中配置一个 SessionFilter，用于在请求到达 MVC 框架之前封装 HttpServletRequest 和 HttpServletResponse 对象，并创建我们自己的 InnerHttpSession 对象，把它设置到 request 和 response 对象中。这样应用系统通过 request.getHttpSession() 返回的就是我们创建的 InnerHttpSession 对象了，我们可以拦截 response 的 addCookies 设置的 Cookie。

处理跨域名来共享 Cookie 的问题：
这里写图片描述

表单重复提交问题

要能够防止表单重复提交，就要标识用户的每一次访问请求，使得每一次访问对服务端来说都是唯一确定的。为了标识用户的每次访问请求，可以在用户请求一个表单域时增加一个隐藏表单项，这个表单项的值每次都是唯一的 token，如：

<form id=”form” method=”post”> 
<input type=hidden name=“crsf_token” value=“xxxx”/> 
</form>

当用户在请求时生成这个唯一的 token 时，同时将这个 token 保存在用户的 Session 中，等用户提交请求时检查这个 token 和当前的 Session 中保存的 token 是否一致。如果一致，说明没有重复提交，否则用户提交上来的 token 已经不是当前的这个请求的合法 token。

多终端登录

这里写图片描述

qqqqq1993qqqqq

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【简记】Java Web 内幕——Cookie与Session深度解析

本文内容：Cookie与Session相关问题解析进阶浏览器如何选择要发送哪些Cookie到服务器端？浏览器在发送请求之前，首先会根据请求url中的域名在cookie列表中找所有与当前域名一样的cookie，然后再根据指定的路径进行匹配，如果当前请求在域匹配的基础上还与路径匹配，那么就会将所有匹配的cookie发送给服务器。Session机制session机制是一种服务器端的机制，服务器使用一
复制链接

扫一扫