session和cookie的区别是什么 (session)

本文目录导航：

• session和cookie的区别是什么？
• 本地vb程序如何读取本地主机的session?
• Session是什么？

session和cookie的区别是什么？

session是存储在主机端的，cookie是存储在客户端的，所以session的安保性要高于cookie。

再者，咱们失掉的session里的信息是经过寄存在会话cookie里的sessionId失掉的。

由于session是寄存在主机里的，所以session里的物品不时参与会参与主机的累赘，咱们会把一些关键的物品放在session里，不太关键的放在客户端cookie里。

cookie分为两大类，一个是会话cookie和耐久化cookie，他们的生命周期和阅读器是分歧的，阅读器关了会话cooki也就隐没了，而耐久化会存储在客户端硬盘中。

本地vb程序如何读取本地主机的session?

倡导你用ASP的Application 对象来做。

他外面有现成的监督事情

Application_OnEnd:当一切用户的 session 都完结，并且运行程序完结时，此事情出现。

Application_OnStart:在首个新的 session 被创立之前（这时 Application 对象被初次援用），此事情会出现。

Application_OnStart 事情

Application_OnStart 事情出当初第一个新的会话创立之前 (当 Application 对象第一次性被援用时)。

此事情搁置在 文件中。

注释：在 Application_OnStart 事情脚本中援用 Session、Request 或许 Response 对象会引发失误。

Application_OnEnd 事情

Application_OnEnd 事情出当初运行程序完结时 (当 web 主机中止运转时)。

此事情搁置在 文件中。

注释：MapPath 方法无法用于 Application_OnEnd 代码中。

语法

Session是什么？

一、术语session在我的阅历里，session这个词被滥用的水平大略仅次于transaction，愈加幽默的是transaction与session在某些语境下的含意是相反的。

session，中文经常翻译为会话，其原本的含意是指虎头蛇尾的一系列举措/信息，比如打电话时从拿起电话拨号到挂断电话这两边的一系列环节可以称之为一个session。

有时刻咱们可以看到这样的话“在一个阅读器会话时期，...”，这里的会话一词用的就是其转义，是指从一个阅读器窗口关上到封锁这个时期①。

最凌乱的是“用户（客户端）在一次性会话时期”这样一句话，它或许指用户的一系列举措（普通状况下是同某个详细目标相关的一系列举措，比如从登录到选购商品到结账登出这样一个网上购物的环节，有时刻也被称为一个transaction），但是有时刻也或许仅仅是指一次性衔接，也有或许是指含意①，其中的差异只能靠高低文来推断②。

但是当session一词与网络协定相关联时，它又往往隐含了“面向衔接”和/或“坚持形态”这样两个含意，“面向衔接”指的是在通讯双方在通讯之前要先建设一个通讯的渠道，比如打电话，直到对方接了电话通讯能力开局，与此相对的是写信，在你把信收回去的时刻你并不能确认对方的地址能否正确，通讯渠道不必定能建设，但对发信人来说，通讯曾经开局了。

“坚持形态”则是指通讯的一方能够把一系列的信息关联起来，使得信息之间可以相互依赖，比如一个服务员能够认出再次莅临的老顾客并且记得上次这个顾客还欠店里一块钱。

这一类的例子有“一个TCP session”或许“一个POP3 session”③。

而到了web主机蓬勃开展的时代，session在web开发语境下的语义又有了新的裁减，它的含意是指一类用来在客户端与主机之间坚持形态的处置计划④。

有时刻session也用来指这种处置计划的存储结构，如“把xxx保管在session里”⑤。

由于各种用于web开发的言语在必定水平上都提供了对这种处置计划的允许，所以在某种特定言语的语境下，session也被用来指代该言语的处置计划，比如经常把Java里提供的简称为session⑥。

鉴于这种凌乱已无法扭转，本文中session一词的运用也会依据高低文有不同的含意，请大家留意分辨。

在本文中，经常使用中文“阅读器会话时期”来表白含意①，经常使用“session机制”来表白含意④，经常使用“session”表白含意⑤，使用详细的“HttpSession”来表白含意⑥二、HTTP协定与形态坚持HTTP协定自身是有形态的，这与HTTP协定原本的目标是相符的，客户端只须要繁难的向主机恳求下载某些文件，无论是客户端还是主机都没有必要纪录彼此过去的行为，每一次性恳求之间都是独立的，好比一个顾客和一个智能售货机或许一个普通的（非会员制）大卖场之间的相关一样。

