整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
随着移动网络的发展与演化，我们手机上现在除了有原生 App，还能跑“WebApp”——它即开即用，用完即走。一个优秀的 WebApp 甚至可以拥有和原生 App 媲美的功能和体验。WebApp 优异的性能表现，有一部分原因要归功于浏览器存储技术的提升。cookie存储数据的功能已经很难满足开发所需，逐渐被WebStorage、IndexedDB所取代，本文将介绍这几种存储方式的差异和优缺点。
1.Cookie的来源
Cookie 的本职工作并非本地存储，而是“维持状态”。
因为HTTP协议是无状态的，HTTP协议自身不对请求和响应之间的通信状态进行保存，通俗来说，服务器不知道用户上一次做了什么，这严重阻碍了交互式Web应用程序的实现。在典型的网上购物场景中，用户浏览了几个页面，买了一盒饼干和两瓶饮料。最后结帐时，由于HTTP的无状态性，不通过额外的手段，服务器并不知道用户到底买了什么，于是就诞生了Cookie。它就是用来绕开HTTP的无状态性的“额外手段”之一。服务器可以设置或读取Cookies中包含信息，借此维护用户跟服务器会话中的状态。
我们可以把Cookie 理解为一个存储在浏览器里的一个小小的文本文件，它附着在 HTTP 请求上，在浏览器和服务器之间“飞来飞去”。它可以携带用户信息，当服务器检查 Cookie 的时候，便可以获取到客户端的状态。
在刚才的购物场景中，当用户选购了第一项商品，服务器在向用户发送网页的同时，还发送了一段Cookie，记录着那项商品的信息。当用户访问另一个页面，浏览器会把Cookie发送给服务器，于是服务器知道他之前选购了什么。用户继续选购饮料，服务器就在原来那段Cookie里追加新的商品信息。结帐时，服务器读取发送来的Cookie就行了。
2.什么是Cookie及应用场景
Cookie指某些网站为了辨别用户身份而储存在用户本地终端上的数据(通常经过加密)。 cookie是服务端生成，客户端进行维护和存储。通过cookie,可以让服务器知道请求是来源哪个客户端，就可以进行客户端状态的维护，比如登陆后刷新，请求头就会携带登陆时response header中的set-cookie,Web服务器接到请求时也能读出cookie的值，根据cookie值的内容就可以判断和恢复一些用户的信息状态。
如上图所示，Cookie 以键值对的形式存在。
典型的应用场景有：
记住密码，下次自动登录。
购物车功能。
记录用户浏览数据，进行商品（广告）推荐。
3.Cookie的原理及生成方式
Cookie的原理
第一次访问网站的时候，浏览器发出请求，服务器响应请求后，会在响应头里面添加一个Set-Cookie选项，将cookie放入到响应请求中，在浏览器第二次发请求的时候，会通过Cookie请求头部将Cookie信息发送给服务器，服务端会辨别用户身份，另外，Cookie的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。
Cookie的生成方式主要有两种：
生成方式一：http response header中的set-cookie
我们可以通过响应头里的 Set-Cookie 指定要存储的 Cookie 值。默认情况下，domain 被设置为设置 Cookie 页面的主机名，我们也可以手动设置 domain 的值。
当Cookie的过期时间被设定时，设定的日期和时间只与客户端相关，而不是服务端。
生成方式二：js中可以通过document.cookie可以读写cookie，以键值对的形式展示
例如我们在掘金社区控制台输入以下三句代码，便可以在Chrome 的 Application 面板查看生成的cookie:
从上图中我们可以得出：
Domain 标识指定了哪些域名可以接受Cookie。如果没有设置domain，就会自动绑定到执行语句的当前域。
如果设置为”.baidu.com”,则所有以”baidu.com”结尾的域名都可以访问该Cookie，所以在掘金社区上读取不到第三条代码存储Cookie值。
4.Cookie的缺陷
Cookie 不够大
Cookie的大小限制在4KB左右，对于复杂的存储需求来说是不够用的。当 Cookie 超过 4KB 时，它将面临被裁切的命运。这样看来，Cookie 只能用来存取少量的信息。此外很多浏览器对一个站点的cookie个数也是有限制的。
这里需注意：各浏览器的cookie每一个name=value的value值大概在4k，所以4k并不是一个域名下所有的cookie共享的,而是一个name的大小。
过多的 Cookie 会带来巨大的性能浪费
Cookie 是紧跟域名的。同一个域名下的所有请求，都会携带 Cookie。大家试想，如果我们此刻仅仅是请求一张图片或者一个 CSS 文件，我们也要携带一个 Cookie 跑来跑去（关键是 Cookie 里存储的信息并不需要），这是一件多么劳民伤财的事情。Cookie 虽然小，请求却可以有很多，随着请求的叠加，这样的不必要的 Cookie 带来的开销将是无法想象的。
cookie是用来维护用户信息的，而域名(domain)下所有请求都会携带cookie，但对于静态文件的请求，携带cookie信息根本没有用，此时可以通过cdn（存储静态文件的）的域名和主站的域名分开来解决。
由于在HTTP请求中的Cookie是明文传递的，所以安全性成问题，除非用HTTPS。
5.Cookie与安全
对于 cookie 来说，我们还需要注意安全性。
HttpOnly 不支持读写，浏览器不允许脚本操作document.cookie去更改cookie，
所以为避免跨域脚本 (XSS) 攻击，通过JavaScript的 Document.cookie API无法访问带有 HttpOnly 标记的Cookie，它们只应该发送给服务端。如果包含服务端 Session 信息的 Cookie 不想被客户端 JavaScript 脚本调用，那么就应该为其设置 HttpOnly 标记。
标记为 Secure 的Cookie只应通过被HTTPS协议加密过的请求发送给服务端。但即便设置了 Secure 标记，敏感信息也不应该通过Cookie传输，因为Cookie有其固有的不安全性，Secure 标记也无法提供确实的安全保障。
为了弥补 Cookie 的局限性，让“专业的人做专业的事情”，Web Storage 出现了。
HTML5中新增了本地存储的解决方案----Web Storage，它分成两类：sessionStorage和localStorage。这样有了WebStorage后，cookie能只做它应该做的事情了——作为客户端与服务器交互的通道，保持客户端状态。
1.LocalStorage的特点
保存的数据长期存在，下一次访问该网站的时候，网页可以直接读取以前保存的数据。
基于上面的特点，LocalStorage可以作为浏览器本地缓存方案，用来提升网页首屏渲染速度(根据第一请求返回时，将一些不变信息直接存储在本地)。
2.存入/读取数据
localStorage保存的数据，以“键值对”的形式存在。也就是说，每一项数据都有一个键名和对应的值。所有的数据都是以文本格式保存。
存入数据使用setItem方法。它接受两个参数，第一个是键名，第二个是保存的数据。
localStorage.setItem("key","value");
读取数据使用getItem方法。它只有一个参数，就是键名。
var valueLocal=localStorage.getItem("key");
具体步骤，请看下面的例子：
3.使用场景
LocalStorage在存储方面没有什么特别的限制，理论上 Cookie 无法胜任的、可以用简单的键值对来存取的数据存储任务，都可以交给 LocalStorage 来做。
这里给大家举个例子，考虑到 LocalStorage 的特点之一是持久，有时我们更倾向于用它来存储一些内容稳定的资源。比如图片内容丰富的电商网站会用它来存储 Base64 格式的图片字符串：
sessionStorage保存的数据用于浏览器的一次会话，当会话结束（通常是该窗口关闭），数据被清空；sessionStorage 特别的一点在于，即便是相同域名下的两个页面，只要它们不在同一个浏览器窗口中打开，那么它们的 sessionStorage 内容便无法共享；localStorage 在所有同源窗口中都是共享的；cookie也是在所有同源窗口中都是共享的。除了保存期限的长短不同，SessionStorage的属性和方法与LocalStorage完全一样。
1.sessionStorage的特点
基于上面的特点，sessionStorage 可以有效对表单信息进行维护，比如刷新时，表单信息不丢失。
2.使用场景
sessionStorage 更适合用来存储生命周期和它同步的会话级别的信息。这些信息只适用于当前会话，当你开启新的会话时，它也需要相应的更新或释放。比如微博的 sessionStorage就主要是存储你本次会话的浏览足迹：
lasturl 对应的就是你上一次访问的 URL 地址，这个地址是即时的。当你切换 URL 时，它随之更新，当你关闭页面时，留着它也确实没有什么意义了，干脆释放吧。这样的数据用 sessionStorage 来处理再合适不过。
3.sessionStorage 、localStorage 和 cookie 之间的区别
共同点：都是保存在浏览器端，且都遵循同源策略。
不同点：在于生命周期与作用域的不同
作用域：localStorage只要在相同的协议、相同的主机名、相同的端口下，就能读取/修改到同一份localStorage数据。sessionStorage比localStorage更严苛一点，除了协议、主机名、端口外，还要求在同一窗口（也就是浏览器的标签页）下
生命周期：localStorage 是持久化的本地存储，存储在其中的数据是永远不会过期的，使其消失的唯一办法是手动删除；而 sessionStorage 是临时性的本地存储，它是会话级别的存储，当会话结束（页面被关闭）时，存储内容也随之被释放。
Web Storage 是一个从定义到使用都非常简单的东西。它使用键值对的形式进行存储，这种模式有点类似于对象，却甚至连对象都不是——它只能存储字符串，要想得到对象，我们还需要先对字符串进行一轮解析。
说到底，Web Storage 是对 Cookie 的拓展，它只能用于存储少量的简单数据。当遇到大规模的、结构复杂的数据时，Web Storage 也爱莫能助了。这时候我们就要清楚我们的终极大 boss——IndexedDB！
IndexedDB 是一种低级API，用于客户端存储大量结构化数据(包括文件和blobs)。该API使用索引来实现对该数据的高性能搜索。IndexedDB 是一个运行在浏览器上的非关系型数据库。既然是数据库了，那就不是 5M、10M 这样小打小闹级别了。理论上来说，IndexedDB 是没有存储上限的（一般来说不会小于 250M）。它不仅可以存储字符串，还可以存储二进制数据。
1.IndexedDB的特点
键值对储存。
IndexedDB 内部采用对象仓库（object store）存放数据。所有类型的数据都可以直接存入，包括 JavaScript 对象。对象仓库中，数据以"键值对"的形式保存，每一个数据记录都有对应的主键，主键是独一无二的，不能有重复，否则会抛出一个错误。
异步
IndexedDB 操作时不会锁死浏览器，用户依然可以进行其他操作，这与 LocalStorage 形成对比，后者的操作是同步的。异步设计是为了防止大量数据的读写，拖慢网页的表现。
支持事务。
IndexedDB 支持事务（transaction），这意味着一系列操作步骤之中，只要有一步失败，整个事务就都取消，数据库回滚到事务发生之前的状态，不存在只改写一部分数据的情况。
同源限制
IndexedDB 受到同源限制，每一个数据库对应创建它的域名。网页只能访问自身域名下的数据库，而不能访问跨域的数据库。
储存空间大
IndexedDB 的储存空间比 LocalStorage 大得多，一般来说不少于 250MB，甚至没有上限。
支持二进制储存。
IndexedDB 不仅可以储存字符串，还可以储存二进制数据（ArrayBuffer 对象和 Blob 对象）。
2.IndexedDB的常见操作
在IndexedDB大部分操作并不是我们常用的调用方法，返回结果的模式，而是请求——响应的模式。
建立打开IndexedDB ----window.indexedDB.open("testDB")
这条指令并不会返回一个DB对象的句柄，我们得到的是一个IDBOpenDBRequest对象，而我们希望得到的DB对象在其result属性中
除了result，IDBOpenDBRequest接口定义了几个重要属性:
onerror: 请求失败的回调函数句柄
onsuccess:请求成功的回调函数句柄
onupgradeneeded:请求数据库版本变化句柄
控制台得到一个 IDBDatabase对象，这就是IndexedDB对象
关闭IndexedDB----indexdb.close()
删除IndexedDB----window.indexedDB.deleteDatabase(indexdb)
3.WebStorage、cookie 和 IndexedDB之间的区别
从上表可以看到，cookie 已经不建议用于存储。如果没有大量数据存储需求的话，可以使用 localStorage 和 sessionStorage 。对于不怎么改变的数据尽量使用 localStorage 存储，否则可以用 sessionStorage 存储。
正是浏览器存储、缓存技术的出现和发展，为我们的前端应用带来了无限的转机。近年来基于存储、缓存技术的第三方库层出不绝，此外还衍生出了 PWA 这样优秀的 Web 应用模型。总结下本文几个核心观点：
Cookie 的本职工作并非本地存储，而是“维持状态”
Web Storage 是 HTML5 专门为浏览器存储而提供的数据存储机制，不与服务端发生通信
IndexedDB 用于客户端存储大量结构化数据
---------------------
作者：浪里行舟来源：CSDN原文：https://blog.csdn.net/howgod/article/details/88988509
天我们就来全面了解一下Cookie（小饼干）以及相关的知识！
相信很多同学肯定听过Cookie这个东西，也大概了解其作用，但是其原理以及如何设置，可能没有做过web的同学并不是非常清楚，那今天猪哥就带大家详细了解下Cookie相关的知识！
一、诞生背景
爬虫系列教程的第一篇：HTTP详解中我们便说过HTTP的五大特点，而其中之一便是：无状态
HTTP无状态：服务器无法知道两个请求是否来自同一个浏览器，即服务器不知道用户上一次做了什么，每次请求都是完全相互独立。
早期互联网只是用于简单的浏览文档信息、查看黄页、门户网站等等，并没有交互这个说法。但是随着互联网慢慢发展，宽带、服务器等硬件设施已经得到很大的提升，互联网允许人们可以做更多的事情，所以交互式Web慢慢兴起，而HTTP无状态的特点却严重阻碍其发展！
交互式Web：客户端与服务器可以互动，如用户登录，购买商品，各种论坛等等
不能记录用户上一次做了什么，怎么办？聪明的程序员们就开始思考：怎么样才能记录用户上一次的操作信息呢？于是有人就想到了隐藏域。
隐藏域写法：<input type="hidden" name="field＿name" value="value">
这样把用户上一次操作记录放在form表单的input中，这样请求时将表单提交不就知道上一次用户的操作，但是这样每次都得创建隐藏域而且得赋值太麻烦，而且容易出错！
ps：隐藏域作用强大，时至今日都有很多人在用它解决各种问题！
网景公司当时一名员工Lou Montulli（卢-蒙特利），在1994年将“cookies”的概念应用于网络通信，用来解决用户网上购物的购物车历史记录，而当时最强大的浏览器正是网景浏览器，在网景浏览器的支持下其他浏览器也渐渐开始支持Cookie，到目前所有浏览器都支持Cookie了
二、Cookie是什么
前面我们已经知道了Cookie的诞生是为了解决HTTP无状态的特性无法满足交互式web，那它究竟是什么呢？
上图是在Chrome浏览器中的百度首页的Cookies（Cookie的复数形式），在表格中，每一行都代表着一个Cookie，所以我们来看看Cookie的定义吧！
Cookie是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息，用于服务器记录客户端的状态。
Cookie主要用于以下三个方面：
三、Cookie原理
我们在了解了Cookie是由服务器发出存储在浏览器的特殊信息，那具体是怎么样的一个过程呢？为了大家便于理解，就以用户登录为例子为大家画了一幅Cookie原理图
用户在输入用户名和密码之后，浏览器将用户名和密码发送给服务器，服务器进行验证，验证通过之后将用户信息加密后封装成Cookie放在请求头中返回给浏览器。
HTTP/1.1 200 OK Content-type: text/html Set-Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Aug 2019 21:47:38 GMT; Path=/; Domain=.169it.com; HttpOnly [响应体]
浏览器收到服务器返回数据，发现请求头中有一个：Set-Cookie，然后它就把这个Cookie保存起来，下次浏览器再请求服务器的时候，会把Cookie也放在请求头中传给服务器：
GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg
服务器收到请求后从请求头中拿到cookie，然后解析并到用户信息，说明此用户已登录，Cookie是将数据保存在客户端的。
这里我们可以看到，用户信息是保存在Cookie中，也就相当于是保存在浏览器中，那就说用户可以随意修改用户信息，这是一种不安全的策略！
强调一点：Cookie无论是服务器发给浏览器还是浏览器发给服务器，都是放在请求头中的！
四、Cookie属性
下图中我们可以看到一个Cookie有：Name、Value、Domain、Path、Expires/Max-Age、Size、HTTP、Secure这些属性，那这些属性分别都有什么作用呢？我们来看看
1. Name&Value
Name表示Cookie的名称，服务器就是通过name属性来获取某个Cookie值。
Value表示Cookie 的值，大多数情况下服务器会把这个value当作一个key去缓存中查询保存的数据。
2.Domain&Path
Domain表示可以访问此cookie的域名，下图我们以百度贴吧页的Cookie来讲解一下Domain属性。
从上图中我们可以看出domain有：.baidu.com 顶级域名和.teiba.baidu.com的二级域名，所以这里就会有一个访问规则：顶级域名只能设置或访问顶级域名的Cookie，二级及以下的域名只能访问或设置自身或者顶级域名的Cookie，所以如果要在多个二级域名中共享Cookie的话，只能将Domain属性设置为顶级域名！
Path表示可以访问此cookie的页面路径。比如path=/test，那么只有/test路径下的页面可以读取此cookie。
3.Expires/Max-Age
Expires/Max-Age表示此cookie超时时间。若设置其值为一个时间，那么当到达此时间后，此cookie失效。不设置的话默认值是Session，意思是cookie会和session一起失效。当浏览器关闭(不是浏览器标签页，而是整个浏览器) 后，此cookie失效。
提示：当Cookie的过期时间被设定时，设定的日期和时间只与客户端相关，而不是服务端。
4.Size
Size表示Cookie的name+value的字符数，比如有一个Cookie：id=666，那么Size=2+3=5 。
另外每个浏览器对Cookie的支持都不相同
5.HTTP
HTTP表示cookie的httponly属性。若此属性为true，则只有在http请求头中会带有此cookie的信息，而不能通过document.cookie来访问此cookie。
设计该特征意在提供一个安全措施来帮助阻止通过Javascript发起的跨站脚本攻击(XSS)窃取cookie的行为
6.Secure
Secure表示是否只能通过https来传递此条cookie。不像其它选项，该选项只是一个标记并且没有其它的值。
这种cookie的内容意指具有很高的价值并且可能潜在的被破解以纯文本形式传输。
五、Python操作Cookie
1.生成Cookie
前面我们说过Cookie是由服务端生成的，那如何用Python代码来生成呢？
从上图登录代码中我们看到，在简单的验证用户名和密码之后，服务器跳转到/user，然后set了一个cookie，浏览器收到响应后发现请求头中有一个：Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg，然后浏览器就会将这个Cookie保存起来！
2.获取Cookie
最近我们一直在讲requests模块，这里我们就用requests模块来获取Cookie。
r.cookies表示获取所有cookie，get_dict()函数表示返回的是字典格式cookie。
3.设置Cookie
上篇我们爬取优酷弹幕的文章中便是用了requests模块设置Cookie
我们就浏览器复制过来的Cookie放在代码中，这样便可以顺利的伪装成浏览器，然后正常爬取数据，复制Cookie是爬虫中常用的一种手段！
六、Session
1.诞生背景
其实在Cookie设计之初，并不像猪哥讲的那样Cookie只保存一个key，而是直接保存用户信息，刚开始大家认为这样用起来很爽，但是由于cookie 是存在用户端，而且它本身存储的尺寸大小也有限，最关键是用户可以是可见的，并可以随意的修改，很不安全。那如何又要安全，又可以方便的全局读取信息呢？于是，这个时候，一种新的存储会话机制：Session 诞生了。
2.Session是什么
Session翻译为会话，服务器为每个浏览器创建的一个会话对象，浏览器在第一次请求服务器，服务器便会为这个浏览器生成一个Session对象，保存在服务端，并且把Session的Id以cookie的形式发送给客户端浏览，而以用户显式结束或session超时为结束。
我们来看看Session工作原理：
对于session标识号（sessionID），有两种方式实现：Cookie和URL重写，猪哥就以Cookie的实现方式画一个Session原理图
联系cookie原理图我们可以看到，Cookie是将数据直接保存在客户端，而Session是将数据保存在服务端，就安全性来讲Session更好！
3.Python操作Session
后面猪哥将会以登录的例子来讲解如何用Python代码操作Session
七、面试场景
1.Cookie和Session关系
2.Cookie带来的安全性问题
八、总结
今天为大家讲解了Cookie的相关知识，以及如何使用requests模块操作Cookie，最后顺便提了一下Cookie与Session的关系以及Cookie存在哪些安全问题。希望大家能对Cookie（小饼干）能有个全面的了解，这样对你在今后的爬虫学习中会大有裨益！
关注微信公众号：安徽思恒信息科技有限公司,了解更多技术内容……
TML本地存储有cookies、 localStorage 、sessionStorage、Web SQL、IndexedDB。
以下是它们的区别
*请认真填写需求信息，我们会在24小时内与您取得联系。
