客户端储存
2016-04-19 20:16
323 查看
服务器端存储：
cache :缓存(存放在内存中)，将DB或磁盘中的数据放在缓存中访问，减少磁盘IO
磁盘文件：资源文件：如图片和视频
数据库： 如MySQL和与node.js配合的MongoDB :记录表查询
内存： 频繁访问的资源，提高读取效率
客户端存储：
1.H5之前的存储：
cookies
cookie存储方式：
cookies特点：
在每次http请求头上都会带着：三次握手等请求响应，一直带着cookie比较臃肿，而且会存在安全问题
对每个域名，客户端只会存4K大小的cookie，存储量小
主Domain(域名)污染：如果数据存放在主域名之下，则所有资源名有http请求时，请求头都会带着主域名存在cookie中的数据，会造成主域名cookie的污染
应用场景：用户验证，购物车
userData:
只有IE支持，存储XML文件
2.H5的存储
目标：
解决存储容量限制的问题(一个域名只有4K)
解决请求头常带有存储信息的问题
解决关系型存储的问题(客户端实现表的存储)
跨浏览器(针对userData只有IE支持)
3.H5的存储方式及使用
(1)本地存储(localstorage && sessionstorage)
核心API：localStorage对象 && sessionStorage对象
API存储方式：key-value
过期：localstorage:永久存储，永不失效，除非手动删除
sessionstorage:重新打开页面或关闭浏览器就消失
大小：每个域名可以存5M
浏览器支持：IE8+ 及其他主流浏览器都支持
常用API：getItem, setItem, removeItem, key, clear
储存资源：数组(必须将数组序列化为字符串再存储)，json数据(字符串)，图片，脚本和样式文件。只要能转化成字符串的东西，都可以存。
图片的存储：
借助canvas对象的drawImage()和toDataURL()方法(该方法存在安全策略--不能跨域，跨域请求时需要给服务器设置：access-control-allow-origin：域名)将图片转化成字符串，再存到localStorage中，应用于静态图片的及时呈现。
注意事项：
先判断浏览器是否支持：先在try-catch中set一下，看有没有异常捕获
写数据时，要做异常处理(每个域名只有5M)，避免超出容量抛错
避免把敏感信息存入localStorage
key的唯一性，重复set时会覆盖掉旧值
使用限制：
存储更新策略，过期控制
子域名之间不能共享存储数据(cookie放在主域名下可以共享)：解决，利用H5的postMessage()方法和meaasge事件跨域多文档通信
超出存储大小之后，如何存储(LRU, FIFO)
server 端如何取到(cookie可以)：更改get或post请求，跟到相应的参数后传到服务端
使用场景：
减少网络传输，弱网络环境，高延迟，低带宽，尽量把数据本地化:；脚本样式本地化；3g和2g情况下相差很多，wifi情况下差别很小
(2)离线缓存(application cache) APP cache
Appcache是从浏览器的缓存中分离出来的一块缓存区
API的核心是applicationCache对象
它可以让Web应用在离线的情况下继续使用，通过manifest文件指明需要缓存的资源
离线缓存的原理：
修改manifest文件后（修改manifest文件的版本号就可以到达重新向服务器拉取资源的目的），会向服务器端请求更新缓存，而用户访问时，直接返回的是上一次缓存到的结果。
缺点：
业务有更新时，必须修改manifest文件，更改完以后，第一次是不生效的，因为有缓存，客户端就直接返回缓存中的内容，即更新前的缓存，只有下一次刷新后，缓存才会得到更新。
当修改了manifest文件后，App cache会将manifest文件中所有指定的资源都重新向服务器拉取一次，而不是只请求修改的资源，造成损耗。
使用方法：
<html manifest="sample.appcache"> sample.appcache为manifest文件的路径
在服务器配置文件中添加 mime-type text/cache-manifest
没有manifest文件时，缓存失效，强制走网络
更新：
如果有修改资源文件，必须通过手动修改manifest来刷新被缓存的文件列表
优势：
可以做到完全离线(没有网络时，还可以继续使用web应用)
资源被缓存，加载更快
降低server负载
使用缺陷：
含有manifest属性的当前请求页无论如何都会被缓存
更新需要建立在manifest文件更新的基础上，文件更新后，需要页面的再次刷新才能获取到新更新的资源。
更新是全局的，无法单独更新某个文件（需要结合设置http-cache请求头做到）
对于URL上有参数的话，不建议使用，因为对于网址 index.html 和 index.html?a=1 会认为是两个文件，会分别缓存，任何一个参数的修改都会被重新缓存，更新manifest文件时，会导致多份缓存都向服务器端重新拉取一次。
适用场景：
单地址页面(不含参数)
对实时性要求不高的业务
离线webapp(如：金融时报)
(3)IndexedDB 和 Web SQL
IndexedDB Database 一种能在浏览器中持久地存储结构化数据的数据库，并且为web应用提供了丰富的查询能力。
Opera不支持，chrome 11+, firefox 4+, IE10+支持
IndexedDB Database 的存储结构：IndexedDB是按域名分配独立空间，一个独立域名下可以创建多个数据库，每个数据库可以创建多个对象存储空间，一个对象存储空间可以存储多个对象数据。
IndexedDB Database的实际操作
(4)非主流的客户端存储
userData IE
google Gears chrome12.0之后放弃
4.H5存储优缺点
优势
存储空间大，接口丰富，关系型，省流量，数据相对安全
多种存储方式组合使用
劣势
浏览器的兼容（实现程度不同）， 同源限制（不能跨域） ，脚本控制（只存放在客户端，服务器端要想获得只能通过请求），更新策略（手动更新）
cache :缓存(存放在内存中)，将DB或磁盘中的数据放在缓存中访问，减少磁盘IO
磁盘文件：资源文件：如图片和视频
数据库： 如MySQL和与node.js配合的MongoDB :记录表查询
内存： 频繁访问的资源，提高读取效率
客户端存储：
1.H5之前的存储：
cookies
cookie存储方式：
cookies特点：
在每次http请求头上都会带着：三次握手等请求响应，一直带着cookie比较臃肿，而且会存在安全问题
对每个域名，客户端只会存4K大小的cookie，存储量小
主Domain(域名)污染：如果数据存放在主域名之下，则所有资源名有http请求时，请求头都会带着主域名存在cookie中的数据，会造成主域名cookie的污染
应用场景：用户验证，购物车
userData:
只有IE支持，存储XML文件
2.H5的存储
目标：
解决存储容量限制的问题(一个域名只有4K)
解决请求头常带有存储信息的问题
解决关系型存储的问题(客户端实现表的存储)
跨浏览器(针对userData只有IE支持)
3.H5的存储方式及使用
(1)本地存储(localstorage && sessionstorage)
核心API：localStorage对象 && sessionStorage对象
API存储方式：key-value
过期：localstorage:永久存储，永不失效，除非手动删除
sessionstorage:重新打开页面或关闭浏览器就消失
大小：每个域名可以存5M
浏览器支持：IE8+ 及其他主流浏览器都支持
常用API：getItem, setItem, removeItem, key, clear
储存资源：数组(必须将数组序列化为字符串再存储)，json数据(字符串)，图片，脚本和样式文件。只要能转化成字符串的东西，都可以存。
图片的存储：
借助canvas对象的drawImage()和toDataURL()方法(该方法存在安全策略--不能跨域，跨域请求时需要给服务器设置：access-control-allow-origin：域名)将图片转化成字符串，再存到localStorage中，应用于静态图片的及时呈现。
注意事项：
先判断浏览器是否支持：先在try-catch中set一下，看有没有异常捕获
写数据时，要做异常处理(每个域名只有5M)，避免超出容量抛错
避免把敏感信息存入localStorage
key的唯一性，重复set时会覆盖掉旧值
使用限制：
存储更新策略，过期控制
子域名之间不能共享存储数据(cookie放在主域名下可以共享)：解决，利用H5的postMessage()方法和meaasge事件跨域多文档通信
超出存储大小之后，如何存储(LRU, FIFO)
server 端如何取到(cookie可以)：更改get或post请求，跟到相应的参数后传到服务端
使用场景：
减少网络传输，弱网络环境，高延迟，低带宽，尽量把数据本地化:；脚本样式本地化；3g和2g情况下相差很多，wifi情况下差别很小
(2)离线缓存(application cache) APP cache
Appcache是从浏览器的缓存中分离出来的一块缓存区
API的核心是applicationCache对象
它可以让Web应用在离线的情况下继续使用，通过manifest文件指明需要缓存的资源
离线缓存的原理：
修改manifest文件后（修改manifest文件的版本号就可以到达重新向服务器拉取资源的目的），会向服务器端请求更新缓存，而用户访问时，直接返回的是上一次缓存到的结果。
缺点：
业务有更新时，必须修改manifest文件，更改完以后，第一次是不生效的，因为有缓存，客户端就直接返回缓存中的内容，即更新前的缓存，只有下一次刷新后，缓存才会得到更新。
当修改了manifest文件后，App cache会将manifest文件中所有指定的资源都重新向服务器拉取一次，而不是只请求修改的资源，造成损耗。
使用方法：
<html manifest="sample.appcache"> sample.appcache为manifest文件的路径
在服务器配置文件中添加 mime-type text/cache-manifest
没有manifest文件时，缓存失效，强制走网络
更新：
如果有修改资源文件，必须通过手动修改manifest来刷新被缓存的文件列表
优势：
可以做到完全离线(没有网络时，还可以继续使用web应用)
资源被缓存，加载更快
降低server负载
使用缺陷：
含有manifest属性的当前请求页无论如何都会被缓存
更新需要建立在manifest文件更新的基础上，文件更新后，需要页面的再次刷新才能获取到新更新的资源。
更新是全局的，无法单独更新某个文件（需要结合设置http-cache请求头做到）
对于URL上有参数的话，不建议使用，因为对于网址 index.html 和 index.html?a=1 会认为是两个文件，会分别缓存，任何一个参数的修改都会被重新缓存，更新manifest文件时，会导致多份缓存都向服务器端重新拉取一次。
适用场景：
单地址页面(不含参数)
对实时性要求不高的业务
离线webapp(如：金融时报)
(3)IndexedDB 和 Web SQL
IndexedDB Database 一种能在浏览器中持久地存储结构化数据的数据库，并且为web应用提供了丰富的查询能力。
Opera不支持，chrome 11+, firefox 4+, IE10+支持
IndexedDB Database 的存储结构：IndexedDB是按域名分配独立空间，一个独立域名下可以创建多个数据库，每个数据库可以创建多个对象存储空间，一个对象存储空间可以存储多个对象数据。
IndexedDB Database的实际操作
(4)非主流的客户端存储
userData IE
google Gears chrome12.0之后放弃
4.H5存储优缺点
优势
存储空间大，接口丰富，关系型，省流量，数据相对安全
多种存储方式组合使用
劣势
浏览器的兼容（实现程度不同）， 同源限制（不能跨域） ，脚本控制（只存放在客户端，服务器端要想获得只能通过请求），更新策略（手动更新）
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 