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)，是目前比较流行的企业业务整合的解决方案之一. 简单的说, 就是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。

 

 

Session和Cookie比较：（网上参考）

1. 应用场景

Cookie的典型应用场景是Remember Me服务，即用户的账户信息通过cookie的形式保存在客户端，当用户再次请求匹配的URL的时候，账户信息会被传送到服务端，交由相应的程序完成自动登录等功能。当然也可以保存一些客户端信息，比如页面布局以及搜索历史等等。

Session的典型应用场景是用户登录某网站之后，将其登录信息放入session，在以后的每次请求中查询相应的登录信息以确保该用户合法。当然还是有购物车等等经典场景；

2. 安全性

cookie将信息保存在客户端，如果不进行加密的话，无疑会暴露一些隐私信息，安全性很差，一般情况下敏感信息是经过加密后存储在cookie中，但很容易就会被窃取。而session只会将信息存储在服务端，如果存储在文件或数据库中，也有被窃取的可能，只是可能性比cookie小了太多。

Session安全性方面比较突出的是存在会话劫持的问题，这是一种安全威胁，这在下文会进行更详细的说明。总体来讲，session的安全性要高于cookie；

3. 性能

Cookie存储在客户端，消耗的是客户端的I/O和内存，而session存储在服务端，消耗的是服务端的资源。但是session对服务器造成的压力比较集中，而cookie很好地分散了资源消耗，就这点来说，cookie是要优于session的；

4. 时效性

Cookie可以通过设置有效期使其较长时间内存在于客户端，而session一般只有比较短的有效期（用户主动销毁session或关闭浏览器后引发超时）；

5. 其他

Cookie的处理在开发中没有session方便。而且cookie在客户端是有数量和大小的限制的，而session的大小却只以硬件为限制，能存储的数据无疑大了太多。

 

 

关于Session和Cookie两方面的知识还有太多太多要学，现在理解只是皮毛。