Asp.Net Session学习总结

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

https://www.cnblogs.com/ideacore/p/6423281.html

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

最近这两天被一个Web Farm环境下的Session处理问题虐得很痛苦，这是一个ASP.NETSession基础知识的一个合集，有的地方感觉是有重复，比较啰嗦，我基本上按照原文将他翻译出来了，小弟程序水平不高，英语水平更差（09年高考英语65分，满分150），自我感觉Session基础内容是讲清楚了，我粗浅的理解下，没有发现有什么错误了，文章较浅，请各位发现有什么不对的地方告诉我，我一定尽快处理，这篇文章很适合初学者看，作者说的很清楚，能把ASP.NET下Session的玩法看得较为清晰。另外我会在我另一篇博文中将我所遇到的问题以及解决办法和大家共享。原文地址：http://www.codeproject.com/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（状态服务）模式和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模式中所讨论的几个问题：

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

2、重启IIS再读取Session数据

3、停止SQL Server服务

我想这些问题我已经在StateServer解释得很清楚了。

（注：第一种将导致无法序列化对象，会抛出异常，第二种无影响，第三种，在关闭数据库服务时会有影响，而重启数据库服务将找回Session内的数据，因为他是持久化储存的。）

优缺点

优点：

Session数据不受IIS重启的影响

最可靠和最安全的Session管理模式

他在本地中心化保存Session数据，能使其他应用方便地进行访问

在Web Farm 和Web Garden情境下非常实用

缺点：

和默认模式比较起来，会显得很慢

对象的序列化和反序列化会成为性能瓶颈

因为需要在不同的服务器上访问SQL Server，我们必须保证SQL Server的稳定运行。

参考资料：

ASP.NET Session 简单超实用使用总结

https://www.cnblogs.com/yinrq/p/5032493.html

一、概述
Session用于存储特定的用户会话所需的信息。 Session对象的引入是为了弥补HTTP协议的不足，HTTP协议是一种无状态的协议。

Session中文是“会话”的意思，在ASP.NET中代表了服务器与客户端之间的“会话”。Session的作用时间从用户到达某个特定的Web页开始，到该用户离开Web站点，或在程序中利用代码终止某个Session结束。引用Session 则可以让一个用户访问多个页面之间的切换也会保留该用户的信息。

系统为每个访问者都设立一个独立的Session对象，用以存储Session变量，并且各个访问者的Session对象互不干扰。

Session与Cookie是紧密相关的。 Session的使用要求用户浏览器必须支持Cookie，如果浏览器不支持使用Cookie，或者设置为禁用Cookie，那么将不能使用Session。
Session信息对客户来说，不同的用户用不同的Session信息来记录。当用户启用Session时，ASP自动产生一个SessionID.在新会话开始时，服务器将SessionID当做cookie存储在用户的浏览器中。

二、Session数据存放的位置和形式
web.config 配置节点语法：

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

mode:设置将Session信息存储到哪里

Off：不使用Session功能；

InProc :将Session存储在IIS进程内，这是默认值,也最常用（优点是简单，性能最高。但是当重启IIS服务器时Session丢失。）；

StateServer ：将Session存储在ASP.NET状态服务进程中（重新启动Web应用程序时保留会话状态，并使会话状态可以用于网络中的多个Web服务器。）；

SQLServer ：将Session存储在SQL Server中（存储在内存和磁盘中，服务器挂掉重启后都还在）。

cookieless：设置客户端的Session信息存储到哪里

ture 使用Cookieless模式；这时客户端的Session信息就不再使用Cookie存储了，而是将其通过URL存储。

false 使用Cookie模式，这是默认值。

timeout 设置经过多少分钟后服务器自动放弃Session信息。默认为20分钟。

stateConnectionString 设置将Session信息存储在状态服务中时使用的服务器名称和端口号，例如："tcpip=127.0.0.1:42424”。当mode的值是StateServer是，这个属性是必需的。（默认端口42424）。

sqlConnectionString 设置与SQL Server连接时的连接字符串。例如"data source=localhost;Integrated Security=SSPI;Initial Catalog=joye"。当mode的值是SQLServer时，这个属性是必需的。

stateNetworkTimeout 设置当使用StateServer模式存储Session状态时，经过多少秒空闲后，断开Web服务器与存储状态信息的服务器的TCP/IP连接的。默认值是10秒钟。

三、Session的curd操作
代码：

//写入
Session["UserName"] = "joye888";

