版权声明:版权声明:本文为博主原创文章,未经博主允许不得转载。https://blog.csdn.net/Strive_0902/article/details/82927750

HTTP是一种无状态的协议,为了分辨链接是谁发起的,需自己去解决这个问题。不然有些情况下即使是同一个网站每打开一个页面也都要登录一下。而Session和Cookie就是为解决这个问题而提出来的两个机制。

session机制保持回话

  • 存在服务器的一种用来存放用户数据的类HashTable结构。
  • 浏览器第一次发送请求时,服务器自动生成了一HashTable和一Session ID来唯一标识这个HashTable,并将其通过响应发送到浏览器。浏览器第二次发送请求会将前一次服务器响应中的Session ID放在请求中一并发送到服务器上,服务器从请求中提取出Session ID,并和保存的所有Session ID进行对比,找到这个用户对应的HashTable。一般这个值会有个时间限制,超时后毁掉这个值,默认30分钟。
  • 当用户在应用程序的 Web页间跳转时,存储在 Session 对象中的变量不会丢失而是在整个用户会话中一直存在下去。
  • Session的实现方式和Cookie有一定关系。建立一个连接就生成一个session id,打开几个页面就好几个了,这里就用到了Cookie,把session id存在Cookie中,每次访问的时候将Session id带过去就可以识别了.

存在的问题
- 高并发情况下,会占用服务器大量内存
- 分布式(一个业务分成几个子业务,部署在多个服务器)或者集群(一个业务部署在多个服务器)的时候,session不能共享。

解决方案

  • 高并发的时候可以将session存储到redis,如果用户长时间没有访问,将session存储到redis,就减少了服务器的压力
  • 分布式或者集群的时候,先通过redis来判断用户状态也可以实现session共享.

cookie机制保持会话

使用的方法

  • 登录验证后,创建登录凭证(比如:用户id+登录时间+过期时间),将登录凭证进行加密(为了避免暴露信息),加密后写到浏览器的cookie,以后,每次请求都发送cookie,服务器根据对应的解密算法对其进行验证(或者将加密过的cookie内容存储到数据库,请求服务器的时候,服务器在数据库进行查找)。存储在硬盘上的

存在的问题

  • 每次访问都提交cookie,增加请求量
  • 其他访问可能需要cookie(比如说购物车的信息存放在cookie),浏览器对每个域存储的cookie的大小有限制,那么需要控制加密后的凭证。

token机制保持会话

使用方法

  • cookie和session依赖于浏览器,如果客户端不是浏览器,那么需要手动添加token(和cookie类似,也是登录凭证),将token添加到httpheader或者做为参数添加到url。

存在的问题

  • 每次访问的时候手动添加token
  • 和cookie 的方式一样增加了请求量

相同点

  • 所有的方式目的都是为了验证用户状态。
  • 都需要在客户端存储凭证。

不同点

  • session是通过是通过空间换时间,消耗内存存储session对象,但是判断用户状态不用复杂的逻辑。cookie和token用时间换空间,在服务器端逻辑处理进行判断用户状态。
  • 存储数据量方面:session 能够存储任意的 java 对象,cookie 只能存储 String 类型的对象
  • 一个在客户端一个在服务端。因Cookie在客户端所以可以编辑伪造,不是十分安全。
  • Session过多时会消耗服务器资源,大型网站会有专门Session服务器,Cookie存在客户端没问题

 

10-02 19:24