cookie和session的区别

本文详细对比了Session与Cookie的工作机制,包括数据存储位置、数据类型、路径限制等关键特性。探讨了Session依赖Cookie进行会话跟踪的方法,以及当Cookie禁用时如何通过URL重写来实现会话管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1、session保存在服务器,客户端不知道其中的信息;cookie保存在客户端,服务器能够知道其中的信息。
2、session中保存的是对象,cookie中保存的是字符串。
3、session不能区分路径,同一个用户在访问一个网站期间,所有的session在任何一个地方都可以访问到。而cookie中如果设置 了路径参数,那么同一个网站中不同路径下的cookie互相是访问不到的。
4、session默认需要借助cookie才能正常工作。如果客户端完全禁止cookie,session,这种方法将失效。但是如果服务器端启用了url编码,也就是用URLEncoder.encode(“index.jsp?id=3”,”UTF-8”);..把所有的url编码了,则会在url后面出现如下类似的东西index.jsp:jsessionid=fdsaffjdlksfd124324lkdjsf?id=3服务器通过这个进行session的判断。
5 session在用户会话结束后就会关闭了,但cookie因为保存在客户端,可以长期保存
6 cookie:是服务端向客户端写入的小的片段信息。cookie信息保存在服务器缓存区,不会在客户端显现。当你第一次登陆一个网站,服务器向你的机器写得片段信息。你可以在Internet选项中找到存放cookie的文件夹。如果不删除,cookie就一直在这个文件夹中。

为什么会有cookie呢,大家都知道,http是无状态的协议,客户每次读取web页面时,服务器都打开新的会话,而且服务器也不会自动维护客户的上下文信息,那么要怎么才能实现网上商店中的购物车呢,session就是一种保存上下文信息的机制,它是针对每一个用户的,变量的值保存在服务器端,通过 SessionID来区分不同的客户,session是以cookie或URL重写为基础的,默认使用cookie来实现,系统会创造一个名为 JSESSIONID的输出cookie,我们叫做session cookie,以区别persistent cookies,也就是我们通常所说的cookie,注意session cookie是存储于浏览器内存中的,并不是写到硬盘上的,这也就是我们刚才看到的JSESSIONID,我们通常情是看不到JSESSIONID的,但是当我们把浏览器的cookie禁止后,WEB服务器会采用URL重写的方式传递Sessionid,我们就可以在地址栏看到sessionid= KWJHUG6JJM65HS2K6之类的字符串。
明白了原理,我们就可以很容易的分辨出persistent cookies和session cookie的区别了,网上那些关于两者安全性的讨论也就一目了然了,session cookie针对某一次会话而言,会话结束session cookie也就随着消失了,而persistent cookie只是存在于客户端硬盘上的一段文本(通常是加密的),而且可能会遭到cookie欺骗以及针对cookie的跨站脚本攻击,自然不如 session cookie安全了。
通常session cookie是不能跨窗口使用的,当你新开了一个浏览器窗口进入相同页面时,系统会赋予你一个新的sessionid,这样我们信息共享的目的就达不到了,此时我们可以先把sessionid保存在persistent cookie中,然后在新窗口中读出来,就可以得到上一个窗口SessionID了,这样通过session cookie和persistent cookie的结合我们就实现了跨窗口的session tracking(会话跟踪)。
在一些WEB开发的书中,往往只是简单的把Session和cookie作为两种并列的http传送信息的方式,session cookies位于服务器端,persistent cookie位于客户端,可是session又是以cookie为基础的,明白的两者之间的联系和区别,我们就不难选择合适的技术来开发WEB service了。

