前言

Web诞生之初,功能比较单一:允许Internet上任意一个用户都可以从许多文档服务计算机的数据库中搜索和获取文档。服务器不需要记录谁在某一段时间里都浏览了什么文档,每次请求都是一个新的HTTP协议, 即请求加响应,服务器不用记住是谁刚刚发了HTTP请求, 每个请求对服务器来说都是全新的。

随着交互式Web应用的兴起,网站有了登录的需求,如在线购物网站,社交网站等等。这就面临一个问题,服务器必须记住哪些人登录了系统, 哪些人往自己的购物车中添加了商品, 也就是说服务器要识别每个用户。

因为HTTP请求是无状态的,所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串,每个用户收到的都不一样。 当用户向服务器发起HTTP请求的时候,带上这个字符串, 这样服务器就能识别不同的用户了。

所以就有了Session的引入,即服务端和客户端都保存一段文本,客户端每次发起请求都带着,这样服务器就知道客户端是否发起过请求。

这样,就导致客户端频繁向服务端发出请求数据,服务端频繁的去数据库查询用户名和密码并进行对比,判断用户名和密码正确与否。而Session的存储是需要空间的,频繁的查询数据库给服务器造成很大的压力。

随着Web移动端的兴起,这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。

基于服务器验证方式暴露的一些问题

1.Seesion:每次认证用户发起请求时,服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时,内存的开销也会不断增加。

2.可扩展性:在服务端的内存中使用Seesion存储登录信息,伴随而来的是可扩展性问题。

3.CORS(跨域资源共享):当我们需要让数据跨多台移动设备上使用时,跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源,就可以会出现禁止请求的情况。

4.CSRF(跨站请求伪造):用户在访问银行网站时,他们很容易受到跨站请求伪造的攻击,并且能够被利用其访问其他的网站。

于是有人就一直在思考, 服务器为什么要保存这些信息呢, 只让每个客户端去保存该多好?

在这种情况下,Token应用而生。

Token是服务端生成的一串字符串,以作客户端进行请求的一个令牌。当客户端第一次访问服务端,服务端会根据传过来的唯一标识userId,运用一些算法,并加上密钥,生成一个Token,然后通过BASE64编码一下之后将这个Token返回给客户端,客户端将Token保存起来(可以通过数据库或文件形式保存本地)。下次请求时,客户端只需要带上Token,服务器收到请求后,会用相同的算法和密钥去验证Token。

Cookie

cookie 是一个非常具体的东西,指的就是浏览器里面能永久存储的一种数据,仅仅是浏览器实现的一种数据存储功能。

cookie由服务器生成,发送给浏览器,浏览器把cookie以kv形式保存到某个目录下的文本文件内,下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的,所以浏览器加入了一些限制确保cookie不会被恶意使用,同时不会占据太多磁盘空间,所以每个域的cookie数量是有限的。

Cookie是客户端保存用户信息的一种机制,用来记录用户的一些信息,也是实现Session的一种方式。Cookie存储的数据量有限,且都是保存在客户端浏览器中。不同的浏览器有不同的存储大小,但一般不超过4KB。因此使用Cookie实际上只能存储一小段的文本信息。

例如:登录网站,今输入用户名密码登录了,第二天再打开很多情况下就直接打开了。这个时候用到的一个机制就是Cookie。

Session

session 从字面上讲,就是会话。这个就类似于你和一个人交谈,你怎么知道当前和你交谈的是张三而不是李四呢?对方肯定有某种特征(长相等)表明他就是张三。

Session是另一种记录客户状态的机制,它是在服务端保存的一个数据结构(主要存储的的SessionID和Session内容,同时也包含了很多自定义的内容如:用户基础信息、权限信息、用户机构信息、固定变量等),这个数据可以保存在集群、数据库、文件中,用于跟踪用户的状态。

客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

session 也是类似的道理,服务器要知道当前发请求给自己的是谁。为了做这种区分,服务器就要给每个客户端分配不同的“身份标识”,然后客户端每次向服务器发请求的时候,都带上这个“身份标识”,服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”,可以有很多种方式,对于浏览器客户端,大家都默认采用 cookie 的方式。

服务器使用session把用户的信息临时保存在了服务器上,用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全,可是session有一个缺陷:如果web服务器做了负载均衡,那么下一个操作请求到了另一台服务器的时候session会丢失。

