HTTP之Cookie和Session

1. Cookie

HTTP 协议是一种无状态的协议,也就是说,当前的 HTTP 请求与以前的 HTTP 请求没有任何联系。显然,这种无状态的情形在某些时候将让用户觉得非常麻烦,比如在网上商城购物时,每购买一个商品都要重新输入一次用户名和密码,用户很快就会失去耐心,而且反复的输入也产生了更大的风险。所以,Web 访问通过使用 Cookie 和 Session 解决这个问题。

当你浏览某网站时,网站服务器会通过在响应消息中设置一个指示信息要求客户端在用户机器上存储一个小文本文件,即 Cookie,用来记录你的用户 ID、密码、浏览过的网页、停留的时间以及其他浏览或请求过的信息等,当你再次来到该网站时,网站通过读取 Cookie,得知你的相关信息,就可以做出相应的动作。Cookie 中的内容大多经过了加密处理,因此我们看到的是一连串看似随机的字母和数字组合,只有服务器处理程序才知道它们真正的含义。

  • 当用户在浏览器中输入 URL,这时浏览器便会向网站主机发送一个读取网页的请求,在这个请求发送出去之前,浏览器先查看本地是否保存有此网站的 Cookie 文件。如果发现了 Cookie 文件,则将 Cookie 文件中的信息(一般都进行了加密)放在请求消息 Cookie 头中一起发送给服务器;如果没有发现Cookie 文件,则不会发送任何 Cookie 消息。
  • 假设客户端在发送请求时没有 Cookie 信息,网站服务器会认为用户时第一次访问这个网站,因此为用户在数据库中设置一个用户 ID,并记录与这次访问相关的一些信息(比如最近访问时间),然后服务器将用户 ID 和访问相关的信息包含在响应消息中返回给客户端(通过设置 Set-Cookie 扩展头来包含这个信息),客户端将获得的用户 ID 和这些信息保存在本地的一个 Cookie 文件里。
  • 如果客户端在发送请求时本地有 Cookie 文件,则把 Cookie 信息也发送给服务器,服务器收到 Cookie 信息后会根据里面的用户信息(比如用户 ID)去检索数据库中保存的对应信息。服务器在数据库中找到用户相关的信息后,会根据这次请求消息更新数据库中的信息,基于更新后的数据库信息返回一个专门针对这个用户的页面,同时返回的还有服务器更新过后的 Cookie 信息,客户端保存的 Cookie 文件将得到更新(比如 "最近访问时间" 发生了更新)。


Cookie 包含哪些信息不是规范的,各个网站都会有自己的保存内容。并且由于 Cookie 保存在客户端,存在一定的安全隐患,所以越来越多的网站趋向于尽量减少 Cookie 中包含信息的数量,很多网站只是将服务器生成的用户 ID 保存在 Cookie 文件中,而与用户相关的其他信息都保存在服务器的数据库中。

服务器要求客户端保存的 Cookie 信息传送到浏览器后,浏览器会根据本地的设置来决定是否保存 Cookie 文件。如果浏览器本地不允许保存 Cookie,那么浏览器在关闭后 Cookie 文件自动删除;如果允许保存,则 Cookie 文件在浏览器关闭后还会保存一段时间,这段时间的大小是由服务器在发送 Cookie 信息时就决定好的,主要通过服务器处理软件在 Cookie 信息的 Expiration(有效期)属性中进行指示,如果这个属性没有被设置,则浏览器默认此 Cookie 文件是不被保存的,即浏览器关闭后就删除。

Cookie 在 EFC 2965 中进行描述,每个客户端最多保持 300 个 Cookie,每个域名下最多 20 个 Cookie(实际上一般浏览器现在都比这个多,Firefow 是 50 个),而每个 Cookie 的大小最大为 4KB。

2. Session

2.1 什么是 Session?

除了使用 Cookie 来保持 HTTP 连接状态以外,Session 是另一种更为安全的方法。Session 从原始意思上讲是会话,如果放在 Web 访问中,是指用户通过浏览器进入某个网站时,从进入网站到浏览器关闭所经过的这段时间,也就是用户与网站一次 "会话" 的时间。这里介绍的 Session 是利用其定义来强调的一种保持用户访问状态的机制。

