ASP.NET中的Session怎么正确使用

Session对象用于存储从一个用户开始访问某个特定的aspx的页面起，到用户离开为止，特定的用户会话所须要的信息。用户在应用程序的页面切换时，Session对象的变量不会被清除。 
对于一个Web应用程序而言，全部用户访问到的Application对象的内容是彻底同样的；而不一样用户会话访问到的Session对象的内容则各不相同。 Session能够保存变量，该变量只能供一个用户使用，也就是说，每个网页浏览者都有本身的Session对象变量，即Session对象具备惟一性。 

什么是Session

Web是无状态的，他提供了一种新的方式：每次都经过用户对服务器提交请求而渲染新的网页。众所周知，HTTP是一种无状态协议，他不能经过页面和客户端保持链接。若是用户须要增长一些信息和跳转到了另外的页面，原有的数据将会丢失，用户将没法恢复这些信息。咱们须要这玩意儿干吗呢？咱们须要保存信息！Session提供了一个在服务器端保存信息的方案。他能支持任何类型对象和用户对象信息做为对象保存起来。Session为每个客户端都独立地保存，这意味着Session数据存储着每一个客户端的基础信息。请看下图：

每个客户端都有一份独立的Session

用Session进行状态管理是ASP.NET最好的特性之一，由于它是安全的，对于客户端是透明的，而且他能存储任何类型的对象。而在这些优势以外，有时Session会致使一些对性能要求较高的网站的性能问题。由于他消耗服务器的内存存储用户访问网站所需的数据，如今让咱们来看一看Session对于您Web 应用的利弊。

Session的利弊

接下来咱们讨论普通状况下使用Session的利弊，我会描述每一种Session的使用情境。

优势：

他能在整个应用中帮助维护用户状态和数据。

他能让咱们简单地实现存储任何类型的对象。

独立地保存客户端数据。

对于用户来讲，Session是安全的、透明的。

缺点：

由于Session使用的是服务器的内存，因此在用户量大的时候会成为性能瓶颈。

在序列化和反序列化的过程当中他也会成为性能瓶颈，由于在StateServer（状态服务）模式和sql server模式下咱们须要对咱们存储的数据进行序列化和反序列化咱们所存储的数据。

除此以外，Session的各类模式都有其利弊。接下来咱们将讨论各类Session模式。

对Session进行读/写

读/写Session是很是简单的，就像使用ViewState同样，咱们能使用System.Web.SessionState.HttpSessionState这个类来与Session进行交互，这个类在ASP.NET页面内内建（提供）了Session。下面的代码就是使用Session进行存储的例子：

//Storing UserName in Session

Session["UserName"] = txtUser.Text;

接下来让咱们来看如何从Session读取数据：

//Check weather session variable null or not
if (Session["UserName"] != null)
{
    //Retrieving UserName from Session
    lblWelcome.Text = "Welcome : " + Session["UserName"];
}
else
{
 //Do Something else
}

咱们也能存储其余对象，下面的例子展现了如何存储一个DataSet到Session里

//Storing dataset on Session
Session["DataSet"] = _objDataSet;

下面的代码展现了如何从Session内读取DataSet

//Check weather session variable null or not
if (Session["DataSet"] != null)
{
    //Retrieving UserName from Session
    DataSet _MyDs = (DataSet)Session["DataSet"];
}
else
{
    //Do Something else
}

参考文献：

MSDN (read the session variable section)

Session ID

ASP.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 MSDN

Session模式和Session Provider

在ASP.NET中，有如下几种Session模式可使用

InProc

StateServer

SQLServer

Custom

每一种Session State都有一种Session Provider。如下的图形将展现他们的关系：

Session state体系图

咱们能在这些基础的Session State Provider中进行选择。当ASP.NET接收到带有Session ID的信息请求时Session State和他相应的Provider负责提供和存储对应的信息。下面的表展现了Session 模式以及Provider的名称：

Session State模式	State Provider
InProc	In-memory object（内置对象）
StateServer	Aspnet_state.exe
SQLServer	SQL Server Database
Custom	Custom provider

除此以外，还有另外一个模式：“OFF”，若是咱们选择这个选项，Session将不能为这个应用提供服务。可是咱们的目标是使用Session，因此咱们将讨论上面四种的Session模式。

