当前位置:首页 > 数码 > HTTP协议中Cookie和Session的区别

HTTP协议中Cookie和Session的区别

admin5个月前 (05-14)数码21

引言

HTTP协议是一种无状态协议,这意味着服务器不知道客户端以前的请求。Cookie和Session是用来跟踪浏览器用户身份的会话方式,以弥补HTTP的无状态特性。

Cookie

Cookie是服务器发送到用户浏览器并保存在本地的一小块数据。它会在浏览器下次向同一服务器再发起请求时被携带。Cookie中保存已经登录过的用户信息,下次访问网站的时候,页面可以自动填写登录的一些基本信息。通常,它用于告知服务端两个请求是否来自于同一浏览器,如保持用户的登录状态。Cookie还能保存用户首选项,主题和其他设置信息。

Session

Session的作用是通过服务端记录用户的状态。一般我们会使用Cookie来管理Session,服务器第一次接收到请求时,生成一个SessionID,通过响应头的Set-Cookie命令设置SessionID字段,并向客户端发送要求设置Cookie的响应。客户端收到响应后,在本机保存一个包含SessionID字段的Cookie信息,接下来客户端每次向同一服务器发送请求时,请求头都会带上包含该SessionID的Cookie,然后服务器通过读取请求头中的Cookie,获取到此次请求的SessionID。

Cookie和Session的区别

HTTP协议
特征 Cookie Session
存放位置 客户端浏览器 服务器
安全性 较低 较高
数据大小 单个Cookie不能超过4K 无限制
数据类型 仅支持字符串数据 支持任意数据类型
有效期 可设置长时间 客户端关闭或Session超时失效

总结

Cookie和Session都是跟踪用户会话的有用机制,但它们有不同的特性和适用场景。Cookie适合存储小块的数据,如用户偏好,而Session适合存储动态数据,如购物车的物品。

Token是什么?和session、cookie相比,使用场景有什么区别?

在Web开发领域,相信大家对于Cookie和Session都很熟悉,Cookie和Session都是会话保持技术的解决方案。随着技术的发展,Token机制出现在我们面前,不过很多开发者对于Token和Cookie、Session的区别及使用场景分辨不清。

Cookie和Session的用途

要知道我们访问网站都是通过HTTP协议或HTTPS协议来完成的, HTTP协议它本身是无状态的协议 (即:服务器无法分辨哪些请求是来源于同个客户)。而业务层面会涉及到客户端与服务器端的交互(同网站下多个页面间能共享数据),此时服务器端必须要保持会话状态,这样才能进行用户身份的鉴别。

由于HTTP无状态的特性,如果要实话客户端和服务器端的会话保持,那就需要其它机制来实现,于是Cookie和Session应运而生。

通常情况下, Session和Cookie是搭配在一起使用的 。

Token是什么

上面说到的Session和Cookie机制来保持会话,会存在一个问题:客户端浏览器只要保存自己的SessionID即可,而 服务器却要保存所有用户的Session信息,这对于服务器来说开销较大,而且不利用服务器的扩展 (比如服务器集群时,Session如何同步存储就是个问题)!

于是有人思考,如果把Session信息让客户端来保管而且无法伪造不就可以解决这个问题了?进而有了Token机制。

Token俗称为“令牌” ,它的构成是:

Token机制下的认证流程

Token机制其实和Cookie机制极其相似 ,主要有以下流程:

1、用户登录进行身份认证,认证成功后服务器端生成Token返回给客户端;

2、客户端接收到Token后保存在客户端(可保存在Cookie、LocalStorage、SessionStorage中);

3、客户端再次请求服务器端时,将Token作为请求头放入Headers中;

4、服务器端接收请求头中的Token,将用户参数按照既定规则再进行一次签名,两次签名若一致则认为成功,反之数据存在篡改请求失败。

(生成签名示例图)

(验证签名示例图)

Token与Cookie+Session的区别

Cookie其实也充当的是令牌作用,但它是“有状态”的; 而Token令牌是无状态的,更利于分布式部署。

session和cookie

在讲Token之前,先简单说说什么是session和cookie。

Token

但是这里会有个问题, 服务器要保存所有用户的session信息,开销会很大,如果在分布式的架构下,就需要考虑session共享的问题,需要做额外的设计和开发 ,例如把session中的信息保存到Redis中进行共享;所以因为这个原因,有人考虑这些信息是否可以让客户端保存,可以保存到任何地方,并且保证其安全性,于是就有了Token。

