session会话跟踪原理

闲下来的时候，一点点看项目里别人写的代码，发现只是知道怎么去写，竟然连最常用的session的来龙去脉都不知道，非常可悲，于是静静的翻阅书本、搜索网络资源，并且写下了这篇总结，也希望可以和更多的朋友一起分享知识。

1.session的基本原理（转自http://blog.csdn.net/lovexx1122/article/details/2697113）

cookie英文意思是甜点的意思，我们可以在Web应用程序中可以使用cookie在客户端保持HTTP状态信息。cookie相当于是web服务器送给客户端浏览器的甜点。至于什么时候送，送什么样的甜点，有效期是多常时间，完全由服务器来决定。这就像我们刚入学的时候，班主任就会给你办一张听课证，听课证上面有你的相关的信息，以后每次到学校来都要戴着听课证。听课证就是学校送给你的cookie。在web应用程序中，服务器会发送一些cookie到客户端浏览器，以后每次访问web服务器，都会把cookie放到请求头中发送到服务器。那么浏览器如何来保存服务器送给它的cookie呢？有两种方式：1.每打开一个浏览器窗口，你就会发现在任务管理器中多了一个进程，这说明这个浏览器窗口在内存中有自己的内存地址空间，那么web服务器送过来的cookie就可以存放在内存中，这种存放在内存中的cookie我们称之为临时cookie，当我们把这个浏览器窗口关闭后，操作系统会回收它所占用的内存空间，所以存储在内存中的cookie也被释放了。2.如果服务器设置了cookie的有效时间，这时，浏览器会把这个cookie保存在客户端的本地磁盘上。在windows操作系统中在C:/Documents and Settings/Administrator/Cookies目录中，这里的Administrator是windows是用Administrator用户登录的。如果是用其它用户登录，则Administrator换成这个登录名。

­

    刚才我们把cookie比喻成听课证，那么session就是你的学生档案，这个档案是存放在学校的。session是一种将会话保存在服务器端的技术。用来跟踪用户。session通常借住cookie来传递会话标识号。

­

    Servlet API规范中定义了一个Httpsession接口，该接口中定义了各种管理和操作会话状态的方法。一个Httpsession对象就相当于档案袋，它是保持会话状态信息的存储结构。一个客户端在web服务器对应一个各自的HttpSession对象。由于创建HttpSession对象会消耗服务器内存资源，web服务器并不会在客户端开始访问它时就创建HttpSession对象。只有客户端访问某个特殊的Servlet程序，并且这个Servlet程序决定与客户端开启一个会话时，web应用程序才会创建一个与客户端对应的HttpSession对象，并为这个HttpSession对象分配一个独一无二的会话标识号(SessionID),然后在响应消息中将这个会话标识号传递给客户端。客户端需要记住这个SessionID，并在后续的每次访问请求中把这个SessionID传递给服务器，服务器程序依据回传的SessionID就知道这次请求是那个客户端发送的，从而选择与之对应的HttpSession对象

­

    web应用程序创建了与某个客户端对应的HttpSession对象之后，只要没有超出一个限定的空闲时间段，HttpSession对象就驻留在web服务器内存之中。HttpSession接口中定义了一个setAttribute方法将对象存储到HttpSession对象中，相当于往档案袋中放入档案信息。还定义了一个getAttribute来取得放进去的对象。

­

    session是实现网上商城的购物车的最佳方案    

 

2.URL重写（不错的链接http://edocs.weblogicfans.net/wls/docs92/webapp/sessions.html#wp100770）

看完上面的原理，对session的基本情况算是有了一个了解，但是不可深究，于是又几经搜索，得到了下面这段对于url重写的总结。

 

在某些情况下，浏览器或无线设备可能不接受 cookie，因此无法使用 cookie 进行会话跟踪。对于这种情况，URL 重写是一个解决方案，当 WebLogic Server 检测到浏览器不接受 cookie 时，会自动替换为 URL 重写。URL 重写包括将会话 ID 编码到 servlet 传回浏览器的那些网页的超链接中。当用户随后单击这些链接时，WebLogic Server 将从 URL 地址中提取 ID，并在 servlet 调用 getSession() 方法时查找相应的 HttpSession。

在 WebLogic 特定的部署描述符 weblogic.xml中的 session-descriptor 元素下，设置 url-rewriting-enabled 参数，从而启用 WebLogic Server 中的 URL 重写。此特性的默认值是 true。请参阅 url-rewriting-enabled。