Session States

Session 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_Start

Session_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 Events

Session 模式

咱们已经讨论过Session模式，接下来讲说这些模式的不一样：

Off

InProc

StateServer

SQLServer

Custom

若是咱们在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 = intRoll;
        this.Name = strName;
    }
 
    private int intRoll;
    private string strName;
    public int Roll
    {
        get
        {
            return intRoll;
        }
        set
        {
            intRoll = value;
        }
    }
 
    public string Name
    {
        get
        {
            return strName;
        }
        set
        {
            strName = value;
        }
    }
}

如今来看后端代码，我增长了两个Button：一个是保存Session，另外一个是获取Session：

protected void btnSubmit_Click(object sender, EventArgs e)
{
    StudentInfo _objStudentInfo = 
      new StudentInfo(Int32.Parse( txtRoll.Text) ,txtUserName.Text);
    Session["objStudentInfo"] = _objStudentInfo;
    ResetField();
}
protected void btnRestore_Click(object sender, EventArgs e)
{
    StudentInfo _objStudentInfo = (StudentInfo) Session["objStudentInfo"];
    txtRoll.Text = _objStudentInfo.Roll.ToString();
    txtUserName.Text = _objStudentInfo.Name;
}

步骤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 Mode

ASP.NET Session State

SQL 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命令。

下面是参数的使用：

Parameters	Description
-ssadd	增长 SQLServer 模式 session state.
-sstype p	P 持久化.将这些数据持久化存储于数据库中
-S	服务器名
-U	用户名
-P	密码.

运行结束后，你见看到以下的信息：

配置结束。

第三步：

打开SQL Server，查看数据库ASPState库，将有两张表：

ASPStateTempApplications

ASPStateTempSessions

更改设置中的链接字符串，创建一个像StateServer例子中那样的应用

点击Submit时保存Roll Number和用户名，打开数据库，进入ASPStateTempSessions表，这是你保存的Session数据：

如今咱们再来讨论如下StateServer模式中所讨论的几个问题：

一、从StydentInfo类中移除Serialize特性（keyword）

二、重启IIS再读取Session数据

三、中止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模式？

一、 当咱们想将Session数据存储在SQL Server以外的数据库内时。

二、 当咱们必须使用一个已存在的（特定的）表来存储Session数据的时候。

三、 当咱们须要使用自定义的SessionID的时候

如何配置自定义Session模式？

咱们须要在web.config里进行这样的配置：

若是你想了解更多的关于自定义模式的信息，请查阅参考资料。

优缺点：

优势：

一、 咱们能使用一个已存在的表（指定的表）来存储Session数据。当咱们使用一个以前使用的数据库时，这样作是颇有用的。

二、 他独立于IIS运行，因此重启服务器对他也没有影响。

三、 咱们能创建本身的Session ID逻辑来分配Session ID。

缺点：

一、 处理数据很慢。

二、 建立一个自定义的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模式	是否推荐
InProc	No
StateServer	Yes
SQLServer	Yes

Web 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，咱们可使用下列的方法：

使用Cookie

ASP.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中使用，总结以下：

一、 InProc Session Provider是最快的，由于全部数据都存在应用程序的内存里，Session数据在IIS重启，或者站点被回收的状况下丢失，你能够在用户量较小的网站上使用这种模式，但别在Web Farm下使用。

二、 State Server模式：Session数据被存储于aspnet_state.exe应用中，他在Web服务以外保存Session数据，因此Web服务出现问题不会对他的Session数据形成影响，在将Session数据存储到StateServer以前须要序列化对象，在Web Farm中咱们能安全地使用这个模式。

三、 SQL Server模式：他将Session数据保存到SQL Server中，咱们须要提供链接串，咱们存储时也须要对对象进行序列化，这种模式在实际Web Farm的生产环境中是很是有用的。

四、 咱们也能使用自定义模式，当咱们须要使用一个已经存在的表来存储Session数据时，在自定义模式中，咱们也能建立自定义的Session ID，可是不推荐你本身来实现Provider，推荐使用第三方的Provider。

但愿您能喜欢这篇文章，但愿您能给我宝贵建议帮助你们共同提升，再次感谢您的阅读。

 

注释：转载 http://www.cr173.com/html/24780_1.html