etag

今日大致浏览了一下《 High Performance Web Sites 》。本书的中文版是《 高性能网站建设指南 》。 本书另有对其中个别问题深入探究的进阶篇《 Even Faster Web Sites 》，中译《 高性能网站建设进阶指南 》。 作者介绍上面的豆瓣链接中有，就不再照搬过来了。 这本书中给出了14条网站性能提升的原则，每个原则独立成章，配有示例。这些原则大多数都非常实用，适合站点架构师、前端工程师。其中对于前端工程师的意义更大一些。 这次看的是原版。我对于Web开发较缺乏实践经验，加之看得匆忙，因此可能存在遗漏、表述不当之处，希望广大网友不吝指正。 原则1 减少HTTP请求数 构造请求、等待响应需要时间，因此请求数量越少越好。减少请求的总体思路就是合并资源，减少显示一个页面需要的文件数。 1. Image Map 通过设置<img>标签的usemap属性与使用<map>标签可以在一幅图片上切分出多个区域，指向不同的链接。比起使用多幅图片分别构造链接减少了请求数。 2. CSS Sprite（CSS贴图整合/贴图拼合/贴图定位） 通过设置元素的background-position样式做到。一般用于界面图标。典型的可以参考TinyMCE编辑器上方的那些小按钮。多个小图实质是从一个统一的大图通过不同的偏移量裁剪而来，这样加载界面上的众多按钮实际上只要请求一次

http协议的请求和响应报文中必定包含http首部，只是平时我们在使用Web的过程中感受不到它，对它关注的也不是很多，最近在阅读《图解HTTP》，学习一下HTTP首部的结构，已经首部中各字段的用法。 HTTP报文首部 HTTP协议的请求和响应报文中必定包含HTTP首部，首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。列了一个请求和响应报文的大致结构脑图 HTTP报文结构 请求和响应中都会存在着首部字段，它们为浏览器和服务器，传递额外重要信息。 通常HTTP首部字段由首部字段名和字段值，中间以":"分割组成： Request Method: GET 字段值对应单个HTTP首部字段可以有多个值： cache - control : public , max - age = 0 首部字段类型 HTTP首部字段根据实际用途分为4中类型。 通用首部字段： 请求报文和响应报文两方都会使用到的首部。 请求首部字段： 从客户端向服务器发送请求报文时使用的首部，补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。 响应首部字段： 从服务器端向客户端返回响应报文时使用的首部，补充了响应时的附加内容，也会要求客户端附加额外的内容信息。 实体首部字段： 针对请求报文和响应报文的实体部分使用到的首部，补充了资源内容更新时间等与实体有关的信息。 通用首部字段 首部字段名 说明 Cache

浏览器缓存，也就是客户端缓存，既是网页性能优化里面静态资源相关优化的一大利器，也是无数web开发人员在工作过程不可避免的一大问题，所以在产品开发的时候我们总是想办法避免缓存产生，而在产品发布之时又在想策略管理缓存提升网页的访问速度。了解浏览器的缓存命中原理，是开发web应用的基础，本文着眼于此，学习浏览器缓存的相关知识，总结缓存避免和缓存管理的方法，结合具体的场景说明缓存的相关问题。希望能对有需要的人有所帮助。 1 浏览器缓存基本认识 它分为强缓存和协商缓存： 1.1 浏览器在加载资源时，先根据这个资源的一些http header判断它是否命中强缓存，强缓存如果命中，浏览器直接从自己的缓存中读取资源，不会发请求到服务器。比如某个css文件，如果浏览器在加载它所在的网页时，这个css文件的缓存配置命中了强缓存，浏览器就直接从缓存中加载这个css，连请求都不会发送到网页所在服务器； 1.2 当强缓存没有命中的时候，浏览器一定会发送一个请求到服务器，通过服务器端依据资源的另外一些http header验证这个资源是否命中协商缓存，如果协商缓存命中，服务器会将这个请求返回，但是不会返回这个资源的数据，而是告诉客户端可以直接从缓存中加载这个资源，于是浏览器就又会从自己的缓存中去加载这个资源； 1.3 强缓存与协商缓存的共同点是：如果命中，都是从客户端缓存中加载资源，而不是从服务器加载资源数据