用户第一次登录后,浏览器会将用户信息发送给服务器,服务器会为该用户创建一个SessionId,并在响应内容(Cookie)中将该SessionId一并返回给浏览器,浏览器将这些数据保存在本地。当用户再次发送请求时,浏览器会自动的把上次请求存储的Cookie数据自动的携带给服务器。

服务器接收到请求信息后,会通过浏览器请求的数据中的SessionId判断当前是哪个用户,然后根据SessionId在Session库中获取用户的Session数据返回给浏览器。

例如:购物车,添加了商品之后客户端处可以知道添加了哪些商品,而服务器端如何判别呢,所以也需要存储一些信息就用到了Session。

Cookie和Session比较

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话,那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案,客户来访的时候只需要查询客户档案表就可以了。

Session生成后,只要用户继续访问,服务器就会更新Session的最后访问时间,并维护该Session。为防止内存溢出,服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器,Session就自动失效了。

Token

在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中,tokens 是多用户下处理认证的最佳方式。

大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。

最简单的Token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,由Token的前几位+盐以哈希算法压缩成一定长的十六进制字符串,可以防止恶意第三方拼接Token请求服务器)

基于Token的验证原理

基于Token的身份验证是无状态的,我们不将用户信息存在服务器或Session中。

这种概念解决了在服务端存储信息时的许多问题,NoSession意味着你的程序可以根据需要去增减机器,而不用去担心用户是否登录。

使用基于 Token 的身份验证方法,在服务端不需要存储用户的登录记录。大概的流程是这样的:

  • 客户端使用用户名跟密码请求登录
  • 服务端收到请求,去验证用户名与密码
  • 验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端
  • 客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里或者数据库里
  • 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
  • 服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端返回请求的数据

每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ,让服务器能接受到来自所有域的请求。需要主要的是,在ACAO头部标明(designating)*时,不得带有像HTTP认证,客户端SSL证书和cookies的证书。

实现思路:

Tokens的优势

1.无状态、可扩展

在客户端存储的Tokens是无状态的,并且能够被扩展。基于这种无状态和不存储Session信息,负载负载均衡器能够将用户信息从一个服务传到其他服务器上。

如果我们将已验证的用户的信息保存在Session中,则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时,可能会造成

一些拥堵。

但是不要着急。使用tokens之后这些问题都迎刃而解,因为tokens自己hold住了用户的验证信息。

2.安全性

请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token,cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中,让我们少了对session操作。

token是有时效的,一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效,token有撤回的操作,通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。

3.可扩展性

Tokens能够创建与其它程序共享权限的程序。例如,能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时,我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens时,可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据,我们可以通过建立自己的API,得出特殊权限的tokens。

4.多平台跨域

我们提前先来谈论一下CORS(跨域资源共享),对应用程序和服务进行扩展的时候,需要介入各种各种的设备和应用程序。

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

只要用户有一个通过了验证的token,数据和资源就能够在任何域上被请求到。

          Access-Control-Allow-Origin: *       

App示例:

APP登录的时候发送加密的用户名和密码到服务器,服务器验证用户名和密码,如果成功,以某种方式比如随机生成32位的字符串作为Token,存储到服务器中,并返回Token到APP,以后APP请求时,凡是需要验证的地方都要带上该Token,然后服务器端验证Token,成功返回所需要的结果,失败返回错误信息,让他重新登录。

对于同一个APP同一个手机当前只有一个Token;手机APP会存储一个当前有效的Token。其中服务器上Token设置一个有效期,每次APP请求的时候都验证Token和有效期。

下面这个例子,可以很好的理解:

『给我来份煎饼(token我是你对面摊卖烤冷面的,scope赊账)』『好』
『鸡蛋(token我是你对面摊卖烤冷面的,scope赊账)』『好』
『再加个鸡蛋(token我是你对面摊卖烤冷面的,scope赊账)』『好』

最终得到一份普通煎饼,外加两个鸡蛋……

如果服务器重启或者因为其他理由,服务器端已保存token丢失。那么用户需 要重新登录和认证。

『给我来份煎饼(token我是你对面摊卖烤冷面的)』『那个……我没见过你』

