Session 存储方式

 

简单来说,Session就是服务器给客户端的一个编号,当一台web服务器运行时,可能 是有多个用户都在浏览这台服务器上的网站,当每个用户首次与这台服务器建立连接时,它就与这个服务器建立了一个Session,同时服务器就会自动为其分 配一个SessionId,用以标识这个用户的唯一身分,这个Session就是有服务器随机产生的一个由24个字符组成的字符串。

         这个唯一的SessionId还是有很大的实际意义,当一个用户提交表单时,浏览器就会将用户的SessionId自动附加在HTTP头信息中,当服务器 处理完这个表单后,就会将结果返回给SessionId所对应的用户。

          如下是Web.config如何配置Session的:

           <configuration>
<system.web>
<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 " />
</system.web>
</configuration>

其中各个节点属性:
mode: Session的存储方式(必有的属性)。
InProc:将Session存到进程内(这是Default值。)
off:禁用Session.
StateServer:将Session存到独立的状态服务中(Asp.net State Service).
SqlServer:将Session存到SqlServer中。
Cookieless:设置客户端Session存储的方式。
false:使用Cookie模式(default).
true:使用Cookieless模式。
timeout:设置Session过期时间(default is 20 minutes)
stateConnectionString: 设置Session独立存放的状态服务所在服务器的名称(地址)和端口号,当mode=&ldquo;stateserver时,这个属性就是必 须的。
sqlConnectionString:设置与Sqlserver的连接字符串,当mode="sqlserver"时,这个属性时必须的。
stateNetWorkTimeout:设置当mode=&ldquo;StateServer&rdquo;时,经过多少秒空闲后, 断开web服务器与存储状态信息服务器的TCP/IP连接(default is 10 seconds).

asp.net中客户端Session的存储。
asp.net中,默认是使用Cookie存储Session的,如果是将cookieless="false",改成 cookieless="true",则session就不用cookie来存储了,而是使用url来存储。

asp.net服务器端session存储在进程内(inproc)
当mode="Inproc"时,服务器的Session存储在IIS进程中,当IIS关闭,重启时,这些Session信息就会丢失,但这种模式最大的 好处就是性能提高。

      asp.net服务器端Session存储在进程外(StateServer)
当mode="StateServer"时,服务器的Session就存储在"ASP.NET State Server"这个服务的进程中,在服务中找到名为:&ldquo;ASP.NET State Service&rdquo;的服务,启动这个服务,在资源管理器的进程中就能找到一个名 为:&ldquo;aspnet_state.exe"的进程,这个就是我们保存 Session的进程。
&rdquo;ASP.NET State Server"服务可以与Web服务器分开.eg:web服务器在192.168.0.100上,&ldquo;asp.net state service"服务在192.168.0.101上,则可以进行设置:
mode="StateServer" stateConnection="tcpip=192.168.1.101:42424".

     asp.net服务器端Session存储到SQLServer中(SQLServer),
当mode="sqlserver"时,服务器的Session就是存储到Sql server中建立一个存储Session的数据库。在
%windir%\Microsoft.NET\Framework\v2.0.50727 下有个名为: InstallSqlState.sql 的sql脚本文件. 这个脚本是专门用来建存储Session的数据库以及一个维护Session信息数据库的SQL Server代理作业的.

      执行此sql脚本后,会看到一个新增的aspstate数据库,但这个数据库中,只有存储过程,没有用户表,用户表放到了tempdb这个数据库中去 了,ASpstateTempSessions和ASPStateTempApplications,Session信息存储到了 ASPStateTempApplication存储了asp中Application对象信息。

    另外查看管理->SQL Server代理->作业,会发现多了一个名为:

ASPState_job_DeleteExpiredSession的作业,这个作业实际上是每分钟去ASPStateTempSession中 删除过期的Session信息。

      上面的方法是建立Session数据库的一个”官方“方法,但在实际的应用中一般没这么去建,而是采用另一种方法,使用下面这段命令来自动创建 Session数据库:

  

aspnet_regsql.exe -S ServerName\InstanceName -U User -P Password -d DBName -ssadd -sstype c

      此命令将在ServerName\InstanceName建立DBName的数据库, 用户存储Session的数据库. 此数据库中包含了存储过程和用户表. 同时在SQL Server代理 -> 作业 中也加入了相应的作业.

      然后在Web.config中设置好配置信息:

mode="SQLServer" sqlConnectionString="data source=ServerName\InstanceName; Integrated Security=SSPI;"

      "Integrated Security=SSPI;" 是指使用Windows集成身份验证.

       如果使用SQL用户登陆方式. 则在sqlConnectionString中设置好"userid=sa; password=***".

      这样一来就可以将Session存放到SQLServer中了

