关于cookie、session、application知识 的整理

以下摘自：http://topic.csdn.net/u/20090418/21/90e2d95d-5c19-47b3-afe7-f704f9f86eb0.html

Cookie:
①存在于客户端（可被阻止）
②只能是文本文档
③如果设置了期限值，则写入客户端的文件；
如果没有，它只对本窗口或其子窗口有效，其它窗口不能访问该Cookie
④在Servlet/JSP中设置的Cookie可以被同路径下或其子路径的Servlet/JSP访问，父路径不可以
○注：这里的路径是指URL，而不是Web文件的目录 。

Session：
①存在于服务器端
②每个Session对应一个窗口，用SessionID标识，这个Session为该窗口及其子窗口共享
③有两种实现方式：a.使用Cookie（在Cookie可用时）b.URL重写（在Cookie被禁用时）
④没有访问路径的问题。同一个WebApplication下的Servlet/JSP设置的Session可以被互相访问
前提是：同一个浏览器窗口或其子窗口

Application：
与一个Web应用程序相对应，该应用程序下所有的Servlet/JSP共用该Application中的信息（ServletContext）

以下摘自：http://blog.ccidnet.com/blog-htm-do-showone-uid-65766-itemid-201068-type-blog.html

客户端与服务器端有相关操作时：1.服务器端会生成一个唯一的编号 2.把保存客户端浏览器相关信息以及自己网页的相关信息的cookie传递给客户端.

cookie分为两种：

1. 一种是设定了生命周期的cookie(通过文本文件写入自己的网页信息，这样可以让不同的网站只能拿自己的cookie)
2. 另一种是没有设定生命周期的cookie,该cookie存在单个浏览器所对应的内存中，而不是通过文本文件的方式写入到客户端硬盘中，故其他浏览器不能访问到这个cookie;即使是两个浏览器访问同一个服务器页面也不能共享内存中的cookie；

重点：一个servlet/jsp文件写的cookie只能够被和该servlet/jsp文件在相同url路径或其子路径下的serlet/jsp文件拿到；
对于cookie：
如果浏览器支持cookie，创建session的时候会把sessionId是存放在浏览器在内存的cookie中的，
如果浏览器不支持cookie，必须自己编程使用url重写的方式实现session，response.encodeURL(),首先要解决转码问题，然后url后面加入sessionid
Session：
session是存储在服务器端内存中，记录客户端相关操作，每个session都只和自己相对应的浏览器相关，sessionId是存放在浏览器在内存的cookie中的。
在程序中得到session对象的方法是通过：request.getSession(true);
而对于getSession(true)方法，则表示如果客户端浏览器没有得到一个sessionid则服务器端就会在内存中分配空间创建并存储该session，如果浏览器有一个sessionid服务器就会拿到那个sessionid所对应的session。从而得到该浏览器在服务器端都做了什么！session是以key-value形式存储的,key都是string类型，value是object类型，故session中可以存任何东西！
而对于getSession(false)方法，则表示不会给浏览器创建和存储一个session
重点：session不像cookie拥有路径访问的问题；同一个web application下的servlet/jsp可以共享同一个session的，但前提是同一个浏览器窗口或其子窗口；(每个session只与同一个浏览器相对应)session是以最近的访问时间开始计算失效时间的，可以通过tomcat的conf路径下的web.xml中的
<session-config>
<session-timeout>30</session-timeout>
</session-config>
来设定session失效时间，
Application：
对于application是能够被该web application下的全部servlet访问；
在API中表现为ServletContext
通过HttpServlet的getServletContext方法拿到；通过ServletContext的get/setAttribute()方法取得/设置相关属性；

以下摘自：http://n.dvbbs.net/topic-767363.aspx

知道ViewState,QueryString,Cookies,,Session,Application,Cache它们的适用范围和使用效率么？

如果大家有什么自己的思路，请列举出来，共大家参考。

这里我的看法：
1，ViewState多半存储本页内的信息，适用少量数据，具有基本安全性；
使用视图状态的优点是：
a, 不需要任何服务器资源。视图状态包含在页代码内的结构中。
b, 简单的实现。
c, 页和控件状态的自动保持。
d, 增强的安全功能。视图状态中的值是散列的、压缩的并且是为 Unicode 实现而编码的，这意味着比隐藏域具有更高的安全性状态。
使用视图状态的缺点是：
a, 性能。由于视图状态存储在页本身，因此如果存储较大的值，在用户显示页和发送页时，页的速度就可能会减慢。
b, 安全性。视图状态存储在页上的隐藏域中。虽然视图状态以哈希格式存储数据，但它可以被篡改。如果直接查看页输出源，可以看到隐藏域中的信息，这导致潜在的安全性问题。
2，QueryString多半是地址栏参数，到下一页使用，明文，无所谓安全；