如何理解Cookie、Session和Token相关推荐

  1. 彻底理解cookie,session,localStorage(附代码)

    2019独角兽企业重金招聘Python工程师标准>>> 1. cookie 1.1 什么是cookie cookie 是存储于访问者的计算机中的变量.每当同一台计算机通过浏览器请求某 ...

  2. 登录状态保持(cookie+session和token)

    http设计之初,登录状态保持, 就是无状态的,这段时间业务逻辑也非常简单,随着互联网时代的来临,用户量的增加,每次登录却无法状态保持,先出现了cookie,但是cookie存储在客户端的浏览器上,并 ...

  3. Cookie + Session登录-Token登录-SSO 单点登录-OAuth 第三方登录

    文章目录 1.Cookie + Session 登录 2. Cookie + Session 存在的问题 3.Token 登录认证 1. Token 机制实现流程 2. Token 机制的特点 3. ...

  4. IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

    1.前言 众所周之,IM是个典型的快速数据流交换系统,当今主流IM系统(尤其移动端IM)的数据流交换方式都是Http短连接+TCP或UDP长连接来实现.Http短连接主要用于从服务器读取各种持久化信息 ...

  5. 【转】彻底理解cookie,session,token

    转自:https://zhuanlan.zhihu.com/p/63061864 彻底理解cookie,session,token 发展史 1.很久很久以前,Web 基本上就是文档的浏览而已, 既然是 ...

  6. 为什么你学不会递归?告别递归,谈谈我的一些经验 关于集合中一些常考的知识点总结 .net辗转java系列(一)视野 彻底理解cookie,session,token...

    为什么你学不会递归?告别递归,谈谈我的一些经验 可能很多人在大一的时候,就已经接触了递归了,不过,我敢保证很多人初学者刚开始接触递归的时候,是一脸懵逼的,我当初也是,给我的感觉就是,递归太神奇了! 可 ...

  7. Cookie 、Session、Token理解以及常见问题总结

    目录 1 什么是 Cookie 和 Session 1.1 Cookie 1.2 Session 2 Cookie和Session的区别 3 Cookie 和 Session 是如何配合的 4 如何考 ...

  8. cookie、session、token理解

    Cookie是保存在浏览器上的一些数据,一般通过HTTP响应头set cookie来设置,当然也可以通过JS脚本来直接设置,Cookie是按照网站来进行组织和保存的,每一个网站都可以在浏览器中保存一些 ...

  9. 还分不清 Cookie、Session、Token、JWT?

    点击上方蓝色"方志朋",选择"设为星标" 回复"666"获取独家整理的学习资料! 转自:掘金   作者:秋天不落叶 juejin.im/po ...

  10. cookie、session以及token的定义、区别、使用环境

    Cookie Cookie 的工作原理 由于 HTTP 是一种无状态的协议,服务器单从网络连接上无从知道客户身份.怎么办呢?就给客户端们颁发一个通行证吧,每人一个,无论谁访问都必须携带自己通行证,这样 ...

最新文章

  1. 欢庆1024之:程序猿不是你想黑,想黑就能黑!
  2. CSS自学教程--一天搞定CSS(终篇总结)
  3. 对一千万条数据进行排序---编程珠玑第二版 第一章
  4. 【第一届“文翁杯”现场竞技赛】(校内“欢乐”赛)T1—洗刷刷(dp)
  5. Tomcat 的运行机制
  6. 知乎容器化构建系统设计和实践
  7. 【杭州】Hack for Cloud Beginner微软黑客松大赛
  8. Adobe正式在中国市场推出Creative Cloud创意应用软件
  9. TThread类详解转
  10. H3C交换机配置DHCP服务器
  11. OSChina 周五乱弹 ——大叔我还小,放过我吧
  12. SpringBoot 使用freemarker 处理文档,找不到文件位置(报错:basePackagePath=““ /* relatively to resourceLoaderClass pkg)
  13. fastLane 初试
  14. mqtt连接百度天工物接入平台
  15. 520程序员的浪漫表白
  16. CF1717D Madoka and The Corruption Scheme
  17. lower_bound()与upper_bound()
  18. 最新92kaifa开发的帝国cms7.5美nv主播视频网站源码 自适应手机端
  19. 学习臧圩人Java面试题解惑系列总结
  20. ECALL Switch/Ordinary模式

热门文章

  1. 深度学习推荐模型-DIN
  2. 无法启动QPCore Service
  3. 大数据分析平台的作用有什么
  4. 如何利用第三方数据进行大数据分析
  5. 企业如何提升数据质量
  6. 在线数据分析4大常用功能
  7. Python编程手册系列 - 日历、日期、时间相关内建模块详解
  8. java统计空间占用_如何计算Java对象占用了多少空间?
  9. T^T找数字(搜索+二进制枚举)
  10. 中介者模式php,PHP设计模式之中介者模式