开发者小组,欢迎大家加入http://home.cnblogs.com/group/msdn2/ net技术QQ群号:21386099 有问题的可以在小组提问
 

不得不说当我了解了session的原理之后感觉到了惊讶,因为session竟然是基于cookie的,所以当一向被认为不安全的cookie和超安全的session等同之后确实很让人接受不了,因为我确实是菜鸟
做了这么多年的web,用了这么多年的session和cookie,竟然就习惯了这两个东西,把他们的功能当成了天然的功能,从来没有考虑过他们的原理,实在是悲哀,直到有一天,我觉醒了。。
首先应该了解http协议的请求过程,这个以前倒是知道,当然是基于tcp/ip协议,客户端请求服务器,服务器回答客户端,无状态的,那么服务器如何区分客户端的呢?看完本文自然明白了

关于cookie

先来说cookie,怎么使用就不说了,cookie按照在客户端存放的方式,可以分为两类,
一种是会话性质的cookie,存放在浏览器内存中,当你在用代码向客户端写入cookie的时候,如果没有指定过期时间,那么cookie是存放在浏览器的内存里面的,不会持久化在硬盘上,也就是你在浏览器的临时文件里找不到!
一种是持久化的cookie,存放在硬盘上,当你指定了cookie的过期时间,那么,在客户端写入cookie的时候就会在浏览器的临时文件下生成一个文件,具体格式和名字可以到浏览器临时文件去看下

cookie的原理是这样的:当你在服务器端的代码里写了response.cookie["mycookie"]="mytestcookie"的时候,返回给客户端的http响应中,会在http相应头中加入cookie的信息,浏览器收到相应后,会按照http响应头里的cookie在客户端建立cookie。
客户端的cookie也是插在http头中发送到服务器端的,并且,一个域,在客户端建立的所有cookie,在客户端的每一次的http请求都会带着,比如testwebsite.com这个站点,任何时刻写到客户端的cookie,只要不过期,浏览器在向testwebsite.com发送http请求的时候,会带上这些cookie,所以cookie在客户端的大小是有限制的

关于session
cookie明白了之后session就容易理解了,asp的session和asp.net默认的session就是通过第一种cookie来实现的,你可以把自己的浏览器的cookie彻底禁用,然后再去登录一些注册过的门户网站,会发现很多都登录不了了。是cookie,将http的请求变得有状态。session的实现是web服务器的事情,不过很显然是利用会话cookie,也就是存放在浏览器内存里的那种cookie来实现的,在cookie里只是存放了SessionID,然后在服务器上建立了一张表,对应客户端的SessionID。这张表是存放在服务器上的进程中的,也就是服务器的内存里,也就是Application里。当客户端请求服务器的时候,如果服务器发现这是一个新的请求,就会分配给他一个SessionID,也就是在浏览器写入一个sessionID的cookie。你可以试一下,在你请求过一次服务器之后,在服务器遍历客户端所有的cookie,就会发现这个叫做SessionID的cookie。
所以在了解了这个session的原理之后我们可以自己来造一个自己的session,过程就不说了。

那么我们现在可以说session就是依赖于会话性的cookie的

关于session的其他
asp.net可以定制session的实现方式,默认是上面说的原理,但是可以改变的。
可以选择不依赖于cookie,就是把sessionID作为URL的一部分放在每一次的请求后面,像这样:
http://www.testwebsite.com/(-此处为一串sessionID的字符串-)/test.aspx
但是这种方式你如果在html中指定url的时候,指定了绝对路径,比如
<a href="http://www.testwebsite.com/other.aspx">test</a>
那么点击这个链接就会不是同一个会话了,因为此时区分客户端的唯一标志就是域名后面那串字符串
php也有类似的做法,不依赖cookie的做法是在get的参数里面带一个sessionID的参数
asp.net还可以定义session里存放数据的存储位置,放在其他进程,放在sqlServer中等等,知道了session的原理就很容易明白,我们可以自己就可以造一个类似session作用的东西的

session的结束问题

还有知道了session的原理就会明白一个session会话如何结束,除非服务器端可以清除一个session会话,客户端是没有能力清除session的,关闭浏览器的时候并不能够结束当前的会话(忽略浏览器关闭事件),在不依赖于cookie的session中最明显,你可以记下你的sessionID那串字符串,关闭浏览器,打开,把sessionID自己替换,你就可以恢复刚才的会话了。所谓的20分钟session超时,是服务器每隔20分钟对于不活动的session清除而已。
还有要指出的是依赖于cookie的session是存放在浏览器内存中的,所以一个浏览器的进程就会产生一个session,可以通过任务管理器查看进程,对于IE来说,只有双击桌面上的浏览器快捷方式才能新启动一个进程的,当然其他类似启动iexplorer.exe的行为也可以

