关于cookie:互联网人必备知识cookie和session认证

4次阅读

共计 2564 个字符，预计需要花费 7 分钟才能阅读完成。

在互联网倒退初期，Web 基本上只是内容的浏览而已，服务器不须要记住每个浏览申请的状态，换句话说，服务器不须要有任何的状态信息，每次客户端的申请都是新的申请，这也是 http 无状态一个很显著的体现。随着互联网大潮的到来，尤其是像在线购物等这种和用户关系密切的零碎的大量衰亡，零碎须要辨识出用户，以便进行各种业务操作，这种需要给 Http 无状态这种个性一个强烈的冲击，所以最终的解决方案就是客户端申请的时候携带着一种标识，这种标识每个用户不同，这样服务端就能够依据这个标识辨别出不同的客户端用户了，这也就诞生了用户认证这个概念。

因为 http 协定是无状态的，所以基于 http 协定进行的认证，都须要依赖客户端上传的某种标识

所谓身份认证，就是判断一个用户是否为非法用户的处理过程。

以上是百科针对于用户认证的泛型定义，和认证相干的受权这里要顺便提一下，认证和受权是两个不同的概念，更是两个不同的阶段，绝大多数带有认证和受权的零碎，在用户操作流程上都是先进行认证，之后依据认证的后果再进行受权操作，有的初学者容易混同二者的概念。举一个很简答的栗子：一个 OA 零碎，在用户登录胜利之后，个别左侧都会依据以后用户的不同角色或者权限呈现不同操作的菜单树，其中用户登录这个过程就是认证的过程，而左侧的菜单树就是对以后用户的受权的一个具体表现形式（当然有的零碎可能不这样做，但不代表没有受权的流程）。

认证是用来证实一个用户身份的操作流程，受权是用来给以后用户赋予权限的操作流程。

通过上一篇文章，置信大家曾经明确了 session 和 cookie 的关系，如果你还没看过，我举荐还是看一下吧。

Session：在计算机中，尤其是在网络应用中，称为“会话管制”。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会失落，而是在整个用户会话中始终存在上来。当用户申请来自应用程序的 Web 页时，如果该用户还没有会话，则 Web 服务器将主动创立一个 Session 对象。当会话过期或被放弃后，服务器将终止该会话。

基于 session 的认证形式，最次要的一个特点就是：服务端存储着用户信息，客户端是通过携带一个 sessionid 的 cookie 来做 session 的标识。很多初期我的项目都喜爱采纳 session 的认证形式，这种形式对于疾速开发上线我的项目极为无利。每个客户端只须要保留一个 cookie，然而服务端却须要保留成千上万的用户 session 信息，这无疑对服务端造成了很大的压力，尤其是当做了负载平衡之后，session 的命中问题更为可怕。举个栗子：用户 A 登录零碎胜利，服务器 A 下发 sessionid，session 信息存储在服务器 A 上，如果当下次申请到服务器 B 上的时候，因为服务器 B 上没有 session 信息，所以就造成了未命中的景象，这也是 session 认证解决方案施行过程面临的一个问题。有问题就有解决方案，其中一个便是 session 复制，服务端的每个服务器都存储每个 session 的一个正本，这样申请无论达到哪个服务器，都能够胜利取到 session 信息，然而这样无疑增大了服务的存储压力，而且 session 在服务器之间的复制提早，session 信息的更新同步、过期同步等操作都令人头疼。所以这种计划在肯定水平上其实并不举荐。

目前业界对于 session 存储的计划个别都偏向于集中式存储，像利用第三方的 redis，Memcached 把 session 信息都存储在同一个中央，所有的服务器都拜访这个中央的数据。这样就防止了 session 复制，同步等问题。然而引入了第三方，就意味着减少了一个第三方挂掉的可能性，所以当初都根本采纳第三方集群的计划来尽量减小这种可能性，把高可用性做到极致。另外说一点，因为大多数 session 机制是基于 cookie 的，在肯定水平上对于浏览器比拟敌对，然而对于很多挪动端利用其实并不是太敌对。

因为 session 的认证信息保留在服务端，数据量达到肯定水平对服务器有肯定的压力，即便是采纳第三方的存储（比方 redis）能够缓解这种问题，然而服务器和第三方存储的 IO 操作所破费的工夫有的时候也是很大的。在这种状况下，有的零碎放弃了 session 的认证形式，而间接采纳的最间接的 cookie 认证形式。

和 session 认证不同，用户的认证信息齐全存储在 cookie 中，换句话说用户的认证信息存储在客户端（这也是为什么不举荐在 cookie 认证中寄存敏感信息）。cookie 认证这种形式的劣势就在于服务端没有了 session 存储的压力，每次辨认用户都只须要解析 cookie 的内容即可（解析 cookie 其实也须要破费工夫），相比拟第三方存储 session 的形式，缩小了一次网络 IO 操作，在肯定水平上进步了申请的响应速度，而且因为服务端处于无状态的模式，所以能够很不便的横向扩大。

基于 cookie 的认证形式也有很多毛病：

cookie 是存储在客户端的，所以在肯定水平上减少了能够伪造的几率，安全性上稍强劲一点。
因为 cookie 在浏览中有跨域的拦截，所以在有跨域需要的时候，须要服务器做相应的配置。
cookie 是有长度限度的，所以不宜存储过长的信息。
用户的客户端可能会禁用 cookie，这个时候能够依附 url 传值来解决这个问题。
服务端想要操作 cookie 认证信息的生效，比拟艰难，不像 session 认证那样不便。

其实我司当初老的零碎都是利用的 cookie 验证形式，只不过 cookie 信息的加密算法很好，而且再加上全站 https 的策略，在肯定水平上安全性还是能够的（如果让我重构一次认证零碎，我不会抉择 cookie 认证）。

无论是基于 session 的还是基于 cookie 的认证形式，都须要客户端上传标识，都须要服务端下发这个标识，并且对这个标识进行加密。尽管加密，然而不法之人一旦拿到这个标识还是能够进行一系列非法操作，所以这个标识里边最好能加上起源 IP 和过期工夫这些属性，再配置上 https，能够更加无效的爱护整个认证流程和数据。兴许还有更好的认证形式，敬请期待！！