//读取
var userName = Session["UserName"].ToString();
Response.Write(userName);

//遍历
IEnumerator sessionEnum = Session.Keys.GetEnumerator();
while (sessionEnum.MoveNext())
{
Response.Write(Session[sessionEnum.Current.ToString()].ToString() + " ");
}

//销毁
Session.Abandon(); //结束会话
Session.Clear();//不结束会话

四、Session运行原理图解

五、Session实际案例-在线购物车和Session配合验证码使用
代码省略。

六、Session和Cookie的区别
1、cookie存客户端，session存服务端。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
========

ASP.NET 状态服务及 session丢失问题解决方案总结

https://blog.csdn.net/qq_28960147/article/details/80964532

ASP.NET 状态服务及 session丢失问题解决方案总结
最近在开发一ASP.NET2.0系统时，在程序中做删除或创建文件操作时，出现session丢失问题。在网上搜了不少资料，最后终于解决了，采用了如下方法：
1、asp.net Session的实现：
asp.net的Session是基于HttpModule技术做的，HttpModule可以在请求被处理之前，对请求进行状态控制，由于Session本身就是用来做状态维护的，因此用HttpModule做Session是再合适不过了。
ASP.NET中Session的状态保持方式
ASP.NET提供了Session对象，从而允许程序员识别、存储和处理同一个浏览器对象对服务器上某个特定网络应用程序的若干次请求的上下文信息。Session对应浏览器与服务器的同一次对话，在浏览器第一请求网络应用程序的某个页面时，服务器会触发Session_onStart事件；在对话超时或者被关闭的时候会触发Session_onEnd 事件。程序员可以在代码中响应这两个事件来处理与同一次对话相关的任务，如开辟和释放该次对话要使用的资源等。
在ASP.NET的程序中要使用Session对象时，必须确保页面的@page指令中EnableSessionState属性是True或者Readonly，并且在web.config文件中正确的设置了SessionState属性。
ASP.NET中Session的状态保持是由web.config文件中的<system.web>标记下的<sessionstate>标记的mode属性来决定的。该属性有四种可能的值：Off、Inproc、StateServer和SQlServer.
设为Off会禁用Session.
Inproc是缺省的设置,这种模式和以前的ASP的会话状态的方法是类似的,会话的状态会被保存在ASP.NET进程中，它的优点是显而易见的：性能。进程内的数据访问自然会比夸进程的访问快。然而，这种方法Session的状态依赖于ASP.NET进程，当IIS进程崩溃或者正常重起启时，保存在进程中的状态将丢失。
为了克服Inproc模式的缺点，ASP.NET提供了两种进程外保持会话状态的方法。
ASP.NET首先提供了提供了一个Windows服务：ASPState,这个服务启动后，ASP.NET应用程序可以将mode属性设置为“SateServer”,来使用这个Windows服务提供的状态管理方法。
除了在web.config文件中设置mode属性为StateServer外，还必须设置运行StateServer服务器的IP地址和端口号.如果在IIS所在的机器运行StateServer则IP地址就是127.0.0.1,端口号通常是42424.配置如下：
mode=”StateServer”
stateConnectionString="tcpip=127.0.0.1:42424"
使用这种模式,会话状态的存储将不依赖IIS进程的失败或者重启,会话的状态将存储在StateServer进程的内存空间中。
另一种会话状态模式是SQLServer模式。这种模式是将会话的状态保存在SQL Server数据库中的。使用这种模式前，必须至少有一台SQL Server服务器，并在服务器中建立需要的表和存储过程。.NET SDK提供了两个脚本来简化这个工作：InstallSqlState.sql和UnInstallSqlState.sql。这两国文件存放在下面路径中：
<%SYSTEMDRIVER%>/Winnt/Microsoft.NET/Framework/<%version%>/
要配置SQL Server 服务器，可以在命令行中运行SQL Server提供的命令行工具osql.exe
osql -s [server name] -u [user] -p [password] <InstallSqlState.sql
例如：
osql -s (local) -u as -p “”-i InstallSqlState.sql
做好必要的数据库准备工作后，将web.config文件中的sessionstate元素的mode属性改为”sqlserver”,并指定SQL连接字符串。具体如下：
mode="SQLServer"
sqlConnectionString="data source=127.0.0.1;userid=sa;password=;Trusted_Connection=yes"
使用SQLServer模式处了可以使Session的状态不依赖于IIS服务器之外，还可以利用SQL Server的集群，使状态存储不依赖于单个的SQL Server,这样就可以为应用程序提供极大的可靠性。

