聊聊Cookie、Session、Token背后的故事_编程技术

聊聊Cookie、Session、Token背后的故事

大家好，我是所长大白(●—●)。

今天和大家聊一下关于cookie、session、token的那些事儿。

这是我的一个读者朋友面试微信的实习岗位时遇到的，在此和大家分享一下。

聊聊Cookie、Session、Token背后的故事

话不多说，直接开车。

1. 网站交互体验升级

作为网友的我们，每天都会使用浏览器来逛各种网站，来满足日常的工作生活需求。

聊聊Cookie、Session、Token背后的故事

现在的交互体验还是很丝滑的，但早期并非如此，而是一锤子买卖。

1.1 无状态的http协议

无状态的http协议是什么鬼?

HTTP无状态协议，是指协议对于业务处理没有记忆能力，之前做了啥完全记不住，每次请求都是完全独立互不影响的，没有任何上下文信息。

缺少状态意味着如果后续处理需要前面的信息，则它必须重传关键信息，这样可能导致每次连接传送的数据量增大。

如果大家没明白，可以想一下《夏洛特烦恼》里面的桥段：

聊聊Cookie、Session、Token背后的故事

大概明白了吧，假如一直用这种原生无状态的http协议，我们每换一个页面可能就得重新登录一次，那还玩个球。

所以必须要解决http协议的无状态，提升网站的交互体验，否则星辰大海是去不了的。

1.2 解决之道

整个事情交互的双方只有客户端和服务端，所以必然要在这两个当事者身上下手。

客户端来买单

客户端每次请求时把自己必要的信息封装发送给服务端，服务端查收处理一下就行。

聊聊Cookie、Session、Token背后的故事

服务端来买单

客户端第一次请求之后，服务端就开始做记录，然后客户端在后续请求中只需要将最基本最少的信息发过来就行，不需要太多信息了。

聊聊Cookie、Session、Token背后的故事

2.Cookie方案

Cookie总是保存在客户端中，按在客户端中的存储位置，可分为内存Cookie和硬盘Cookie，内存Cookie由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的，硬盘Cookie保存在硬盘里，有一个过期时间，除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。

聊聊Cookie、Session、Token背后的故事

2.1 Cookie定义和作用

HTTP Cookie(也叫 Web Cookie 或浏览器 Cookie)是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。

通常Cookie用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的HTTP协议记录稳定的状态信息成为了可能。

Cookie 主要用于以下三个方面：

会话状态管理(如用户登录状态、购物车等其它需要记录的信息)
个性化设置(如用户自定义设置、主题等)
浏览器行为跟踪(如跟踪分析用户行为等)

2.2 服务端创建Cookie

当服务器收到 HTTP 请求时，服务器可以在响应头里面添加一个 Set-Cookie 选项。

浏览器收到响应后通常会保存下 Cookie，之后对该服务器每一次请求中都通过 Cookie 请求头部将 Cookie 信息发送给服务器。另外，Cookie 的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。

聊聊Cookie、Session、Token背后的故事

2.3 B/S的Cookie交互

聊聊Cookie、Session、Token背后的故事

服务器使用 Set-Cookie 响应头部向用户浏览器发送 Cookie信息。

一个简单的 Cookie 可能像这样：

Set-Cookie:@lt;cookie名@gt;=@lt;cookie值@gt;
HTTP/1.0200OK
Content-type:text/html
Set-Cookie:yummy_cookie=choco
Set-Cookie:tasty_cookie=strawberry

客户端对该服务器发起的每一次新请求，浏览器都会将之前保存的Cookie信息通过 Cookie 请求头部再发送给服务器。

GET/sample_page.htmlHTTP/1.1
Host:www.example.org
Cookie:yummy_cookie=choco;tasty_cookie=strawberry

我来访问下淘宝网，抓个包看看这个真实的过程：

聊聊Cookie、Session、Token背后的故事

2.4 存在的问题

Cookie 常用来标记用户或授权会话，被浏览器发出之后可能被劫持，被用于非法行为，可能导致授权用户的会话受到攻击，因此存在安全问题。

还有一种情况就是跨站请求伪造CSRF，简单来说比如你在登录银行网站的同时，登录了一个钓鱼网站，在钓鱼网站进行某些操作时可能会获取银行网站相关的Cookie信息，向银行网站发起转账等非法行为。

跨站请求伪造(英语：Cross-site request forgery)，也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本(XSS)相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作(如发邮件，发消息，甚至财产操作如转账和购买商品)。

由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

不过这种情况有很多解决方法，特别对于银行这类金融性质的站点，用户的任何敏感操作都需要确认，并且敏感信息的 Cookie 只能拥有较短的生命周期。

同时Cookie有容量和数量的限制，每次都要发送很多信息带来额外的流量消耗、复杂的行为Cookie无法满足要求。

聊聊Cookie、Session、Token背后的故事

特别注意：以上存在的问题只是Cookie被用于实现交互状态时存在的问题，但并不是说Cookie本身的问题。

试想一下：菜刀可以用来做菜，也可以被用来从事某些暴力行为，你能说菜刀应该被废除吗?

3. Session方案

3.1 Session机制的概念

如果说Cookie是客户端行为，那么Session就是服务端行为。

聊聊Cookie、Session、Token背后的故事

Cookie机制在最初和服务端完成交互后，保持状态所需的信息都将存储在客户端，后续直接读取发送给服务端进行交互。

Session代表服务器与浏览器的一次会话过程，并且完全由服务端掌控，实现分配ID、会话信息存储、会话检索等功能。

Session机制将用户的所有活动信息、上下文信息、登录信息等都存储在服务端，只是生成一个唯一标识ID发送给客户端，后续的交互将没有重复的用户信息传输，取而代之的是唯一标识ID，暂且称之为Session-ID吧。

3.2 简单的交互流程

当客户端第一次请求session对象时候，服务器会为客户端创建一个session，并将通过特殊算法算出一个session的ID，用来标识该session对象。
当浏览器下次请求别的资源的时候，浏览器会将sessionID放置到请求头中，服务器接收到请求后解析得到sessionID，服务器找到该id的session来确定请求方的身份和一些上下文信息。