到这里你会发现在依赖于cookie的session中,是需要浏览器的支持的!所以当你不用浏览器而自己来制造http请求的时候,session就用了!
对于js的ajax请求,确切的说是xmlhttp这个组件发送的http请求,虽然是你使用js的代码自己制造的,但是依然是借助于浏览器发送的,所以可以获得session。
所以在webservice中使用session我们还得自己造一个东西实现cookie的功能

如果你使用InProc模式的Session,存储过多的数据会导致IIS进程被回收,引发Session不断丢失。

·      如果你使用StateServer存储Session,那么数据在存入Session以前需要进行序列化,序列化会消耗大量的CPU资源。

·      如果你使用SqlServer模式的Session,数据不但要序列化而且还是存储在磁盘上,更不适合存储大量数据。

SessionID是一个由24个字符组成的随机字符串

ookie是否开启不影响Session使用,缺点是不能再使用绝对链接了。

stateNetworkTimeout属性表示从状态服务器请求Session数据最长的时间,默认为10秒,如果网络连接不是很好,请把这个数字适当设置得大一点。

只有把对象标注为可序列化后才能在服务中进行存储。什么是序列化呢?序列化是指将对象实例的状态存储到存储媒体的过程。在此过程中,先将对象的公共字段和私有字段以及类的名称转换为字节流,然后再把字节流写入数据流。在随后对对象进行反序列化时,将创建出与原对象完全相同的副本。要使一个类可序列化,最简单的方法是使用 Serializable 属性对它进行标记。

因此Session能存储的类型为: 对于InProc模式是一切类型,而对于StateServer和SqlServer模式是一切可以序列化的类型。

一定程度上反映了Session是不能跨应用程序的。举例来说,我们在计算机上建立了两个网站,同时都使用Session[“UserName”]来保存登录的用户名,一个网站的用户登录后,另一个网站直接访问Session[“UserName”]是取不到任何值的。那么,Session是否可以跨用户呢?通过前面的分析我们知道,肯定是不行的,Session通过SessionID来区分用户,一般来说SessionID是不可能出现重复的现象,也就是说Session一般是不会“串号”的。既然页面每次提交的时候都会附加上当前用户的SessionID,那么Session应该是可以跨页面的,也就是说一个网站中所有的页面都使用同一份Session。你可以自己来做个试验,请读者打开刚才那个页面,然后按Ctrl+N组合键再打开第二个同样的页面,单击第一个页面中的“写入Session”按钮,单击第二个页面中的“读取Session”按钮,可以发现Session的值被正确读出了。第三个问题的答案有了。


表12.1  三种模式的Session比较

 

InProc

StateServer

SQLServer

存储物理位置

IIS进程(内存)

Windows服务进程(内存)

SQLServer数据库(磁盘)

存储类型限制

无限制

可以序列化的类型

可以序列化的类型

存储大小限制

无限制

使用范围

当前请求上下文,对于每个用户独立

生命周期

第一次访问网站的时候创建Session超时后销毁

优点

性能比较高

Session不依赖Web服务器,不容易丢失

缺点

容易丢失

序列化与反序列化消耗CPU资源

序列化与反序列化消耗CPU资源,从磁盘读取Session比较慢

使用原则

不要存放大量数据

·      为什么当我设置cookieless为true后,在重定向的时候会丢失Session?

n  当使用cookieless时,你必须使用相对路径替换程序中的绝对路径,如果使用绝对路径,ASP.NET将无法在URL中保存SessionID。

  为什么每次请求的SessionID都不相同?

n  可能是没有在Session里面保存任何信息引起的,即程序中任何地方都没有使用Session。只有在Session中保存了内容后,Session才会和浏览器进行关联,此时的SessionID将不会再变化

打开iecookiesview,这款软件是拿来察看和修改本机的cookies的,很方便我们的cookies欺骗入侵。
  在iecookiesview 里找到你要欺骗的那个网站,看到了吗?有你的用户名和md5加密的密码,我们吧这两项改为管理员的,就是把刚才数据库里面的管理员账号和md5加密的密码代替你自己的。点击“更改cookies”,打开一个新的ie,然后再去访问那个论坛,看到没有?你现在已经是管理员了。
  接着,麻烦的事出现了,后台登陆并不是以cookies来实现的,而是以session实现的 ,所以我们同样来欺骗session

 