HTTP协议规格说明定义ETag为“被请求变量的实体值”。 另一种说法是，ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义，并在HTTP响应头中将其传送到客户端，以下是服务器端返回的格式： ETag:"50b1c1d4f775c61:df3" 客户端的查询更新格式是这样的： If-None-Match : W / "50b1c1d4f775c61:df3" 如果ETag没改变，则返回状态304然后不返回，这也和Last-Modified一样。 测试Etag主要在断点下载时比较有用。 Last-Modified和ETags如何帮助提高性能?/Etag 聪明的开发者会把Last-Modified和ETags请求的http报头一起使用，这样可利用客户端（例如浏览器）的缓存。因为服务器首先产生Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户端）缓存。 过程如下: 1.客户端请求一个页面（A）。 2.服务器返回页面A，并在给A加上一个Last-Modified/ETag。 3.客户端展现该页面，并将页面连同Last-Modified/ETag一起缓存。 4.客户再次请求页面A

一、前言 前端缓存主要是分为HTTP缓存和浏览器缓存。其中HTTP缓存是在HTTP请求传输时用到的缓存，主要在服务器代码上设置；而浏览器缓存则主要由前端开发在前端js上进行设置。 缓存可以说是性能优化中简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的距离，减少延迟，并且由于缓存文件可以重复利用，还可以减少带宽，降低网络负荷。 对于一个数据请求来说，可以分为发起网络请求、后端处理、浏览器响应三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求，或者发起了请求但后端存储的数据和前端一致，那么就没有必要再将数据回传回来，这样就减少了响应数据。 缓存类型图解 二、缓存过程分析 浏览器与服务器通信的方式为应答模式，即是：浏览器发起HTTP请求 – 服务器响应该请求。那么浏览器第一次向服务器发起该请求后拿到请求结果，会根据响应报文中HTTP头的缓存标识，决定是否缓存结果，是则将请求结果和缓存标识存入浏览器缓存中，简单的过程如下图： 由上图我们可以知道： 浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识 浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中 三 强制缓存 强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程，强制缓存的情况主要有三种，如下：

web最好的体验是不需要与服务器通信 响应消除所有的网络延迟，并避免数据传输的数据开销。 为了实现这一目标，HTTP规范允许服务器返回多个不同的缓存控制指令来控制如何，以及多长时间可以通过浏览器和其他中间缓存缓存单个响应。 0.0.1. 好在每个现代浏览器都自带了 HTTP 缓存实现功能。 您只需要确保每个服务器响应都提供正确的 HTTP 标头指令，以指示浏览器何时可以缓存响应以及可以缓存多久。 0.0.2. 作为开发者，怎么利用HTTP Cache？ 浏览器会替我们完成所有工作，它会自动检测之前是否指定了验证令牌，它会将验证令牌追加到发出的请求上，并且它会根据从服务器接收的响应在必要时更新缓存时间戳。 0.0.3. 唯一要做的 就是确保服务器提供必要的 ETag 令牌。检查您的服务器文档中有无必要的配置标志。** 0.0.4. 送上Ngix 实战配置，不玩虚的 # 为JS 文件添加长时间缓存 location ~* \.js$ { add_header "section" "long expire"; # 仅供说明 add_header Cache-Control "max-age=31536000"; } # 或者为JS文件删除ETags location ~* \.js$ { add_header "section" "no etags"; # 仅供说明 etag off;

场景：因为自己做的后台，一直有为前端提供接口，一直知道用的是restful框架，可是没有深入理解，先整理如下。 转载自：http://kb.cnblogs.com/page/512047/ http://kb.cnblogs.com/page/521718/ 1. 什么是REST 　　REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到：“我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。” 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。 　　REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。 　　 2. 理解RESTful