2、丢失原因：
转（1）：Asp.net 默认配置下，Session莫名丢失的原因及解决办法
正常操作情况下Session会无故丢失。因为程序是在不停的被操作，排除Session超时的可能。另外，Session超时时间被设定成60分钟，不会这么快就超时的。
这次到CSDN上搜了一下帖子，发现好多人在讨论这个问题，然后我又google了一下，发现微软网站上也有类似的内容。
现在我就把原因和解决办法写出来。
原因：
由于Asp.net程序是默认配置，所以Web.Config文件中关于Session的设定如下：
<sessionState
mode='InProc'
stateConnectionString='tcpip=127.0.0.1:42424'
sqlConnectionString='data source=127.0.0.1;Trusted_Connection=yes'
cookieless='true'
timeout='60'/>

我们会发现sessionState标签中有个属性mode，它可以有3种取值：InProc、StateServer?SQLServer（大小写敏感）。默认情况下是InProc，也就是将Session保存在进程内（IIS5是aspnet_wp.exe，而IIS6是W3wp.exe），这个进程不稳定，在某些事件发生时，进程会重起，所以造成了存储在该进程内的Session丢失。
[asp的Session是具有进程依赖性的。ASP Session状态存于IIS的进程中，也就是inetinfo.exe这个程序。所以当inetinfo.exe进程崩溃时，这些信息也就丢失。]

哪些情况下该进程会重起呢？微软的一篇文章告诉了我们：
1、配置文件中processModel标签的memoryLimit属性
2、Global.asax或者Web.config文件被更改
3、Bin文件夹中的Web程序（DLL）被修改
4、杀毒软件扫描了一些.config文件。
更多的信息请参考PRB: Session variables are lost intermittently in ASP.NET applications
解决办法：
前面说到的sessionState标签中mode属性可以有三个取值，除了InProc之外，还可以为StateServer、SQLServer。这两种存Session的方法都是进程外的，所以当aspnet_wp.exe重起的时候，不会影响到Session。

现在请将mode设定为StateServer。StateServer是本机的一个服务，可以在系统服务里看到服务名为ASP.NET State Service的服务，默认情况是不启动的。当我们设定mode为StateServer之后，请手工将该服务启动。这样，我们就能利用本机的StateService来存储Session了，除非电脑重启或者StateService崩掉，否则Session是不会丢的（因Session超时被丢弃是正常的）。
除此之外，我们还可以将Session通过其他电脑的StateService来保存[如使用状态服务器]。具体的修改是这样的。同样还在sessionState标签中，有个stateConnectionString='tcpip=127.0.0.1:42424'属性，其中有个ip地址，默认为本机（127.0.0.1），你可以将其改成你所知的运行了StateService服务的电脑IP，这样就可以实现位于不同电脑上的Asp.net程序互通Session了。

如果你有更高的要求，需要在服务期重启时Session也不丢失，可以考虑将mode设定成SQLServer，同样需要修改sqlConnectionString属性。关于使用SQLServer保存Session的操作，请访问这里。
在使用StateServer或者SQLServer存储Session时，所有需要保存到Session的对象除了基本数据类型（默认的数据类型，如int、string等）外，都必须序列化。只需将[Serializable]标签放到要序列化的类前就可以了。
如：
[Serializable]
public class MyClass
{
......
}
具体的序列化相关的知识请参这里。
至此，问题解决。

参考文章：
ASP.NET Session State FAQ
ASP.NET Session State
[ASP.NET] Session 详解
PRB: Session Data Is Lost When You Use ASP.NET InProc Session State Mode
PRB: Session Data Is Lost When You Use ASP.NET InProc Session State Mode
ASP.NET HTTP 运行时
.NET 中的对象序列化
备注
（1）使用 StateServer 模式
确保运行 ASP.NET 状态服务的服务器是要存储会话状态信息的远程服务器。该服务与 ASP.NET 一起安装，其默认位置为
<驱动器>:/systemroot/Microsoft.NET/Framework/version/aspnet_state.exe。
在应用程序的 Web.config 文件中，
设置 mode=StateServer 并设置 stateConnectionString 属性。
例如，stateConnectionString="tcpip=sarath:42424"。
（2）使用 SQLServer 模式
在运行 SQL Server 的计算机（它将存储会话状态）上运行 InstallSqlState.sql
（默认的安装位置为 <驱动器>:/systemroot/Microsoft.NET/Framework/version）。
这将创建一个名为 ASPState 的数据库，该数据库具有新的存储过程并且在 TempDB 数据库中具有 ASPStateTempApplications 表和 ASPStateTempSessions 表。
在应用程序的 Web.config 文件中，设置 mode=SQLServer 并设置 sqlConnectionString 属性。例如，sqlConnectionString="data source=localhost;Integrated Security=SSPI;Initial Catalog=northwind"。
（3）示例
以下示例指定若干会话状态配置设置。

