Cookie，Session，Token深度解析与联系

目录

一，Cookie解析

1.1 Cookie机制理解

1.2 什么是Cookie？

1.3 Cookie的其他注意事项

二，Session解析

2.1 Session机制理解

2.2 什么是Session？

2.3 Session的其他注意事项

2.4 Session模拟实现

三，Token解析

3.1 Token的由来

3.2 什么是Token？

3.3 Token的验证流程

3.4 Token的优势

四，总结

4.1 Cookie与Session

4.2 Session与Token

4.3 Token与Cookie

---

一，Cookie解析

1.1 Cookie机制理解

Cookie技术是客户端的解决方案，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。让我们说得更具体一些：当用户使用浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器；接着，服务器在向客户端回传相应的超文本的同时也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体（Response Body）中的，而是存放于HTTP响应头（Response Header）；当客户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息存放在一个统一的位置，自此，客户端再向服务器发送请求的时候，都会把相应的Cookie再次发回至服务器。而这次，Cookie信息则存放在HTTP请求头（Request Header）了。有了Cookie这样的技术实现，服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的Cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。通常，我们可以从很多网站的登录界面中看到“请记住我”这样的选项，如果你勾选了它之后再登录，那么在下一次访问该网站的时候就不需要进行重复而繁琐的登录动作了，而这个功能就是通过Cookie实现的。

在程序中，会话跟踪是很重要的事情。理论上，一个用户的所有请求操作都应该属于同一个会话，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不论是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。

而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。

Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

如果你把Cookies看成为http协议的一个扩展的话，理解起来就容易的多了，其实本质上cookies就是http的一个扩展。有两个http头部是专门负责设置以及发送cookie的,它们分别是Set-Cookie以及Cookie。当服务器返回给客户端一个http响应信息时，其中如果包含Set-Cookie这个头部时，意思就是指示客户端建立一个cookie，并且在后续的http请求中自动发送这个cookie到服务器端，直到这个cookie过期。如果cookie的生存时间是整个会话期间的话，那么浏览器会将cookie保存在内存中，浏览器关闭时就会自动清除这个cookie。另外一种情况就是保存在客户端的硬盘中，浏览器关闭的话，该cookie也不会被清除，下次打开浏览器访问对应网站时，这个cookie就会自动再次发送到服务器端。一个cookie的设置以及发送过程分为以下四步：

1. 客户端发送一个http请求到服务器端

2. 服务器端发送一个http响应到客户端，其中包含Set-Cookie头部

3. 客户端发送一个http请求到服务器端，其中包含Cookie头部

4. 服务器端发送一个http响应到客户端

示意图如下：

在客户端的第二次请求中包含的Cookie头部中，提供给了服务器端可以用来唯一标识客户端身份的信息。这时，服务器端也就可以判断客户端是否启用了cookies。尽管，用户可能在和应用程序交互的过程中突然禁用cookies的使用，但是，这个情况基本是不太可能发生的，所以可以不加以考虑，这在实践中也被证明是对的。

1.2 什么是Cookie？

Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。目前Cookie已经成为标准，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。

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

通过对Cookie机制的理解不难看出，其实Cookie就是浏览器上能永久存储的一种信息数据。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。由于Cookie是存在于客户端上的，cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。

1.3 Cookie的其他注意事项

1.3.1 Cookie的不可跨域名性

很多网站都会使用Cookie。例如，Google会向客户端颁发Cookie，Baidu也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Baidu颁发的Cookie呢？或者Google能不能修改Baidu颁发的Cookie呢？

答案是否定的。Cookie具有不可跨域名性。这是由Cookie的隐私安全机制决定的。隐私安全机制能够禁止网站非法获取其他网站的Cookie。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操作Google的Cookie，而不能操作Baidu的Cookie。

Cookie在客户端是由浏览器来管理的。浏览器能够保证Google只会操作Google的Cookie而不会操作Baidu的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Baidu的域名不一样，因此Google不能操作Baidu的Cookie。

需要注意的是，虽然网站images.google.com与网站www.google.com同属于Google，但是域名不一样，二者同样不能互相操作彼此的Cookie。

