51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 1136|回复: 0
打印 上一主题 下一主题

[转贴] 面试高频题cookie、session和token的区别,你知道么?

[复制链接]
  • TA的每日心情
    无聊
    昨天 09:04
  • 签到天数: 1044 天

    连续签到: 2 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2022-3-17 10:30:46 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    在以往的面试记录里,我又看到了一个多次被问到的知识点,那就是 cookie、session、token 的区别有哪些?如果现在来问你,不知道你能否说清楚呢?
      今天不仅仅是整理出这三者的区别,更重要的是能够真正去理解这三者之间的作用和联系。
      cookie、session、token三者联系
      在互联网里,一样事物的诞生往往是为了解决某种问题,这句话同样适用于此。
      其实说到底,cookie、session、token 都围绕了一个点:身份认证。

      为什么要认证
      很简单,比如电商购物网站需要登录。在输入账号密码点击登录之后,对服务器就产生了一次会话 session,就像你我之间进行了一次交谈,我根据你的名字样貌记住了你。那么服务器也需要能够记住你,需要把大家区分开来。
      但是,由于http协议是无状态的,已经登录过的用户没法通过协议层把状态保存下来,所以下次再请求的时候,服务器还是不知道你是谁。
      有什么办法呢?

      Session
      当服务器收到登录请求之后,生成一个 session id 一起返回给客户端,客户端下次再请求的时候把 session id 一起带上。这时候每个客户端请求对应各自的 session id ,服务就知道怎么区分了。

      Cookie
      而客户端与服务器之间的会话,一般会使用 Cookie 来管理。
      服务在向客户端返回响应时,会在首部字段Set-Cookie内写入 Session ID(如 PHPSESSID=028a8c…)。

    客户端接收到从服务器端发来的 Session ID 后,会将其作为 Cookie 保存在本地。
      比如我登录了一个论坛,浏览器 F12 就可以看到保存在本地的 cookie。

    产生的问题
      由于服务器也要保存这 session信息用于跟客户端传过来的进行比对,数量小了还好,请数量大了,服务器要保存的内容页就越多,会吃不消。
      此外,还会影响服务器的拓展能力。比如服务由2台机器组成一个集群,而我之前登录后,session id保存在服务器A上,但是下次请求如果发送到服务器B就不行了,因为人家没存,所以不认。
      还会有如下等问题:
      对于非浏览器的客户端、手机移动端等不适用,因为session依赖于cookie,而移动端经常没有cookie;
      因为session认证本质基于cookie,所以如果cookie被截获,用户很容易收到跨站请求伪造攻击。并且如果浏览器禁用了cookie,这种方式也会失效;
      前后端分离系统中更加不适用,后端部署复杂,前端发送的请求往往经过多个中间件到达后端,cookie中关于session的信息会转发多次;
      由于基于Cookie,而cookie无法跨域,所以session的认证也无法跨域,对单点登录不适用。
      服务器:唉!该死的 sessionid,要是可以不用该多好呀 o(╥﹏╥)o。

      Token
      嗯?其实这个事情核心在于身份认证,想个办法既能解决认证,又不用服务器保存不就好了:
      客户端使用用户名和密码请求登录;
      服务端收到请求,验证用户名和密码;
      验证成功后,服务端会签发一个 token 令牌,再把这个token返回给客户端;
      客户端收到 token 后可以把它存储起来,比如放到cookie中;
      客户端每次向服务端请求资源时需要携带服务端签发的 token,可以在 cookie 或者 header 中携带;
      服务端收到请求,然后去验证客户端请求里面带着的 token,如果验证成功,就向客户端返回请求数据。
      重点就是在于服务端可以不用保存 token。
      比如,当第一次收到客户端传过来的用户名和密码时,服务器认证通过后,通过加密算法生成一个字符串当做 token。当拿到后续请求中的 token,服务器再解析这个token,可以从中获取关键的信息,从而判断该token的有效性。
      目前接触到的大多数系统,都是基于token验证来的,因为它的优点更适合当下的系统应用环境:
      ·无状态,可以更方便扩展
      ·更安全,可以防止跨站请求伪造 CSRF
      ·方便多平台跨域
      ·可以标准化,比如基于JWT Json web token (JWT)



    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏1
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-13 01:26 , Processed in 0.062659 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表