<configuration>
<system.web>
<sessionState mode="InProc"
cookieless="true"
timeout="20"/>
</sessionState>
</system.web>
</configuration>
要求
包含于：<system.web>
Web 平台：IIS 5.0、IIS 5.1、IIS 6.0
配置文件：Machine.config、Web.config
配置节处理程序：System.Web.SessionState.SessionStateSectionHandler
请参见

ASP.NET 配置 | ASP.NET 设置架构 | SessionStateModule
作者：来源： (责任编辑:webjx)--- -------------收集之二---------------------------------
[出现原因：]在Windows2003的服务器中的IIS6加入了应用程序池来回收一些无用的进程的功能，当由于网站程序的错误或访问量太多的导致的应用程序池会自动回收该进程，防止网站进入“死机”状态，而这时候的应用程序池的回收就会导致session变量被清除，就出现了session变量不见的现象。
为了解决这种在Windows2003下才出现的问题，我们在服务端起动ASP.NET State Service服务，并且在系统的machine.config做了一些改动。现在默认的情况下会话状态mode是StateServer。如果您的网站根目录下也配有一个web.config配置文件，请把mode="InProc"改成mode="StateServer"，如下代码，就可以防止session变量的丢失：
<sessionState
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI"
cookieless="false"
timeout="30"
/>
+ 注：只适用于支持asp.net的用户。

转（2）：原因及一些解决之道
将Session保存在State Server里：
1.启动服务“ASP.NET State Service”，
2.然后，修改web.config:
<sessionState
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="140000"
/>
注意://mode="StateServer"这种模式下即使修改页面也不会丢失session!
当然:mode="InProc"如果你的模式为这种,修改页面的时候会丢失session!!!!!!

在WebConfig里将Session的Mode设成SQLServer或者StateServer都不会丢Session的，
前者需要写入数据库，后者需要系统开StateServer服务。

原因1：
bin目录中的文件被改写，asp.net有一种机制，为了保证dll重新编译之后，系统正常运行，它会重新启动一次网站进程，这时就会导致Session丢失，所以如果有access数据库位于bin目录，或者有其他文件被系统改写，就会导致Session丢失。[目录的删除操作一定丢失session。asp.net的内部机制对待目录有点像个守财奴，它死守着目录，你创建它不会管（往里加），一但创建他就会监视该目录，若你要删除或重命名它的（动它的目录），它就发生重起了。。]
原因2：
文件夹选项中，如果没有打开“在单独的进程中打开文件夹窗口”，一旦新建一个窗口，系统可能认为是新的Session会话，而无法访问原来的Session，所以需要打开该选项，否则会导致Session丢失
原因3：
似乎大部分的Session丢失是客户端引起的，所以要从客户端下手，看看cookie有没有打开
原因4：
Session的时间设置是不是有问题，会不会因为超时造成丢失。
[默认时间是20分钟，可以在Web.Config中设置Session的timeOut，如改为60分钟等]
原因5：
IE中的cookie数量限制（每个域20个cookie）可能导致session丢失
原因6：
使用web garden模式，且使用了InProc mode作为保存session的方式
解决丢失的经验
1. 判断是不是原因1造成的，可以在每次刷新页面的时候，跟踪bin中某个文件的修改时间。
2. 做Session读写日志，每次读写Session都要记录下来，并且要记录SessionID、Session值、所在页面、当前函数、函数中的第几次Session操作，这样找丢失的原因会方便很多
3. 如果允许的话，建议使用state server或sql server保存session，这样不容易丢失
4. 在global.asa中加入代码记录Session的创建时间和结束时间，超时造成的Session丢失是可以在SessionEnd中记录下来的。
5. 如果有些代码中使用客户端脚本，如javascript维护Session状态，就要尝试调试脚本，是不是因为脚本错误引起Session丢失。

转（3）：Session丢失原因与解决方案小结
可能的原因1：
win2003 server下的IIS6默认设置下对每个运行在默认应用池中的工作者进程都会经过20多个小时后自动回收该进程，造成保存在该进程中的session丢失。