但是痴呆（或许贪心？）的人们很快发现假设能够提供一些按需生成的灵活信息会使web变得愈加有用，就像给有线电视加上点播性能一样。

这种需求一方面迫使HTML逐渐参与了表单、脚本、DOM等客户端行为，另一方面在主机端则出现了CGI规范以照应客户端的灵活恳求，作为传输载体的HTTP协定也参与了文件上载、cookie这些个性。

其中cookie的作用就是为了处置HTTP协定有形态的毛病所作出的致力。

至于起初出现的session机制则是又一种在客户端与主机之间坚持形态的处置计划。

让咱们用几个例子来形容一下cookie和session机制之间的区别与咨询。

笔者曾经常去的一家咖啡店有喝5杯咖啡收费赠一杯咖啡的活动，但是一次性性生产5杯咖啡的时机微不足道，这时就须要某种方式来纪录某位顾客的生产数量。

构想一下其实也无外乎上方的几种计划：1、该店的店员很凶猛，能记住每位顾客的生产数量，只需顾客一走进咖啡店，店员就知道该怎样看待了。

这种做法就是协定自身允许形态。

2、发给顾客一张卡片，上方记载着生产的数量，普通还有个有效期限。

每次生产时，假设顾客出示这张卡片，则此次生产就会与以前或以后的生产相咨询起来。

这种做法就是在客户端坚持形态。

3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次生产时，假设顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录参与一些生产信息。

这种做法就是在主机端坚持形态。

由于HTTP协定是有形态的，而出于种种思考也不宿愿使之成为有形态的，因此，前面两种计划就成为理想的选用。

详细来说cookie机制驳回的是在客户端坚持形态的计划，而session机制驳回的是在主机端坚持形态的计划。

同时咱们也看到，由于驳回主机端坚持形态的计划在客户端也须要保管一个标识，所以session机制或许须要借助于cookie机制来到达保管标识的目标，但实践上它还有其余选用。

三、了解cookie机制 cookie机制的基本原理就如上方的例子一样繁难，但是还有几个疑问须要处置：“会员卡”如何散发；“会员卡”的内容；以及客户如何经常使用“会员卡”。

正统的cookie散发是经过裁减HTTP协定来成功的，主机经过在HTTP的照应头中加上一行不凡的批示以揭示阅读器依照批示生成相应的cookie。

但是纯正的客户端脚本如JavaScript或许VBScript也可以生成cookie。

而cookie的经常使用是由阅读器依照必定的准则在后盾智能发送给主机的。

阅读器审核一切存储的cookie，假设某个cookie所申明的作用范畴大于等于将要恳求的资源所在的位置，则把该cookie附在恳求资源的HTTP恳求头上发送给主机。

意思是麦当劳的会员卡只能在麦当劳的店里出示，假设某家分店还发行了自己的会员卡，那么进这家店的时刻除了要出示麦当劳的会员卡，还要出示这家店的会员卡。

cookie的内容关键包括：名字，值，过时时期，门路和域。

其中域可以指定某一个域比如，相当于总店招牌，比如宝洁公司，也可以指定一个域下的详细某台机器比如或许，可以用飘柔来做比。

门路就是跟在域名前面的URL门路，比如/或许/foo等等，可以用某飘柔专柜做比。

门路与域合在一同就形成了cookie的作用范畴。

假设不设置过时时期，则示意这个cookie的生命期为阅读器会话时期，只需封锁阅读器窗口，cookie就隐没了。

这种生命期为阅读器会话期的cookie被称为会话cookie。

会话cookie普通不存储在硬盘上而是保管在内存里，当然这种行为并不是规范规则的。

假设设置了过时时期，阅读器就会把cookie保管到硬盘上，封锁后再次关上阅读器，这些cookie依然有效直到超越设定的过时时期。

存储在硬盘上的cookie可以在不同的阅读器进程间共享，比如两个IE窗口。

而关于保管在内存里的cookie，不同的阅读器有不同的处置方式。

关于IE，在一个关上的窗口上按Ctrl-N（或许从文件菜单）关上的窗口可以与原窗口共享，而经常使用其余方式新开的IE进程则不能共享曾经关上的窗口的内存cookie；关于Mozilla Firefox0.8，一切的进程和标签页都可以共享雷同的cookie。

普通来说是用javascript的关上的窗口会与原窗口共享内存cookie。

阅读器关于会话cookie的这种只认cookie不认人的处置方式经常给驳回session机制的web运行程序开发者形成很大的困扰。

