Session ,cookie,cache

 

Session ,cookie,cache

 

为什么会有cookie呢,大家都知道，http是无状态的协议，客户每次读取web页面时，服务器都打开新的会话，而且服务器也不会自动维护客户的上下文信息，那么要怎么才能实现网上商店中的购物车呢，session就是一种保存上下文信息的机制，它是针对每一个用户的，变量的值保存在服务器端，通过SessionID来区分不同的客户,session是以cookie或URL重写为基础的，默认使用cookie来实现，系统会创造一个名为JSESSIONID的输出cookie，我们叫做session cookie,以区别persistent cookies,也就是我们通常所说的cookie,注意session cookie是存储于浏览器内存中的，并不是写到硬盘上的，这也就是我们刚才看到的JSESSIONID，我们通常情是看不到JSESSIONID的，但是当我们把浏览器的cookie禁止后，web服务器会采用URL重写的方式传递Sessionid，我们就可以在地址栏看到sessionid=KWJHUG6JJM65HS2K6之类的字符串。

             明白了原理，我们就可以很容易的分辨出persistent cookies和session cookie的区别了，网上那些关于两者安全性的讨论也就一目了然了，session cookie针对某一次会话而言，会话结束session cookie也就随着消失了，而persistent cookie只是存在于客户端硬盘上的一段文本（通常是加密的），而且可能会遭到cookie欺骗以及针对cookie的跨站脚本攻击，自然不如session cookie安全了。

             通常session cookie是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的sessionid，这样我们信息共享的目的就达不到了，此时我们可以先把sessionid保存在persistent cookie中，然后在新窗口中读出来，就可以得到上一个窗口SessionID了，这样通过session cookie和persistent cookie的结合我们就实现了跨窗口的session tracking（会话跟踪）。

            在一些web开发的书中，往往只是简单的把Session和cookie作为两种并列的http传送信息的方式，session cookies位于服务器端，persistent cookie位于客户端，可是session又是以cookie为基础的，明白的两者之间的联系和区别，我们就不难选择合适的技术来开发web service了。

 

mode view control 模式

 

cs中的class 型及其属性=模型

page_onload{} = control 控制

aspx = 视图

 

Application、Cookie、Session和Cache

在我们开发网站时涉及到页面间数据共享的时候，我们常常需要使用某一种方式来持久化我们的数据，持久化数据的方式有许多种，这就要求我们在其中做出选择。

在做开发的时候我们需要精确的选择我们使用的数据持久化方式，下面对于Application、Cookie、Session和Cache的描述或许可以帮助您作出决定：

Application：提供对所有会话的应用程序范围的方法和事件的访问。还提供对可用于存储信息的应用程序范围的缓存的访问。应用程序状态是可供 ASP.NET 应用程序中的所有类使用的数据储存库。它存储在服务器的内存中，因此与在数据库中存储和检索信息相比，它的执行速度更快。与特定于单个用户会话的会话状态不同，应用程序状态应用于所有的用户和会话。因此，应用程序状态非常适合存储那些数量少、不随用户的变化而变化的常用数据。

Application的关键特性有：存储于服务器内存中，与用户无关即多用户共享，在应用程序的整个生存期中存在即不会被主动丢弃，不被序列化，不发生服务器-客户端的数据传输。

Cookie：Cookie 提供了一种在 Web 应用程序中存储用户特定信息的方法。例如，当用户访问您的站点时，您可以使用 Cookie 存储用户首选项或其他信息。当该用户再次访问您的网站时，应用程序便可以检索以前存储的信息。在开发人员以编程方式设置Cookie时，需要将自己希望保存的数据序列化为字符串（并且要注意，很多浏览器对Cookie有4096字节的限制）然后进行设置。

Cookie的关键特性有：存储于客户端硬盘上，与用户相关，在一定时间内持久化存储，可以跨浏览器共享数据，需要被序列化，发生服务器-客户端数据传输。

Session：为当前用户会话提供信息。还提供对可用于存储信息的会话范围的缓存的访问，以及控制如何管理会话的方法。应用程序状态是可供 ASP.NET 应用程序中的所有类使用的数据储存库。它存储在服务器的内存中，因此与在数据库中存储和检索信息相比，它的执行速度更快。与不特定于单个用户会话的应用程序状态不同，会话状态应用于单个的用户和会话。因此，应用程序状态非常适合存储那些数量少、随用户的变化而变化的常用数据。而且由于其不发生服务器-客户端数据传输，Session还适合存储关于用户的安全数据，如购物车信息。