因为Session,Application等数据默认保存在运行该Web应用程序的工作者进程中,如果回收工作者进程，则会造成丢失。

解决办法：
修改配置，设置为不定时自动回收该工作者进程，比如设置为当超出占用现有物理内存60％后自动回收该进程。通过使用默认应用程序池，可以确保多个应用程序间互相隔离，保证由于一个应用程序的崩溃不会影响另外的Web应用程序。还可以使一个独立的应用程序运行在一个指定的用户帐号特权之下。如果使用StateServer方式或者Sql Server数据库方式来保存Session,则不受该设置的影响。

可能的原因2：
系统要运行在负载平衡的 Web 场环境中，而系统配置文件web.config中的Session状态却设置为InProc（即在本地存储会话状态），导至在用户访问量大时，Session常经超时的情况。引起这个现象的原因主要是因为用户通过负载平衡IP来访问WEB应用系统，某段时候在某台服务器保存了Session的会话状态，但在其它的WEB前端服务器中却没有保存Session的会话状态，而随着并发量的增大，负载平衡会当作路由随时访问空闲的服务器，结果空闲的服务器并没有之前保存的Session会话状态。

解决办法：
1.当您在负载平衡的 Web 场环境中运行 ASP.NET Web 应用程序时，一定要使用 SqlServer 或 StateServer 会话状态模式，在项目中我们基于性能考虑并没有选择SqlServer模式来存储Session状态，而是选择一台SessionStateServer 服务器来用户的Session会话状态。我们要在系统配置文件web.config中设置如下：
<sessionState
mode="StateServer" cookieless="false" timeout="240"
stateConnectionString="tcpip=192.168.0.1:42424" stateNetworkTimeout="14400" />
还要添加一项
<machineKey
validationKey="78AE3850338BFADCE59D8DDF58C9E4518E7510149C46142D7AAD7F1AD49D95D4" decryptionKey="5FC88DFC24EA123C" validation="SHA1"/>

2. 我们同时还要在SessionStateServer 服务器中启动ASP.NET State Service服务，具体设置：控制面板>>管理工具>>服务>>ASP.NET State Service，把它设为自动启动即可。

3. 每台前端WEB服务的Microsoft“Internet 信息服务”(IIS)设置
要在 Web 场中的不同 Web 服务器间维护会话状态，Microsoft“Internet 信息服务”(IIS) 配置数据库中 Web 站点的应用程序路径（例如，/LM/W3SVC/2）与 Web 场中所有 Web 服务器必须相同。大小写也必须相同，因为应用程序路径是区分大小写的。在一台 Web 服务器上，承载 ASP.NET应用程序的 Web 站点的实例 ID 可能是 2（其中应用程序路径是 /LM/W3SVC/2）。在另一台 Web 服务器上，Web 站点的实例 ID 可能是 3（其中应用程序路径是 /LM/W3SVC/3）。因此，Web 场中的 Web 服务器之间的应用程序路径是不同的。我们必须使Web 场Web 站点的实例 ID 相同即可。你可以在IIS中把某一个WEB配置信息保存为一个文件，其他Web 服务器的IIS配置可以来自这一个文件。您如果想知道具体的设置请访问Microsoft Support网站：

转(4)：丢失问题集锦
SessionState 的Timeout)，其主要原因有三种。
一：有些杀病毒软件会去扫描您的Web.Config文件，那时Session肯定掉，这是微软的说法。
二:程序内部里有让Session掉失的代码，及服务器内存不足产生的。
三：程序有框架页面和跨域情况。
第一种解决办法是:使杀病毒软件屏蔽扫描Web.Config文件(程序运行时自己也不要去编辑它)
第二种是检查代码有无Session.Abandon()之类的。
第三种是在Window服务中将ASP.NET State Service 启动。
http://community.csdn.net/Expert/topic/3100/3100218.xml?temp=.4426386
还有可能就是你在测试期间改动了，网站的文件。