上方就是一个goolge设置cookie的照应头的例子HTTP/1.1 302 FoundLocation:PREF=ID=0565f77e132de138:NW=1:TM=:LM=:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=-Type: text/html这是经常使用HTTPLook这个HTTP Sniffer软件来俘获的HTTP通讯纪录的一局部阅读器在再次访问goolge的资源时智能向外发送cookie经常使用Firefox可以很容易的观察现有的cookie的值经常使用HTTPLook配合Firefox可以很容易的了解cookie的上班原理。

IE也可以设置在接受cookie前征询这是一个征询接受cookie的对话框。

四、了解session机制session机制是一种主机端的机制，主机经常使用一种相似于散列表的结构（也或许就是经常使用散列表）来保管信息。

当程序须要为某个客户端的恳求创立一个session的时刻，主机首先审核这个客户端的恳求里能否已蕴含了一个session标识 - 称为session id，假设已蕴含一个session id则说明以前曾经为此客户端创立过session，主机就依照session id把这个session检索进去经常使用（假设检索不到，或许会新建一个），假设客户端恳求不蕴含session id，则为此客户端创立一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到法令以仿制的字符串，这个session id将被在本次照应中前往给客户端保管。

保管这个session id的方式可以驳回cookie，这样在交互环节中阅读器可以智能的依照规则把这个标识施展给主机。

普通这个cookie的名字都是相似于SEEESIONID，而。

比如weblogic关于web运行程序生成的cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-，它的名字就是JSESSIONID。

由于cookie可以被人为的制止，必定有其余机制以便在cookie被制止时依然能够把session id传递回主机。

经常被经常使用的一种技术叫做URL重写，就是把session id间接附加在URL门路的前面，附加方式也有两种，一种是作为URL门路的附加信息，体现方式为!-另一种是作为查问字符串附加在URL前面，体现方式为!-这两种方式关于用户来说是没有区别的，只是主机在解析的时刻处置的方式不同，驳回第一种方式也无利于把session id的信息和反常程序参数区离开来。

为了在整个交互环节中一直坚持形态，就必定在每个客户端或许恳求的门路前面都蕴含这个session id。

另一种技术叫做表单暗藏字段。

就是主机会智能修正表单，参与一个暗藏字段，以便在表单提交时能够把session id传递回主机。

比如上方的表单<form action=/xxx><input type=text></form>在被传递给客户端之前将被改写成<form action=/xxx><input type=hidden value=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-><input type=text></form>这种技术如今已较少运行，笔者接触过的很新鲜的iPlanet6(SunONE运行主机的前身)就经常使用了这种技术。

实践上这种技术可以繁难的用对action运行URL重写来替代。

在议论session机制的时刻，经常听到这样一种曲解“只需封锁阅读器，session就隐没了”。

其实可以构想一下会员卡的例子，除非顾客被动对店家提出销卡，否则店家相对不会随便删除顾客的资料。

对session来说也是一样的，除非程序通知主机删除一个session，否则主机会不时保管，程序普通都是在用户做log off的时刻发个指令去删除session。

但是阅读器素来不会被动在封锁之前通知主机它将要封锁，因此主机基本不会无时机知道阅读器曾经封锁，之所以会有这种错觉，是大局部session机制都经常使用会话cookie来保管session id，而封锁阅读器后这个session id就隐没了，再次衔接主机时也就无法找到原来的session。

假设主机设置的cookie被保管到硬盘上，或许经常使用某种手腕改写阅读器收回的HTTP恳求头，把原来的session id发送给主机，则再次关上阅读器依然能够找到原来的session。

恰好是由于封锁阅读器不会造成session被删除，迫使主机为seesion设置了一个失效时期，当距离客户端上一次性经常使用session的时期超越这个失效时期时，主机就可以以为客户端曾经中止了活动，才会把session删除以节俭存储空间。

五、了解是Java平台对session机制的成功规范，由于它仅仅是个接口，详细到每个web运行主机的提供商，除了对规范允许之外，依然会有一些规范里没有规则的纤细差异。

这里咱们以BEA的Weblogic Server8.1作为例子来展示。

首先，Weblogic Server提供了一系列的参数来管理它的HttpSession的成功，包括经常使用cookie的开关选项，经常使用URL重写的开关选项，session耐久化的设置，session失效时期的设置，以及针对cookie的各种设置，比如设置cookie的名字、门路、域，cookie的生活时期等。

