文件缓存：查询字符串VS的Last-Modified？ [英] File Caching: Query string vs Last-Modified?

问题描述

我周围的缓存我的网站资产的方式愚弄，发现类似矿用查询字符串大多数网站覆盖缓存（例如：/css/style.css?v=124942823）

后来，我注意到，每当我救了我的style.css文件的最后修改标题是更新，使得查询字符串不必要的。

所以我想：

• 为什么这么多的网站使用查询字符串的方法，而不是仅仅让Last-Modified头做的工作？


• 我应该取消设置上次修改标头，只是与查询字符串工作？ （有没有什么特别的优势吗？）

谢谢！

解决方案

TL; DR

  

这么多的网站为什么使用查询字符串的方法，而不是仅仅让Last-Modified头做的工作？

更改查询字符串的URL改变了，确保内容是新鲜。

  

我应该取消设置上次修改标头，只是与查询字符串工作？

没有。虽然这是的几乎的正确答案。

---

有在网络上使用的三个基本的​​缓存策略：

• 无缓存，缓存或者禁止


• 使用验证/有条件请求


• 缓存永远

要说明三个，请考虑以下情形：

一个用户访问的第一次一个网站，装载十页和叶。每个页面加载相同的CSS文件。对于上述每个缓存策略多少请求会做的？

无缓存：10个请求

在这种情况下，应该清楚的是不是别的影响的结果，对于CSS文件10的请求将导致它被发送到客户端（浏览器）的10倍。

优点

• 内容永远是新鲜的


• 无需努力/管理

劣势

• 效率最低，内容始终传送

验证请求：请求10

如果的Last-Modified 或的Etag 使用，会有的也的是10个请求。不过其中9只为标题，并没有身​​体转移。客户端使用条件的要求，以避免重新下载东西它已经拥有。就拿CSS文件用于此网站。

请求该文件中的第一次，发生以下情况：

  $卷曲-i http://cdn.sstatic.net/stackoverflow/all.css
