二十七----浏览器存储

一、浏览器缓存包括http缓存、webstorage、cookie、indexDB等。
1、http缓存包括强缓存（http1.0看expire字段是否设置，http1.1看cache-control:max-age是否设置）。浏览器请求时先判断本地缓存记录的时间和当前时间对比超过这个字段设置的时间则表示强缓存失效，失效则走协商缓存。若未失效则使用本地缓存
2、http缓存包括协商缓存（http1.1看cache-control:no-cache是否设置，last-modify,etag是否返回）。浏览器请求时如果有强缓存字段，先走强缓存逻辑，没有则走协商缓存。
1）有last-modify，则携带if-modify-since:last-modidfy传递给服务器，服务器收到后会将这个值与服务资源存的值对比，不一致则返回该资源，浏览器使用返回资源；一致则返回304，浏览器则使用本地缓存资源。注：这个方案应该精确到秒，所以在秒级上修改了资源，这种情况下资源会失效。
2）有etag，则携带if-none-match:etag传递给服务器，服务器收到后会将这个值与服务资源存的etag值对比，不一致则返回该资源，浏览器使用返回资源；一致则返回304，浏览器则使用本地缓存资源。
cache-control:max-age:强缓存，设置缓存的最大有效期，单位为秒，no-store：不缓存，no-cache:协商缓存。

1. 浏览器点击回车
   浏览器先检查本地缓存是否失效，如果没失效则命中强缓存，如果失效则走协商缓存向服务器发请求，如果资源未失效则返回304，失效则返回200
2. 浏览器点击刷新按钮
   浏览器会对本地缓存失效，但是会携带协商缓存使用的字段，向服务器发请求，如果资源未失效则返回304，失效则返回200
3. 在浏览器界面F5
   浏览器会对本地缓存失效，但是会携带协商缓存使用的字段，向服务器发请求，如果资源未失效则返回304，失效则返回200
4. CTR+F5（强制刷新）
   使得本地缓存失效，不使用缓存，直接请求服务器使用返回资源

http缓存位置：它主要存在disk cache和memery cache里，还有一个就是service worker，Push Cache（http2.0）
同源策略是浏览器的一个安全策略，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。同源判断的依据是：协议、域名、端口号必须相同。如果没有同源策略的话，很容易导致XSS和CSRF攻击。

二、cookie
cooick产生的背景是因为，HTTP是无状态协议，在没有cooick之前，HTTP的请求头是没有任何状态标记的，这就导致一个问题，服务器本次收到的请求不知道发起请求的客户端有没有登陆过或者购买过其他产品，这就对服务端处理请求产生了不小的麻烦。因此呢，需要客户端在发起请求的时候，携带一些必要的信息供服务器进行判断发起请求的客户端的当前状态，这些信息基本都是经过加密的。这个时候，就产生了一种方案：

1. 客户端在第一次请求的时候，服务器会在响应头中添加一个字段set-cookie，
2. 当客户端收到响应之后，会去解析响应头，如果存在set-cookie字段的话，就在浏览器中写入set-cookie中的数据。写入的时候，会与当前域名作为绑定。
3. 在客户端发起下一次请求的时候，就会将与该域名绑定的cookie设置到请求头的cookie字段中(必须符合同源策略并且，路径信息需要相同)。

cooike的数据结构长下面这样：

| 属性名   | 释意                                                         |
| -------- | ------------------------------------------------------------ |
| name     | 设置的cookie名称                                             |
| value    | 设置的cookie值                                               |
| Domain   | 域名信息，标识这个cookie属于哪个域名。在发送请求的时候会判断此字段与当前请求的地址是否同源 |
| Path     | 路径信息。如果同源的话，接下来就会判断路径是否一样。<br /><br />例如：/a/：可以匹配 /a/b; /a/b/c，/a就只能匹配www.xxxx.com/a; |
| Expires  | 过期时间                                                     |
| Size     | 大小                                                         |
| HttpOnly | 仅仅传递，不能通过脚本读取。防止XSS攻击                      |
| Secure   | 仅仅在https请求中携带                                        |
| sameSite | 跨站点时，是否可以携带cookie，用来防范：CSRF攻击             |
| Priority | 优先级，chrome的提案，定义了三种优先级，Low/Medium/High，当cookie数量超出时，低优先级的cookie会被优先清除 |

cooike在存储的过程中，受限于大小，只能存储4kb左右。会存在过期时间，不能作为持久化存储。如果没有进行相应的安全防护可能导致XSS攻击以及CSRF攻击。

三、webStorage

因为cookie的存储的不足，因此产生了webStorage。

webStorage又分为localStorage（本地存储）与sessionStorage（会话存储）这两个，这两个相比于cookie，在可存储的大小上，有了质的提升，可以存储5M左右的数据。并且localStorage与sessionStorage跟cookie一样，也必须满足同源策略才能根据key值获取到相应的value。

localStorage与sessionStorage发送的时候，也不会携带到的请求头中去，防止一些安全问题的产生，因不会放到请求头中，因此也减少了不必要的流量开销。
但localStorage与sessionStorage之间又有些不同，不同之处在于localStorage在页面关闭的时候，数据不会被清除。并且可以跨页面使用。sessionStorage页面闭关数据就被清除。所谓的跨页面使用指的是：你在浏览器里打开了两个窗口，一个访问的是http://www.baidu.com/a.html，另一个访问的是http://www.baidu.com/b.html，那么因为协议，域名，端口号都一致，符合同源策略。就可以都访问存储在http://www.baidu.com下的localStorage数据。但是sessionStorage只能是在当期那页面有效，并且当页面退出的时候，相应存储的数据也会被清理掉。

四、indexedDB

阮一峰老师的博客已经讲解的很详细了。链接地址：浏览器数据库 IndexedDB 入门教程

注：cookie和localStorage都受同源策略的限制

但是cookie在同一浏览器的相同域名、不同端口号下，是可以共享的，即cookied只区分域名不区分端口号。
localStorage不可以共享