Cookie 是 HTTP 的请求头中最不好理解的一个概念, Cookie 的值其实就是一个自定义的字符串, 相当于浏览器这边进行本地存储的一种机制, 如程序猿想让浏览器这边存一些信息就可以使用 Cookie.
先来问一个问题: 浏览器是否可以将信息写到磁盘文件中???
Cookie
先来回答上面的问题: 浏览器是不可以将信息写到磁盘文件中的; 原因如下:
其实浏览器中的 JS 是不能访问磁盘上的文件的, 为了安全性, 如果能够访问磁盘中的数据, 也就意味着我们只要进入网页就可能会中毒; 就相当于网页里面直接往你的磁盘里写入了一个病毒程序, 或者直接通过网页把你的文件删除等;
因此为了安全性浏览器就限制了 JS 的能力. Cookie 就是浏览器能够让网页进行持久化保存数据的一种方法, 你可以设置为 7 天有效, 也可以设置为三天有效, 这些程序猿都是可以操作的.
✍︎ 简单学习 Cookie
由于 Cookie 存储空间实在有限, 因此只能存取一些简单的信息, 最常见的例子就是用户的身份信息; 如我们在网页登录 gitee 网站, 可以进行记住密码, 点击记住密码后, 服务器就把身份信息通过 Cookie 返回到浏览器这边了, 当再次访问 gitee 请求中就自动带着刚才 Cookie 并且包含着身份信息.
首次请求的响应就会带有一个 Set-Cookie 字段, 里面就是 Cookie 的值, 如下图所示:
如果访问网站的个人主页界面, 请求中就会自动带上刚才的 Cookie:
这部分就是刚才响应中返回的 Set-Cookie 的值; 因为带有 Set-Cookie 的响应可能有很多, 因此这里的字符串就比较长.
整体流程如下:
其实并不是所有的的网站都依赖于 Cookie, 也有很多方式能够将数据进行存储, 如下:
(1) LocalStorage: 这是 HTML5 开始引入的存储机制, 通过 JS 提供的一组 API 来操作数据, 当然也是支持键值对的存储结构, 这里的数据就能够持久的存储下去;
(2) IndexDB: 比较新的浏览器才支持的机制, 浏览器内部集成了一个 “数据库”, 支持类似于 SQL 的方式来进行操作数据.
✍︎ ✍︎ 深度学习 Cookie
关于 Cookie 是如何存储的???
Cookie 是按照域名 / 地址进行存储, 每个域名或者地址存自己的 Cookie; 也就是说 Gitee 网页上存储的 Cookie 和 Github 网页上存储的 Cookie 是相互独立的.
但是也要说明一下不同的端口的服务器也都是有一组 Cookie; 实际上商业服务器往往是一组服务器程序, 这一组程序经常需要共享 Cookie 信息; 如访问百度搜索会有一个 Cookie, 然后再去访问百度地图也有一个 Cookie, 百度搜索和百度地图就是两个服务器, 但是这两个服务器需要共同的 Cookie. 当然 Cookie 也不是一成不变的, 也是需要更新的.
关于 Cookie 和 Session:
- Cookie 是 HTTP 协议中的一个字段, 也是浏览器在客户端保存数据的一种比较古老的方式; Cookie 就是从服务器中产生的, 通过 HTTP 响应的 Set-Cookie 字段来进行设置, 返回给浏览器; 下次登录的时候就会加入到请求中发送给服务器; 当然存储方式也是以键值对的结构进行存储, 这里的键值对也是我们自定义的.
- Session 也就是 “会话”, HTTP 本身是无状态的, 某个用户对服务器进行了两次请求, 第一次请求和第二次请求对于服务器来说是感知不到有什么关联信息的; 但是在实际开发过程中有需要有状态, 用户登录完成之后, 后续再访问这个网站的时候就需要能知道这个用户的身份信息; 而 Session 就是在服务器端存储的, 也可以将 Session 想象成是一个 Hash 表, key 就是 sessionId, 而 value 就是程序猿自定义的数据.
其实两者是相互配合的关系, 如下图所示:
在此场景下, 服务器返回的 Set-Cookie 里一定要放 SessionId 么???
其实进行联系的不一定非得是 SessionId, 也可以是 UserId, 也可以是其它的 ID.
如果直接将用户信息序列化一下, 通过 Set-Cookie 返回给浏览器可行么?
也是可以的, 只要两个请求能够联系起来就行. 使用 SessionId 只是一种常见的做法, 好处就是方便进行注销, 在管理 session 的哈希表中将对应的键值删除就行; 使用 SessionId 也有助于保护用户的隐私.
上图中 Cookie 和 Session 的联动主要是针对主流的网页实现的, 像手机 app 登录机制可能都没有使用 HTTP 协议, 更不必说 Cookie 了.