普通状况下，session都是存储在内存里，当主机进程被中止或许重启的时刻，内存里的session也会被清空，假设设置了session的耐久化个性，主机就会把session保管到硬盘上，当主机进程从新进行或这些信息将能够被再次经常使用，Weblogic Server允许的耐久性方式包括文件、数据库、客户端cookie保管和复制。

复制严厉说来不算耐久化保管，由于session实践上还是保管在内存里，不过雷同的信息被复制到各个cluster内的主机进程中，这样即使某个主机进程中止上班也依然可以从其余进程中取得session。

cookie生活时期的设置则会影响阅读器生成的cookie能否是一个会话cookie。

自动是经常使用会话cookie。

有兴味的可以用它来实验咱们在第四节里提到的那个曲解。

cookie的门路关于web运行程序来说是一个十分关键的选项，Weblogic Server对这个选项的自动处置方式使得它与其余主机有显著的区别。

前面咱们会专题探讨。

关于session的设置参考5]六、HttpSession经常出现疑问（在本小节中session的含意为⑤和⑥的混合）1、session在何时被创立一个经常出现的曲解是以为session在有客户端访问时就被创立，但是理想是直到某server端程序调用(true)这样的语句时才被创立，留意假设JSP没有显示的经常使用 <%@page session=false%> 封锁session，则JSP文件在编译成Servlet时将会智能加上这样一条语句HttpSession session = (true);这也是JSP中隐含的session对象的来历。

由于session会消耗内存资源，因此，假设不计划经常使用session，应该在一切的JSP中封锁它。

2、session何时被删除综合前面的探讨，session在下列状况下被删除a.程序调用();或b.距离上一次性收到客户端发送的session id时时期隔超越了session的超时设置;或c.主机进程被中止（非耐久session）3、如何做到在阅读器封锁时删除session严厉的讲，做不到这一点。

可以做一点致力的方法是在一切的客户端页面里经常使用javascript代码来监督阅读器的封锁举措，而后向主机发送一个恳求来删除session。

但是关于阅读器解体或许强行杀死进程这些十分规手腕依然无能为力。

4、有个HttpSessionListener是怎样回事你可以创立这样的listener去监控session的创立和销毁事情，使得在出现这样的事情时你可以做一些相应的上班。

留意是session的创立和销毁举措触发listener，而不是相反。

相似的与HttpSession无关的listener还有HttpSessionBindingListener，HttpSessionActivationListener和HttpSessionAttributeListener。

5、寄存在session中的对象必定是可序列化的吗不是必需的。

要求对象可序列化只是为了session能够在集群中被复制或许能够耐久保管或许在必要时server能够临时把session替换出内存。

在Weblogic Server的session中搁置一个无法序列化的对象在管理台上会收到一个正告。

我所用过的某个iPlanet版本假设session中有无法序列化的对象，在session销毁时会有一个Exception，很奇异。

6、如何能力正确的接待客户端制止cookie的或许性对一切的URL经常使用URL重写，包括超链接，form的action，和重定向的URL，详细做法参见6]、开两个阅读器窗口访问运行程序会经常使用同一个session还是不同的session参见第三小节对cookie的探讨，对session来说是只认id不认人，因此不同的阅读器，不同的窗口关上方式以及不同的cookie存储方式都会对这个疑问的答案有影响。

8、如何防止用户关上两个阅读器窗口操作造成的session凌乱这个疑问与防止表单屡次提交是相似的，可以经过设置客户端的令牌来处置。

就是在主机每次生成一个不同的id前往给客户端，同时保管在session里，客户端提交表单时必定把这个id也前往主机，程序首先比拟前往的id与保管在session里的值能否分歧，假设不分歧则说明本次操作曾经被提交过了。

可以参看《J2EE外围形式》关于示意层形式的局部。

须要留意的是关于经常使用javascript 关上的窗口，普通不设置这个id，或许经常使用独自的id，以防主窗口无法操作，倡导不要再关上的窗口里做修正操作，这样就可以不用设置。

9、为什么在Weblogic Server中扭转session的值后要从新调用一次性做这个举措关键是为了在集群环境中揭示Weblogic Server session中的值出现了扭转，须要向其余主机进程复制新的session值。

10、为什么session不见了扫除session反常失效的要素之外，主机自身的或许性应该是微不足道的，只管笔者在iPlanet6SP1加若干补丁的Solaris版本上倒也遇到过；阅读器插件的或许性次之，笔者也遇到过3721插件形成的疑问；实践上防火墙或许代理主机在cookie处置上也有或许会出现疑问。

出现这一疑问的大局部要素都是程序的失误，最经常出现的就是在一个运行程序中去访问另外一个运行程序。