注意：用户登录网站www.google.com之后会发现访问images.google.com时登录信息仍然有效，而普通的Cookie是做不到的。这是因为Google做了特殊处理。

1.3.2 Unicode编码：保存中文

中文与英文字符不同，中文属于Unicode字符，在内存中占4个字符，而英文属于ASCII字符，内存中只占2个字节。Cookie中使用Unicode字符时需要对Unicode字符进行编码，否则会乱码。

提示：Cookie中保存中文只能编码。一般使用UTF-8编码即可。不推荐使用GBK等中文编码，因为浏览器不一定支持，而且JavaScript也不支持GBK编码。

1.3.3 Cookie的修改，删除

Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数代表其他的意义。

注意：修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

1.3.4 Cookie的查看

一般情况下查看网站颁发的Cookie可以在控制台上数据js脚本alert (document. cookie)就可以查看了。

 这样一个对话框显示本网站颁发的所有Cookie的内容。另外在浏览器的应用程序中的Cookie面板上也能看到这个相关信息，里面更清楚地看到相应的过期时间等等。

 需要注意的是，Cookie功能需要浏览器的支持。如果浏览器不支持Cookie（如大部分手机中的浏览器）或者把Cookie禁用了，Cookie功能就会失效。不同的浏览器采用不同的方式保存Cookie。

二，Session解析

2.1 Session机制理解

除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

Session技术则是服务端的解决方案，它是通过服务器来保持状态的。由于Session这个词汇包含的语义很多，因此需要在这里明确一下 Session的含义。首先，我们通常都会把Session翻译成会话，因此我们可以把客户端浏览器与服务器之间一系列交互的动作称为一个 Session。从这个语义出发，我们会提到Session持续的时间，会提到在Session过程中进行了什么操作等等；其次，Session指的是服务器端为客户端所开辟的存储空间，在其中保存的信息就是用于保持状态。从这个语义出发，我们则会提到往Session中存放什么内容，如何根据键值从 Session中获取匹配的内容等。要使用Session，第一步当然是创建Session了。那么Session在何时创建呢？当然还是在服务器端程序运行的过程中创建的，不同语言实现的应用程序有不同创建Session的方法，而在Java中是通过调用HttpServletRequest的getSession方法（使用true作为参数）创建的。在创建了Session的同时，服务器会为该Session生成唯一的Session id，而这个Session id在随后的请求中会被用来重新获得已经创建的Session；在Session被创建之后，就可以调用Session相关的方法往Session中增加内容了，而这些内容只会保存在服务器中，发到客户端的只有Session id；当客户端再次发送请求的时候，会将这个Session id带上，服务器接受到请求之后就会依据Session id找到相应的Session，从而再次使用之。正式这样一个过程，用户的状态也就得以保持了。过程图如下：

2.2 什么是Session？

综上所看，Session其实就是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

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

2.3 Session的其他注意事项

2.3.1 Session的生命周期

Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。

Session在用户第一次访问服务器的时候自动创建。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。

Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。

2.3.2 Session的有效期

由于会有越来越多的用户访问服务器，因此Session也会越来越多。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。

Session的超时时间为maxInactiveInterval属性，可以通过对应的getMaxInactiveInterval()获取，通过setMaxInactiveInterval(longinterval)修改。

Session的超时时间也可以在web.xml中修改。另外，通过调用Session的invalidate()方法可以使Session失效。

2.3.3 Session对浏览器的要求

虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session依据该Cookie来识别是否为同一用户。

该Cookie为服务器自动生成的，它的maxAge属性一般为–1，表示仅当前浏览器内有效，并且各浏览器窗口间不共享，关闭浏览器就会失效。

因此同一机器的两个浏览器窗口访问服务器时，会生成两个不同的Session。但是由浏览器窗口内的链接、脚本等打开的新窗口（也就是说不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的Cookie，因此会共享一个Session。

注意：新开的浏览器窗口会生成新的Session，但子窗口除外。子窗口会共用父窗口的Session。例如，在链接上右击，在弹出的快捷菜单中选择“在新窗口中打开”时，子窗口便可以访问父窗口的Session。