URL 重写的编码准则
下面是支持 URL 重写的一般准则。

避免直接向输出流中写入 URL，如下显示：
out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");而要使用 HttpServletResponse.encodeURL() 方法，例如：

out.println("<a href=\"     + response.encodeURL("myshop/catalog.jsp")      + "\">catalog</a>");调用 encodeURL() 方法可以确定 URL 是否需要重写。如果确实需要重写，WebLogic Server 将重写 URL，即，在会话 ID 前添加一个分号，然后将其追加到 URL 后面。

除作为 WebLogic Server 响应而返回的 URL 外，还会对发送重定向的 URL 进行编码。例如：
if (session.isNew())  response.sendRedirect (response.encodeRedirectUrl(welcomeURL));  新建会话时，即使浏览器确实接受 cookie，WebLogic Server 也将使用 URL 重写，因为在初次访问会话时，服务器无法判断浏览器是否接受 cookie。

当使用插件（Apache、NSAPI、ISAPI、HttpClusterServlet 或 HttpProxyServlet）时，如果在使用 response.sendRedirect(url) 或 response.encodeRedirectURL(url) 的后端服务器上使用 URL 重写，则在以下条件下 PathTrim 和 PathPrepend 参数将被应用于该 URL：如果 PathPrepend 为空或已经应用了 PathPrepend，那么只将 PathTrim 应用于 URL。

通过检查从 HttpServletRequest.isRequestedSessionIdFromCookie() 方法返回的 Boolean，servlet 可以判断给定的会话 ID 是否是从 cookie 中收到的。您的应用程序可能会相应响应，或仅依赖于 WebLogic Server 的 URL 重写。
注意： CISCO 本地定向器负载均衡器要求 URL 重写中使用问号“?”分隔符。由于 WLS URL 重写机制使用分号“;”作为分隔符，因此 URL 重写与该负载均衡器不兼容。

URL 重写和无线访问协议 (WAP) 如果您正在编写 WAP 应用程序，您必须使用 URL 重写，因为 WAP 协议不支持 cookie。另外，某些 WAP 设备对 URL 长度有 128 位字符的限制（其中包括特性），这限制了使用 URL 重写可以传输的数据量。为了给各个特性预留较多空间，可以限制 WebLogic Server 随机生成的会话 ID 的大小。

特别是，如果要使用 WAPEnabled 特性，请通过单击“服务器”“协议” HTTP“高级选项”使用管理控制台。WAPEnabled 特性将会话 ID 的大小限制在 52 位字符内，且不允许使用特殊字符，例如“!”和“#”。还可以使用 weblogic.xml 的 IDLength 参数进一步限制会话 ID 的大小。

3.web.config

 

有关session的配置在web.config中，分为客户端和服务器端，自我感觉这个了解就好，所以不过多的描写，有兴趣的朋友可以做深入了解。

<sessionState mode="Off|InProc|StateServer|SQLServer"
cookieless="true|false"
timeout="number of minutes"
stateConnectionString="tcpip=server:port"
sqlConnectionString="sql connection string"
stateNetworkTimeout="number of seconds"
/>

4.session的存储方式（http://www.jb51.net/article/30252.htm）

 

1.1保存在IIS进程中：

　　保存在IIS进程中是指把Session数据保存在IIS的运行的进程中，也就是inetinfo.exe这个进程中，这也是默认的Session的存方式，也是最常用的。

　　这种方式的优点是简单，性能最高。但是当重启IIS服务器时Session丢失。

　　1.2.保存在StateServer上

　　这种存储模式是指将Session数据存储在一个称为Asp.Net状态服务进程中，该进程独立于Asp.Net辅助进程或IIS应用程序池的单独进程，使用此模式可以确保在重新启动Web应用程序时保留会话状态，并使会话状态可以用于网络中的多个Web服务器。

　　1.3.保存在SQL Server数据库中

　　可以配置把Session数据存储到SQL Server数据库中，为了进行这样的配置，程序员首先需要准备SQL Server数据服务器，然后在运行.NET自带安装工具安装状态数据库。

　　这种方式在服务器挂掉重启后都还在，因为他存储在内存和磁盘中。

 

总结：读完这些，算是对session少了困惑，当然最重要的是实践，在事件中领悟的是最深刻最可靠地。