本文转自：http://www.cnblogs.com/japanbbq/archive/2011/08/31/2160494.html

Session:

Session是“会话”的意思，然而，因为http协议是无状态的，那么每次客户端请求服务器端，服务器端都会以“崭新”的页面展示给客户端，这在静态的html页面中是不会存在任何影响，但是在动态页面中，需要与用户交互，要保持与客户端用户的联系，则需要一些东西来保持，而Session的话，则是具有“保持状态，保持会话”的能力。

注意的是，Session是保存在服务器端的。（Cookie是保存在客户端的）需要注意的是，如果用户突然关闭了客户端页面，那么Session就会丢失，即“会话丢失”。

服务器端创建session的三个步骤（网上参考）：

1. 生成全局唯一标识符（sessionid）；

2. 开辟数据存储空间。一般会在内存中创建相应的数据结构，但这种情况下，系统一旦掉电，所有的会话数据就会丢失，如果是电子商务网站，这种事故会造成严重的后果。不过也可以写到文件里甚至存储在数据库中，这样虽然会增加I/O开销，但session可以实现某种程度的持久化，而且更有利于session的共享；

3. 将session的全局唯一标示符发送给客户端。

问题的关键就在服务端如何发送这个session的唯一标识上。联系到HTTP协议，数据无非可以放到请求行、头域或Body里，基于此，一般来说会有两种常用的方式：cookie和URL重写。

1. Cookie（sessionid会保存在Cookie里，并且失效时间为0，就是浏览器进程的有效时间，如果关闭了浏览器，那么session就会失效，原理就是如此）

读者应该想到了，对，服务端只要设置Set-cookie头就可以将session的标识符传送到客户端，而客户端此后的每一次请求都会带上这个标识符，由于cookie可以设置失效时间，所以一般包含session信息的cookie会设置失效时间为0，即浏览器进程有效时间。至于浏览器怎么处理这个0，每个浏览器都有自己的方案，但差别都不会太大（一般体现在新建浏览器窗口的时候）；

2. URL重写（平时网上url地址上有 ?sessionID=xxxx 字样）

所谓URL重写，顾名思义就是重写URL。试想，在返回用户请求的页面之前，将页面内所有的URL后面全部以get参数的方式加上session标识符（或者加在path info部分等等），这样用户在收到响应之后，无论点击哪个链接或提交表单，都会在再带上session的标识符，从而就实现了会话的保持。读者可能会觉得这种做法比较麻烦，确实是这样，但是，如果客户端禁用了cookie的话，URL重写将会是首选。

Session在ASP.Net的基本用法

定义的时候： Session["ddd"]=xxxx;

使用的时候：Session["ddd"]即可

如果需要保存类的对象的话，用法跟ViewState是一样的：

发送端：

UserInfo ui = new UserInfo();
Session["ui"] = ui;
ui.name = name.Text;
ui.age = age.Text;
ui.sex = sex.Text;
ui.password = password.Text;
Response.Redirect("a.aspx");

接收端：

UserInfo ui = Session["ui"] as UserInfo;
name.Text = ui.name;
age.Text = ui.age;
password.Text = ui.password;
sex.Text = ui.sex;

Session时间（销毁方式：超时和手动销毁）：

asp.net Session的默认时间设置是20分钟，即超过20分钟后,服务器会自动放弃Session信息.

Session Hijack （网上参考）：

Session hijack即会话劫持是一种比较严重的安全威胁，也是一种广泛存在的威胁，在session技术中，客户端和服务端通过传送session的标识符来维护会话，但这个标识符很容易就能被嗅探到，从而被其他人利用，这属于一种中间人攻击。

Cookie

cookie的最大好处使用的就是"Remember Me"的服务。

cookie保存在客户端，如果用户禁用了cookie的话，可能会存在一些问题，所以在设计的时候要注意（判断cookie是否为null）

