会话状态Session解析以及原理分析

我们知道web网站在客户端存储数据有三种形式:1. Cookie   2. hidden(隐藏域) 3.QueryString 其中viewstate什么的都是通过第二种方式隐藏域存储滴。

客户端存储数据有三种形式,那服务器端有几种呢? 嘿嘿 服务器端有:1. Session 2. Application 3. database 4. caching(缓存) 其中session用的较多,当然数据库是必须的。

开发过管理系统项目(不限大小)的童鞋应该都接触过session,在管理系统中session最典型的应用就是当用户登录后在服务器端记录客户的唯一标示(比如用户名),然后再另外的页面中使用这个信息,当然也能判断用户是否登录后进入的系统,防止没有授权直接进入系统。

先看一下怎么使用session吧

//添加一个名为sessionTest的Session并且给他赋值
        Session["sessionTest"] = "test";
           //读取Session名为sessionTest的值
        Response.Write(Session["sessionTest"].ToString());
      1. 很简单吧!除了人为的创建session,还有就是当客户端浏览器访问一个站点的时候,服务端会自动创建一个session来存储客户端的信息,那么问题来了服务端不可能就一个客户端访问吧!会有成千上万的客户端访问它,那么问题又来了,服务端怎么区分不同的客户端呢?
      1.1 说到这就要引入一个新的名词了什么呢 ? 没错 sessionID,那么什么是sessionID呢?

简单的说当客户端第一次访问某个站点的时候,将会在服务端生成一个唯一的Key,然后发送给客户端,在服务器端通过Key来取得相应的数据。通常,我们将这个key称为SessionID。

1.2 大家都知道HTTP是无状态的,那么这个sessionID保存到客户端的什么地方呢?想想客户端“我们知道web网站在客户端存储数据有三种形式:1. Cookie   2. hidden(隐藏域) 3.QueryString”   ,这三个你觉得那个更有可能,没错是cookice,当然当客户端禁用cookice的情况先就会采用存储在QueryString中。

2. 服务端的session

2.1 在页面对象或者HttpContext对象中,都有一个名为Session的属性,在一次会话中,它们引用的都是同一个对象,定义如下

public virtual HttpSessionState Session { get; }
              在往上来看看HttpSessionState怎么定义的

public sealed class HttpSessionState : ICollection, IEnumerable
             2.1.1 从这个类中我们可以找到操作session 的一些方法,下面是一些常用的方法

1 public void Abandon();
2 public void Add(string name, object value);
3 public void Clear();
4 public void Remove(string name);
5
6 public object this[int index] { get; set; }
7 public object this[string name] { get; set; }

从字面意思上就大概知道是什么方法,所以我就不一一解释了,看到6,7行可以知道session可以通过索引的方式访问。
            2.1.2 这个HttpSessionState来自于SessionStateModule。在每次请求处理过程中,HttpApplication在请求的处理管道中会检查当前请求的处理程序是否实现了接口IRequiresSessionState,如果实现了,那么SessionStateModule将为这个请求分配HttpSession。同时SessionModule还负责SessionID的生成  CookIeless会话管理。顺便提一下在使用一般处理程序的时候,默认情况下并没有实现这个接口,所以,如果在一般处理程序中使用Session必须实现IRequiresSessionState接口否则会导致异常。

3. 客户端的SessionID
          第一次访问某站点的报文

从相应报文中可以明显的看到服务端为客户端添加了一个Cookice,所以这个Cookice的值就为SessionID,还可以看到服务端并没有指定这个Cookice的过期时间所以这个Cookice会存储在内存中当浏览器关闭后,Cookice会立即消失。

第二次访问

从请求报文中很明显的看到,客户端想服务端发送了一个名为ASP.NET_SessionId的Cookice

时间: 2024-08-02 12:40:27

会话状态Session解析以及原理分析的相关文章

ASP.NET Session的实现原理分析

ASP.NET Session的实现原理分析 用户向服务器提交请求时,服务器都会给每个用户分配一个SessionId,保存在用户浏览器的Cookies中,SessionId是全局的,也就是说只要Cookies还存在,服务器就会认为这是同一个用户,从而实现了每个用户都有自己独立的全局Session域.当用户再去请求的时候,在http头把这个SessionID的Cookie发到服务器端,服务器就去找这个SessionID,如果找到了.就证明这个用户的状态是存在的. 我们可以通过以下实验更清除的了解S

AsyncTask解析(上)——原理分析与超简单demo实现

