详解cookie、session、token关于前后端的那些事（强烈推荐）

最新推荐文章于 2024-07-03 16:30:47 发布

Army-海军

最新推荐文章于 2024-07-03 16:30:47 发布

阅读量1.8w

点赞数 38

分类专栏： JavaScript 文章标签： session cookie token

本文链接：https://blog.csdn.net/weixin_41229588/article/details/106801062

版权

JavaScript 专栏收录该内容

50 篇文章 17 订阅

订阅专栏

http协议是无状态协议，cookie、session、token可以帮助服务器区分到底是谁在访问

session

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

现在的在线购物网站，需要登录的网站等等，马上就面临一个问题，那就是要管理会话，必须记住哪些人登录系统，哪些人往自己的购物车中放商品，也就是说我必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是无状态的，所以想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字串，每个人收到的都不一样，每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来，这样我就能区分开谁是谁了，每个人只需要保存自己的session id，而服务器要保存所有人的session id ！如果访问服务器多了，就得由成千上万，甚至几十万个。

这对服务器说是一个巨大的开销，严重的限制了服务器扩展能力，比如说我用两个机器组成了一个集群，小F通过机器A登录了系统，那session id会保存在机器A上，假设小F的下一次请求被转发到机器B怎么办？机器B可没有小F的 session id啊。

有时候会采用： session sticky ，就是让小F的请求一直粘连在机器A上，但是这也不管用，要是机器A挂掉了，还得转到机器B去。

那只好做session 的复制了，把session id 在两个机器之间搬来搬去。

后来有个叫Memcached的支了招：把session id 集中存储到一个地方，所有的机器都来访问这个地方的数据，这样一来，就不用复制了，但是增加了单点失败的可能性，要是那个负责session 的机器挂了，所有人都得重新登录一遍。

也尝试把这个单点的机器也搞出集群，增加可靠性，但不管如何，这小小的session 对后台来说是一个沉重的负担

Token

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

1.用户通过用户名和密码向服务端发送请求

2.服务端通过验证，生成一个token发送给客户端

3.客户端保存token，发送请求时带上token

4.服务器通过验证，返回数据

token的优势

1.无状态、可扩展

2.支持移动设备

3.跨程序调用

4.安全

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

比如说，小F已经登录了系统，我给他发一个令牌(token)，里边包含了小F的 user id，下一次小F 再次通过Http 请求访问我的时候，把这个token 通过Http header 带过来不就可以了。

带过来之后就可以通过user id 查到他的权限和和他相关各种数据返回了了。

安全性

对数据做一个签名，比如说HMAC-SHA256 算法，加上一个只有我才知道的密钥，对数据做一个签名，把这个签名和数据一起作为token ，由于密钥别人不知道，就无法伪造token了。

这个token 我不保存，当用户把这个token 给我发过来的时候，我再用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名，和token 中的签名做个比较，如果相同，我就知道用户已经登录过了，并且可以直接取到该用户的的user id , 如果不相同，数据部分肯定被人篡改过，就证明这个人没有登录

这样还是维持了http 无状态情况，机器集群现在可以轻松地做水平扩展，用户访问量增大，直接加机器就行。

cookie和session的区别就是保存在了前端。而session保存在了后端，两者都是后端生成。具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的。cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session， session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie

单个cookie保存的数据不能超过4k,很多浏览器都限制一个站点最多保存20个cookie。

可以将登陆信息等重要信息存放为session。

使用cookie的缺点

如果浏览器使用的是 cookie，那么所有的数据都保存在浏览器端，

cookie可以被用户禁止
cookie不安全(对于敏感数据，需要加密)
cookie只能保存少量的数据(大约是4k)，cookie的数量也有限制(大约是几百个)，不同浏览器设置不一样，反正都不多
cookie只能保存字符串
对服务器压力小

使用session的缺点

一般是寄生在Cookie下的，当Cookie被禁止，Session也被禁止

当然可以通过url重写来摆脱cookie

当用户访问量很大时，对服务器压力大

我们现在知道session是将用户信息储存在服务器上面,如果访问服务器的用户越来越多,那么服务器上面的session也越来越多, session会对服务器造成压力，影响服务器的负载.如果Session内容过于复杂，当大量客户访问服务器时还可能会导致内存溢出。

用户信息丢失, 或者说用户访问的不是这台服务器的情况下,就会出现数据库丢失.

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

Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。
CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。