需要cookie的原因跟需要session一样，因为http协议是无状态的，每次都是新的页面，不会保存任何信息，而cookie的话，会保存在客户端的电脑上，那么到时需要用的时候，可以利用后台的服务器端调用，也可以就用客户端来进行调用。

Cookie只是一段文本，所以它只能保存字符串。而且浏览器对它有大小限制以及它会随着每次请求被发送到服务器，所以应该保证它不要太大。 Cookie的内容也是明文保存的，有些浏览器提供界面修改，所以，不适合保存重要的或者涉及隐私的内容。（网上参考）

Cookie的限制：

大多数浏览器支持最大为 4096 字节的 Cookie。由于这限制了 Cookie 的大小，最好用 Cookie 来存储少量数据，或者存储用户 ID 之类的标识符。用户 ID 随后便可用于标识用户，以及从数据库或其他数据源中读取用户信息。浏览器还限制站点可以在用户计算机上存储的 Cookie 的数量。大多数浏览器只允许每个站点存储 20 个 Cookie；如果试图存储更多 Cookie，则最旧的 Cookie 便会被丢弃。有些浏览器还会对它们将接受的来自所有站点的 Cookie 总数作出绝对限制，通常为 300 个。

Cookie中的属性：（网上参考）

name: 每个cookie由一个唯一的名称代表，这个名称可以包含字母、数字、下划线。cookie的名称是不分大小写，所以mycookie和MyCookie是一样。但考虑到服务器端语言可能区分大小写，建议定义和使用时还是区分大小写。

value: 保存在cookie中的字符串值。这个值在存储之前必须使用encodeURIComponent()对其进行编码，以免丢失数据或占用了cookie。注意：cookie名字和值加起来的字节数不能超过4095字节，也即4KB。

domain: 出于安全考虑，网站不能访问由其他域所创建的cookie。创建cookie以后，域的信息会作为cookie的一部分存储下来。关于域，这里给一个例子，如http://ibm.com/foo/index.aspx, 它的域为：ibm.com。

path: cookie的另一个安全特征，限制对web服务器上特定目录的访问。即控制哪些访问能触发发送.例如请求的地址是上面的url,如果path=/foo,这个cookie就会被发送,但是path为其他的话,该cookie会被忽略。

expires: cookie的过期时间。

secure: 一个true/false值，用于表示cookie是否只能从安全网站（使用SSL和https协议的网站）中访问。如果这个值被设置为true

Cookie的基本步骤：（网上参考）

浏览器对于Web服务器应答包头中Cookie的操作步骤：

a. 从Web服务器的应答包头中提取所有的cookie。

b. 解析这些cookie的组成部分（名称，值，路径等等）。

c. 判定主机是否允许设置这些cookie。允许的话，则把这些cookie存储在本地。

浏览器对Web服务器请求包头中所有的cookie进行筛选的步骤：

a. 根据请求的url和本地存储cookie的属性，判断那些cookie能被发送给Web服务器。

b. 对于多个cookie，判定发送的顺序。
c. 把需要发送的cookie加入到请求http包头中一起发送。

Cookie在ASP.Net中的基本用法：

发送端：

HttpCookie cookie = new HttpCookie("UserInfo");

cookie["name"] = name.Text;

cookie["age"] = age.Text;

cookie["sex"] = sex.Text;

cookie["language"] = language.Text;

cookie.Expires = DateTime.MaxValue;

Response.Cookies.Add(cookie);

Response.Redirect("cookie2.aspx");

接收端：

HttpCookie cookie = Request.Cookies["UserInfo"];

if(cookie!=null)

{

name.Text = cookie["name"];
age.Text = cookie["age"];
language.Text = cookie["language"];
sex.Text = cookie["sex"];

}

else

{ }

最好在接收端上加上一个条件判断，这样则避免如果禁用了cookie，就不会导致出错，也可以确定cookie是否存在。

Cookie的用途：

防止网上重复投票；
通过cookie实现自动登陆
单点登陆 ( Single Sign On, SSO)，是目前比较流行的企业业务整合的解决方案之一. 简单的说, 就是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。