Token是服务端生成的一串字符串,可以看做客户端进行请求的一个令牌。

基于Token的认证流程

整体的流程是这样的:

总结 希望我的回答,能够帮助到你!我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。

Token顾名思义就是令牌、凭证、钥匙 。只有这把钥匙,你才能打开门。token一般都是服务端生成,比如一个web系统,用户登录的时候,服务端校验用户名密码通过以后,会生成一个token,同时会生成refreshToken和一个过期时间。然后将refreshToken和token返回给客户端。客户端会将token保存下来。后续所有的请求都会携带这个token。服务端会判断当前token是否存在已经是否过期。如果token不存在或者过期就会拒绝本次请求。如果token过期怎么办,就用refreshToken刷新时间。当然这里可能还有别的方案。比如只生成token,每次请求的时候都刷新过期时间。如果长时间没有刷新过期时间,那token就会过期。

session就是回话,这是服务端的一种操作。当你第一次访问一个web网站的时候,服务端会生成一个session,并有一个sessionid和他对应。这个session是存储到内存中的,你可以向这个session中写入信息,比如当前登录用户的信息。sessionid会被返回到客户端,客户端一般采用cookie来保存。当然这个cookie不用人为写入。用tomcat容器来举个例子。 当后端调用HttpServletRequest对象的getSession的方法的时候,tomcat内部会生成一个jsessonid(tomcat sessionid的叫法)。这个jsessonid会随本次请求返回给客户端。响应头信息

这个jessionid就会写到cookie中。之后jessionid就会通过cookie传递到服务端。

这里我们就会很清楚了, session的数据是存储到内存中。那问题就来了,如果我们的服务是分布式部署,有多台机器的话,可能我们第一次登陆的时候,我们把用户的信息存储到了session,但是后面的请求到了B机器上,那B机器是获取不到用户的session的。另外就是session存储在内存中,那服务器重启,session就丢失了,这就是他的弊端。现在有一些技术,例如session共享、iphash、session持久等也可以解决上述问题 。

cookie是浏览器的一种策略。上述讲到了sessionid就是存储在cookie中的。我们知道http协议是无状态的,cookie就是用来解决这个问题的。cookie中可以用来保存服务端返回的一些用户信息的,例如前文提到的token、sessionid。每一次的请求,都会携带这些cookie。服务端从请求头中取到cookie中的信息,就可以识别本次请求的来源,这样,http是不是就变成有状态的了。

这里说几点cookie注意事项。

1、cookie存放在客户端,所以是不安全的。人为可以清除

3、cookie有大小的限制,4KB。

这个问题,网上有很多的答案,相信都看过了,估计也没有看明白。所以我就不去网上复制了,用自己的话,尽量说通俗,说重点。

cookie和session实际上是同一套认证流程,相辅相成。session保存在服务器,cookie保存在客户端。最常见的做法就是客户端的cookie仅仅保存一个sessionID,这个sessionID是一个毫无规则的随机数,由服务器在客户端登录通过后随机生产的。往后,客户端每次访问该网站都要带上这个由sessionID组成的cookie。服务器收到请求,首先拿到客户端的sessionID,然后从服务器内存中查询它所代表的客户端(用户名,用户组,有哪些权限等)。

与token相比,这里的重点是,服务器必须保存sessionID以及该ID所代表的客户端信息。这些内容可以保存在内存,也可以保存到数据库(通常是内存数据库)。

而token则可以服务器完全不用保存任何登录信息。

token的流程是这样的。客户端登录通过后,服务器生成一堆客户端身份信息,包括用户名、用户组、有那些权限、过期时间等等。另外再对这些信息进行签名。之后把身份信息和签名作为一个整体传给客户端。这个整体就叫做token。之后,客户端负责保存该token,而服务器不再保存。客户端每次访问该网站都要带上这个token。服务器收到请求后,把它分割成身份信息和签名,然后验证签名,若验证成功,就直接使用身份信息(用户名、用户组、有哪些权限等等)。

可以看出,相对于cookie/session机制,token机制中,服务器根本不需要保存用户的身份信息(用户名、用户组、权限等等)。这样就减轻了服务器的负担。

