哈喽，大家好呀，我是呼噜噜
你有没有过这样的经历？
你深夜加班，在云笔记平台上，奋笔疾书，为明天的工作和会议准备材料
该平台又又又弹出一个广告，你想把它给关掉，当你点击关闭图标时，跳转到浏览器的新页面上
只能点击浏览器的“后退”按钮
这个时候你愣住了。然而你千辛万苦地码了1w字的文稿没了
它们就像从未存在过一样，消失得无影无踪
"不！！！"，看来今晚班要加的更晚了...
为什么网页记不住你的操作？
恭喜你，我的朋友，你触碰到了互联网世界一个古老的盲点，早期网页没有记忆力的！当你刷新页面或者重新打开页面，对它来说都是一个全新的开始。
但那时的网页就像"金鱼"一样，只有"七秒"的记忆~
我们知道浏览器上的网页，往往并不是大脑，核心的服务都在服务器上，而浏览器和服务器是通过HTTP协议来通信的。
HTTP协议，也叫超文本传输协议，英文HyperText Transfer Protocol，它是一个基于请求与响应，无状态的，应用层的协议，也是互联网上应用最为广泛的一种网络协议
它的一大特点就是，无状态Stateless，意思是，它对于交互性场景是没有记忆能力。这就是导致服务器根本不认识我们的根本原因，因为服务器无法从网页，获取到用户的状态信息
为什么HTTP被设计成这样？
这不能怪HTTP协议，在互联网的远古时代，网页非常简单，就是看看新闻、读读文章，没有“记住”用户的需求。
另一方面设计成无状态，服务器就不需要保存海量用户的状态信息，结构简单，处理速度快，能服务更多的人。就像一个从不记账的杂货铺老板，买完就走，谁也不欠谁，效率极高。
这个时代的互联网，真是“健忘”！
但"大人时代变了"，如今人们有了网上购物、在线银行、在线交流等等各种交互场景，我们需要网页能够记录信息，保持状态。否则无法满足人们的日益激增的需求
Cookie
那么该怎么让服务器，记住你呢？
在吃零食的时候，天才的你，看到手上的小饼干，想到为什么不让http传输的时候？
携带这个小饼干，小饼干存放着用户的信息，这样就能让服务器能记住并识别你
早在1994 年，在一家名为“网景Netscape”的公司。一位名叫Lou Montulli（卢-蒙特利）的工程师，为了解决用户网上购物的购物车历史记录，就想到了这个办法，并把它命名为Cookie
Cookie指的是程序间传递的一小块数据，而接收方不需要理解这块数据的内容，只需原样传回即可。服务器给你一块“小饼干”，你不用关心里面是什么，下次你带着这块饼干来，服务器就知道是你了。
Cookie 有以下这些特点：
- 简单：它就是一小段文本。
- 无感：浏览器自动处理，用户几乎感觉不到它的存在。
- 兼容：几乎所有浏览器都支持。
它的核心目标非常纯粹：让无状态的 HTTP 协议，拥有记忆的能力
Cookie 就像一张随身携带的身份证，它服务端产生，发送到浏览器并由浏览器保存到本地，然后浏览器每次去拜访服务器，都会带上它，服务器一看就知道"哦，是你啊，我的老朋友"。
在浏览器本地中的Cookie的如下图所示：
Cookie的参数含义如下所示：
| 参数 (Attribute) | 核心功能与用途 |
|---|---|
| key=value | 存储的核心数据，例如 user=Alice。 |
| Expires** / **Max-Age | 设置过期时间。Max-Age (秒) 优先于 Expires (日期)，决定了 Cookie 的生命周期。 |
| Domain | 指定作用域，即哪些域名可以访问此 Cookie。 |
| Path | 指定作用路径，即在域名下的哪个路径会发送此 Cookie。 |
| Secure | 安全传输：确保 Cookie 仅通过 HTTPS 发送，防止网络窃听。 |
| HttpOnly | 防脚本窃取：禁止 JavaScript 访问，有效防御 XSS 攻击。 |
| SameSite | 防跨站伪造：控制跨站请求时是否携带 Cookie，核心防御 CSRF 攻击。 |
随着对 Cookie 的深入使用，你会发现它存在一些明显的局限性：
- 大小限制：每个
Cookie的大小不能超过4KB，这意味着它只能存储非常有限的数据。 - 性能开销：每次发起
HTTP请求时，浏览器都会自动携带该域名下的所有Cookie，即使请求的只是一张图片。如果Cookie数量较多，每次请求都带着这么一大坨数据，会造成带宽浪费。 - 安全风险：
Cookie是以明文形式存储在浏览器中，并且可以被JavaScript直接访问，因此容易遭受CSRF（跨站请求伪造）和XSS（跨站脚本攻击）等安全威胁。
那么，该如何应对这些问题呢？
Session
天才的你，想到了既然将敏感的信息，存到cookie里，不安全，有泄漏的风险
那么我们为什么把这些信息存放到服务器上的"柜子"里，服务器只给客户端发一个"凭证号"，客户端下次访问带着这个"凭证号"，去服务器上找到对应柜子里的信息
这个"柜子"就是 Session，而客户端里的那个"凭证号"，就是存在Cookie里的 Session ID
这样Session让Cookie既实现了减负又增加信息量，Cookie变得极其轻量（只存一个ID），而且所有敏感数据都保存在服务器端，安全问题和传输效率问题都得到了极大的改善。
Cookie + Session 它们2个的配合，天衣无缝，长期以来一直是Web开发的黄金搭档。时至今日，这套方案依然是无数网站的核心基石！
但随着时代的发展，这个时候聪明的你很快就发现，Session的弊端了:
- 服务器资源占用：每个活跃的 Session 都会持续占用服务器的内存资源。网站访问量巨大，成千上万的用户，会压垮服务器
- 扩展性困境：在分布式集群部署中，如何在不同服务器间同步或共享
Session状态，成为一个必须解决的复杂问题，否则用户请求可能因被负载均衡导向不同服务器而丢失状态。 - 作用域限制：
Session通常与创建它的域名绑定，无法在跨域场景下直接共享。 - 生命周期短暂：其默认生命周期与浏览器窗口一致，关闭浏览器往往导致
Session失效。这对于需要持久化存储的用户状态（例如“七天免登录”）而言，是无法实现的
另外还有一些常用的信息根本就没那么重要，比如夜间模式、主题、语种等等，相关的参数，完全不需要存在服务器上！
那该怎么办？
Web Storage
当进入移动互联网时代时，Web 应用变得越来越复杂，网站访问量巨大，成千上万的用户，带来的用户数据是庞大的
好在作为 HTML5 标准的一部分，W3C 及时推出了 Web Storage API，一个纯粹的、容量更大的、API 更友好的浏览器端存储技术，它包含两个关键的对象：LocalStorage 和 SessionStorage
天才的你发现，这不又回到客户端存储了嘛！
有时我们不得不感叹，技术的演进总是在螺旋式轮回中前进，不断解决旧问题，然后遇到新挑战!
LocalStorage 和 SessionStorage 就像是浏览器给我们开发者提供的两个"本地小仓库"，一个用于"持久化"存储，一个用于"临时"存储。
LocalStorage
LocalStorage是浏览器提供的一种数据存储方式，其数据具有持久性，即使关闭浏览器后，数据依然存在，直到显式地删除为止。也就是说，只要我们不手动清除浏览器数据，或者代码不主动删除，这些数据会永远存在。
相对于Cookie的4KB，它通常有5MB，甚至更大的空间
它的数据以键值对（key-value）的形式，被存储在浏览器的一个文件或数据库里。它与域名绑定，a.com 存的数据，在 b.com 是无法访问的
一般可以用于以下场景：
- 存储用户偏好：比如网站的主题（白天/夜间模式）、语言选择。
- 缓存不常变动的数据：比如一个电商网站的商品分类菜单，可以缓存到
localStorage，下次用户访问时直接从本地读取，加快页面渲染速度，减少不必要的 API 请求。 - 存储一些非敏感的用户信息：比如用户的草稿、浏览历史（注意隐私）。
在浏览器本地中的LocalStorage 和 SessionStorage如下图所示：
SessionStorage
SessionStorage同样是浏览器提供的一种数据存储方式，用法与 localStorage完全一样，不一样的是它的生命周期。
其存储的数据是会话级别的。这里的“会话”指的是从你打开一个浏览器标签页，到你关闭这个标签页的整个过程。
- 当标签页关闭时，
sessionStorage里的数据会自动被清除。 - 即使是同一个网站，在不同的标签页里打开，它们的
sessionStorage也是不互通的**。** 刷新页面，数据不会丢失。（受同源策略的限制）
它的典型应用场景如下：
- 临时消息：如页内提示、
Toast等“阅后即焚”的一次性信息。 - 状态持久：在单页应用内，暂存未提交的表单数据等页面状态，避免视图切换导致数据丢失。
- 操作防抖：通过设置标志位，防止表单重复提交等瞬时操作。
小结
从无状态的HTTP协议，到Cookie，再到为了安全和效率，升级为"钥匙+储物柜"的Session模式。最后为了给服务器减负，又赋予了浏览器本地储存的方案LocalStorage 和 SessionStorage
我们可以发现技术的发展，都是以解决实际问题为内在驱动的，比起单纯的背八股文，了解这些技术的背后故事，更能帮你深入理解其精髓
Web技术的发展，总离不开安全这个词，那当我伪造你的Cookie，冒充你的身份（CSRF攻击），或者在你的网页里注入恶意脚本，偷走你Local Storage里的信息时（XSS攻击）
天才的你又该如何应对？
感谢你的阅读，本文到这里就结束啦，在评论区留下你的想法和方案吧！
作者：小牛呼噜噜
本文到这里就结束啦，感谢阅读，关注同名公众号：小牛呼噜噜，防失联+获取更多技术干货