网络协议：Cookie与Session技术

柔情只为你懂 2023-09-23 14:42 106阅读 0赞

> 会话（Session）跟踪是 Web 程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是 Cookie 与 Session。Cookie通 过在客户端记录信息确定用户身份，Session 通过在服务器端记录信息确定用户身份。
> 
> 本篇内容包括：会话 Session 发展史（包括会话 Session 的产生、会话 Session 的问题 和 会话 Session 的问题解决），Cookie（Cookie 的概念、Cookie 的类型），Session（实现）（Session 的概念、Cookie 的类型）以及 其他相关知识点的内容！

--------------------

### 文章目录 ###

*   *  一、会话 Session 发展史
     *   *   *  1、会话 Session 的产生
             *  2、会话 Session 的问题
             *  3、会话 Session 的问题解决
     *  二、Cookie
     *   *   *  1、Cookie 的概念
             *  2、Cookie 的类型
     *  三、Session（实现）
     *   *   *  1、Session 的概念
             *  2、Session 的原理
     *  四、相关知识点
     *   *   *  1、Cookie 与 Session 的区别与联系
             *  2、关于 Token

--------------------

## 一、会话 Session 发展史 ##

#### 1、会话 Session 的产生 ####

在开始的阶段，Web 的使用场景往往仅限于网页浏览，即 每次请求都是一个新的 HTTP 协议，也不需要记录谁在某一段时间里都浏览了什么文档。

在后面的阶段，随着类似于购物网站的交互式 Web 页面/应用的兴起，开始出现了需要用户登录的需要，即服务器需要记录登陆了哪些人，哪些人购买了哪些商品，也就是对客户端需要进行区分。

*  应对此种变化的方式就是：服务器端会给请求的客户端下发一个 SessionId，即 会话标识，齐通常由一串唯一字符构成，客户端携带着 SessionId，就可以被 服务端区分了。

#### 2、会话 Session 的问题 ####

接下来的阶段，随着交互式 Web 网站用户的增加，服务端开始发现一个问题，即「每个客户端只需保存自己的 SessionId，而服务端需要保存所有 SessionId，随着访问服务的增加，记录 SessionId 的开销饿越来越大，严重的限制了服务器扩展能力」

*  场景一：两个机器组成了一个集群保存 SessionId 信息，用户通过机器 A 登录了系统， 那 SessionId 会保存在机器 A 上，则当请求机器 B 时会找不到 SessionId；
 *  场景二：将用户请求一直粘在机器 A 上，但假如机器 A 挂掉，依然会走到机器 B
 *  场景三：做 Session 复制，SessionId 在两台机器来回复制…?
 *  场景四：把 SessionId 集中存储到一个地方，所有的机器都来访问这个地方的数据，这样一来，就不用复制了，但是增加了单点失败的可能性！

#### 3、会话 Session 的问题解决 ####

再后来的阶段，开始有人思考， 为什么要保存 Session 信息在服务端呢，在客户端保存是否会有更好的效果？

可是如果不保存这些 SessionId，怎么验证客户端发给我的 SessionId 的确是我生成的呢？关键点就是验证 ！

比如说，用户小 A 已经登录了系统， 我给他发一个令牌（Token）， 里边包含了小 A 的 userId，下一次小 A 再次通过 Http 请求访问服务端的时候， 把这个 Token 通过 Http header 带过来就可以了。但为了避免被伪造，可以做个签名，比如说用 HMAC-SHA256 算法，加上一个只有服务端才知道的密钥，对数据做一个签名，把这个签名和数据一起作为Token，由于密钥别人不知道， 就无法伪造 Token 了。

这个 Token 服务端不保存， 当小 A 把这个 Token 给服务端发过来的时候，服务端再用同样的 HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名，和 Token 中的签名做个比较， 如果相同， 我就知道小 A 已经登录过了，并且可以直接取到小 A 的 userId , 如果不相同， 数据部分肯定被人篡改过， 我就告诉发送者：“对不起，没有认证“。

这样一来，服务端就不保存 SessionId 了，服务端只是生成 Token ,然后验证 Token，服务端用服务端的 CPU 计算时间获取了服务端的 Session 存储空间 ！

Ps：当然如果一个人的 Token 被别人偷走了， 那谁也没办法

--------------------

## 二、Cookie ##

#### 1、Cookie 的概念 ####

Cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。其本质是某些网站为了辨别用户身份，进行 Session 跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息

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

#### 2、Cookie 的类型 ####

Cookie 总时由用户客户端进行保存的（一般是浏览器），按其存储位置可分为：内存式 Cookie 和硬盘式 Cookie。

内存式 Cookie 存储在内存中，浏览器关闭后就会消失，由于其存储时间较短，因此也被称为非持久 Cookie 或会话 Cookie。

硬盘式 Cookie 保存在硬盘中，其不会随浏览器的关闭而消失，除非用户手工清理或到了过期时间。由于硬盘式 Cookie 存储时间是长期的，因此也被称为持久 Cookie。

--------------------

## 三、Session（实现） ##

> Ps：不要混淆 Session 和 Session 实现。

#### 1、Session 的概念 ####

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

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

#### 2、Session 的原理 ####

当程序需要为某个客户端的请求创建一个 Session 的时候，服务器首先检查这个客户端的请求里是否已包含了一个 Session 标识，称为 SessionId，

*  如果客户端已包含一个 SessionId 则说明以前已经为此客户端创建过Session，服务器就按照 SessionId 把这个Session检索出来使用（如果检索不到，可能会新建一个）;
 *  如果客户端请求不包含 SessionId ，则为此客户端创建一个Session并且生成一个与此Session相关联的 SessionId ， SessionId 的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个 SessionId 将被在本次响应中返回给客户端保存。

--------------------

## 四、相关知识点 ##

#### 1、Cookie 与 Session 的区别与联系 ####

两者的区别：

1、Cookie 数据存放在客户端，Session 数据放在服务器上。

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

3、Session 会在一定时间内保存在服务器上，当访问增多，会比较占用你服务器的性能，考虑性能应当使用 Cookie。

4、不同浏览器对 Cookie 的数据大小限制不同，个数限制也不相同。单个 Cookie 保存的数据不能超过 4K，很多浏览器都限制一个站点最多保存 20 个 Cookie。

5、可以考虑将登陆信息等重要信息存放为 Session，不重要的信息可以放在 Cookie 中。

两者的联系：

1、都是用来记录用户的信息，以便让服务器分辨不同的用户。

2、可以搭配使用，但都有自己的使用局限，要考虑到安全和性能的问题。

#### 2、关于 Token ####

Token，即访问资源接口（API）时所需要的资源凭证

简单 Token 的组成： uid（用户唯一的身份标识） 、time (当前时间的时间戳) ,sign（签名，Token 的前几位以 hash 算法压缩成的一定长度的 16 进制字符串）

特点：服务端无状态变化、可扩展性好，支持移动端设备，安全，支持跨域程序调用，Token 的身份验证流程

基于 Token 的验证原理（过程）

*  客户端使用用户名和密码进行登录
 *  服务端收到请求，去验证用户名与密码
 *  验证成功后，服务端会签发一个 Token 并把这个 Token 发送给客户端
 *  客户端收到 Token 后，会把它存储起来，比如放在 Cookie 里 或者 localStorage 里
 *  客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
 *  服务端收到请求后，先验证客户端请求里带着的 Token ，如果验证成功，就向客户端返回请求的数据