我们举个例来说,假如目前有一千万个用户登录了,在访问不同的网页。如果用cookie/session,则服务器内存(或内存数据库)中要同时记录1千万个用户的信息。每次客户端访问一个页面,服务器都要从内存中查询出他的登录信息。而如果用token,则服务器内存中不记录用户登录信息。它只需要在收到请求后,直接使用客户端发过来的登录身份信息。

可以这么说, cookie/session是服务器说客户端是谁,客户端才是谁。而token是客户端说我(客户端)是谁,我就是谁 。当然了,token是有签名机制的。要是客户端伪造身份,签名通不过。这个签名算法很简单,就是将客户端的身份信息加上一个只有服务器知道的盐值(不能泄露),然后进行md5散列算法(这里只是简化,方便理解,实际细节要稍复杂一些)。

cookie/session在单服务器,单域名时比较简单,否则的话,就要考虑如何将客户端的session保存或同步到多个服务器。还要考虑一旦宕机,内存中的这些信息是否会丢失。token因为服务器不保存用户身份,就不存在这个问题。这是token的优点。

token因为服务器不保存用户身份信息,一切都依赖当初那个签名。所以存在被盗用的风险。也就是说一旦盗用,服务器可能毫无办法,因为它只认签名算法。而session机制,服务器看谁不爽,可以随时把他踢出(从内存中删掉)。正是因为如此,token高度依赖过期时间。过期时间不能太长。过期短,可以减少被盗用的风险。

除了上面所说的,我个人认为,如果开发的系统足够小,倾向于使用cookie/session。如果系统同时登录用户多,集群服务器多,有单点登录需求,则倾向于使用token。

万维网的发展 历史

Token, 令牌,代表执行某些操作的权利的对象。

token主要用于鉴权使用,主要有以下几类:

cookie主要是网站用于在浏览器临时存放的数据,包括浏览器缓存数据以及服务器设定的一些数据,主要存放在浏览器端。

session主要用于保存会话数据,一般存储在服务器端,同时每一条session对用一个sessionID,sessionID是存放在浏览器的cookie中。

传统上的会话登陆和鉴权主要用session加cookie实现,随着分布式系统的快速演进,尤其是微服务的应用,token+cookie的授权访问机制得到亲睐,通常在用户登录后,服务器生成访问令牌(Access token),浏览器存储cookie中,在每次请求资源时都会在请求头中带上token,用于服务器授权访问使用。

Token和session都是web网站的会话保持、认证的解决方案;

既然都一样为什么还有token的说法。

从token产生的背景说起

1.移动端应用使得服务器端Session失效

2.分布式系统中Session无法共享

所以说session对于以上两种情况无效了,所以有了Token的说法

那么什么是token,token长什么样子?

先给大家一个直观的感受

token:PC-fa0be4a762-23-947-4f6496

说白了token保存就是用户的信息(不能保存密码等敏感信息)

token的组成:

客户端标识-USERCODE-USERID-CREATIONDATE-RONDEM[6位]

USERCODE,RONDEM[6位]经过MD5加密就变成了以上字符串

token的请求流程

请求流程解析

1.前端用户发送登录信息至认证系统

2.验证用户登录信息,判断用户是否存在

3.如果用户存在,生成token信息(客户端标识-USERCODE-USERID-CREATIONDATE-RONDEM[6位]),并存储在redis中

4.并将该token返回前端,附加至header

验证token

客户端

将token附加至header

服务端

最后总结一下

一般的垂直架构项目使用Session没有任何问题,但是分布式项目或涉及到移动端则考虑使用token。

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

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

cookie的组成有:名称(key)、值(value)、有效域(domain)、路径(域的路径,一般设置为全局:)、失效时间、安全标志(指定后,cookie只有在使用SSL连接时才发送到服务器(https))。下面是一个简单的js使用cookie的例子:

用户登录时产生cookie:

= id=+[id]+; path=/;

= name=+[name]+; path=/;

= avatar=+[avatar]+; path=/;

使用到cookie时做如下解析:

