浏览器缓存HTTP缓存的细节补充和探讨

最近在掘金上看到一篇讲解HTTP缓存的文章《前端优化：浏览器缓存技术介绍》，我觉得讲得很好，如果大家不熟悉HTTP缓存的话可以先看下这篇博客，很多细节都讲的很具体，向博主学习！
看完后感觉有几个细节博主可能没有展开，引起了疑问和好奇，我查了下资料把疑问分享给大家，也提了一些问题，希望有高手大佬帮忙解答，有想法欢迎指出一起探讨。

疑问1：如果不启用强缓存的话，协商缓存根本没有意义，这个该怎么理解呢？博客原文为：

原博客的截图

原博客小伙伴的留言

相信有小伙伴和我一样，第一反应一头雾水，其实这句的描述不是很贴切，原因是作者没有讲Cache-Control的几个可选值的含义，配合起来讲解就很容易理解了。
对于强缓存来说，Cache-Control 是最重要的规则。常见的取值有private、public、no-cache、max-age，no-store，默认为private。
private: 只有浏览器可以缓存，(默认)
public: 可以被任何缓存区缓存，包括浏览器和代理服务器
max-age=xxx: 缓存的内容将在 xxx 秒后失效
no-cache: 需要使用协商缓存来验证缓存数据
no-store: 所有内容都不会缓存，强制缓存，协商缓存都不会触发
其中，max-age=xxx并不是独立的属性，如你设置了Cache-Control:max-age=1800，等价于Cache-Control:private, max-age=1800，你也可以设置成Cache-Control:public, max-age=1800，所以当你想要每次请求都去询问服务器对比一下，设置Cache-Control:no-cache或者Cache-Control:no-cache, max-age=0就可以，现在看来Cache-Control也是用来控制协商缓存的。Cache-Control是缓存的总开关，作者把Cache-Control看做是强缓存的属性，所以才会出现如果不启用强缓存的话，协商缓存根本没有意义的描述。

问题1：如果我设置了Cache-Control:private或者Cache-Control:public，但没有设置max-age，那么第一次从服务器下载缓存起来的文件有默认效期吗？有的话是多长呢？有答案的小伙伴求评论区告知。

疑问2：Etag / If-None-Match貌似平白无故多出一次tag计算，它比Last-Modified / If-Modified-Since 好在哪儿？

大家知道，ETag规范比Last-Modified规范出的晚，说明ETag一定是在Last-Modified存在某些缺陷短板才应运而生的。一种普遍的ETag算法是取文件的特征值计算Hash（比如md5）。Etag 主要为了解决 Last-Modified 无法解决的一些问题：
1）、有时候有些文件的内容不会改变，但是文件的元数据却经常改变，(比如创建日期、创建作者这些)，这个时候服务器并不希望浏览器认为这个文件被修改了，而重新下载一次；
2）、有时候有些文件修改的频率非常高，几毫秒就修改一次，If-Modified-Since 的粒度是秒级的，这种频率无法被察觉(也有人说UNIX操作系统记录MTIME只能精确到秒)；
3）、某些服务器不能精确的得到文件的最后修改时间。
也就是说文件的最后修改时间变了不能100%说明文件内容变了，文件内容变了也不能100%体现在最后修改时间，用文件的最后修改时间来表示文件发生修改并不可靠所以才有了ETag。
看起来ETag已经完全可以替代Last-Modified了，而且我心里也是这么想的，可以网上的声音却不一样。我这里汇总一下：

说法1：有的地方说Etag / If-None-Match的优先级高于Last-Modified / If-Modified-Since。但ETag不是Last-Modified的替代，你得根据你程序的特点选择一个适合的使用。

如果浏览器的Request Header里If-None-Match和If-Modified-Since两个都存在，服务器会只处理If-None-Match，如果服务器算出来的ETag跟If-None-Match不一样会直接返回新的文件和新的ETag，If-Modified-Since就被忽略了，如果算出来ETag跟If-None-Match一样，就直接返回304，不会再去判断If-Modified-Since了。

说法2：如果 Last-Modified 和 ETag 同时被使用，则要求它们的验证都必须通过才会返回304，若其中某个验证没通过，则服务器会按常规返回资源实体及200状态码。nginx默认是两则都开启的。

作者引用的文章《 [浅谈浏览器http的缓存机制]》里就是这种观点。

那么问题来了：
1、文件的Hash本身足以说明文件是否发生修改，是可靠结论，为啥还要继续判断 Last-Modified呢？
2、如果为了解决Last-Modified有时难以察觉文件变化才使用ETag，不应该Last-Modified优先级高于ETag吗？Last-Modified发生变化就直接返回200，没变化或者获取不到再判断ETag？
3、实在模拟不出文件内容变了，最后修改时间没变的情形，无法验证“如果 Last-Modified 和 ETag 同时被使用，则要求它们的验证都必须通过才会返回304”,是否正确。各位大佬帮忙支支招

问题3：为啥读缓存时from memory cache ，from disk cache会有两个，什么时候from memory 什么时候from disk呢？

from memory cache是指从浏览器缓存读文件，进程死了，文件就没了。
from disk cache是指从PC本地磁盘读文件，进程死了，磁盘文件还在。
那么这个事就和服务器没关系了，也不是标准规范，纯属浏览器个人行为。所以各家浏览器的表现还不一样，比如firefox浏览器就只有from memory cache，没有from disk cache，它不会把文件备份到磁盘。
from disk cache多见于chrome，据了解chrome在访问一个新域名的网站时，会把新下载的文件的一部分（包括css、js）备份一份到磁盘，下一次如果命中强缓存的话，先从磁盘读取文件，磁盘里没有再去浏览器缓存里读，如果都没有再问服务器要。但是先从浏览器缓存读不比磁盘快吗？原因我认为是：chrome不想给用户造成“吃内存”的现象，把一些他们认为可以存磁盘的文件塞到磁盘了（也有可能是浏览器缓存只开辟固定空间，放不下了再塞到磁盘，所以看上去有的js放在了浏览器缓存，有的js又放在磁盘，抓不到规律），当磁盘文件的数量远远大于浏览器缓存数量，索性先读磁盘来得更直接一些。比如我用chrome随便打开一个页面，刷新下看到from disk cache的数量还是要多一些的。

某页面读取缓存情况.png