当我们访问一个页面以后，这个页面中的静态资源(如图片、HTML文件、JavaScript文件等)往往会被浏览器保存下来，这个过程称为缓存(cache)。这么做是为了使用户再次访问相同页面的时候，这些静态资源不用从服务器重新下载到本地，而从缓存中直接读取，这样就加快了页面访问的速度，同时减轻了服务器和网络带宽的压力。
1 查看浏览器缓存查看chrome浏览器缓存位置：在浏览器url栏输入chrome://version，找到个人资料路径。按照路径去本地查找即可。
2 设置缓存过期时间缓存过期时间设置参考如下链接：https://blog.csdn.net/hoostone/article/details/39252857/
3 缓存处理机制 4 常见的缓存策略Expires策略
在HTTP1.0版本中，通过Expires字段控制文件缓存过期时间，浏览器在文件过期前可以直接从缓存中读取数据。缺点是，其使用的过期时间使服务器的时间，当客户端的时间与服务器时间不同步或者跨时区时，就会造成很大麻烦，所以从HTTP1.1版开始，使用”Cache-Control:max-age=XXX“来解决这个问题。如果响应包含带max-age指令的Cache-Control字段，则接收方必须忽略Expires字段
Modified策略
响应Last-Modified/请求If-Modified-Since表示资源的最后修改时间。
浏览器第一次向服务器发起请求的时候，服务器的响应标头会通过Last-Modified字段，传递该资源文件的最后修改时间，浏览器将其进行缓存。如果浏览器再次使用该文件，但是无法决定缓存中的该文件是否可用，会向服务器重新发送请求，由服务器决定，同时这个请求通过
If-Modified-Since字段将最后修改时间返回给服务器。服务器取出请求中If-Modified-Since附带的”最后修改时间“，与服务器上保存的已请求资源的”最后修改时间“进行比对，如果两个时间相同，说明资源没有改变，则返回HTTP 304状态码，告诉浏览器继续使用所缓存的资源。如果"最后修改时间"较新，说明资源改动过，则返回200状态码，将最新的资源文件重新发给浏览器。
Cache-Control策略
在HTTP1.1版本中，使用Cache-Control来控制页面的缓存。Cache-Control与Expires的作用一致，都指明当前资源的有效期，如果同时设置，Cache-Control的优先级高于Expires。在RFC 7234的官方文档中，请求的Cache-Control指令包括max-age、max-stale、min-fresh、no-cache、no-store、no-transform、only-if-cached，响应的Cache-Control指令包括must-revalidate、no-cache、no-store、no-transform、publie、private、proxy-revalidate、max-age、s-maxage。下面就其中的几条常见指令简要说明以下，详细内容可参考官方文档。
public：所有内容都将缓存
private：内容只缓存到私有缓存中
max-age:缓存的内容将在XXX秒后失效
no-cache:缓存，但是缓存是否可用由服务器决定，返回200或304状态码
no-store:不缓存，返回200状态码。
另外，有些响应标头中会出现Pragma字段，这是为了兼容HTTP1.0，起作用与”Cache-Control:no-cache“是一样的，此处不在详述。
ETag策略
ETag是服务器为相应资源在服务器端生成的唯一标识符，类似于指纹或者SVN版本控制系统里的内置版本号。如果资源发生改变，则生成新的ETag值。在响应标头中，ETag需要同时配合Cache-Control使用。当浏览器判断出缓存资源过期时(即超出"Cache-Control:max-age=XXX秒")，如果该资源具有ETag标识，则浏览器向服务器发送请求，请求标头中包括If-None-Match字段(存储ETag值)，服务器收到请求后将请求发送过来的ETag和服务器资源当前的ETag进行对比。如果二者相同，证明该资源内容没有改变，缓存中的资源仍然可用，因此返回带304状态码的响应。如果二者不同，证明该资源内容在服务器端产生了改变，需要重新向浏览器返回最新内容，于是带200状态码的响应。
Last-Modified和ETag之争
HTTP1.1中ETag的出现主要是为了解决几个比较难解决的问题。Last-Modified标注的最后修改时间只能精确到秒级，如果某些文件在1秒内修改多次，它将不能准确标注文件的修改时间。如果某些文件会定期自动生成，Last-Modified改变了，但其内容并没有任何变化，导致文件缓存策略失效。当Last-Modified与ETag一起使用时，ETag的优先级更高，服务器会优先验证ETag。
常见的浏览器端存储技术：cookie、sessionStorage(会话存储空间)、localStorage(本地存储空间)、userData、indexDB，如下图所示：
服务器端存储技术：session
一、HTML5 web存储(WebStorage)
HTML5 可以在本地存储用户的浏览器数据，不存储在服务器上，可以存储大量数据而不影响网站性能。这些数据只用于用户请求网站数据。数据以键/值对存在。存储一些不需要和服务器进行交互的数据。
客户端存储临时数据的两种对象：localStorage(本地存储空间)、sessionStorage(会话存储空间)，均只能存储字符串类型的对象(虽然规范中可以存储其他原生类型的对象，但是目前为止没有浏览器对其进行实现)
1.localStorage(本地存储空间)：没有时间限制(关闭浏览器，再次打开浏览器，存储的数据依然存在)
2.sessionStorage(会话存储空间)：针对一个session的数据存储(关闭浏览器窗口，存储的数据清空，即关闭窗口再次进浏览器数据清空了)，前进、后退、刷新数据依然存在
3.它们均只能存储字符串类型的对象
4.都是用来存储客户端临时信息的对象
5.不同浏览器无法共享sessionStorage、localStorage中的信息；相同浏览器不同页面可以共享localStorage中的信息(同协议、同域名、同端口)；但是sessionStorage不行
二、cookie与session
Cookie是网站为了辨别用户身份、进行会话跟踪而存储在用户本机中的文本文件，属于缓存文件的一种，可以在浏览器的缓存文件夹中看到存储的Cookie信息。如下图所示：HTTP服务器可以使用这些信息维护一个在无状态HTTP下有状态的会话。用户也可以选择禁用cookie，如果用户禁用了cookie功能而导致页面部分功能失效，网站应该友善地提醒用户允许接受Cookie，并指引用户进行设置。
Session(会话)代表一次完整的通信过程，简单来说就是从你打开浏览器，输入网址，按下Enter键开始，到你在该网站结束浏览并关闭浏览器结束，这一整段时间内完成的所有操作统称为一次“会话”。由于HTTP是无状态的，因此要在整个会话期间进行状态的维持就可以通过会话Cookie来实现。由于HTTP是无状态的，因此要在整个会话期间进行状态的维持就可以通过会话cookie来实现。实现的原理大致如下：
1.用户A的第一个请求到达服务器后，服务器会在内存中专门开辟一小块空间供用户A使用，并为这个小空间生成唯一的编号No001(又称为SessionID)，服务器接收到第一个请求并产生第一个响应时，会把这个编号放入响应里面，并传递用户A的浏览器。
2.用户A的浏览器接收到服务器的响应后，从中去除SessionID，保存到自己的临时Cookie中(保存在内存区域中)，后续在用户A中的所有请求中，都会带上这个编号(Cookie会自动附加到请求中)，并传递到服务器。对于用户B，也有同样的处理过程。
3.如果用户A完成了登录操作，服务器会把用户A的部分信息(如用户ID等)保存到开辟的那个会话空间中，这样当后续再有请求到达时，服务器根据请求中附带的这个SessionID，找到对应的会话空间，并读取会话空间中存储的信息，进而可以确定是用户A发起的请求。
4.依次类推，如果服务器收到一个请求，其附带的SessionID为No002，则找到No002对应的存储区域，从中读取出B的用户信息，进而判断当前请求是用户B发出的。
5.当用户退出或注销系统的时候，服务器端应该清除对应会话空间的内容。如果退出后忘记关闭浏览器窗口，单击“后退”按钮又会回到系统当中，从而造成安全隐患。
浏览器中的Cookie有两类：一类作为缓存保存在硬盘的缓存文件夹中；另一类叫做临时Cookie，是保存在浏览器内存中，关闭浏览器会从内存中释放此临时Cookie。
三、Cookie和会话的区别
1.Cookie保存在客户端，用户记录用户信息。Cookie主要分为两类：一类保存在浏览器的缓存空间中，拥有缓存的属性；另一类是临时Cookie，保存在客户端的内存中，如存储SessionID信息。
2.会话保存在服务器端，也用于记录用户信息。可以通过SessionID来判断是哪个用户发起的请求，进而可以决定其访问和处理权限。
3.通过Cookie和会话解决了HTTP在客户端与服务器之间无状态的问题。