(1)
session总是放在服务器上的,每个客户会跟一个sessionID对应。因为HTTP是无连接的,如何区分同一个客户的多次请求呢,就需要客户端每次发请求的时候,发送相应的sessionID。
通常情况下,sessionID在客户端以cookie的形式保存。如果浏览器静止了cookie,客户端再向服务器发请求的时候,就不会发送sessionID,因此服务器就会将这个请求作为一个新客户,所以就会出现session值丢失的假象。
这时候出现一个问题,如果客户浏览器不支持cookie,怎么办?J2EE提供的另一个办法就是URL重写,写超链接的时侯,总是用response.encodeURL(url),连接就会变成*.jsp?sessionID=……,完成了原来用cookie完成的功能。
J2EE建议,不论客户浏览器是否支持cookie,服务器端编程都建议使用URL重写。
(2)
web上用的都是非连接的网络协议
session 是存在服务器上的
每个session有一个唯一的session ID(为了标识他是那个客户端的)
在启动session的同时,会在客户端生成cookie,服务器把session ID加到cookie中
每次服务器和客户端交互的时候,就是从cookie中取得session ID 来定位服务器上的session
这样只要你的cookie不过期,服务器上有你的session,就不会出问题
(3)
JSP实现在浏览器关闭cookies情况下的会话管理
通常,会话管理是通过服务器将 Session ID 作为一个 cookie 存储在用户的 Web 浏览器中来唯一标识每个用户会话。如果浏览器不支持 cookies,或者将浏览器设置为不接受 cookies,我们可以通过 URL 重写来实现会话管理。
  实质上 URL 重写是通过向 URL 连接添加参数,并把 session ID 作为值包含在连接中。然而,为使这生效,你需要为你的 servlet 响应部分的每个连接添加 session ID 。
   把 session ID 加到一个连接可以使用一对方法来简化:response.encodeURL() 使 URL 包含 session ID,如果你需要使用重定向,可以使用 response.encodeRedirectURL () 来对 URL 进行编码。
  encodeURL () 及 encodeRedirectedURL () 方法首先判断 cookies 是否被浏览器支持;如果支持,则参数 URL 被原样返回,session ID 将通过 cookies 来维持。
  来看下面的例子,两个 JSP 文件:hello1.jsp 和 hello2.jsp,及它们之间的影响。我们在 hello1.jsp 中简单的创建一个会话,并在 session 中存储一个对象实例。接着用户可以点击页面的连接到达 hello2.jsp。在 hello2.jsp 中,我们从 session 中获取原先放置的对象并显示它的内容。注意,我们在 hello1.jsp 中调用了 encodeURL() 方法来获得 hello2.jsp 的链接,使得在浏览器停用 cookies 的情况下,session ID 自动添加到 URL,hello2.jsp 仍能得到 session 对象。
  首先在启用 cookies 的情况下运行。然后关闭对 cookie 的支持,重启浏览器,再运行一次。每次你都可以看到会话管理在起作用,并能在页之间传递信息。
注意,如果你想让这个例子能在关闭了 cookies 的浏览器中工作,你的 JSP 引擎必须支持 URL 重写。

转自http://www.cnblogs.com/windows/articles/1605634.html

如果你创建了一个cookie,并将他发送到浏览器,默认情况下它是一个会话级别的cookie:存储在浏览器的内存中,用户退出浏览器之后被删除。如果你希望浏览器将该cookie存储在磁盘上,则需要使用maxAge,并给出一个以秒为单位的时间。将最大时效设为0则是命令浏览器删除该 cookie。
  发送cookie需要使用HttpServletResponse的addCookie方法,将cookie插入到一个 Set-Cookie HTTP请求报头中。由于这个方法并不修改任何之前指定的Set-Cookie报头,而是创建新的报头,因此我们将这个方法称为是addCookie,而非setCookie。同样要记住响应报头必须在任何文档内容发送到客户端之前设置。

session

session机制是一种服务器端的机制,服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。
  但程序需要为某个客户端的请求创建一个session的时候,服务器首先检查这个客户端的请求里是否包含了一个session标识-称为session id,如果已经包含一个session id则说明以前已经为此客户创建过session,服务器就按照session id把这个session检索出来使用(如果检索不到,可能会新建一个,这种情况可能出现在服务端已经删除了该用户对应的session对象,但用户人为地在请求的URL后面附加上一个JSESSION的参数)。
  如果客户请求不包含session id,则为此客户创建一个session并且生成一个与此session相关联的session id,这个session id将在本次响应中返回给客户端保存。

一个常见的错误是以为session在有客户端访问时就被创建,然而事实是直到某server端程序(如Servlet)调用HttpServletRequest.getSession(true)这样的语句时才会被创建。

内容概要:文章基于4A架构(业务架构、应用架构、数据架构、技术架构),对SAP的成本中心利润中心进行了详细对比分析。业务架构上,成本中心是成本控制的责任单元,负责成本归集与控制,而利润中心是利润创造的独立实体,负责收入、成本利润的核算。应用架构方面,两者都依托于SAP的CO模块,但功能有所区分,如成本中心侧重于成本要素归集预算管理,利润中心则关注内部交易核算获利能力分析。数据架构中,成本中心与利润中心存在多对一的关系,交易数据通过成本归集、分摊利润计算流程联动。技术架构依赖SAP S/4HANA的内存计算ABAP技术,支持实时核算与跨系统集成。总结来看,成本中心利润中心在4A架构下相互关联,共同为企业提供精细化管理决策支持。 适合人群:从事企业财务管理、成本控制或利润核算的专业人员,以及对SAP系统有一定了解的企业信息化管理人员。 使用场景及目标:①帮助企业理解成本中心利润中心在4A架构下的运作机制;②指导企业在实施SAP系统时合理配置成本中心利润中心,优化业务流程;③提升企业对成本利润的精细化管理水平,支持业务决策。 其他说明:文章不仅阐述了理论概念,还提供了具体的应用场景技术实现方式,有助于读者全面理解并应用于实际工作中。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值