简单来说,Session就是服务器给客户端的一个编号,当一台web服务器运行时,可能 是有多个用户都在浏览这台服务器上的网站,当每个用户首次与这台服务器建立连接时,它就与这个服务器建立了一个Session,同时服务器就会自动为其分 配一个SessionId,用以标识这个用户的唯一身分,这个Session就是有服务器随机产生的一个由24个字符组成的字符串。

         这个唯一的SessionId还是有很大的实际意义,当一个用户提交表单时,浏览器就会将用户的SessionId自动附加在HTTP头信息中,当服务器 处理完这个表单后,就会将结果返回给SessionId所对应的用户。

          如下是Web.config如何配置Session的:

           <configuration>
<system.web>
<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 " />
</system.web>
</configuration>

其中各个节点属性:
mode: Session的存储方式(必有的属性)。
InProc:将Session存到进程内(这是Default值。)
off:禁用Session.
StateServer:将Session存到独立的状态服务中(Asp.net State Service).
SqlServer:将Session存到SqlServer中。
Cookieless:设置客户端Session存储的方式。
false:使用Cookie模式(default).
true:使用Cookieless模式。
timeout:设置Session过期时间(default is 20 minutes)
stateConnectionString: 设置Session独立存放的状态服务所在服务器的名称(地址)和端口号,当mode=&ldquo;stateserver时,这个属性就是必 须的。
sqlConnectionString:设置与Sqlserver的连接字符串,当mode="sqlserver"时,这个属性时必须的。
stateNetWorkTimeout:设置当mode=&ldquo;StateServer&rdquo;时,经过多少秒空闲后, 断开web服务器与存储状态信息服务器的TCP/IP连接(default is 10 seconds).

asp.net中客户端Session的存储。
asp.net中,默认是使用Cookie存储Session的,如果是将cookieless="false",改成 cookieless="true",则session就不用cookie来存储了,而是使用url来存储。

asp.net服务器端session存储在进程内(inproc)
当mode="Inproc"时,服务器的Session存储在IIS进程中,当IIS关闭,重启时,这些Session信息就会丢失,但这种模式最大的 好处就是性能提高。

      asp.net服务器端Session存储在进程外(StateServer)
当mode="StateServer"时,服务器的Session就存储在"ASP.NET State Server"这个服务的进程中,在服务中找到名为:&ldquo;ASP.NET State Service&rdquo;的服务,启动这个服务,在资源管理器的进程中就能找到一个名 为:&ldquo;aspnet_state.exe"的进程,这个就是我们保存 Session的进程。
&rdquo;ASP.NET State Server"服务可以与Web服务器分开.eg:web服务器在192.168.0.100上,&ldquo;asp.net state service"服务在192.168.0.101上,则可以进行设置:
mode="StateServer" stateConnection="tcpip=192.168.1.101:42424".

     asp.net服务器端Session存储到SQLServer中(SQLServer),
当mode="sqlserver"时,服务器的Session就是存储到Sql server中建立一个存储Session的数据库。在
%windir%\Microsoft.NET\Framework\v2.0.50727 下有个名为: InstallSqlState.sql 的sql脚本文件. 这个脚本是专门用来建存储Session的数据库以及一个维护Session信息数据库的SQL Server代理作业的.

      执行此sql脚本后,会看到一个新增的aspstate数据库,但这个数据库中,只有存储过程,没有用户表,用户表放到了tempdb这个数据库中去 了,ASpstateTempSessions和ASPStateTempApplications,Session信息存储到了 ASPStateTempApplication存储了asp中Application对象信息。

    另外查看管理->SQL Server代理->作业,会发现多了一个名为:

ASPState_job_DeleteExpiredSession的作业,这个作业实际上是每分钟去ASPStateTempSession中 删除过期的Session信息。

      上面的方法是建立Session数据库的一个”官方“方法,但在实际的应用中一般没这么去建,而是采用另一种方法,使用下面这段命令来自动创建 Session数据库:

  

aspnet_regsql.exe -S ServerName\InstanceName -U User -P Password -d DBName -ssadd -sstype c

      此命令将在ServerName\InstanceName建立DBName的数据库, 用户存储Session的数据库. 此数据库中包含了存储过程和用户表. 同时在SQL Server代理 -> 作业 中也加入了相应的作业.

      然后在Web.config中设置好配置信息:

mode="SQLServer" sqlConnectionString="data source=ServerName\InstanceName; Integrated Security=SSPI;"

      "Integrated Security=SSPI;" 是指使用Windows集成身份验证.

       如果使用SQL用户登陆方式. 则在sqlConnectionString中设置好"userid=sa; password=***".

      这样一来就可以将Session存放到SQLServer中了

猜你喜欢

转载自www.cnblogs.com/zyy1688/p/10002669.html
今日推荐