2.4 Session模拟实现

由于常见的Session使用场景一般是在用户的登录验证上，因此我们仅在controller层进行处理即可。

/**
 * <p>
 * 前端控制器
 * </p>
 *
 * @author young
 * @since 2022-03-13
 */
@RestController
@RequestMapping
public class AdminController {

    @Autowired
    private AdminServiceImp adminService;

    @PostMapping("/admin/login/status")
    public Object loginStatus(HttpServletRequest request, HttpSession session) {
        JSONObject object = new JSONObject();
        String name = request.getParameter("name");
        String password = request.getParameter("password");
        boolean b = adminService.veritypasswd(name, password);
        if (b) {
            object.put("code", 1);
            object.put("msg", "登陆成功！");
            session.setAttribute("name", name);
        } else {
            object.put("code", 0);
            object.put("msg", "用户名或密码错误！");
        }
        return object;
    }
}

在用户登录判断请求接口时，如果用户账号密码输入正确，那么我们就通过setAttribute方法来设置session的值。当用户发起登陆请求后就可以在浏览器上的网络情况上看到请求响应信息里有生成的JSESSIONID信息了。

三，Token解析

3.1 Token的由来

总所周知，HTTP请求都是以无状态的形式对接。即HTTP服务器不知道本次请求和上一次请求是否有关联。所以就有了Session的引入，即服务端和客户端都保存一段文本，客户端每次发起请求都带着，这样服务器就知道客户端是否发起过请求。

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

并且这种基于服务器的验证方式还有一些问题：

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

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

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

在这种情况下，我们需要去寻求一种更好的方法，于是Token在这种情况下应运而生。

3.2 什么是Token？

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

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

3.3 Token的验证流程

1. 当用户登录成功之后, 服务器端就会通过指定算法生成一个 token，并设置过期时间，（可以将token 存储在redis，）再将这个token值返回给客户端；

2. 客户端拿到 token 值之后,进行保存；

3. 当客户端调用接口请求数据时,就会携带token值发送给服务器；

4. 服务器接收到客户端的请求之后,会取出token值与保存（在redis中的）token值做对比。

5. 如果token对比成功，说明用户处于登录状态，否则表示登录状态失效，需要用户重新登陆。用户每次重新登陆会刷新token的过期时间。

具体流程图大致如下：

在非微服务的情况下，可以定义拦截器来代替上面API网关的功能。

3.4 Token的优势

无状态、可扩展

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

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

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

安全性

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

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

可扩展性

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

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

多平台跨域

我们提前先来谈论一下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: * 

四，总结

cookie 储存在用户本地终端上的数据，服务器生成，发送给浏览器，下次请求统一网站给服务器。

session 会话，代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续。 cookie中存放着一个sessionID，请求时会发送这个ID； session因为请求（request对象）而产生； session是一个容器，可以存放会话过程中的任何对象； session的创建与使用总是在服务端，浏览器从来都没有得到过session对象；

Token 令牌，是一种用于用户身份的验证方式

4.1Cookie与Session

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

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用COOKIE。

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

4.2 Session与Token

从身份认证的角度来看，token安全行比session好； Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。 而Token ，如果指的是OAuth Token或类似的机制的话，提供的是认证和授权 ，认证是针对用户，授权是针对第三方应用的 。其目的是让 其有权利访问某用户的信息。

4.3 Token与Cookie

Cookie是不允许垮域访问的，但是Token是支持的， 前提是传输的用户认证信息通过HTTP头传输；

当我们授权（登录）一个程序时，Token就是作为一个依据，判断我们是否已经授权该软件；Cookie就是写在客户端的一个文件，里面包括我们的登录信息之类的，这样我们下次在登录某个网站，就会自动调用Cookie自动登录用户名；Session和Cookie差不多，只是Session是写在服务器端的文件，也需要在客户端写入Cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有Session id；而Token的状态是存储在客户端。

以上仅作为学习过程的总结，再此记下一笔。好记性不如烂笔头~