为什么要使用Etag呢?Etag主要为了解决Last-Modified无法解决的一些问题
提起向百度提交数据,大家基本都会想到sitemap,最近又推出的etag是什么东东?真的能有效果吗? sitemap是解决网站收录至关重要的途径之一,而通常sitemap的更新都不是很及时,并且体量都相对较大,此时也消耗了相应的网站流量及带宽。而ETag可以用来标示网页是否发生了变化,如果没有变化返回304状态码,就不用再重新传输整个网页了。 在我们的sitemap配置了ETag之后,对日志一段时间的监测发现,其sitemap响应时间以及耗时的平均时间均大幅度下降,爬虫访问sitemap文件的次数有所增加,
本文将重点介绍如何在Spring中添加ETag功能、如何使用 curl来验证添加了ETag功能的REST API以及对这些REST API进行集成测试。
服务器如果是集群,不同服务器返回的 Http Header 中的 Etag 参数不一样。如果是图片是程序生成的,我们可以用 no-cache 这些 header 来控制,但如果这些图片是 apache 或 nginx 等呢?
回顾 在web后台开发中我们经常需要存储一些变量到session中进行暂存,最为特殊的就是“购物车”,由于http的无状态特性,因此我们需要在客户端打上一个标记,唯一的标示客户端并和服务端session一一对应,因此就有了通过cookie和url进行存储或传递这个标示--sessionID。 sessionID是一个长的字符串,它往往默认通过cookie来保存,这个session并不持久化到硬盘而是暂存到内存中,每次请求时都会在head中带上这个包含sessionID的cookie,服务端可以根据该id标
在HTTP1.1规范中,新增了一个HTTP头信息:ETag。对于普通开发者来说,可能平时真的不会接触到该HTTP头。平时接触不到或者说用得少,不代表这个请求头不重要。ETag使用得当,是可以减少服务器带宽压力的。
在客户端通过浏览器发出第一次请求某一个URL时,根据 HTTP 协议的规定,浏览器会向服务器传送报头(Http Request Header),服务器端响应同时记录相关属性标记(Http Reponse Header),服务器端的返回状态会是200,格式类似如下:
客户端检查资源超过有效期、强缓存命中失败的情况下,则发出请求“询问”服务器是否资源真的过期了,询问的同时在请求头要携带着资源的「上次更新时间」或者「唯一实体标识」(不同http版本导致的共存问题)。
在上一篇文章中,我们了解了 HTTP 强缓存,今天我们来了解一下协商缓存相关的内容。
幸运的是,Java附带了第一个这些格式的预定义格式化程序。可以在下面找到将标题设置为当天结束的示例。
HTTP客户端可能发送一些协议头来告诉服务端它们已经看过了哪些资源。这在获取网页(使用HTTPGET请求)时非常常见,可以避免发送客户端已经获得的完整数据。然而,相同的协议头可用于所有HTTP方法(POST, PUT, DELETE, 以及其它)。
条件获取(Conditional Retrieval)旨在解决这样的问题:客户端获取某个资源并对其进行缓存,当再次获取相同资源时,如果资源数据与之前获取的一致,则不再返回真正的资源数据,而是在回复中设置一个“标识”表明获取的资源并未发生改变。[源代码从这里下载] 一、 HTTP对条件获取的支持 HTTP对条件获取提供了原生的支持。具体的实现是这样的:服务端接收到客户端针对某个资源的第一次获取请求时,除了将资源数据作为HTTP回复主体返回之外,还会设置一个叫做ETag的回复报头。这个ETag与资源本身关联并且
Etag由服务器端生成,客户端通过If-None-Match这个条件请求来验证资源是否修改。请求一个文件的流程可能如下:
什么是ETag? 实体标签(EntityTag)是唯一标识了一个组件的一个特定版本的字符串,是web服务器用于确认缓存组件的有效性的一种机制,通常可以使用组件的某些属性来构造它。 条件GET请求 浏览
为什么需要优化 缓存可以减少冗余的数据传输。节省了网络带宽,从而更快的加载页面。 缓存降低了服务器的要求,从而服务器更快的响应。 那么我们使用缓存,缓存的资源文件到什么地方去了呢?首先来看下有哪几种缓
最近,我一直在玩 Netlify (https://www.netlify.com/),结果我对内容交付网络(CDN)常见的缓存策略越来越熟悉。有一种将 ETag标识符用于 Web 资源的策略。
RavenDB 使用基于 HTTP 的 REST 用于客户端和服务端的通信,也就是说我们在操作文档的时候其实就是使用 WEB 发送 HTTP 请求,那么基于这一点 RavenDB 就可以利用 HTTP 的特性来执行一些东西。 其中最常见的是 RavenDB 客户端 API 使用 HTTP 特性在客户端开启缓存。每个从服务端返回的响应都包含一个 etag 头内容,如果我们只是请求的单个文档,那么这个 etag 头内容就是文档的 etag 标题,如果我们请求的是多个文档的话,这个 etag 头内容就会包含一个计算值(具体计算值将在后面的专题详细讲解)。客户端将会缓存服务器的响应、URL 和 etag 的值,那么当有和缓存 URL 想的请求进入客户端时,我们会将其发送到服务端,同时也告知服务端,客户端存在一个特定 etag 值的请求结果。服务端在收到信息后会检查 etag 和客户端上的 etag 是否一样,如果一样就不返回数据,让客户端继续使用缓存的数据,这样就减少了网络的负载和服务端的压力。 另外,RavenDB 还有一个叫做 Aggressive Caching 的功能,它可以让看客户端 API 注册来自服务端的更改。也就是说,当我们在本地缓存了一些值后,就不需要再向服务端发送请求,让服务端判断是否要给我们返回新数据,通过这个功能如果服务端的数据发生了改变,那么服务端就会通知客户端,这时我们可以去请求服务端来获取新的数据。这个功能对于查询类似 configure 文档或大型文档来说可以大大的节省性能。
Cache 是HTTP协议中的一个非常重要的功能,使用Cache可以大大提高应用程序的性能,减少数据的网络传输。
其中 location 是指一个 url,比如 http://yoursite.com/getCustomDict,该请求只需满足以下两点即可完成分词热更新。
浏览器缓存是前端开发中不可避免的问题,对于web应用来说,它是提升页面性能同时减少服务器压力的利器。本文将简单地描述总结下浏览器缓存的知识和应用,希望对自己和大家都有所帮助 浏览器缓存类型 有两种,强缓存和协商缓存 1.强缓存:不会向服务器发送请求,直接从缓存中读取资源,在chrome控制台的network选项中可以看到该请求返回200的状态码,并且size显示from disk cache或from memory cache; 2.协商缓存:向服务器发送请求,服务器会根据这个请求的request head
网络篇—浏览器缓存(一) 一、缓存类型 有两种,强缓存和协商缓存 强缓存 不会向服务器发送请求,直接从缓存中读取资源; 协商缓存 向服务器发送请求,服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存,如果命中,则返回304状态码并带上新的response header通知浏览器从缓存中读取资源; 异同 共同点:都是从客户端缓存中读取资源; 区别:强缓存不会发请求,协商缓存会发请求; 二、和缓存有关的header 强缓存 Expires:response he
先判断 Etag, 再判断 last-modified. 但是结果会由服务器决策.
可分为两大类:http缓存和浏览器缓存。我们今天重点讲的是http缓存,所以关于浏览器缓存大家自行去查阅。下面这张图是前端缓存的一个大致知识点:
HTTP 缓存不是必须的,但重用缓存的资源通常是必要的。它可以减少服务器的压力,如果不使用缓存,每次发起请求都要求服务器发送相应数据,很多时候服务器发来的内容并没有发生变化,就会“浪费”服务器带宽。可以在客户端设置缓存,给缓存加上过期时间,如果期限没到就是用本地缓存的内容。然而常见的 HTTP 缓存只能存储 GET 响应,对于其他类型的响应则无能为力。
【转载请注明出处】:https://blog.csdn.net/huahao1989/article/details/107730210
上一篇文章我写了koa-static的源码解析[1],其中用到了HTTP的缓存策略,给返回的静态文件设置了一些缓存的头,比如Cache-Control之类的。于是我就跟朋友讨论了一下HTTP的缓存策略:
转自:http://hongjiang.info/http-header-range-and-content-range/
https://www.cnblogs.com/520yang/articles/4807408.html
浏览器缓存,是浏览器端保存数据,用于快速读取或避免重复资源请求的优化机制,有效的缓存使用可以避免重复的网络请求和加快页面速度,从而提高用户体验。
在本系列的前两篇文章中,分别向大家介绍了用于完成下载任务的 WebClinet 和 WinINet 的基本用法和一些实用技巧。 今天来为大家讲述下载过程中最常遇到的断点续传问题。 首先明确一点,本文所说的断点续传特指 HTTP 协议中的断点续传,文章中讲述了实现断点续传的方法思路和关键代码,想了解更多细节的同学,请下载并查看本文附带的 demo。 工作原理 http 协议中定义了一些请求/响应头,通过组合使用这些头信息,即可实现分批下载同一文件的目的。例如,在一次 http 请求中只请求文件中的一部分数据,
通过网络获取内容既缓慢,成本又高:大的响应需要在客户端和服务器之间进行多次往返通信,这拖延了浏览器可以使用和处理内容的时间,同时也增加了访问者的数据成本。因此,缓存和重用以前获取的资源的能力成为优化性能很关键的一个方面。
实操 Web Cache 摘要 写这篇文章的原因,是我看到网上很多谈这类的文章,多是人云亦云,不求实事,误导读者。 下面文中我会一个一个做实验,并展示给你,说明为什么会这样。只有自己亲自尝试才能拿出有说服力的真凭实据。 2014-03-12 首次发布 2015-08-27 修改,增加特殊数据缓存 ---- 目录 1. 测试环境 2. 文件修改日期 If-Modified-Since / Last-Modified 2.1.1. if_modified_since 2.1. 静态文件 2.2. 通过rewri
基础知识 1) 什么是”Last-Modified”? 在浏览器第一次请求某一个URL时,服务器端的返回状态会是200,内容是你请求的资源,同时有一个Last-Modified的属性标记此文件在服
最近在准备优化日志请求时遇到了一些令人疑惑的问题,比如为什么响应头里出现了两个 cache control、为什么明明设置了 no cache 却还是发请求,为什么多次访问时有时请求里带了 etag,有时又没有带?等等。。。 后来查了一些资料以及同事亲自验证,总算对这些问题有了个清晰的理解,现在整理出来以备忘。 1、缓存的分类 缓存分为服务端侧(server side,比如 Nginx、Apache)和客户端侧(client side,比如 web browser)。 服务端缓存又分为 代理服务器缓存 和
Entity tags (ETags) are a mechanism that web servers and browsers use to determine whether the component in the browser's cache matches the one on the origin server. (An “entity” is another word a “component”: images, scripts, stylesheets, etc.) ETags were added to provide a mechanism for validating entities that is more flexible than the last-modified date. An ETag is a string that uniquely identifies a specific version of a component. The only format constraints are that the string be quoted. The origin server specifies the component's ETag using the ETag response header.
客户端(一般是浏览器)发送了一个带条件的 GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回 304 Not Modified 这个状态码。
引言 通过网络获取内容既缓慢,成本又高:大的响应需要在客户端和服务器之间进行多次往返通信,这拖延了浏览器可以使用和处理内容的时间,同时也增加了访问者的数据成本。因此,缓存和重用以前获取的资源的能力成为优化性能很关键的一个方面。 序 本文用于解决以下六个疑问。 与缓存相关的HTTP首部字段主要有哪些? 这些HTTP首部字段之间的联系与区别? HTTP缓存首部字段的优先级? HTTP缓存首部字段的特点与局限性? 用户不同的页面刷新行为的差别? 在实践中我们该用哪些报文头来控制缓存呢
本文所需的一些预备知识可以看这里: http://www.cnblogs.com/cgzl/p/9010978.html 和 http://www.cnblogs.com/cgzl/p/9019314.html
本文首发于政采云前端团队博客:图解 HTTP 缓存 https://www.zoo.team/article/http-cache
HTTP 的缓存机制,可以说这是前端工程师需要掌握的重要知识点之一。本文将针对 HTTP 缓存整体的流程做一个详细的讲解,争取做到大家读完整篇文章后,对缓存有一个整体的了解。
什么是http缓存呢,当我们使用chrome浏览器,按F12打开控制台,在网络请求中有时候看到状态码是200,有时候状态码是304,当我们去看这种请求的时候,我们会发现状态码为304的状态结果是:Status Code: 304 Not Modified,而状态码为200的时候一般会有四种情况,一种是直接返回200,没有任何其他的标志,另一种是Status Code: 200 OK (from memory cache),还有一种是Status Code: 200 (from disk cache)。最后一种不是太常见,Status Code: 200 (from Service Worker).后面这三种状态码看到的效果是灰色的,其实从给出的信息也能看出来是从缓存中获取上数据。下面我们来详细介绍一下他们都分别是什么时候出现的。
在介绍缓存的时候,我们习惯将缓存分为强缓存和协商缓存两种。两者的主要区别是使用本地缓存的时候,是否需要向服务器验证本地缓存是否依旧有效。顾名思义,协商缓存,就是需要和服务器进行协商,最终确定是否使用本地缓存。
领取专属 10元无门槛券
手把手带您无忧上云