写给后端程序员的HTTP缓存原理介绍

通过Internet获取资源既缓慢,成本又高。为此,Http协议里包含了控制缓存的部分,以使Http客户端可以缓存和重用以前获取的资源,从而优化性能,提升体验。虽然Http中关于缓存控制的部分,随着协议演进,有一些变化。但我觉着,作为后端程序员,在开发Web服务时,只需要关注请求头If-None-Match、响应头ETag、响应头Cache-Control就足够了。因为这三个Http头就可以满足你的需求,并且,当今绝大多数的浏览器,都支持这三个Http头。我们所要做的就是,确保每个服务器响应都提供正确的 HTTP 头指令,以指导浏览器何时可以缓存响应以及可以缓存多久。

缓存在哪儿?

上图中有三个角色,浏览器、Web代理和服务器,如图所示Http缓存存在于浏览器和Web代理中。当然在服务器内部,也存在着各种缓存,但这已经不是本文要讨论的Http缓存了。所谓的Http缓存控制,就是一种约定,通过设置不同的响应头Cache-Control来控制浏览器和Web代理对缓存的使用策略,通过设置请求头If-None-Match和响应头ETag,来对缓存的有效性进行验证。

响应头ETag

ETag全称Entity Tag,用来标识一个资源。在具体的实现中,ETag可以是资源的hash值,也可以是一个内部维护的版本号。但不管怎样,ETag应该能反映出资源内容的变化,这是Http缓存可以正常工作的基础。

如上例中所展示的,服务器在返回响应时,通常会在Http头中包含一些关于响应的元数据信息,其中,ETag就是其中一个,本例中返回了值为x1323ddx的ETag。当资源/file的内容发生变化时,服务器应当返回不同的ETag。

请求头If-None-Match

对于同一个资源,比如上一例中的/file,在进行了一次请求之后,浏览器就已经有了/file的一个版本的内容,和这个版本的ETag,当下次用户再需要这个资源,浏览器再次向服务器请求的时候,可以利用请求头If-None-Match来告诉服务器自己已经有个ETag为x1323ddx的/file,这样,如果服务器上的/file没有变化,也就是说服务器上的/file的ETag也是x1323ddx的话,服务器就不会再返回/file的内容,而是返回一个304的响应,告诉浏览器该资源没有变化,缓存有效。

如上例中所示,在使用了If-None-Match之后,服务器只需要很小的响应就可以达到相同的结果,从而优化了性能。

响应头Cache-Control

每个资源都可以通过Http头Cache-Control来定义自己的缓存策略,Cache-Control控制谁在什么条件下可以缓存响应以及可以缓存多久。 最快的请求是不必与服务器进行通信的请求:通过响应的本地副本,我们可以避免所有的网络延迟以及数据传输的数据成本。为此,HTTP 规范允许服务器返回一系列不同的 Cache-Control 指令,控制浏览器或者其他中继缓存如何缓存某个响应以及缓存多长时间。

Cache-Control 头在 HTTP/1.1 规范中定义,取代了之前用来定义响应缓存策略的头(例如 Expires)。当前的所有浏览器都支持 Cache-Control,因此,使用它就够了。

以下我来介绍可以再Cache-Control中设置的常用指令。

max-age