最近因为在做项目的过程中经常需要进行网络传输,所以打算把几个常用的网络通信框架和GitHub上面的开源框架梳理一遍,本文简单介绍了AsyncTask工作原理以及一个十分简单的应用demo. 当然,了解一个组件,最好是先从Android API文档入手. 那么首先我们来看一下AsyncTask的继承结构: 可以看到,AsyncTask跟Handler一样,是直接从Object类继承的,属于安卓系统包里的基本组件. 再来看看文档中对AsyncTask给出的描述: 从中我们可以得到3个比较重要的信息点

[精华] RDMA技术原理分析、主流实现对比和解析

替换高清大图 请点击此处输入图片描述  摘要: 远程直接内存访问(即Remote Direct Memory Access)是一种直接内存访问技术,它将数据直接从一台计算机的内存传输到另一台计算机,无需双方操作系统的介入,本文旨在技术引导,详细内容请通过文末"阅读原文"参阅<RDMA原理分析.对比和技术实现解析>电子书. RDMA技术最早出现在Infiniband网络,用于HPC高性能计算集群的互联.传统的基于Socket套接字(TCP/IP协议栈)的网络通信,需要经过操作

深入理解HTTP协议、HTTP协议原理分析

深入理解HTTP协议.HTTP协议原理分析 目录(?)[+] http协议学习系列 1. 基础概念篇 1.1 介绍 HTTP是Hyper Text Transfer Protocol(超文本传输协议)的缩写.它的发展是万维网协会(World Wide Web Consortium)和Internet工作小组IETF(Internet Engineering Task Force)合作的结果,(他们)最终发布了一系列的RFC,RFC 1945定义了HTTP/1.0版本.其中最著名的就是RFC 26

alljoyn:基于java动态代理的RPC实现原理分析

alljoyn是由高通开源,allseen组织下,作为IOT的一个开源软件框架. 本文分析它的core部分的远程调用方法的实现过程. 以android core sdk的release版本中的simple程序为例子. (eg alljoyn-14.06.00a-android-sdk-rel\alljoyn-android\core\alljoyn-14.06.00a-rel\java\samples\simple\client) 1. 下面是一个定义为alljoyn接口,并定义了一个远程调用方

Tomcat7.0源码分析——请求原理分析(中)

前言 在<TOMCAT7.0源码分析--请求原理分析(上)>一文中已经介绍了关于Tomcat7.0处理请求前作的初始化和准备工作,请读者在阅读本文前确保掌握<TOMCAT7.0源码分析--请求原理分析(上)>一文中的相关知识以及HTTP协议和TCP协议的一些内容.本文重点讲解Tomcat7.0在准备好接受请求后,请求过程的原理分析. 请求处理架构 在正式开始之前,我们先来看看图1中的Tomcat请求处理架构. 图1 Tomcat请求处理架构 图1列出了Tomcat请求处理架构中的主

MyBatis的深入原理分析之1-架构设计以及实例分析

MyBatis是目前非常流行的ORM框架,它的功能很强大,然而其实现却比较简单.优雅.本文主要讲述MyBatis的架构设计思路,并且讨论MyBatis的几个核心部件,然后结合一个select查询实例,深入代码,来探究MyBatis的实现. 一.MyBatis的框架设计        注:上图很大程度上参考了iteye 上的chenjc_it所写的博文原理分析之二:框架整体设计 中的MyBatis架构体图,chenjc_it总结的非常好,赞一个! 1.接口层---和数据库交互的方式 MyBatis

Tomcat源码分析——请求原理分析(下)

前言 本文继续讲解TOMCAT的请求原理分析,建议朋友们阅读本文时首先阅读过<TOMCAT源码分析——请求原理分析(上)>和<TOMCAT源码分析——请求原理分析(中)>.在<TOMCAT源码分析——请求原理分析(中)>一文我简单讲到了Pipeline,但并未完全展开,本文将从Pipeline开始讲解请求原理的剩余内容. 管道 在Tomcat中管道Pipeline是一个接口,定义了使得一组阀门Valve按照顺序执行的规范,Pipeline中定义的接口如下: getBas

Tomcat源码分析——请求原理分析(中)

前言 在<TOMCAT源码分析——请求原理分析(上)>一文中已经介绍了关于Tomcat7.0处理请求前作的初始化和准备工作,请读者在阅读本文前确保掌握<TOMCAT源码分析——请求原理分析(上)>一文中的相关知识以及HTTP协议和TCP协议的一些内容.本文重点讲解Tomcat7.0在准备好接受请求后,请求过程的原理分析. 请求处理架构 在正式开始之前,我们先来看看图1中的Tomcat请求处理架构. 图1 Tomcat请求处理架构 图1列出了Tomcat请求处理架构中的主要组件,这里