咱们在下一节探讨这个疑问。

七、跨运行程序的session共享经常有这样的状况，一个大名目被宰割成若干小名目开发，为了能够互不搅扰，要求每个小名目作为一个独自的web运行程序开发，可是到了最后突然发现某几个小名目之间须要共享一些信息，或许想经常使用session来成功SSO(single sign on)，在session中保管login的用户信息，最人造的要求是运行程序间能够访问彼此的session。

但是依照Servlet规范，session的作用范畴应该仅仅限于以后运行程序下，不同的运行程序之间是不能够相互访问对方的session的。

各个运行主机从实践成果上都遵守了这一规范，但是成功的细节却或许各有不同，因此处置跨运行程序session共享的方法也各不相反。

首先来看一下Tomcat是如何成功web运行程序之间session的隔离的，从Tomcat设置的cookie门路来看，它对不同的运行程序设置的cookie门路是不同的，这样不同的运行程序所用的session id是不同的，因此即使在同一个阅读器窗口里访问不同的运行程序，发送给主机的session id也可以是不同的。

依据这个个性，咱们可以推测Tomcat中session的内存结构大抵如下。

笔者以前用过的iPlanet也驳回的是雷同的方式，预计SunONE与iPlanet之间不会有太大的差异。

关于这种方式的主机，处置的思绪很繁难，实践履行起来也不难。

要么让一切的运行程序共享一个session id，要么让运行程序能够取得其余运行程序的session id。

iPlanet中有一种很繁难的方法来成功共享一个session id，那就是把各个运行程序的cookie门路都设为/（实践上应该是/NASApp，关于运行程序来讲它的作用相当于根）。

<session-info><path>/NASApp</path></session-info>须要留意的是，操作共享的session应该遵照一些编程商定，比如在session attribute名字的前面加上运行程序的前缀，使得setAttribute(name, neo)变成setAttribute(, neo)，以防止命名空间抵触，造成相互笼罩。

在Tomcat中则没有这么繁难的选用。

在Tomcat版本3上，咱们还可以有一些手腕来共享session。

关于版本4以上的Tomcat，目前笔者尚未发现繁难的方法。

只能借助于第三方的力气，比如经常使用文件、数据库、JMS或许客户端cookie，URL参数或许暗藏字段等手腕。

咱们再看一下Weblogic Server是如何处置session的。

从截屏画面上可以看到Weblogic Server对一切的运行程序设置的cookie的门路都是/，这是不是象征着在Weblogic Server中自动的就可以共享session了呢？但是一个小实验即可证实即使不同的运行程序经常使用的是同一个session，各个运行程序依然只能访问自己所设置的那些属性。

这说明Weblogic Server中的session的内存结构或许如下关于这样一种结构，在session机制自身过去处置session共享的疑问应该是无法能的了。

除了借助于第三方的力气，比如经常使用文件、数据库、JMS或许客户端cookie，URL参数或许暗藏字段等手腕，还有一种较为繁难的做法，就是把一个运行程序的session放到ServletContext中，这样另外一个运行程序就可以从ServletContext中取得前一个运行程序的援用。

示例代码如下，运行程序(appA, session); 运行程序BcontextA = (/appA);HttpSession sessionA = (HttpSession)(appA); 值得留意的是这种用法无法移植，由于依据ServletContext的JavaDoc，运行主机可以处于安保的要素关于(/appA);前往空值，以上做法在Weblogic Server 8.1中经过。

那么Weblogic Server为什么要把一切的运行程序的cookie门路都设为/呢？原来是为了SSO，凡是共享这个session的运行程序都可以共享认证的信息。

一个繁难的实验就可以证实这一点，修正首先登录的那个运行程序的形容符，把cookie门路修正为/appA访问另外一个运行程序会从新要求登录，即使是反过去，先访问cookie门路为/的运行程序，再访问修正过门路的这个，只管不再揭示登录，但是登录的用户信息也会失落。

留意做这个实验时认证方式应该经常使用FORM，由于阅读器和web主机对basic认证方式有其余的处置方式，第二次恳求的认证不是经过session来成功的。

详细请参看7] secion 14.8 Authorization，你可以修正所附的示例程序来做这些实验。

八、总结session机制自身并不复杂，但是其成功和性能上的灵敏性却使得详细状况复杂多变。

这也要求咱们不能把仅仅某一次性的阅历或许某一个阅读器，主机的阅历当作广泛实用的阅历，而是一直须要详细状况详细剖析。