在很久很久以前的互联网上，前后端还是不分离的。浏览器显示的网页，都是通过后端的模版技术动态渲染成 HTML ，返回给浏览器的。那时候还没有 Ajax 的流行，浏览器要做的操作，都得一次一次的请求后端，后端返回一个完整的 HTML 页面来显示结果。

在这个背景之下，HTTP 协议又不支持保持会话。那后端怎么知道多个请求之间的联系？例如某个用户先执行操作 A ，然后执行了 B 。所以，需要一种“保持用户状态”的机制，在后端能保存用户的状态使得后端知道用户执行了哪些操作，又能为这些操作保存一些信息。这个就是 Session 会话了。本质上，它是设计出来“保持用户状态”的。

后来，Ajax 使得异步刷新页面，以及后来大前端的流行，各自新的标准和浏览器技术涌现出来。使得我们有更多的方法来做到类似“保持用户状态”的效果。例如，我们可以把用户的状态保存在浏览器端的 Storage 里面。这时候，就会显得后端 Session 来保持用户状态，没有以前那么必要了。当然，也有很多场景会需要在后端保持用户状态。

那么，在不怎么需要后端 Session 来保持用户状态的场景，后端就不需要为用户专门开辟一个区域来存储，它只需要去知道这个请求是否合法的访问就足够了。所以，开始使用了 token 。

所以，session 会在每次访问后，重新刷新 session 的有效期。因为他需要持续保持会话，只要用户一天不离开，会话都需要继续持续下去。某种程度来说，这个有效期时间也可以当成是某个“用户状态”的数据。

另一方面，在使用 token 时，它仅用于判断请求是否合法访问，没有说要用来保持用户状态的。那就很自然的不会去保持用户状态。所以就是一种固定的有效期。不会像会话的场景一样自动延长。也就是只能手动的通过 refresh_token 来延长。

上面说了这么多，都没有提到 cookie 。我理解的是，用不用 cookie 其实都不影响理解 session 和 token 的一些区别。我不能把 token 放在 cookie 吗？我不能把 sessionid 放在 header 用吗？只是没有这个用的习惯而已。