下面是帮助中的内容:
(ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.2052/cpguide/html/cpconsessionstate.htm)
ASP.NET 提供一个简单、易于使用的会话状态模型，您可以使用该模型跨多个 Web 请求存储任意数据和对象。
它使用基于字典的、内存中的对象引用（这些对象引用存在于 IIS 进程中）缓存来完成该操作。
使用进程内会话状态模式时请考虑下面的限制：
使用进程内会话状态模式时，如果 aspnet_wp.exe 或应用程序域重新启动，则会话状态数据将丢失。这些重新启动通常会在下面的情况中发生：
（1）在应用程序的 Web.config 文件的 <processModel> 元素中，设置一个导致新进程在条件被满足时启动的属性，例如 memoryLimit。
（2）修改 Global.asax 或 Web.config 文件。
（3）更改到 Web 应用程序的 /Bin 目录。
（4）用杀毒软件扫描并修改 Global.asax 文件、Web.config 文件或 Web 应用程序的 /Bin 目录下的文件。
（5）如果在应用程序的 Web.config 文件的 <processModel> 元素中启用了网络园模式，请不要使用进程内会话状态模式。否则将发生随机数据丢失。

我也碰到过。本机器上的Session或者Cookie丢失。
<sessionState
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="40"
/>
mode=""的三个属性。本地/其他机器/sqlserver。
很多网络架构，各个服务器之间都是通过一台专门保存状态的服务器（专门的状态服务器）来保存比如说session,cookie..

我以前遇到这种问题，我用了以下几个方法来解决。现在也没有这种情况发生了。
１、release，不要debug发布。
２、<sessionState cookieless="true" 把cookieless设为true。因为客户端禁用cookie时，session也无效。
３、在IIS中把Session过期时间延长。
４、让杀毒软件不扫描bin文件夹下的文件和Web.Config文件。
以上我是不明不白的做的。不过Session正常使用了！呵呵~~我幸运!

没啥好讲的，不要用Session好了，直接用Forms认证把，
我前两天的系统就是用这个搞定的，觉得挺好的。
刚碰到一个类似的问题：在使用frameset的时候，session变量丢失。
在微软的网站上找到了解决的方法
http://support.microsoft.com/kb/323752/EN-US/
不知道是否有用？

IIS--->>应用程序连接池--->>属性---->>[回收][性能][运行状况]里的各项参数尽量都往大的改^_^),我不知道改拉那个才对的,反正我改完后所有的session都好拉.客户的网站和动网论坛的后台也跟着好拉。

转(5): 模态窗口中打开新窗口的session丢失
一直被这个问题郁闷。在窗口A中使用showModalDialog()打开了一个新的模态窗口B。然后在B窗口中进行一些业务操作，最后还需要根据业务操作打印一些表单，结果此时在B中调用open()方法就会出现session丢失的现象，提示用户重新登陆。
两天来一直没头苍蝇一样不停的试验各种方法。如果在这个窗口中采用打开非模态对话框的打开方法showModelessDialog()就没有任何问题，但是直接使用open()方法就是不能达到想要的效果。在网上不停的google，到各大bbs寻找解答，提供的都是最简单的应用。好不容易找到一篇文章，其中提到session对象的有效范围，却也没有具体提到我遇到的问题：
IE中: 
有效的窗品包括
1.Session对象只在建立Session对象的窗口中有效。
2.在建立Session对象的窗口中新开链接的窗口 
无效的窗口包括
1.直接启动IE浏览器的窗口
2.不是在建立Session对象的窗口中新开链接的窗口。（即作者在建立Session对象的A窗口弹出的B窗口上调用了open()方法。）
考虑只在建立session对象的窗口中有效，于是就在子窗口中重新使用session.setAttribute()方法，以为如此就可以成功，结果还是不行，郁闷。
早上起来突然来了灵感，既然子窗口中造成了session丢失，在父窗口中是无论如何还存在着session的变量的，我可以不必在子窗口中重新设置session变量，而可以直接调用父窗口的javascript函数open()方法可能会到目的吧。不管如何先试试，结果果然如此。 很多时候问题就是这样的，想要偷懒，于是不自己钻研，到处寻求解答，最后还是得靠自己来搞定。
========

ASP.NET一般处理程序访问Session问题

https://www.cnblogs.com/yunfeifei/p/3674832.html

我们在使用一般处理程序的时候，访问Session会出现如下错误：

解决方案如下：

//引用命名空间
using System.Web.SessionState;

//继承IRequiresSessionState接口，拥有Session的读写权限
//继承IReadOnlySessionState接口，拥有Session的只读权限
public class Handler1 : IHttpHandler,IRequiresSessionState
{

public void ProcessRequest(HttpContext context)
{
context.Response.ContentType = "text/plain";
context.Response.Write("Hello World");
}

public bool IsReusable
{
get
{
return false;
}
}
}
========