该指令指定从当前请求开始,允许获取的响应被重用的最长时间(单位为秒。例如:Cache-Control:max-age=60表示响应可以再缓存和重用 60 秒。需要注意的是,在max-age指定的时间之内,浏览器不会向服务器发送任何请求,包括验证缓存是否有效的请求,也就是说,如果在这段时间之内,服务器上的资源发生了变化,那么浏览器将不能得到通知,而使用老版本的资源。所以在设置缓存时间的长度时,需要慎重。

public和private

如果设置了public,表示该响应可以再浏览器或者任何中继的Web代理中缓存,public是默认值,即Cache-Control:max-age=60等同于Cache-Control:public, max-age=60。

在服务器设置了private比如Cache-Control:private, max-age=60的情况下,表示只有用户的浏览器可以缓存private响应,不允许任何中继Web代理对其进行缓存 – 例如,用户浏览器可以缓存包含用户私人信息的 HTML 网页,但是 CDN 不能缓存。

no-cache

如果服务器在响应中设置了no-cache即Cache-Control:no-cache,那么浏览器在使用缓存的资源之前,必须先与服务器确认返回的响应是否被更改,如果资源未被更改,可以避免下载。这个验证之前的响应是否被修改,就是通过上面介绍的请求头If-None-match和响应头ETag来实现的。

需要注意的是,no-cache这个名字有一点误导。设置了no-cache之后,并不是说浏览器就不再缓存数据,只是浏览器在使用缓存数据时,需要先确认一下数据是否还跟服务器保持一致。如果设置了no-cache,而ETag的实现没有反应出资源的变化,那就会导致浏览器的缓存数据一直得不到更新的情况。

no-store

如果服务器在响应中设置了no-store即Cache-Control:no-store,那么浏览器和任何中继的Web代理,都不会存储这次相应的数据。当下次请求该资源时,浏览器只能重新请求服务器,重新从服务器读取资源。

怎样决定一个资源的Cache-Control策略呢?

下面这个流程图,可以帮到你。

时间: 2024-12-25 08:26:27

写给后端程序员的HTTP缓存原理介绍的相关文章

写给后端程序员的HTTP缓存原理介绍--怎样决定一个资源的Cache-Control策略呢

通过Internet获取资源既缓慢,成本又高.为此,Http协议里包含了控制缓存的部分,以使Http客户端可以缓存和重用以前获 取的资源,从而优化性能,提升体验.虽然Http中关于缓存控制的部分,随着协议演进,有一些变化.但我觉着,作为后端程 序员,在开发Web服务时,只需要关注请求头If-None-Match.响应头ETag.响应头Cache-Control就足够了.因为这三个Http 头就可以满足你的需求,并且,当今绝大多数的浏览器,都支持这三个Http头.我们所要做的就是,确保每个服务器响

后端程序员都做些什么?

后端程序员都做些什么? 2017-12-25 刘欣 程序猿 来自:码农翻身(微信号:coderising) 这个问题来自于QQ网友,一句两句说不清楚,索性写个文章. 我刚开始做Web开发的时候,根本没有前端,后端之说. 原因很简单,那个时候服务器端的代码就是一切:接受浏览器的请求,实现业务逻辑,访问数据库,用JSP生成HTML,然后发送给浏览器. 即使后来Javascript在浏览器中添加了一些AJAX的效果,那也是锦上添花,绝对不敢造次.因为页面的HTML主要还是用所谓"套模板"的方

写给 iOS 程序员看的 C++(2)

原文:Introduction to C++ for iOS Developers: Part 2 作者:Matt Galloway 译者:kmyhy 欢迎回到<写给 iOS 程序员看的 C++ 教程系列>第二部分! 在第一部分,你学习了类和内存管理. 在第二部分,你将进一步深入类的学习,以及其他更有意思的特性.你会学习什么是模板以及标准模板库. 最后,你将大致了解 Objectiv-C++--一种将 C++ 混入 Ojective-C 的技术. 准备好了吗?让我们开始吧! 多态 这里的多态不

【系列】后端程序员前端之路(2016/3/24更新)

后端程序员前端之路01 后端程序员前端之路02--CSS选择器详解 后端程序员前端之路03--HTML语义化 后端程序员前端之路04--html元素分类 后端程序员前端之路05--盒子模型详解 后端程序员前端之路06--布局模型,颜色值,长度值 --不断更新中,如果有帮助到你,请点“推荐”.你的支持,是我坚持的动力O(∩_∩)O谢谢~

写给嵌入式程序员的循环冗余校验(CRC)算法入门引导

写给嵌入式程序员的循环冗余校验(CRC)算法入门引导 http://blog.csdn.net/liyuanbhu/article/details/7882789 前言 CRC校验(循环冗余校验)是数据通讯中最常采用的校验方式.在嵌入式软件开发中,经常要用到CRC 算法对各种数据进行校验.因此,掌握基本的CRC算法应是嵌入式程序员的基本技能.可是,我认识的嵌入式程序员中能真正掌握CRC算法的人却很少,平常在项目中见到的CRC的代码多数都是那种效率非常低下的实现方式. 其实,在网上有一篇介绍CRC

敏捷软件开发:原则、模式与实践——第13章 写给C#程序员的UML概述

第13章 写给C#程序员的UML概述 UML包含3类主要的图示.静态图(static diagram)描述了类.对象.数据结构以及它们之间的关系,藉此表现出了软件元素间那些不变的逻辑结构.动态图(dynamic diagram)展示了软件实体在运行过程中是如何变化的,其中描述了运行流程或者实体改变状态的方式.物理图(physical diagram)展示了软件实体不变的物理结构,其中描述了诸如源文件.库.二进制文件.数据文件等物理实体以及它们之间的关系. 查看如下代码,这段程序实现了一个基于简单

Java后端程序员1年工作经验总结

java后端1年经验和技术总结(1) 1.引言 毕业已经一年有余,这一年里特别感谢技术管理人员的器重,以及同事的帮忙,学到了不少东西.这一年里走过一些弯路,也碰到一些难题,也受到过做为一名开发却经常为系统维护和发布当救火队员的苦恼.遂决定梳理一下自己所学的东西,为大家分享一下. 经过一年意识到以前也有很多认识误区,比如: 偏爱收集,经常收集各种资料视频塞满一个个硬盘,然后心满意足的看着容量不行动. 不重基础,总觉得很多基础东西不需要再看了,其实不懂的地方很多,计算机程序方面任何一个结果都必有原因

不要困在自己建造的盒子里——写给.NET程序员(转)

从我个人的观点看,本文中“.NET程序员”是指具有如下特点的程序员群体: 学习.工作的技术范围均局限于.NET平台及衍生,对.NET之外的技术没有主动接触或学习的欲望.不断学习各种.NET平台上的库或框架,如ADO.NET,ASP.NET MVC,WPF,Silverlight,WCF,WP,EF,NHibernate……工作无法脱离Visual Studio,习惯于图形化的工作环境.时常抱怨微软的技术更新太快,微软开发平台包办太多以至于自己身价贬值.对面向对象.设计模式.软件架构等东西具有极大

不要困在自己建造的盒子里——写给.NET程序员(附精彩评论)

转自:http://kb.cnblogs.com/page/92260/ 此文章的主旨是希望过于专注.NET程序员在做好工作.写好.NET程序的同时,能分拨出一点时间接触一下.NET之外的东西(例如10%-20%的时间),而不是鼓动大家什么都去学最后什么都学不精,更不是说.NET不行或劝大家放弃.NET.恕我愚钝,此主旨在文中表达不够清楚,看评论中很多朋友误解了,特此说明. 另外,本文中的观点并不全部是我个人的想法,相当一部分来自我以前聊过天的某些大牛,他们很多来自微软.百度.腾讯等知名企业,并