var cookie = ;var cookieArr = (;);var user_info = {};for(var i = 0; i < ; i++) {

user_info[cookieArr[i](=)[0]] = cookieArr[i](=)[1];

$(#user_name)(user_info[ name]);

$(#user_avatar)(src, user_info[ avatar]);

$(#user_id)(user_info[ id]);

token的意思是“令牌”,是用户身份的验证方式,最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串,可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token,避免多次查库

cookie 和session的区别

1、cookie数据存放在客户的浏览器上,session数据放在服务器上。

2、cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗

考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能

考虑到减轻服务器性能方面,应当使用COOKIE。

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

5、所以个人建议:

将登陆信息等重要信息存放为SESSION

其他信息如果需要保留,可以放在COOKIE中

token 和session 的区别

session 和 oauth token并不矛盾,作为身份认证 token安全性比session好,因为每个请求都有签名还能防止监听以及重放攻击,而session就必须靠链路层来保障通讯安全了。如上所说,如果你需要实现有状态的会话,仍然可以增加session来在服务器端保存一些状态

App通常用restful api跟server打交道。Rest是stateless的,也就是app不需要像browser那样用cookie来保存session,因此用session token来标示自己就够了,session/state由api server的逻辑处理。 如果你的后端不是stateless的rest api, 那么你可能需要在app里保存session.可以在app里嵌入webkit,用一个隐藏的browser来管理cookie session.

Session 是一种HTTP存储机制,目的是为无状态的HTTP提供的持久机制。所谓Session 认证只是简单的把User 信息存储到Session 里,因为SID 的不可预测性,暂且认为是安全的。这是一种认证手段。 而Token ,如果指的是OAuth Token 或类似的机制的话,提供的是 认证 和 授权 ,认证是针对用户,授权是针对App 。其目的是让 某App有权利访问 某用户 的信息。这里的 Token是唯一的。不可以转移到其它 App上,也不可以转到其它 用户 上。 转过来说Session 。Session只提供一种简单的认证,即有此 SID,即认为有此 User的全部权利。是需要严格保密的,这个数据应该只保存在站方,不应该共享给其它网站或者第三方App。 所以简单来说,如果你的用户数据可能需要和第三方共享,或者允许第三方调用 API 接口,用 Token 。如果永远只是自己的网站,自己的 App,用什么就无所谓了。

token就是令牌,比如你授权(登录)一个程序时,他就是个依据,判断你是否已经授权该软件;cookie就是写在客户端的一个txt文件,里面包括你登录信息之类的,这样你下次在登录某个网站,就会自动调用cookie自动登录用户名;session和cookie差不多,只是session是写在服务器端的文件,也需要在客户端写入cookie文件,但是文件里是你的浏览器编号的状态是存储在服务器端,客户端只有session id;而Token的状态是存储在客户端。

想要全面深入地掌握Token,我们需要先了解这些:Token的概念、身份验证过程、实现思路、使用场景,以及Cookie、Session、Token的区别。

内容纲要 Token的定义

Token是验证用户身份的一种方式,简称做“令牌”。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名,由token的前几位+盐,以哈希算法压缩成一定长的十六进制字符串,可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token,避免多次查库。

Token的身份验证过程

每一次请求都需要Token,Token应该在HTTP的头部发送,从而保证Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ,让服务器能接受到来自所有域的请求。

需要注意的是,在ACAO头部标明(designating)*时,不得带有像HTTP认证,客户端SSL证书和cookies的证书。

Token的实现思路

当我们在程序中认证了信息,并取得Token之后,我们便能通过这个Token做许多的事情。我们甚至能基于创建一个基于权限的token传给第三方应用程序,这些第三方程序能够获取到我们的数据(当然只有在我们允许的特定的token)。

Token的应用场景 Cookie和Session的区别

综合以上考量,建议方案:

Session和Cookie取长补短、配合使用,将登陆信息等重要信息存放为Session,其他信息如果需要保留,可以放在Cookie中。

Token 和 Session 的区别

Session和Token并不矛盾,作为身份认证,Token安全性比Session高,因为Token发送的每个请求都带有签名,能防止监听,以及重放攻击。而session就必须靠链路层来保障通讯安全。如上所说,如果需要实现有状态的会话,可以通过增加session,在服务器端保存一些状态。

App通常用Restful API跟server打交道。Rest是Stateless的,也就是App不需要像Browser那样用Cookie来保存Session,因此使用Session Token来标示就足够了。Session/state由API Server的逻辑处理。如果后端不是Stateless的rest API,那么可能需要在App里保存Session,可以在App里嵌入webkit,用一个隐藏的Browser来管理Cookie Session.

Session是一种HTTP存储机制,目的是为无状态的HTTP提供持久机制。 所谓的Session认证,只是简单的把User信息存储到Session里,因为SID的不可预测性,暂且认为是安全的,这是一种认证手段。

Session只提供一种简单的认证,即有此SID,以及User的全部权利。是需要严格保密的,这个数据只在使用站点保存,不可共享给其它网站或者第三方App。所以简单来说,如果你的用户数据可能需要和第三方共享,或者允许第三方调用API接口,则使用Token,如果只是自己的网站或App应用,使用什么都OK。

Token,指的是OAuth Token或类似的机制的话,提供的是认证和授权 ,认证是针对用户,授权是针对App。其目的是让某App有权利访问某用户的信息,这里的Token是唯一的,不可以转移到其它App上,也不可以转到其它用户上。

Token就是令牌,比如你授权(登录)一个程序时,他就是个依据,判断你是否已经授权该软件。Cookie就是写在客户端的一个txt文件,记录下用户的访问、登录等信息,下次用户再登录某个网站时,服务器接收到请求,就会自动调用Cookie,自动登录用户名。

Session和Cookie差不多,只是Session是写在服务器端的文件,也需要在客户端写入Cookie文件,但是文件里是用户的浏览器编号的状态是存储在服务器端,客户端只有session id,而Token的状态是存储在客户端的。

以上,是关于Token、Session、Cookie的知识点介绍,更加深入的详解,感兴趣的童鞋,可查看我持续分享的【BAT架构技术专题合集500+】,回复【架构】,即可领取。

Token是什么?

Token是令牌、凭证、钥匙,在Web领域中进行 身份验证 ,关键点在验证!!,说验证就必须了解一下Web领域的发展史呢。

2.随着人们需求的改变,比如在线购物系统,需要登陆的网站等,这时候需要进行 交互 性,服务器接收到请求的时候,要根据你是否登陆,以及判断你是谁,来给你响应,这时候问题就来了,怎么知道每次请求的谁呢,所以就出来了一个 会话标识(session id),就是一个随机的字符串 ,每个人登陆的时候,服务器都会返回一个会话标识,这是再请求的时候,只要带上会话标识,服务器就知道请求的是谁。

3. 这样子每个人只要保存自己的session id就可以啦,服务器要保存 所有人 的session id!!!如果有成千上万的人访问服务器,那对服务器是巨大的开销,严重限制了服务器端的扩展能力,比如机器A跟机器B组成了服务器集群,那么访问了机器A,会话标识在机器A上,如果转到机器B,就不能访问了,也许会说,那复制呢,机器A搬到机器B,也有说统一把标识放在一个机器上,但是万一这个机器挂了呢,那体验就很差了。

4. 这个时候就有人想,用户自己保存自己的标识,就是Token,访问的时候带上这个Token,这个 Token是用户id+签名 ,验证时,服务器只要相同的算法和服务器才知道的密钥进行签名,如果结果跟Token中的签名一样,那就可以证明是登陆过的用户。

这样一来,服务器不保存session id,只要生成Token,访问时,只要对Token进行判断,Token也是有有效期的,所以也要进行refreshToken的。

Token,Cookie,Session三者使用场景的区别?

Token主要是Web领域的身份认证 ,最常见的就是Web API这个功能:

Cookie 就是饼干, 它是服务器生产,永久保存在浏览器的数据,以kv的形式 ,你可以打开你的浏览器(这里以win10 edge为例),点击上方的三个点的按钮,再点击更多工具,再点击开发人员工具,再点击网络,此时内容选择文档,然后刷新页面,找Cookie即可。

Session是会话标识,是服务器用来判断正在会话的用户是谁,服务器生产的随机数 ,保存在服务器中,用户端也要进行保存,虽然能实现会话的共能,但对服务器的扩展能力限制,同时当服务器是两台机器组成以上的时候,会导致两台机器以上保存的session同步问题,会导致用户体验极差。

Token跟Session最大的区别就是Token服务端不用保存,同时是通过签名等技术实现的,Session因为是随机数,导致服务器要进行保存。

cookie 和session 的区别详解

session是存储在服务器端的,cookie是存储在客户端的,所以session的安全性要高于cookie。 再者,我们获取的session里的信息是通过存放在会话cookie里的sessionId获取的。 因为session是存放在服务器里的,所以session里的东西不断增加会增加服务器的负担,我们会把一些重要的东西放在session里,不太重要的放在客户端cookie里。 cookie分为两大类,一个是会话cookie和持久化cookie,他们的生命周期和浏览器是一致的,浏览器关了会话cooki也就消失了,而持久化会存储在客户端硬盘中。

免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。

标签: HTTP协议