HTTP / 1.1 200 OK
服务器：CloudFlare的-nginx的
日期：星期一，2014年7时38分31秒格林尼治标准​​时间5月12日
内容类型：text / CSS
连接：保持活动
设置Cookie：__cfduid = d3fa9eddf76d614f83603a42f3e552f961399880311549;到期=周一，12月23日2019 GMT二十三点50分00秒;路径= /;域= .sstatic.net;仅Http
缓存控制：公众，最大年龄= 604800
最后一次修改：星期三，2014年4月30日22时09分37秒GMT
ETag的：8026e7dfc064cf1：0
有所不同：接受编码
CF-缓存状态：HIT
到期：星期一，2014年7点38分31秒格林尼治标准​​时间5月19日
CF-RAY：1294f50b2d6b08de-CDG
.avatar变化：悬停{backgro .....一些内容KB
 

对于同一网址的后续请求是这样的：

  $卷曲-i -H如果-Modified-Since的：星期三，2014年4月30日22时09分37秒GMThttp://cdn.sstatic.net/stackoverflow/all的CSS
HTTP / 1.1 304未修改
服务器：CloudFlare的-nginx的
日期：星期一，2014年7点40分11秒格林尼治标准​​时间5月12日
内容类型：text / CSS
连接：保持活动
设置Cookie：__cfduid = d0cc5​​afd385060dd8ba26265f0ebf40f81399880411024;到期=周一，12月23日2019 GMT二十三点50分00秒;路径= /;域= .sstatic.net;仅Http
缓存控制：公众，最大年龄= 604800
最后一次修改：星期三，2014年4月30日22时09分37秒GMT
ETag的：8026e7dfc064cf1：0
有所不同：接受编码
CF-缓存状态：HIT
到期：星期一，2014年7时40分11秒格林尼治标准​​时间5月19日
CF-RAY：1294f778e75d04a3-CDG
 

请注意，没有身体，响应是 304未修改。这是告诉客户端它已经有该网址的内容（在本地缓存）仍然是新鲜的。

这并不是说这是最佳的方案。使用工具，如的Chrome开发者工具的网络标签允许您查看究竟有多长，以及做什么，一个请求花费：

由于响应没有主体，响应时间将大大减少，因为有更少的数据传输。但是，是的还是响应。有是的仍然是所有连接到远程服务器的开销。

优点

• 内容永远是新鲜的


• 只有一个完全的请求发送


• 九请求更苗条仅包含头文件


• 更高效

劣势

• 仍发出请求的最大数量


• 还是招致DNS查找


• 仍然需要建立到远程服务器
的连接

• 不脱机工作


• 可能需要服务器配置

缓存永远：1请求

如果没有ETag的，没有最后修改的头，只有一个Expires头在未来定远 - 只为一个URL的第一访问将导致与远程服务器的任何通信。这是一个知名？为更好的前端性能的最佳实践。如果是这样的情况下，对于后续请求的客户机将从它自己的高速缓存中读取的内容和与远程服务器在所有无法通信。

这具有明显的性能优势，这是在移动设备上，其中，延迟可能显著尤其显著（说得客气一点）。

优点

• 最快捷，内容仅供传输一次

劣势

• 的网址必须更改为prevent现有游客陈旧加载缓存版本


• 最省力设置/管理

不要使用查询字符串清除缓存

这是规避客户端的缓存网站使用的查询参数。当内容改变（或者如果该网站的一个新版本被发布）在查询的参数被修改，并且因此<青霉>新的将被链接已经改变请求的文件的版本。这是较少的工作/多重命名每次改变时文件方便，它不是然而没有问题，

使用的查询字符串prevents代理缓存在下面引用笔者demonstating来自浏览器的请求＆LT; - >代理缓存服务器16; - >网站不使用代理缓存：

  

加载mylogo.gif？V = 1.2的两倍（在两者之间清除缓存）结果
  在这些报头：

 ＆GT;＆GT; GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP / 1.1
＆LT;＆LT; HTTP / 1.0 200 OK
＆LT;＆LT;日期：星期六，2008年○点19分34秒格林尼治标准​​时间8月23日
＆LT;＆LT;到期日：星期二，2018年8月21日0点19分34秒GMT
＆LT;＆LT;的X缓存：错过someserver.com
＆LT;＆LT;的X缓存查找：错过someserver.com＆GT;＆GT; GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP / 1.1
＆LT;＆LT; HTTP / 1.0 200 OK
＆LT;＆LT;日期：星期六，2008年0时19分47秒格林尼治标准​​时间8月23日
＆LT;＆LT;到期日：星期二，2018年8月21日格林尼治标准​​时间〇时19分47秒
＆LT;＆LT;的X缓存：错过someserver.com
＆LT;＆LT;的X缓存查找：错过someserver.com
 

  
  

这显然第二个反应是不是由代理服务：在
  缓存响应头说MISS，日期和过期值的变化，
  和尾矿的stevesouders.com访问日志显示了两个命中。

这不应该掉以轻心 - 访问网站物理上位于世界的响应时间对方可能会很慢的时候。正从沿路线位于代理服务器的应答可能意味着一个网站之间的区别在于可使用或不 - 在高速缓存-永远资源的情况下，它意味着一个URL的第一负载是缓慢的，在使用验证请求它的情况下意味着整个网站将是缓慢的。

相反的版本控制资产

最佳的解决方案是版本控制文件，例如，每当内容变化也是如此的URL。通常情况下，将被作为自动生成过程的一部分。

然而近妥协是实现一个重写规则这样作为

 ＃------------------------------- -----------------------------------------
＃|基于文件名的缓存无效|
＃------------------------------------------------- -----------------------------＃如果你没有使用一个构建过程来管理您的文件名的版本提速，
＃你可能要考虑启用以下指令路由所有
＃请求，如`/ CSS / style.12345.css`为`/ CSS / style.css`。＃要理解为什么这是重要的，比`*的.css v231`一个更好的主意，阅读？
＃http://stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring＆LT; IfModule mod_rewrite.c＆GT;
   的RewriteCond％{} REQUEST_FILENAME！-f
   重写规则^ \\（\\ D +）\\（JS | CSS | PNG | JPE G |？GIF）（+）。$ $ 1. $ 3 [L]
＆LT; / IfModule＆GT;
 

在这种方式 foo.123.css 的请求是由服务器处理为 foo.css - 这与使用清除缓存查询参数的所有优点，但是的没有的禁用代理缓存的问题。

I was fooling around with ways of caching my website's assets and noticed most websites similar to mine use query strings to override caching (e.g.: /css/style.css?v=124942823)

Afterwards, I noticed that whenever I saved my style.css file, the last-modified headers were "updated", making the query string unnecessary.

So I wonder:

• Why do so many websites use the "query string" method, instead of just letting the last-modified header do its work?
• Should I unset the Last-modified header and just work with query strings? (Is there any particular advantage to this?)

Thanks!

解决方案

TL;DR

Why do so many websites use the "query string" method, instead of just letting the last-modified header do its work?

Changing the query string changes the url, ensuring content is "fresh".

Should I unset the Last-modified header and just work with query strings?

No. Though that's almost the right answer.

---

There are three basic caching strategies used on the web:

• No caching, or caching disabled
• Using validation/conditional requests
• Caching forever

To illustrate all three, consider the following scenario:

A user accesses a website for the first time, loads ten pages and leaves. Each page loads the same css file. For each of the above caching strategies how many requests would be made?

No caching: 10 requests

In this scenario, it should be clear that there isn't anything else influencing the result, 10 requests for the css file would result in it being sent to the client (browser) 10 times.

Advantages

• Content always fresh
• No effort/management required

Disadvantages

• Least efficient, content always transferred

Validation requests: 10 requests

If Last-Modified or Etag are used, there will also be 10 requests. However 9 of them will only be the headers, and no body is transferred. Clients use conditional requests to avoid re-downloading something it already has. Take for example the css file for this site.

The very first time the file is requested, the following happens:

$ curl -i http://cdn.sstatic.net/stackoverflow/all.css
HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Mon, 12 May 2014 07:38:31 GMT
Content-Type: text/css
Connection: keep-alive
Set-Cookie: __cfduid=d3fa9eddf76d614f83603a42f3e552f961399880311549; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.sstatic.net; HttpOnly
Cache-Control: public, max-age=604800
Last-Modified: Wed, 30 Apr 2014 22:09:37 GMT
ETag: "8026e7dfc064cf1:0"
Vary: Accept-Encoding
CF-Cache-Status: HIT
Expires: Mon, 19 May 2014 07:38:31 GMT
CF-RAY: 1294f50b2d6b08de-CDG
.avatar-change:hover{backgro.....Some KB of content

A subsequent request for the same url would look like this:

$ curl -i -H "If-Modified-Since:Wed, 30 Apr 2014 22:09:37 GMT" http://cdn.sstatic.net/stackoverflow/all.css
HTTP/1.1 304 Not Modified
Server: cloudflare-nginx
Date: Mon, 12 May 2014 07:40:11 GMT
Content-Type: text/css
Connection: keep-alive
Set-Cookie: __cfduid=d0cc5afd385060dd8ba26265f0ebf40f81399880411024; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.sstatic.net; HttpOnly
Cache-Control: public, max-age=604800
Last-Modified: Wed, 30 Apr 2014 22:09:37 GMT
ETag: "8026e7dfc064cf1:0"
Vary: Accept-Encoding
CF-Cache-Status: HIT
Expires: Mon, 19 May 2014 07:40:11 GMT
CF-RAY: 1294f778e75d04a3-CDG

Note there is no body, and the response is a 304 Not Modified. This is telling the client that the content it already has (in local cache) for that url is still fresh.

That's not to say this is the optimal scenario. Using tools such as the network tab of chrome developer tools allows you to see exactly how long, and doing what, a request takes:

Because the response has no body, the response time will be much less because there's less data to transfer. But there is still a response. and there is still all of the overhead of connecting to the remote server.

Advantages

• Content always fresh
• Only one "Full" request sent
• Nine requests are much slimmer only containing headers
• More efficient

Disadvantages

• Still issues the maximum number of requests
• Still incurs DNS lookups
• Still needs to establish a connection to the remote server
• Doesn't work offline
• May require server configuration

Caching forever: 1 request

If there are no etags, no last modified header and only an expires header set far in the future - only the very first access to a url will result in any communication with the remote server. This is a well-known? best practice for better frontend performance. If this is the case, for subsequent requests a client will read the content from it's own cache and not communicate with the remote server at all.

This has clear performance advantages, which are especially significant on mobile devices where latency can be significant (to put it mildly).

Advantages

• Most efficient, content only transferred once

Disadvantages

• The url must change to prevent existing visitors loading stale cached versions
• Most effort to setup/manage

Don't use query strings for cache busting

It is to circumvent a client's cache that sites use a query argument. When the content changes (or if a new version of the site is published) the query argument is modified, and therefore a new version of that file will be requested as the url has changed. This is less work/more convenient than renaming the file every time it changes, it is not however without its problems,

Using query strings prevents proxy caching, in the below quote the author is demonstating that a request from browser<->proxy cache server<->website does not use the proxy cache:

Loading mylogo.gif?v=1.2 twice (clearing the cache in between) results in these headers:

>> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP/1.1
<< HTTP/1.0 200 OK
<< Date: Sat, 23 Aug 2008 00:19:34 GMT
<< Expires: Tue, 21 Aug 2018 00:19:34 GMT
<< X-Cache: MISS from someserver.com
<< X-Cache-Lookup: MISS from someserver.com

>> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP/1.1
<< HTTP/1.0 200 OK
<< Date: Sat, 23 Aug 2008 00:19:47 GMT
<< Expires: Tue, 21 Aug 2018 00:19:47 GMT
<< X-Cache: MISS from someserver.com
<< X-Cache-Lookup: MISS from someserver.com

Here it’s clear the second response was not served by the proxy: the caching response headers say MISS, the Date and Expires values change, and tailing the stevesouders.com access log shows two hits.

This shouldn't be taken lightly - when accessing a website physically located on the other side of the world response times can be very slow. Getting an answer from a proxy server located along the route can mean the difference between a website being usable or not - in the case of cached-forever resources it means the first load of a url is slow, in the case of using validation requests it means the whole site will be sluggish.

Instead version-control assets

The "best" solution is to version control files such that whenever the content changes so does the url. Normally that would be automated as part of the build process.

However a near-compromise to that is to implement a rewrite rule such as

# ------------------------------------------------------------------------------
# | Filename-based cache busting                                               |
# ------------------------------------------------------------------------------

# If you're not using a build process to manage your filename version revving,
# you might want to consider enabling the following directives to route all
# requests such as `/css/style.12345.css` to `/css/style.css`.

# To understand why this is important and a better idea than `*.css?v231`, read:
# http://stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring

<IfModule mod_rewrite.c>
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule ^(.+)\.(\d+)\.(js|css|png|jpe?g|gif)$ $1.$3 [L]
</IfModule>

In this way a request for foo.123.css is processed by the server as foo.css - this has all the advantages of using a query parameter for cache busting, but without the problem of disabling proxy caching.

这篇关于文件缓存：查询字符串VS的Last-Modified？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！