Session和Cookie深度剖析

Session和Cookie的区别

具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。
    cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式
    session机制。session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
 
    当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。
    保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。
    经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如：
     <form name="testform" action="/xxx">
     <input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
     <input type="text">
     </form>
实际上这种技术可以简单的用对action应用URL重写来代替。

Session优缺点以及推荐解决方案

Session有哪些缺点
       ①当mode="InProc"时，也就是默认设置时，容易丢失数据，为什么?因为网站会因为各种原因重启。

　　② 当mode="InProc"时，Session保存的东西越多，就越占用服务器内存，对于用户在线人数较多的网站，服务器的内存压力会比较大。

　　③当mode="InProc"时，程序的扩展性会受到影响，原因很简单：服务器的内存不能在多台服务器间共享。

　　④虽然Session可以支持扩展性，也就是设置mode="SQLServer"或者mode="StateServer"，但这种方式下，还是有缺点：在每次请求时，也不管你用不用会话数据，都为你准备好，这其实是浪费资源的。

　　⑤ 如果你没有关闭Session，SessionStateModule就一直在工作中，尤其是全采用默认设置时，会对每个请求执行一系列的调用。浪费资源。

　　⑥并发问题，前面有解释，也有示例。

　　⑦当你使用无 Cookie 会话时，为了安全，Session默认会使用 重新生成已过期的会话标识符 的策略，此时，如果通过使用 HTTP POST 方法发起已使用已过期会话 ID 发起的请求，将丢失发送的所有数据。这是因为 ASP.NET 会执行重定向，以确保浏览器在 URL 中具有新的会话标识符。
 不使用Session的替代方法
　　对于前面我列出的Session的一些缺点，如果您认为你有些是不能接受的，那么，可以参考一下我提出的替代解决方法。

　　①如果需要在一个页面的前后调用过程中维持一些简单的数据，可以使用<input type="hidden" />元素来保存这些数据。

　　②您希望在整个网站都能共享一些会话数据，就像mode="InProc"那样。此时，我们可以使用Cookie与Cache相结合做法，自行控制会话数据的保存与加载。具体做法也简单：为请求分配置一个Key(有就忽略)，然后用这个Key去访问Cache，以完成保存与加载的逻辑。如果要使用的会话数据数量不止一个，可以自定义一个类型或者使用一个诸如Dictionary, HashTable 这样的集合来保存它们。很简单吧，基本上这种方式就是与mode="InProc"差不多了。只是没有锁定问题，因此也就没有并发问题。

　　③ 如果您想实现mode="StateServer"类似的效果，那么可以考虑使用memcached这类技术，或者自己写个简单的服务，在内部使用一个或者多个Dictionary, HashTable来保存数据即可。这样我们可以更精确的控制读写时机。这种方法也需要使用Cookie保存会话ID。

　　4. 如果您想实现mode="SQLServer"类似的效果，那么可以考虑使用mongodb这类技术，同样我们可以更精确的控制读写时机。这种方法也需要使用Cookie保存会话ID。如果您没用使用过mongodb

　　从前面三种替代方法来看，如果不使用Session，那么Cookie就是必需的。其实Cookie本身就是设计用来维持会话状态的。只是它不适合保存过大的数据而已，因此，用它保存会话ID这样的数据，可以说是很恰当的。事实上，Session就是这样做的。

　　推荐方法：为了保持网站程序有较好的扩展性，且不需要保存过大的会话数据，那么，直接使用Cookie将是最好的选择。

　　由于Cookie保存在浏览器，且不安全，所以建议只保存诸如：id, key 之类的简单数据，需要其它的会话数据时再根据这些id, Key去获取。
Cookie解析

先了解一下Cookie工作原理以及保存方式：

Cookie通过HTTP Headers从服务器端返回到浏览器上。首先，服务器端在响应中利用Set-Cookie header来创建一个Cookie ，然后，浏览器在它的请求中通过Cookie header包含这个已经创建的Cookie，并且反它返回至服务器，从而完成浏览器的论证。

Internet Explorer 将站点的 Cookie 保存在文件名格式为 <user>@<domain>.txt 的文件中，其中 <user> 是您的帐户名。例如，如果您的名称为 user，您访问的站点为 www.nowamagic.net，那么该站点的 Cookie 将保存在名为 user@nowamagic.net.txt 的文件中。（该文件名可能包含一个顺序的编号，如 user@nowamagic.net [1].txt。） Cookie 文本文件是与用户相关的，所以会按照帐户分别保存。

一个 Cookie 会占用大约 50 个字符的基本空间开销（用于保存有效期信息等），再加上其中保存的值的长度，其总和接近 4K 的限制。大多数浏览器只允许每个站点保存 20 个 Cookie 。

cookie运行解决方案

1、多数的服务器会使用session复制的方法：当session的值被改变时，将它复制到其它机器上。这个方案又有两种具体的实现 ，一种是广播的方式，缺点：当访问量增大的时候 ，带宽增大，而且随着机器增加，网络负担成指数级上升，不具备高度可扩展性 ；另一种是TCP-ring的方式，也就是把集群中所有的服务器看成一个环，A->B->C->D->A，首尾相接，缺点：一是配置复杂；二是每增添/减少一台机器时，ring都需要重新调整，这将成为性能瓶颈；三是要求前端的Load Balancer具有相当强的智能，才能将用户请求分发到正确的机器上。

2、将session保存在单一的数据源中，这个数据源可被集群中所有的机器所共享 ，但带来的问题就是性能问题了。

解决方案:是把session以Cookie的形式保存在客户端。

优点：极高的扩展性和可用性

1. 通过良好的编程，控制保存在cookie中的session对象的大小。
2. 通过加密和安全传输技术（SSL），减少cookie被破解的可能性。
3. 只在cookie中存放不敏感数据，即使被盗也不会有重大损失。
4. 控制cookie的生命期，使之不会永远有效。偷盗者很可能拿到一个过期的cookie。

缺点：

1. Cookie数量和长度的限制。每个domain最多只能有20条cookie，每个cookie长度不能超过4KB，否则会被截掉。
2. 安全性问题。如果cookie被人拦截了，那人就可以取得所有的session信息。即使加密也与事无补，因为拦截者并不需要知道cookie的意义，他只要原样转发cookie就可以达到目的了。
3. 有些状态不可能保存在客户端。例如，为了防止重复提交表单，我们需要在服务器端保存一个计数器。如果我们把这个计数器保存在客户端，那么它起不到任何作用。