asp.net 两种会话数据方式

最新推荐文章于 2022-09-26 17:16:57 发布

躬匠

最新推荐文章于 2022-09-26 17:16:57 发布

阅读量1.8k

点赞数 1

分类专栏： asp.net 文章标签： asp.net 两种会话数据方式

本文链接：https://blog.csdn.net/ydm19891101/article/details/45392017

版权

asp.net 专栏收录该内容

38 篇文章 2 订阅

订阅专栏

什么是会话？

在日常生活中，从拨通电话到挂断电话之间的一连串的你问我答的过程就是一个会话。

会话可简单理解为：用户打开一个浏览器，点击多个超链接，访问服务器多个web资源，然后关闭浏览器，整个过程称之为一个会话。

为何要引入会话?

HTTP 是一种无状态协议。这意味着 Web 服务器会将针对页面的每个 HTTP 请求作为独立的请求进行处理。服务器不会保留以前的请求过程中所使用的变量值的任何信息。

每个用户在使用浏览器与服务器进行会话的过程中，不可避免各自会产生一些数据，。而这些数据又不能保存在request或servletContext中，我们必须采取一定的机制使服务器为每个用户保存这些数据，下面就是保存会话数据的两种技术。

保存会话数据的两种技术：

Cookie
- Cookie是客户端技术，服务器把每个用户的数据以cookie的形式写给用户各自的浏览器。当用户使用浏览器再去访问服务器中的web资源时，就会带着各自的数据去。这样，web资源处理的就是用户各自的数据了。
Session
- Session是服务器端技术，利用这个技术，服务器在运行时可以为每一个用户的浏览器创建一个其独享的session对象，由于session为用户浏览器独享，所以用户在访问服务器的web资源时，可以把各自的数据放在各自的session中，当用户再去访问服务器中的其它web资源时，其它web资源再从用户各自的session中取出数据为用户服务。

上一篇文章已经简单讲解了Cookie的基础知识，在这里就不再累述。在继续讲解Session技术之前，我们先来了解一下Cookie保存会话数据的缺点。

客户端浏览器每次请求Web服务时都需要带上Cookie，这个Cookie的数据量可能会随着浏览器访问Web服务的增多而增加。但是如果传递的状态信息较多，将极大降低网络传输效率和增大服务器端程序处理的难度。这个时候该Session上场了，Session技术作为服务器端技术，有效的避免了Cookie传递数据量小的缺陷。

在客户端浏览器与Web服务器首次建立会话或在某次会话失效重新建立会话时，都会为具体的浏览器分配一个唯一的标识号SessionId以及服务器内存。浏览器与服务器之间就是靠这个唯一的SessionId来保持会话状态，通过浏览器访问产生的数据信息也放在对应的服务器内存中。SessionId是在服务器与浏览器首次建立会话时由服务器写在响应头中的。客户端需要记住此会话标识号，并在后续的每次访问请求中都把这个会话标识号传送给Web服务器，Web服务器端程序依据回传的会话标识号就知道这次请求是哪个客户端发出的。在这里，我们只知道这个SessionId是由服务器写进响应头里的，那具体是响应头的那里呢？

Session可以且通常是借助Cookie来传递会话标识号的。但也可以将应用程序配置为在“无 Cookie”会话的 URL 中存储 SessionID 值。通过在 Web.config 文件的 sessionState 节中将 cookieless 属性设置为 true，可以指定不将会话标识符存储在 Cookie 中。

<configuration>
  <system.web>
    <sessionState cookieless="true"
      regenerateExpiredSessionId="true" />
  </system.web>
</configuration>

ASP.NET 通过自动在页的 URL 中插入唯一的会话 ID 来保持无 Cookie 会话状态。例如，下面的 URL 已被 ASP.NET 修改，以包含唯一的会话 ID lit3py55t21z5v55vlm25s55：

http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx

Session的跟踪机制

1.只有在客户端访问某个能与客户端开启会话的服务器程序时，Web应用程序才会为该客户端分配服务器内存。

2.Web服务器为首次建立会话的浏览器分配一个独一无二的会话标识号，然后在响应消息中将这个会话标识号传递给客户端。客户端需要记住会话标识号，并在后续的每次访问请求中都把这个会话标识号传送给Web服务器，Web服务器端程序依据回传的会话标识号就知道这次请求是哪个客户端发出的，从而到对应的服务器内存中存取数据。

存数据

string firstName = "Jeff";
string lastName = "Smith";
string city = "Seattle";
Session["FirstName"] = firstName;
Session["LastName"] = lastName;
Session["City"] = city;

取数据

string firstName = (string)(Session["First"]);
string lastName = (string)(Session["Last"]);
string city = (string)(Session["City"])

3.只要浏览器与服务器之间的会话没有超出一个限定的空闲时间段，为该浏览器分配的服务器内存就可以被属于同一个会话的各个请求的处理程序共享。

Session的超时管理

Web服务器无法判断当前的客户端浏览器是否还会继续访问，也无法检测客户端浏览器是否关闭，所以，即使客户已经离开或关闭了浏览器，Web服务器还要保留为之分配的内存。

随着时间的推移而不断增加新的访问客户端，Web服务器内存中将会因此积累起大量的不再被使用的内存，并将最终导致服务器内存耗尽。

Web服务器采用“超时限制”的办法来判断客户端是否还在继续访问，如果某个客户端在一定的时间之内没有发出后续请求，Web服务器则认为客户端已经停止了活动，结束与该客户端的会话并将回收为它分配的内存。

如果客户端浏览器超时后再次发出访问请求，Web服务器则认为这是一个新的会话的开始，将为之分配新的内存和分配新的会话标识号。

Session的安全性

会话标识号无论是作为 Cookie 还是作为 URL 的一部分，System.Web.SessionState.HttpSessionState.SessionID 值都以明文的形式发送。恶意用户通过获取 SessionID 值并将其包含在对服务器的请求中，可以访问另一位用户的会话。如果您将敏感信息存储在会话状态中，这将变得很不安全，建议使用 SSL 来加密浏览器和服务器之间包含 SessionID 值的任何通信

Session的简单应用

判断用户登陆状态

 protected void Page_Load(object sender, EventArgs e)
        {
            if (Session["UserName"] == null)
            {
                Response.Redirect("Login.aspx");
            }
            else
            {
                Response.Write("欢迎您，"+Session["UserName"]);
                Response.Redirect("Admin.aspx");
            }
        }

Session的应用不止上面的一种，在这里不再讲述。

参考文献：https://msdn.microsoft.com/zh-cn/library/ms178582(v=vs.80).aspx

https://msdn.microsoft.com/zh-cn/library/ms178201(v=vs.80).aspxa