Session的关键特性有：存储于服务器内存中，与会话相关，在会话的整个生存期中存在即不会被主动丢弃，不被序列化，不发生服务器-客户端数据传输。

Cache：ASP.NET 为您提供了一个强大的、便于使用的缓存机制，用于将需要大量服务器资源来创建的对象存储在内存中。缓存这些类型的资源会大大改进应用程序的性能。它存储于服务器的内存中，允许您自定义如何缓存项以及将它们缓存多长时间。例如，当缺乏系统内存时，缓存会自动移除很少使用的或优先级较低的项以释放内存。该技术也称为清理，这是缓存确保过期数据不使用宝贵的服务器资源的方式之一。它不与会话相关，所以它是多会话共享的，因此使用它可以提高网站性能，但是可能泄露用户的安全信息，还由于在服务器缺乏内存时可能会自动移除Cache因此需要在每次获取数据时检测该Cache项是否还存在。

Cache的关键特性有：存储于服务器内存中，与会话无关，根据服务器内存资源的状况随时可能被丢弃，不被序列化，不发生服务器-客户端数据传输。

在这里，我还希望对ViewState也顺便做一个描述，以便与上面四种数据持久化的方式做一个对比。因为，ViewState虽然不能够跨页面共享数据，但是在同一个页面里，可以用于在对同一页的多个请求之间保留值。

ViewState： ViewState 属性提供一个字典对象，用于在对同一页的多个请求之间保留值。这是页用来在往返行程之间保留页和控件属性值的默认方法。在处理页时，页和控件的当前状态会散列为一个字符串，并在页中保存为一个隐藏域或多个隐藏域（如果存储在 ViewState 属性中的数据量超过了 MaxPageStateFieldLength 属性中的指定值）。当将页回发到服务器时，页会在页初始化阶段分析视图状态字符串，并还原页中的属性信息。也可以使用视图状态来存储值。在默认情况下，ViewState不被加密，并且发生服务器-客户端数据传输。

ViewState的关键特性有：存储于页面上，与会话且与页面相关，被序列化，默认发生服务器-客户端传输，默认不被加密。

至于在什么样的情况下ViewState不发生服务器端-客户端传输，或者被加密，我们将在后面的章节中予以讲述。

综上，我们总结出一些常见而典型的例子：

电子商务网站的购物车：使用Session，因为购物车信息是会话相关的而且安全性很重要。

论坛或其它网站的“记住我”功能：使用Cookie，因为这是保存的往往只是一个用户名，而且当用户下次登陆时还需要这个用户名仍然存在。

站点计数器：如果您不用数据库的话那就是使用Application了，因为计数器是会话无关的。但是即使在使用数据库的情况下我也建议你同时使用Application来保存计数值，然后再每隔一段时间保存到数据库里去，因为这样可以减少访问数据库的次数以提高性能。

产品信息：Cache是优先的选择，因为产品信息通常是与会话无关、修改频率低且访问频率高的数据，使用Cache来保存可以有效地提高网站的性能。

最后，我们给出一个表格，列出以上几种数据持久化方式的特性对比，以便您做出决定：

 Application Cache Session Cookie ViewState

	Application	Cache	Session	Cookie	ViewState
存储位置	服务器	服务器	服务器	客户端	客户端
是否会被主动丢弃	不会	会	不会	不会	不会
与会话相关	否	否	是	是	是
是否被序列化	否	否	否	是	是
是否发生服务器 - 客户端传输	否	否	否	是	是（默认情况）
是否被加密	否	否	否	是	否（默认情况）

 

ValidateRequest

指示是否应发生请求验证。如果为 true，请求验证将根据具有潜在危险的值的硬编码列表检查所有输入数据。如果出现匹配情况，将引发 HttpRequestValidationException 类。默认值为 true。

该功能在计算机配置文件 (Machine.config) 中启用。可以在应用程序配置文件 (Web.config) 中或在页上将该属性设置为 false 来禁用该功能。

 

注意    该功能有助于减少对简单页或 ASP.NET 应用程序进行跨站点脚本攻击的风险。如果应用程序不能正确验证用户输入，则可能会受到多种类型的格式错误的输入的攻击，包括跨站点脚本攻击和 SQL Server 指令注入式攻击。应该仔细地评估应用程序中所有形式的输入，并确保对它们进行了正确地验证和编码，或者确保应用程序在处理数据或将信息发送回客户端之前已退出。除此之外，别无它法。有关跨站点脚本的详细信息，请参见 http://www.cert.org/advisories/CA-2000-02.html。