3，Cookies需要在客户端存储少量信息，不需要较高的安全性；
使用 Cookie 的优点是：
a, 不需要任何服务器资源。Cookie 存储在客户端并在发送后由服务器读取。
b, 简单。Cookie 是具有简单键值对的轻量的、基于文本的结构。
c,可配置到期时间。Cookie 可以在浏览器会话结束时到期，或者可以在客户端计算机上无限期存在，这取决于客户端的到期规则。
使用 Cookie 的缺点是：
a, 大小受到限制。
b, 用户配置为拒绝接受。有些用户禁用了浏览器或客户端设备接收 Cookie 的能力，因此限制了这一功能。
c, 安全性。Cookie 可能会受到篡改。用户可能会操纵其计算机上的 Cookie，这可能意味着安全性会受到影响或者导致依赖于 Cookie 的应用程序失败。
d, 持久性。客户端计算机上 Cookie 的持久性受到客户端 Cookie 到期进程以及用户干预的制约。
e, Cookie 通常用于为已知用户自定义内容的个性化情况。在大多数此类情况中，Cookie 是作为“标识”而不是“身份验证”，所以在 Cookie 中只存储用户名、账户名或唯一用户 ID（例如 GUID）并使用它来访问站点的用户个性化结构是足够的了。

4，Session存储在会话状态变量中的理想数据是特定于单独的、短期的、敏感的数据，应该是安全的，但过多使用会降低服务其性能；
使用会话状态的优点是：
a, 易于实现。会话状态功能易于使用。
b, 会话特定的事件。会话管理事件可以由应用程序引发和使用。
c, 持久性。放置于会话状态变量中的数据可以经受得住 Internet 信息服务 (IIS) 重新启动和辅助进程重新启动，而不丢失会话数据，这是因为这些数据存储在另一个进程空间中。
d, 平台可缩放性。会话状态对象可在多计算机和多进程配置中使用，因而优化了可缩放性方案。
e, 尽管会话状态最常见的用途是与 Cookie 一起向 Web 应用程序提供用户标识功能，但会话状态可用于不支持 HTTP Cookie 的浏览器。
使用会话状态的缺点是：
a, 性能。会话状态变量在被移除或替换前保留在内存中，因而可能降低服务器性能。如果会话状态变量包含类似大型数据集的信息块，则可能会因服务器负荷的增加影响 Web 服务器的性能。

5，Application插入到应用程序状态变量的理想数据是那些由多个会话共享并且不经常更改的数据
使用应用程序状态的优点是：
a, 易于实现。应用程序状态易于使用。
b, 全局范围。由于应用程序状态可供应用程序中的所有页来访问，因此在应用程序状态中存储信息可能意味着仅保留信息的一个副本（例如，相对于在会话状态或在单独页中保存信息的多个副本）。
使用应用程序状态的缺点是：
a, 全局范围。应用程序状态的全局性可能也是一项缺点。在应用程序状态中存储的变量仅对于该应用程序正在其中运行的特定进程而言是全局的，并且每一应用程序进程可能具有不同的值。因此，不能依赖应用程序状态来存储唯一值或更新网络园和网络场配置中的全局计数器。
b, 持久性。因为在应用程序状态中存储的全局数据是易失的，所以如果包含这些数据的 Web 服务器进程被损坏（最有可能是因服务器崩溃、升级或关闭而损坏），将丢失这些数据。
c, 资源要求。应用程序状态需要服务器内存，这可能会影响服务器的性能以及应用程序的可缩放性。应用程序状态的精心设计和实现可以提高 Web 应用程序性能。例如，如果将常用的、相关的静态数据集放置到应用程序状态中，则可以通过减少对数据库的数据请求总数来提高站点性能。但是，这里存在一种性能平衡。当服务器负载增加时，包含大块信息的应用程序状态变量就会降低 Web 服务器的性能。在移除或替换值之前，将不释放在应用程序状态中存储的变量所占用的内存。因此，最好只将应用程序状态变量用于更改不频繁的小型数据集。

6，Cache，.NET 为您提供了一个强大的、便于使用的缓存机制，允许您将需要大量的服务器资源来创建的对象存储在内存中。其生存期依赖于该应用程序的生存期。重新启动应用程序后，将重新创建 Cache 对象。他的作用比较丰富，机制也比较多，请参阅相关的资料。

另：还有Context.Item