(这个问题很奇怪,我会承认。它本质上是一个"如果"那是一个问题,而不是我需要的任何项目。我很感激,如果你请更正我在下面做出的任何不正确的假设 - 我确定没有网络工程师!)
是否可以使用DNS txt记录(或新记录)来缓存整个.css / .js文件以用于网页浏览?
我怀疑最简单的方法(如果可能的话)就是使用browserify&小型DNS客户端“挖掘”#39;一个自定义的node.js DNS服务器,它已经过训练,可以回复整个静态文件(.css,.js)。示例请求可能是:jquery.min.js.example.com,其中txt记录响应将是jquery.min.js的全部内容。它甚至可以是像7fba88.js.example.com这样的部分哈希值,因此可以验证结果文件是否来自“未中和的”#39; DNS缓存,在浏览器中的回复上运行javascript哈希。
我怀疑DNS协议可能比HTTP协议更快(开销更少,UPD与TCP),也可能提供更好的缓存形式。 DNS txt请求(以255个字节的块...)可以缓存在您的localhost上,用于您访问的任何网站 - 以及任何Web浏览器 - 并且通常也由您的ISP缓存。
HTTP请求也有缓存,但它不是那么好。如果.css文件与已下载到浏览器的文件相同,则浏览器仍需要连接到HTTP d(或像CloudFlare.com这样的CDN)才能获得304响应。 (请忽略离线缓存清单。)此外,如果您在浏览器中打开一个新选项卡,该新选项卡将再次为同一站点请求这些静态文件。
我想很多ISP服务器管理员会非常恼火地看到他们的DNS缓存充满了静态文件。我不知道他们在这种情况下做了什么,也许他们不允许你的域名缓存,这不会很好。
有什么想法吗?
对@Joe的回答:在这个假设的场景中,DNS客户端(可能是browserify和this module or similar)将在head-tag中运行,并在显示body标签之前拉出其余的静态内容。它不会与websocket连接太不同,因为它会在网页内运行。
答案 0 :(得分:2)
这种方法的主要问题是浏览器无法发送UDP数据包。
请参阅此处,了解正如您所述的讨论DNS TXT记录潜在漏洞的文章:DNS TXT records represent vulnerability for caching DNS servers。如本文所述,系统管理员和公共DNS服务器管理员可以完全禁用TXT记录的缓存,这将阻止将其用作有效的缓存机制。
native-dns不会让浏览器自己发送DNS请求。浏览器将HTTP请求发送到Node.js DNS server module,{{3}}将处理服务器上的DNS请求并将回复发送到浏览器。所以你仍然需要向浏览器返回HTTP 200
或304
响应,后者需要更多的工作,因为你必须实现自己的服务器端缓存机制来确定文件是否已经改变了。