trackbacks-0
对比起 ，Session 是存储在服务器端的会话，相对安全，并且不像 Cookie 那样有存储长度限制，本文简单介绍 Session 的使用。 由于 Session 是以文本文件形式存储在服务器端的，所以不怕客户端修改 Session 内容。实际上在服务器端的 Session 文件，PHP 自动修改 Session 文件的权限，只保留了系统读和写权限，而且不能通过 ftp 修改，所以安全得多。 对于 Cookie 来说，假设我们要验证用户是否登陆，就必须在 Cookie 中保存用户名和密码（可能是 md5 加密后字符串），并在每次请求页面的时候进行验证。如果用户名和密码存储在数据库，每次都要执行一次数据库查询，给数据库造成多余的负担。因为我们并不能 只做一次验证。为什么呢？因为客户端 Cookie 中的信息是有可能被修改的。假如你存储 $admin 变量来表示用户是否登陆，$admin 为 true 的时候表示登陆，为 false 的时候表示未登录，在第一次通过验证后将 $admin 等于 true 存储在 Cookie，下次就不用验证了，这样对么？错了，假如有人伪造一个值为 true 的 $admin 变量那不是就立即取的了管理权限么？非常的不安全。 而 Session 就不同了，Session 是存储在服务器端的，远程用户没办法修改 Session 文件的内容，因此我们可以单纯存储一个 $admin 变量来判断是否登陆，首次验证通过后设置 $admin 值为 true，以后判断该值是否为 true，假如不是，转入登陆界面，这样就可以减少很多数据库操作了。而且可以减少每次为了验证 Cookie 而传递密码的不安全性了（Session 验证只需要传递一次，假如你没有使用 SSL 安全协议的话）。即使密码进行了 md5 加密，也是很容易被截获的。 当然使用 Session 还有很多优点，比如控制容易，可以按照用户自定义存储等（存储于数据库）。我这里就不多说了。 Session 在 php.ini 是否需要设置呢？一般不需要的，因为并不是每个人都有修改 php.ini 的权限，默认 Session 的存放路径是服务器的系统临时文件夹，我们可以自定义存放在自己的文件夹里，这个稍后我会介绍。 开始介绍如何创建 Session。非常简单，真的。 启动 Session 会话，并创建一个 $admin 变量： &?php//
启动 Sessionsession_start();//
声明一个名为 admin 的变量，并赋空值。$_SESSION["admin"] =?& 如果你使用了 Seesion，或者该 PHP 文件要调用 Session 变量，那么就必须在调用 Session 之前启动它，使用 session_start() 函数。其它都不需要你设置了，PHP 自动完成 Session 文件的创建。 执行完这个程序后，我们可以到系统临时文件夹找到这个 Session 文件，一般文件名形如：sess_4cdbff89168ec，后面是 32 位编码后的随机字符串。用编辑器打开它，看一下它的内容：admin|N;一般该内容是这样的结构：变量名|类型:长度:值; 并用分号隔开每个变量。有些是可以省略的，比如长度和类型。 我们来看一下验证程序，假设数据库存储的是用户名和 md5 加密后的密码：login.php &?php//
表单提交后...$posts = $_POST;//
清除一些空白符号foreach ($posts as $key =& $value) {
$posts[$key] = trim($value);}$password = md5($posts["password"]);$username = $posts["username"]; $query = "SELECT `username` FROM `user` WHERE `password` = '$password' AND `username` = '$username'";//
取得查询结果$userInfo = $DB-&getRow($query); if (!empty($userInfo)) {
当验证通过后，启动 Session
session_start();
注册登陆成功的 admin 变量，并赋值 true
$_SESSION["admin"] =} else {
die("用户名密码错误");}?& 我们在需要用户验证的页面启动 Session，判断是否登陆： &?php//
防止全局变量造成安全隐患$admin =//
启动会话，这步必不可少session_start();//
判断是否登陆if (isset($_SESSION["admin"]) && $_SESSION["admin"] === true) {
echo "您已经成功登陆";} else {
验证失败，将 $_SESSION["admin"] 置为 false
$_SESSION["admin"] =
die("您无权访问");}?& 是不是很简单呢？将 $_SESSION 看成是存储在服务器端的数组即可，我们注册的每一个变量都是数组的键，跟使用数组没有什么分别。 如果要登出系统怎么办？销毁 Session 即可。 &?phpsession_start();//
这种方法是将原来注册的某个变量销毁unset($_SESSION['admin']);//
这种方法是销毁整个 Session 文件session_destroy();?& Session 能否像 Cookie 那样设置生存周期呢？有了 Session 是否就完全抛弃 Cookie 呢？我想说，结合 Cookie 来使用 Session 才是最方便的。 Session 是如何来判断客户端用户的呢？它是通过 Session ID 来判断的，什么是 Session ID，就是那个 Session 文件的文件名，Session ID 是随机生成的，因此能保证唯一性和随机性，确保 Session 的安全。一般如果没有设置 Session 的生存周期，则 Session ID 存储在内存中，关闭浏览器后该 ID 自动注销，重新请求该页面后，重新注册一个 Session ID。 如果客户端没有禁用 Cookie，则 Cookie 在启动 Session 会话的时候扮演的是存储 Session ID 和 Session 生存期的角色。 我们来手动设置 Session 的生存期： &?phpsession_start();//
保存一天$lifeTime = 24 * 3600;setcookie(session_name(), session_id(), time() + $lifeTime, "/");?& 其实 Session 还提供了一个函数 session_set_cookie_params(); 来设置 Session 的生存期的，该函数必须在 session_start() 函数调用之前调用： &?php//
保存一天$lifeTime = 24 * 3600;session_set_cookie_params($lifeTime);session_start();$_SESSION["admin"] =?& 如果客户端使用 IE 6.0 ， session_set_cookie_params(); 函数设置 Cookie 会有些问题，所以我们还是手动调用 setcookie 函数来创建 cookie。 假设客户端禁用 Cookie 怎么办？没办法，所有生存周期都是浏览器进程了，只要关闭浏览器，再次请求页面又得重新注册 Session。那么怎么传递 Session ID 呢？通过 URL 或者通过隐藏表单来传递，PHP 会自动将 Session ID 发送到 URL 上，URL 形如：/index.php?PHPSESSID= bba5b2a240a77e5b44cfa01d49cf9669，其中 URL 中的参数 PHPSESSID 就是 Session ID了，我们可以使用 $_GET 来获取该值，从而实现 Session ID 页面间传递。 &?php//
保存一天$lifeTime = 24 * 3600;//
取得当前 Session 名，默认为 PHPSESSID$sessionName = session_name();//
取得 Session ID$sessionID = $_GET[$sessionName];//
使用 session_id() 设置获得的 Session IDsession_id($sessionID); session_set_cookie_params($lifeTime);session_start();$_SESSION['admin'] =?& 对于虚拟主机来说，如果所有用户的 Session 都保存在系统临时文件夹里，将给维护造成困难，而且降低了安全性，我们可以手动设置 Session 文件的保存路径，session_save_path() 就提供了这样一个功能。我们可以将 Session 存放目录指向一个不能通过 Web 方式访问的文件夹，当然，该文件夹必须具备可读写属性。 &?php//
设置一个存放目录$savePath = './session_save_dir/';//
保存一天$lifeTime = 24 * 3600;session_save_path($savePath);session_set_cookie_params($lifeTime);session_start();$_SESSION['admin'] =?& 同 session_set_cookie_params(); 函数一样，session_save_path() 函数也必须在 session_start() 函数调用之前调用。 我们还可以将数组，对象存储在 Session 中。操作数组和操作一般变量没有什么区别，而保存对象的话，PHP 会自动对对象进行序列化（也叫串行化），然后保存于 Session 中。下面例子说明了这一点：person.php &?phpclass person {
function output() {
echo $this-&
function setAge($age) {
$this-&age = $
}}?& setage.php &?phpsession_start();require_once 'person.php';$person = new person();$person-&setAge(21);$_SESSION['person'] = $echo '&a href='output.php'&check here to output age&/a&';?& output.php &?php// 设置回调函数，确保重新构建对象。ini_set('unserialize_callback_func', 'mycallback');function mycallback($classname) {
include_once $classname . '.php';}session_start();$person = $_SESSION['person'];//
输出 21$person-&output();?& 当我们执行 setage.php 文件的时候，调用了 setage() 方法，设置了年龄为 21，并将该状态序列化后保存在 Session 中（PHP 将自动完成这一转换），当转到 output.php 后，要输出这个值，就必须反序列化刚才保存的对象，又因为在解序列化的时候需要实例化一个未定义类，所以我们定义了以后回调函数，自动包含 person.php 这个类文件，因此对象被重构，并取得当前 age 的值为 21，然后调用 output() 方法输出该值。 另外，我们还可以使用 session_set_save_handler 函数来自定义 Session 的调用方式。
阅读(...) 评论() &西西软件下载最安全的下载网站、值得信赖的软件下载站！
您的位置：
→ ASP.NET中的Session怎么正确使用
Session对象用于存储从一个用户开始访问某个特定的aspx的页面起，到用户离开为止，特定的用户会话所需要的信息。用户在应用程序的页面切换时，Session对象的变量不会被清除。 对于一个Web应用程序而言，所有用户访问到的Application对象的内容是完全一样的；而不同用户会话访问到的Session对象的内容则各不相同。
Session可以保存变量，该变量只能供一个用户使用，也就是说，每一个网页浏览者都有自己的Session对象变量，即Session对象具有唯一性。&最近这两天被一个Web Farm环境下的Session处理问题虐得很痛苦，这是一个ASP.NETSession基础知识的一个合集，有的地方感觉是有重复，比较拢一旧习凑赵慕氤隼戳耍〉艹绦蛩讲桓撸⒂锼礁睿09年高考英语65分，满分150），自我感觉Session基础内容是讲清楚了，我粗浅的理解下，没有发现有什么错误了，文章较浅，请各位发现有什么不对的地方告诉我，我一定尽快处理，这篇文章很适合初学者看，作者说的很清楚，能把ASP.NET下Session的玩法看得较为清晰。另外我会在我另一篇博文中将我所遇到的问题以及解决办法和大家共享。原文地址：/Articles/32545/Exploring-Session-in-ASP-Net这篇文章将使你非常好地理解Session，在这篇文章中，我会包含Session的基础知识，用不同的方式储存Session对象，包含Web园（Web Farm）和Web农场（Web Garden）以及负载均衡等等情境。我也将详细阐明Session在实际生产环境中的应用。希望您能喜欢这篇文章，欢迎您反馈您的看法和建议。什么是Session Web是无状态的，他提供了一种新的方式：每次都通过用户对服务器提交请求而渲染新的网页。众所周知，HTTP是一种无状态协议，他不能通过页面和客户端保持连接。如果用户需要增加一些信息和跳转到了另外的页面，原有的数据将会丢失，用户将无法恢复这些信息。我们需要这玩意儿干嘛呢？我们需要保存信息！Session提供了一个在服务器端保存信息的方案。他能支持任何类型对象和用户对象信息作为对象保存起来。Session为每一个客户端都独立地保存，这意味着Session数据存储着每个客户端的基础信息。请看下图：每一个客户端都有一份独立的Session用Session进行状态管理是ASP.NET最好的特性之一，因为它是安全的，对于客户端是透明的，并且他能存储任何类型的对象。而在这些优点之外，有时Session会导致一些对性能要求较高的网站的性能问题。因为他消耗服务器的内存存储用户访问网站所需的数据，现在让我们来看一看Session对于您Web 应用的利弊。Session的利弊 接下来我们讨论普通情况下使用Session的利弊，我会描述每一种Session的使用情境。优点： 他能在整个应用中帮助维护用户状态和数据。 他能让我们简单地实现存储任何类型的对象。 独立地保存客户端数据。 对于用户来说，Session是安全的、透明的。缺点： 因为Session使用的是服务器的内存，所以在用户量大的时候会成为性能瓶颈。 在序列化和反序列化的过程中他也会成为性能瓶颈，因为在StateServer（状态服务）模式和模式下我们需要对我们存储的数据进行序列化和反序列化我们所存储的数据。 除此之外，Session的各种模式都有其利弊。接下来我们将讨论各种Session模式。对Session进行读/写读/写Session是非常简单的，就像使用ViewState一样，我们能使用System.Web.SessionState.HttessionState这个类来与Session进行交互，这个类在ASP.NET页面内内建（提供）了Session。下面的代码就是使用Session进行存储的例子：//Storing UserName in Session
Session[&UserName&] = txtUser.T接下来让我们来看如何从Session读取数据：//Check weather session variable null or not
if (Session[&UserName&] != null)
//Retrieving UserName from Session
lblWelcome.Text = &Welcome : & + Session[&UserName&];
//Do Something else
}我们也能存储其他对象，下面的例子展示了如何存储一个DataSet到Session里//Storing dataset on Session
Session[&DataSet&] = _objDataS下面的代码展示了如何从Session内读取DataSet//Check weather session variable null or not
if (Session[&DataSet&] != null)
//Retrieving UserName from Session
DataSet _MyDs = (DataSet)Session[&DataSet&];
//Do Something else
}参考文献：MSDN (read the session variable section)Session IDASP.NET使用了120bit的标识符用以标识每个Session。这是足够安全的、不可逆的设计。当客户端和服务端进行通信的时候，在他们之间需要传输这个Session ID，当客户端发送request（请求）数据时，ASP.NET搜索Session ID，通过Session ID检索数据。这个过程通过以下步骤进行： 客户端点击网站-&客户端信息被Session储存 服务端为客户端创建一个唯一的Session ID，并在服务端存储这个ID 客户端通过发送带有SessionID的请求以获取在服务端保存的信息 服务器端通过Session Provider从状态服务（State Server）中获取序列化后的数据并且进行类型强制转换成对象以下为流程图片：客户端、Web服务器、Session Provider的通信参考文献：SessionID in MSDNSession模式和Session Provider在ASP.NET中，有以下几种Session模式可以使用InProcStateServerSQLServerCustom每一种Session State都有一种Session Provider。以下的图形将展示他们的关系：Session state体系图我们能在这些基础的Session State Provider中进行选择。当ASP.NET接收到带有Session ID的信息请求时Session State和他相应的Provider负责提供和存储对应的信息。下面的表展示了Session 模式以及Provider的名称：Session State模式State ProviderInProcIn-memory object（内置对象）StateServerAspnet_state.exeSQLServerSQL Server DatabaseCustomCustom provider除此之外，还有另一个模式：“OFF”，如果我们选择这个选项，Session将不能为这个应用提供服务。但是我们的目标是使用Session，所以我们将讨论上面四种的Session模式。Session StatesSession State模式基本上可以认为把所有的Session配置、维护都交给了Web应用。Session State他本身就是一个大东西，他基本上意味着你所有关于Session 的配置无论实在web.config或者页面后端代码。在web.config里元素被用作Session的配置。在元素中可以配置的有Mode（模式）,Timeout（超时）,StateConnectionString（State连接字符串）,CustomProvider（自定义的Provider）等等。我们已经讨论过了每个部分的连接字符串在我们讨论Session mode之前，接下来我们简述以下Session的一些事件：Session事件在ASP.NET中有两个可以使用的Session事件：Session_StartSession_End你能处理应用中的这两个事件在global.asax这个文件里，当一个新的Session开启时session_start事件被触发，当Session被回收或是过期时Session_End被触发：void Session_Start(object sender, EventArgs e)
// Code that runs when a new session is started
void Session_End(object sender, EventArgs e)
// Code that runs when a session ends.
}参考文献：Application and Session EventsSession 模式我们已经讨论过Session模式，接下来说说这些模式的不同：OffInProcStateServerSQLServerCustom如果我们在web.config内设定Session Mode=&off&，Session将在应用中不可用，他的设置是这样的：InProc Session 模式：这是ASP.NET默认的Session模式，他在当前的应用程序域中存储Session信息。这是性能最好的Session模式。但是他最大的缺点在于：当我们重启服务的时候Session数据将会丢失。InProc模式有一些优缺点，接下来我们将详细这些点。InProc概述：我们已经说过，InProc模式Session数据将会储存在当前应用程序域中，所以他是最简单、快速、好用的。InProc模式Session数据保存在应用程序域内的一个集合对象，他在一个应用程序池中进行工作，如果我们重启服务，我们将丢失Session数据。正常情况下客户端发送请求，State Provider从内存对象中读取数据并返回给客户端，在web.config中我们必须提供Session模式和设置过期时间：上面的设置中，设置了Session的过期时间为30分钟，这也可以从后台代码中进行配置。Session.TimeOut=30;在ASP.NET中有两个Session事件可以进行使用：Session_Start()和Session_End()而这种模式（后端代码控制）只支持Session_End()事件。这个事件在Session超时时被调用，一般情况下，InProc Session模式是这样的：当Session过期时Session_End()事件被调用。InProc是一个非常快的处理机制，因为没有序列化地读/写过程，并且数据保存在相同的域内。什么时候我们使用InProc模式呢？InProc是默认的Session模式，他对小型应用程序和用户量比较小的程序非常合适，我们应尽量避免在Web园（Web Garden）和Web农场（Web Farm）情境下使用他（以后我会讲到这个情境）优缺点：优点： 他把Session数据存储在当前应用程序域内，所以访问数据会非常的快速、简单、高效。 在InProc模式中不需要对对象进行序列化存储。 使用起来非常简单，就像ViewState一样。缺点： 虽然InProc是最快的，最通用的，也是默认的机制，但是他有许多限制： 如果工作的应用进程被回收，Session数据将全部丢失。 虽然他是最快的，但是当Session数据太大和用户过多时，他会由于内存的大量使用而影响整个程序的性能。 我们不能在Web园环境中使用这种模式。 这种模式不适合用于Web农场（Web Farm）环境中。现在，我们来看看其他可用的方法来规避这些缺点，首先是StateServer模式：StateServer Session模式StateServer模式概述这也叫做Out-Proc Session模式。StateServer使用了一个独立的Windows服务来提供Session服务，他独立于IIS，也能独使用一台服务器。StateServer的服务来自于aspnet_state.exe提供。这个服务也能和您的应用服务共同运行在同一台服务器上，注意他是独立于Web应用程序域的一个服务。这意味着你重启你的Web服务后Session数据依然存在。这个方案的缺点在于有一个性能瓶颈：数据读写需要进行序列化和反序列化，因为不是同一个应用程序域，所以他也增加了数据读写的性能消耗，因为他们是两个不同的进程。配置StateServer Session模式在StateServer模式里，Session数据存储在独立于IIS的一个服务里。这个进程作为一个Windows服务运行，你能在Windows服务管理器（MMC）或者命令行中进行启动。默认情况下，ASP.NET StateServer（中文名：ASP.NET状态服务）默认情况下启动方式是“手动”我们必须将他设置为自动。如果从命令行启动的化只需要输入：&net start aspnet_state&；默认情况下，这个服务监听TCP端口42424，但是我们可以在注册表里改变这个设置，如图：现在，我们来看一看web.config对StateServer的设置，在StateServer的设置里我们需要指定StateServer连接字符串stateConnectionString：指向运行StateServer的系统。默认设置下，StateConnectionString使用IP127.0.0.1（localhost）端口使用42424。当我们使用StateServer，我们还能设置超时stateNetworkTimeOut特性指定等待服务响应的秒数，即发出请求到取消响应的事件时间间隔。默认情况下是10秒。当使用StateServer进行存储时对象将被序列化进行储存，而读取对象时，将对数据进行反序列化，我们来看下面的例子：StateServer是如何工作的我们使用StateServer来避免当重启Web服务时无谓的Session数据丢失。StateServer是在aspnet_state.exe进程作为一个服务来进行维护的，这个进程维护着所有的Session数据，但是在存储到StateServer之前我们需要对数据进行序列化。如上图所示，客户端发送请求到Web服务器，Web服务器将Session数据存储在StateServer里，StateServer也许在当前的系统里，也可能在另一个系统里，但他一定是独立于IIS的，为了实现他，我们必须在web.config里进行配置stateConnectionString。例如我们设置指向127.0.0.1:42424，这将把数据存储在本地的系统内，为了实现改变StateServer指向的目的，我们改变了IP，并且确定aspnet_state.exe正常运行于这个系统上，接下来当你需要读写Session时（也就是通过修改IP来导致一个错误的指向），你就会引发下图这样的异常：当我们存储一个对象到Session，对象将被序列化。系统利用State Provider将数据存储进StateServer。当读取数据时，State Provider将返回数据，完整的流程图如下图：StateServer Session模式例子：这是一个简单的使用StateServer Session模式的例子，我直接在IIS里创建这个例子，能轻松地明白他的用法：步骤1：打开Visual Studio&文件&新建&网站。选择HTTP作为web应用的位置。现在你打开IIS，你将会看到创建了一个虚拟目录，名字是你的应用名，在我的例子中是StateServer。步骤2：创建一个简单的UI：他将获取一个学生的角色编号和名字，我们将保存名字和编号到StateServer Session里。我也将创建一个类：StudentInfo，这个类的定义如下：[Serializable]
public class StudentInfo
//Default Constructor
public StudentInfo()
/// Create object of student Class
///Int RollNumber
///String Name
public StudentInfo(int intRoll, string strName)
this.Roll = intR
this.Name = strN
private int intR
private string strN
public int Roll
return intR
public string Name
return strN
}现在来看后端代码，我增加了两个Button：一个是保存Session，另一个是获取Session：protected void btnSubmit_Click(object sender, EventArgs e)
StudentInfo _objStudentInfo =
new StudentInfo(Int32.Parse( txtRoll.Text) ,txtUserName.Text);
Session[&objStudentInfo&] = _objStudentI
ResetField();
protected void btnRestore_Click(object sender, EventArgs e)
StudentInfo _objStudentInfo = (StudentInfo) Session[&objStudentInfo&];
txtRoll.Text = _objStudentInfo.Roll.ToString();
txtUserName.Text = _objStudentInfo.N
}步骤3：配置你的web.config的StateServer，在之前介绍过，请确保web.config在配置所指向的服务器上的State Server是处于开启并运行的状态。步骤4：运行应用。输入数据，点击Submit。接下来的测试，我将完整的解释如何使用StateServer首先：移除StudentInfo类[Serializable]特性，然后运行应用。当你点解Submit按钮，你将看到如下的错误：清晰地指出了在存储之前你必须序列化你的对象。第二：运行程序，在点击了Submit按钮保存数据后，重启IIS如果在InProc中，我保证你的Session数据将会丢失，但是在StateServer中，点击Restore Session按钮，你将获取你的原始数据，因为StateServer数据不依赖于IIS，它独立地保存数据。第三：在Windows 服务管理程序（MMC）中停止StateServer服务，你再点击Submit按钮，你将看到如下错误：因为你的StateServer进程没有运行，所以当你在使用StateServer的时候，请牢记这三点。优点和缺点基于上述讨论：优点： StateServer独立于IIS运行，所以无论IIS出什么问题都影响不到StateServer的数据。 他能在Web Farm和Web Garden环境中使用。缺点： 要进行序列化和反序列化，拖慢速度。 StateServer需要保证正常运行。我在这里停止StateServer的讲述，你将在负载均衡中看到他更多更有趣的点，Web Farm，Web Garden情境下。 参考文献：State Server Session ModeASP.NET Session StateSQL Server Session模式SQL Server模式简介ASP.NET这个Session模式提供给我们了更强的安全性和可靠性，在这个模式下，Session数据被序列化并存储到一个SQL Server的数据库中，这个模式缺点在于Session需要序列化和反序列化的读写方式成为了主要的性能瓶颈，他是Web Farm的最佳选择。设置SQL Server，我们需要这些SQL脚本：安装：InstallSqlState.sql卸载：UninstallSQLState.sql最简单的配置方式是利用aspnet_regsql命令。之前已经解释过了如何配置，这是最有用的状态管理方法在web Farm模式里。我们为何使用SQL Server模式？SQL Server Session模式提供了更安全、更可靠的Session管理。他保证了数据在一个集中式的环境中（数据库）。当我们需要更安全地实现Session时就应该使用SQL Server模式。假如服务器经常需要重启，这是一个完美的解决方案。这是一个完美解决web Farm和web园的方案（这个我将在后面详细解释）。当我们需要在两个应用间共享Session时我们需要使用SQL Server模式。配置SQL Server Session模式在SQL Server模式中，我们的数据保存在SQL Server中，所以我们首先要在web.config里提供数据库连接字符串，sqlConnectionString是被用来做这事的。在连接字符串配置完成后，我们将要配置SQL Server，我将在这里演示如何用aspnet_regsql命令进行数据库配置。第一步：进入命令行，进入到Framework version目录E.g. :c:\windows\microsoft.net\framework\。第二步，带参运行aspnet_regsql命令。下面是参数的使用：ParametersDescription-ssadd增加 SQLServer 模式 session state.-sstype pP 持久化.将这些数据持久化存储于数据库中-S服务器名-U用户名-P密码.运行结束后，你见看到如下的信息：配置结束。第三步：打开SQL Server，查看数据库ASPState库，将有两张表：ASPStateTempApplicationsASPStateTempSessions更改设置中的连接字符串，建立一个像StateServer例子中那样的应用点击Submit时保存Roll Number和用户名，打开数据库，进入ASPStateTempSessions表，这是你保存的Session数据：现在我们再来讨论以下StateServer模式中所讨论的几个问题：1、从StydentInfo类中移除Serialize特性（keyword）2、重启IIS再读取Session数据3、停止SQL Server服务我想这些问题我已经在StateServer解释得很清楚了。（注：第一种将导致无法序列化对象，会抛出异常，第二种无影响，第三种，在关闭数据库服务时会有影响，而重启数据库服务将找回Session内的数据，因为他是持久化储存的。）优缺点优点： Session数据不受IIS重启的影响 最可靠和最安全的Session管理模式 他在本地中心化保存Session数据，能使其他应用方便地进行访问 在Web Farm 和Web Garden情境下非常实用缺点： 和默认模式比较起来，会显得很慢 对象的序列化和反序列化会成为性能瓶颈 因为需要在不同的服务器上访问SQL Server，我们必须保证SQL Server的稳定运行。参考资料：Read more about SQLServer mode自定义Session模式通常情况下，我们使用InProc模式、StateServer模式、SQL Server模式就够了，可是我们还是需要了解一些用户自定义Session模式的相关知识。这是一种相当有趣的Session模式，因为用户的Session全部交由了我们进行控制，甚至Session ID，你都能通过自己写算法来生成Session ID。你能够容易地从基类SessionStateStoreProviderBase开发出自定义的Provider，你也能通过实现ISessionIDManager接口来产生SessionID。下图是自定义方法的处理过程：在Initialize方法中，我们能设置一个自定义Provider。他将提供给Provider初始化连接。SetItemExpireCallback被用作提供SessionTimeOut（Session过期），当Session过期时我们能注册一个方法进行调用。InitializeRequest在请求发起的时候被调用，CreateNewStoreData在创建一个SessionStateStoreData（Session数据存储类）实例时候被调用。我们何时使用自定义Session模式？1、 当我们想将Session数据存储在SQL Server之外的数据库内时。2、 当我们必须使用一个已存在的（特定的）表来存储Session数据的时候。3、 当我们需要使用自定义的SessionID的时候如何配置自定义Session模式？ 我们需要在web.config里进行这样的配置：如果你想了解更多的关于自定义模式的信息，请查阅参考资料。优缺点：优点：1、 我们能使用一个已存在的表（指定的表）来存储Session数据。当我们使用一个之前使用的数据库时，这样做是很有用的。2、 他独立于IIS运行，所以重启服务器对他也没有影响。3、 我们能建立自己的Session ID逻辑来分配Session ID。缺点：1、 处理数据很慢。2、 创建一个自定义的Session状态Provider是一个基础性（low-level）任务，他需要小心处理各种情况以及保证数据安全。我推荐您使用第三方提供的Provider而不是自己写一套Provider。参考资料：Custom Mode生产部署的概述：在实际的生产工作环境中部署我们的应用对于一个Web开发者来说是一个非常重大的挑战。因为在大的生产环境中，有大量的用户数据需要处理，数据量大到一台服务器难以负载这么巨大的数据处理量。这个概念来自于Web Farm，Web Garden，负载均衡的使用。 在几个月前，我部署了一个实际环境：这个环境要处理百万级的用户访问以及超过10个域控制器，通过负载均衡搭载了超过10台服务器和服务数据库。例如交易服务器、LCS服务器。最大的挑战来自于跨多个服务器的Session管理。下图对这个生产环境展示了一个简单的图形：我将试着解释并让您记住各个不同应用场景。应用程序池这是当您在创建一个实际生产环境时最重要的一个东西。应用程序池是用在IIS里用来分隔不同的工作进程的应用程序的，应用程序池能分隔我们的应用程序，使其获得更好的安全性，可靠性和有效性。应用程序池的应用在服务器中当一个进程出现问题，或者被回收时其他进程不受影响。 应用程序池的角色： 应用程序池的配置角色是一个重要的安全措施，在IIS6和IIS7里。因为当应用程序访问资源时他指定了应用程序的身份。在IIS7里，有三种预定义的身份指定方式，这和IIS6是一样的。应用程序池角色描述LocalSystem内建于服务器上管理权限的账户. 他能访问本地和远程资源. 任何服务器的文件或者资源, 我们必须把应用程序的身份设置为LocalSystem.LocalServices内置的本地身份验证. 他不能进行任何网络访问。NetworkServices这是应用程序池的默认身份，NetworkServices是一个经过验证的本地用户账户权限。建立和指定应用程序池 打开IIS管理页面，右键单击应用程序池目录-&新建给应用程序池一个ID，然后点击OK。现在，右键单击一个虚拟目录（我正在使用的StateServer站点）分配StateServerAppPool给StateServer虚拟目录。现在这个StateServer站点运行在了一个指定的独立的应用程序池StateServerAppPool里。其他任何应用都不会影响到这个程序。这是独立应用程序池的主要优点。 Web Garden 默认情况下，每一个应用程序池都运行在一个独立的工作进程里（W3Wp.exe）。我们能分配多个进程给单个应用程序池，一个应用程序池跑多个进程，这样的情况叫做Web Garden（Web园），多个工作进程单个应用程序在很多情况下都能够有更优秀的输出性能和更少的相应时间，每一个工作进程都会有他们自己的线程和内存空间。 如上图所示，在IIS里，将会有多个应用程序池，并且每个应用程序池至少有一个工作进程，而一个Web Garden将有多个工作进程。 在你的应用程序里，使用Web园将必然出现一个限制条件：如果我们使用InProc模式，我们的应用程序将无法正确的工作，因为Session将工作在不同的进程里。为了避免这样的问题，我们将使用进程外（OurProc）的Session模式，我们可以使用State Server或者SQL Server Session模式。 主要优点： 在Web园内的工作进程对每个进程都共享请求，如果一个进程挂了，其他的进程还能正常工作，继续处理请求。如何建立一个Web Garden？右键单击程序池-&Performance（性能？）选项卡-&选择Web Garden（Web园）部分默认情况下他的值为1，现在把他改为一个比1大的数字。如何在Web园内指定Session？我已经解释过InProc模式是在单个工作进程中进行处理，在进程内存储对象，现在，如果我们要处理多个进程，Session处理将会变得很困难，因为每个工作进程独享自己的内存。那么假如第一个请求数据到了WP1并且保存了Session数据，第二个请求到了WP2我将无法正确获得Session的数据，取值的话将会抛出异常。所以，请避免在Web Garden模式下使用InProc模式。我们使用StateServer或者SQLServer模式对这种情况进行处理，之前解释过，这两种模式不依赖于工作进程，在之前的例子里也说过当IIS重启你依然能访问到Session数据。Session模式是否推荐InProcNoStateServerYesSQLServerYesWeb Farm和负载均衡 这是在生产环境中最常见的情形，当你需要在多台服务器上部署你的应用时，使用这种模式的主要原因是我们要将负载均衡到多台服务器上，一个负载均衡器被用于分发负载到多台服务器上。 我们来看上图，客户端通过URL发送请求时先到负载均衡器，然后通过负载均衡器将请求分发给服务器，负载均衡器将在不同的服务器之间进行请求的分发。 现在我们如何处理我们的Session呢？ 在WEB Farm和负载均衡情况下处理Session在Web Farm中处理Session是一个有挑战性的工作。InProc：InProc Session模式，Session数据以对象形式被存储在工作进程中，每个服务器将有他自己的工作进程，并将保持Session数据在内存中。 假如一台服务器down了，那么请求将会访问其他服务器，而其他服务器里是不存在相应Session数据的。所以在Web Farm情形下不推荐使用InProc模式。State Server：之前已经解释过如何使用和配置StateServer模式了，在WebFarm的环境下你将了解他是多么的重要，因为所有Session数据将在一个位置进行存储。 记住，在web Farm环境里，你必须保证你有相同的节在你所有的web服务器上，其他配置和之前描述的一致，所有的web.config文件都要有相同的配置属性(stateConnectionString)在Session State里。SQL Server：这是另一个选择，这也是在Web Farm环境里的最佳选择，我们首先需要配置数据库，接下来的步骤之前已经说过了。如上图所示，所有的web服务器Session数据都将被存储于一个SQL Server数据库。请记住一点，在StateServer模式和SQL Server模式下你都将把对象进行序列化存储。当一台Web服务器挂掉的时候，负载均衡器将把请求分发到其他服务器他将能从数据库里取出Session数据，因为所有Session数据都是存放于数据库里的。总之，我们能用StateServer和SQL Server模式来进行Web Farm的部署，我们需要尽量避免使用InProc模式。Session和Cookie 客户端使用Cookie来配合使用Session，因为客户端需要给每个请求提供合适的Session ID，我们可以使用下列的方法： 使用CookieASP.NET使用了一个特定的Cookie名叫作：ASP.NET_SessionId这是当Session集合被创建的时候自动提供的，这是默认设置，Session ID通过Cookie进行传送。Cookie Munging 当用户向服务器发送一个请求时，服务器解码Session ID并将他加入到每个页面的链接里，当用户点击链接，ASP.NET编码Session ID并传送到用户所请求的页面，现在，请求的页面可以获取Session变量了。这一切都是自动完成的，当ASP.NET发现用户浏览器不支持Cookie时。如何实现Cookie Munging 为了这个，我们必须保证我们的Session State为Cookie-less。移除Session 下面的方法被用来移除Session方法描述Session.Remove(strSessionName)从Session State中移除一个项目Session.RemoveAll()从Session集合中移除所有项目Session.Clear()从Session集合中移除所有项目. Note: Clear和RemoveAll.RemoveAll()没有区别Clear()是内部的.Session.Abandon()取消当前的Session。启用和禁用Session 从性能优化来说，我们可以启用或禁用Session，因为每个页面都进行读写Session会出现一些性能开销，所以，更合适地启用或者禁用Session，而不是使用他的默认配置：always。我们启用和禁用Session可以采取两种方式： 页面级 应用级页面级 我们能禁用Session在页面指令的EnableSessionState属性中 同样的，我们可以让他成为只读的，这将只允许访问Session而禁止写入信息到Session应用级 通过设置web.config的属性EnableSessionState可以让Session在整个应用程序内被禁用， 一般我们都是采用页面级的限制，这样能灵活控制Session的使用。参考文献：How to Disable ASP.NET Session State总结 希望你现在能更熟悉Session了，如何使用Session，以及如何在Web Farm中使用，总结如下：1、 InProc Session Provider是最快的，因为所有数据都存在应用程序的内存里，Session数据在IIS重启，或者站点被回收的情况下丢失，你可以在用户量较小的网站上使用这种模式，但别在Web Farm下使用。2、 State Server模式：Session数据被存储于aspnet_state.exe应用中，他在Web服务之外保存Session数据，所以Web服务出现问题不会对他的Session数据造成影响，在将Session数据存储到StateServer之前需要序列化对象，在Web Farm中我们能安全地使用这个模式。3、 SQL Server模式：他将Session数据保存到SQL Server中，我们需要提供连接串，我们存储时也需要对对象进行序列化，这种模式在实际Web Farm的生产环境中是非常有用的。4、 我们也能使用自定义模式，当我们需要使用一个已经存在的表来存储Session数据时，在自定义模式中，我们也能创建自定义的Session ID，但是不推荐你自己来实现Provider，推荐使用第三方的Provider。希望您能喜欢这篇文章，希望您能给我宝贵建议帮助大家共同提高，再次感谢您的阅读。
阅读本文后您有什么感想? 已有
人给出评价!
访问量多的