2.2 Session 工作机制

  • 当用户 A 打开浏览器,输入 URL 向服务器发出请求时,服务器为这个用户分配了一个全局唯一的标识,称为 Session ID,标识与这个用户的这次会话。
  • 这个 Session ID 可以保存在服务器的内容中,也可以写到文件里甚至数据库中,后者会增加每次读取 Session ID 的系统开销,但也能降低前者在停电或系统宕机情况下所带来的损失。
  • 如果在服务器为用户 A 提供网页的同时,另一个用户 B 也打开浏览器请求服务器提供服务,服务器会再为 B 分配一个 Session ID,这两个 Session ID 是不能相同的,通常服务器会使用散列函数为正在访问的不同用户产生各自的 Session ID,尽最大可能确保各个 ID 的全局唯一性。
  • 在为用户生成新的 Session ID 后,此 Session ID 会包含在响应消息中返回给浏览器。当用户下次访问服务器时就可以在请求中包含此 Session ID,服务器将收到的 Session ID 与数据库或文件中保存的 ID 进行比较,如果匹配则可以获知用户以前访问的信息以及相关的状态,否则将需要重新生成 Session ID 并返回给浏览器。

服务器将 Session ID 返回给浏览器的方法有以下两种:

  1. 一种是 Cookie 方法,即采用 HTTP 协议中的 Cookie 机制来实现,服务器端产生 Session ID 后,通过 Set-Cookie 扩展头将 Session ID 传送给浏览器,而浏览器此后的每一次请求都会在 Cookie 头里带上这个 ID.
  2. 由于 Cookie 可能被人为禁止,所以必须有其他机制以便在 Cookie 被禁止时仍然能够把 Session ID 传递回服务器,这样就产生了另一种 Session ID 传送方法,叫 URL 重写。就是服务器在返回用户请求的页面之前,将页面内所有的 URL 后面附上 Session ID,这样用户在收到响应之后,无论点击哪个链接,都会再带上 Session ID,从而就实现了会话的保持。把 Session ID 附加在 URL 后面的方式也有两种,一种是作为 URL 路径的附加信息,表现形式为http://../xxx;jsessionid=...;另一种是作为查询字符串附加在 URL 后面,表现形式为http://.../xxx?jsessionid=...。这两种方式对于用户来说是没有区别的,只是服务器在解析时的处理机制不同,采用第一种方式比较有利于把 Session ID 的信息和正常程序参数区分开来。

2.3 Session 的结束

前面说 Session 的定义是用户访问某网站到关闭浏览器的会话时间,但在实际 Web 访问中,关闭浏览器并不意味着 Session 真正结束了,因为 Session ID 还会保存在服务器中。要在服务器中清除 Session ID 的信息,需要浏览器主动发出一个结束 Session 的请求。比如点击网页上的 "注销"、"退出" 等链接,而很多用户一般都会在不想继续访问时直接关闭浏览器,所以 Session ID 在过期(服务器设置的一个时间)之前会作为一个隐患继续存在。不管是采用 Cookie 的方式还是采用 URL 重写的方式,都有这种 ID 遗留问题,如果攻击者获取了 Session ID,即使用户已经关闭了相关联的浏览器程序,他们仍然可以在请求中包含这个 ID 来访问服务器,获取用户的关键信息。

3. Session 和 Cookie 的差异

  1. 应用场景。Cookie 的典型应用场景是 Remember Me 服务,即用户包括账号在内的关键信息通过 Cookie 文件的形式保存在客户端,当用户再次请求匹配的 URL 的时候,Cookie 信息会被传送到服务端,交由相应的程序完成自动登录等功能;Session 的典型应用场景是用户登录某网站之后,服务器将其登录信息以及其他关键信息放入由一个 Session ID 关联的数据库或文件中,在以后的每次请求中都检验 Session ID 来确保该用户合法。
  2. 安全性。Cookie 将一些信息保存在客户端,如果不进行加密的话,无疑会暴露一些隐私信息,安全性很差,一般情况下敏感信息是经过加密后存储在 Cookie 中,但也很容易被窃取。而 Session 主要将信息存储在服务器端,如果存储在文件或数据库中,也有被窃取的可能,只是这种可能性非常小。Session 与 Cookie 在安全性方面都存在会话劫持的问题,即在网络通信中被攻击者捕获而用来冒充真正用户。总体来讲,Session 的安全性要高于 Cookie。
  3. 性能。Cookie 存储在客户端,消耗的是客户端的 I/O 和内存,而 Session 存储在服务器端,消耗的是服务器端的资源。但是 Session 对服务器造成的压力比较集中,而 Cookie 很好地分散了资源消耗,就这点来说,Cookie 是要优于 Session 的。
  4. 时效性。Cookie 可以通过设置有效期使其在较长时间内存在于客户端,而 Session 一般只有比较短的有效期(用户主动清除 Session 或过期超时)。
  5. 其他。Cookie 的处理在开发中没有 Session 方便,而且 Cookie 在客户端是有数量和大小的限制的,而 Session 的大小却只以硬件为限制,能存储的数据无疑大了许多。

猜你喜欢

转载自www.cnblogs.com/jimodetiantang/p/9157935.html
今日推荐