提升性能：通过 Accept-Encoding 主导 web 请求压缩 (提升性能的手段)

前言

在 Web 开发中，性能至关重要。用户期望网站快速加载并响应迅速，否则他们可能会放弃你的网站并转而寻找其他更快的选择。压缩是提高 Web 性能的有效技术之一，可以通过减小传输文件的大小来加快页面加载速度。

什么是请求压缩？

请求压缩是一种通过使用压缩算法（例如 GZIP 或 Brotli）压缩 HTTP 请求和响应正文以减小其大小的技术。这样做的好处如下：减少服务器和客户端之间传输的数据量缩短页面加载时间节省带宽

Accept-Encoding 请求头

Accept-Encoding 请求头允许客户端向服务器指示它可以接受哪些压缩算法。当服务器收到一个包含 Accept-Encoding 头的请求时，它将使用客户端指定的算法之一（如果可用）来压缩响应正文。Accept-Encoding 头的语法如下：```Accept-Encoding: [, ]...```其中 是服务器支持的压缩算法，例如：gzipbr (Brotli)deflate客户端可以指定多个算法，按优先级顺序排列。服务器将选择客户端最喜欢的算法，如果它可用的话。

启用请求压缩

在大多数 Web 服务器（例如 Apache、Nginx 和 IIS）上，请求压缩默认处于启用状态。但是，你可以检查配置文件以确保它是启用的。Apache在 Apache 中，在 .htaccess 文件中添加以下行以启用请求压缩：```SetOutputFilter DEFLATE```Nginx在 Nginx 中，在 nginx.conf 文件中添加以下行以启用请求压缩：```gzip on;```IIS在 IIS 中，通过 IIS 管理器启用请求压缩：1. 打开 IIS 管理器。2. 选择你的网站或应用程序池。3. 在“功能视图”窗格中，双击“HTTP 压缩”。4. 选中“启用动态压缩”复选框。

测试请求压缩

你可以使用不同的工具来测试请求压缩，例如：WebPageTest（）GTmetrix（）PageSpeed Insights（）这些工具将分析你的网站并提供有关你正在使用的压缩算法以及你可以进行哪些改进的报告。

使用 Content-Encoding 响应头

当服务器使用压缩算法压缩响应正文时，它将 Content-Encoding 响应头添加到响应中。此头指示客户端使用的压缩算法，以便客户端可以正确解压缩正文。Content-Encoding 头的语法如下：```Content-Encoding: ```其中 是服务器用于压缩响应正文的算法，例如：gzipbrdeflate

浏览器支持

所有现代浏览器都支持请求和响应压缩。以下是最流行的浏览器及其支持的压缩算法的列表：| 浏览器 | GZIP | Brotli ||---|---|---|| Chrome | 支持 | 支持 || Firefox | 支持 | 支持 || Safari | 支持 | 支持 || Edge | 支持 | 支持 || Internet Explorer | 支持 | 不支持 |

最佳实践

以下是使用 Accept-Encoding 头和请求压缩的一些最佳实践：在所有 HTTP 请求中包含 Accept-Encoding 头。优先考虑最有效的压缩算法，例如 Brotli 和 GZIP。定期测试你的网站以确保启用并正确配置请求压缩。考虑使用 HTTP/2，它支持更好的压缩功能。

结论

通过使用 Accept-Encoding 头和请求压缩，你可以显著提高 Web 性能。通过减小传输文件的大小，你可以加快页面加载速度、节省带宽并为你的用户提供更好的整体体验。遵循本文中概述的最佳实践以有效地利用请求压缩。

---

Accept-Encoding编码类型

GZIP，由Jean-loup Gailly和Mark Adler创建，最初是为UNIX系统文件设计的压缩技术，常用的GZIP格式文件在Linux系统中广泛存在，尤其在互联网上，它是一种非常普遍的数据压缩格式。 HTTP协议中的GZIP编码是一种旨在提升Web应用性能的技术，对于流量较大的网站，通过GZIP压缩技术可以显著提高页面加载速度，用户在访问时可以更快地看到网页内容。 服务器通常会启用这种功能，当用户请求访问时，服务器会压缩内容再发送给浏览器，文本内容通常能压缩到原始大小的40%左右，从而加快传输速度。 然而，这也增加了服务器的处理负担。 COMPRESS是Unix系统早期的压缩工具，它产生的压缩档案会附上.Z扩展名。 相比GZIP，它在压缩比例上可能不如后者理想，现在人们通常更倾向于使用GZIP进行档案压缩，因为它能提供更好的压缩效果。 如果需要将多个文件压缩，通常会先使用tar命令打包，然后再用GZIP处理。

HTTP Keep-Alive模式是什么?

HTTP协议中客户端发送一个小请求，服务器响应以所期望的信息（例如一个html文件或一副gif图像）。 服务器通常在发送回所请求的数据之后就关闭连接。 这样客户端读数据时会返回EOF（-1），就知道数据已经接收完全了。 1、什么是Keep-Alive模式？我们知道HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

http 1.0中默认是关闭的，需要在http头加入Connection: Keep-Alive，才能启用Keep-Alive；http 1.1中默认启用Keep-Alive，如果加入Connection: close ，才关闭。 目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成一个完整的Keep-Alive连接就看服务器设置情况。

2、启用Keep-Alive的优点从上面的分析来看，启用Keep-Alive模式肯定更高效，性能更高。 因为避免了建立/释放连接的开销。 下面是RFC 2616上的总结：

By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, Servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts. HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time. Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network. Latency on subsequent requests is reduced since there is no time spent in TCPs connection opening handshake. HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old semantics after an error is reported.

RFC 2616（P47）还指出：单用户客户端与任何服务器或代理之间的连接数不应该超过2个。 一个代理与其它服务器或代码之间应该使用超过2 * N的活跃并发连接。 这是为了提高HTTP响应时间，避免拥塞（冗余的连接并不能代码执行性能的提升）。

3、回到我们的问题（即如何判断消息内容/长度的大小？）Keep-Alive模式，客户端如何判断请求所得到的响应数据已经接收完成（或者说如何知道服务器已经发生完了数据）？我们已经知道了，Keep-Alive模式发送玩数据HTTP服务器不会自动断开连接，所有不能再使用返回EOF（-1）来判断（当然你一定要这样使用也没有办法，可以想象那效率是何等的低）！下面我介绍两种来判断方法。

3.1、使用消息首部字段Conent-Length故名思意，Conent-Length表示实体内容长度，客户端（服务器）可以根据这个值来判断数据是否接收完成。但是如果消息中没有Conent-Length，那该如何来判断呢？又在什么情况下会没有Conent-Length呢？请继续往下看……

3.2、使用消息首部字段Transfer-Encoding当客户端向服务器请求一个静态页面或者一张图片时，服务器可以很清楚的知道内容大小，然后通过Content-length消息首部字段告诉客户端需要接收多少数据。 但是如果是动态页面等时，服务器是不可能预先知道内容大小，这时就可以使用Transfer-Encoding：chunk模式来传输数据了。 即如果要一边产生数据，一边发给客户端，服务器就需要使用Transfer-Encoding: chunked这样的方式来代替Content-Length。

chunk编码将数据分成一块一块的发生。 Chunked编码将使用若干个Chunk串连而成，由一个标明长度为0的chunk标示结束。 每个Chunk分为头部和正文两部分，头部内容指定正文的字符总数（十六进制的数字）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF)隔开。 在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）。

Chunk编码的格式如下：

Chunked-Body = *chunk

chunk = chunk-size [ chunk-ext ] CRLF

chunk-data CRLF

hex-no-zero =

chunk-size = hex-no-zero *HEX

chunk-ext = *( ; chunk-ext-name [ = chunk-ext-value ] )

chunk-ext-name = token

chunk-ext-val = token | quoted-string

chunk-data = chunk-size(OCTET)

footer = *entity-header

即Chunk编码由四部分组成：1、0至多个chunk块，2、0 CRLF，3、footer，4、CRLF.而每个chunk块由：chunk-size、chunk-ext（可选）、CRLF、chunk-data、CRLF组成。

4、消息长度的总结其实，上面2中方法都可以归纳为是如何判断http消息的大小、消息的数量。 RFC 2616对消息的长度总结如下：一个消息的transfer-length（传输长度）是指消息中的message-body（消息体）的长度。 当应用了transfer-coding（传输编码），每个消息中的message-body（消息体）的长度（transfer-length）由以下几种情况决定（优先级由高到低）：

任何不含有消息体的消息（如1XXX、204、304等响应消息和任何头(HEAD，首部)请求的响应消息），总是由一个空行（CLRF）结束。 如果出现了Transfer-Encoding头字段 并且值为非“IDEntity”，那么transfer-length由“chunked” 传输编码定义，除非消息由于关闭连接而终止。 如果出现了Content-Length头字段，它的值表示entity-length（实体长度）和transfer-length（传输长度）。如果这两个长度的大小不一样（i.e.设置了Transfer-Encoding头字段），那么将不能发送Content-Length头字段。并且如果同时收到了Transfer-Encoding字段和Content-Length头字段，那么必须忽略Content-Length字段。 如果消息使用媒体类型“multipart/byteranges”，并且transfer-length 没有另外指定，那么这种自定界（self-delimiting）媒体类型定义transfer-length 。除非发送者知道接收者能够解析该类型，否则不能使用该类型。 由服务器关闭连接确定消息长度。（注意：关闭连接不能用于确定请求消息的结束，因为服务器不能再发响应消息给客户端了。）

为了兼容HTTP/1.0应用程序，HTTP/1.1的请求消息体中必须包含一个合法的Content-Length头字段，除非知道服务器兼容HTTP/1.1。 一个请求包含消息体，并且Content-Length字段没有给定，如果不能判断消息的长度，服务器应该用用400 (bad request) 来响应；或者服务器坚持希望收到一个合法的Content-Length字段，用 411 (length required)来响应。

所有HTTP/1.1的接收者应用程序必须接受“chunked” transfer-coding (传输编码)，因此当不能事先知道消息的长度，允许使用这种机制来传输消息。 消息不应该够同时包含 Content-Length头字段和non-identity transfer-coding。 如果一个消息同时包含non-identity transfer-coding和Content-Length ，必须忽略Content-Length 。

5、HTTP头字段总结最后我总结下HTTP协议的头部字段。

1、 Accept：告诉WEB服务器自己接受什么介质类型，*/* 表示任何类型，type/* 表示该类型下的所有子类型，type/sub-type。 2、 Accept-Charset： 浏览器申明自己接收的字符集

Accept-Encoding： 浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）

Accept-Language：浏览器申明自己接收的语言

语言跟字符集的区别：中文是语言，中文有多种字符集，比如big5，gb2312，gbk等等。 3、 Accept-Ranges：WEB服务器表明自己是否接受获取其某个实体的一部分（比如文件的一部分）的请求。 bytes：表示接受，none：表示不接受。 4、 Age：当代理服务器用自己缓存的实体去响应请求时，用该头部表明该实体从产生到现在经过多长时间了。 5、 Authorization：当客户端接收到来自WEB服务器的 WWW-Authenticate 响应时，用该头部来回应自己的身份验证信息给WEB服务器。 6、 Cache-Control：请求：no-cache（不要缓存的实体，要求现在从WEB服务器去取）

max-age：（只接受 Age 值小于 max-age 值，并且没有过期的对象）

max-stale：（可以接受过去的对象，但是过期时间必须小于 max-stale 值）

min-fresh：（接受其新鲜生命期大于其当前 Age 跟 min-fresh 值之和的缓存对象）

响应：public(可以用 Cached 内容回应任何用户)

private（只能用缓存内容回应先前请求该内容的那个用户）

no-cache（可以缓存，但是只有在跟WEB服务器验证了其有效后，才能返回给客户端）

max-age：（本响应包含的对象的过期时间）

ALL: no-store（不允许缓存） 7、 Connection：请求：close（告诉WEB服务器或者代理服务器，在完成本次请求的响应后，断开连接，不要等待本次连接的后续请求了）。

keepalive（告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求）。

响应：close（连接已经关闭）。

keepalive（连接保持着，在等待本次连接的后续请求）。

Keep-Alive：如果浏览器请求保持连接，则该头部表明希望 WEB 服务器保持连接多长时间（秒）。 例如：Keep-Alive：300 8、 Content-Encoding：WEB服务器表明自己使用了什么压缩方法（gzip，deflate）压缩响应中的对象。 例如：Content-Encoding：gzip 9、Content-Language：WEB 服务器告诉浏览器自己响应的对象的语言。 10、Content-Length： WEB 服务器告诉浏览器自己响应的对象的长度。 例如：Content-Length: 11、Content-Range： WEB 服务器表明该响应包含的部分对象为整个对象的哪个部分。 例如：Content-Range: bytes -/ 12、Content-Type： WEB 服务器告诉浏览器自己响应的对象的类型。 例如：Content-Type：application/xml 13、ETag：就是一个对象（比如URL）的标志值，就一个对象而言，比如一个 html 文件，如果被修改了，其 Etag 也会别修改，所以ETag 的作用跟 Last-Modified 的作用差不多，主要供 WEB 服务器判断一个对象是否改变了。 比如前一次请求某个 html 文件时，获得了其 ETag，当这次又请求这个文件时，浏览器就会把先前获得的 ETag 值发送给WEB 服务器，然后 WEB 服务器会把这个 ETag 跟该文件的当前 ETag 进行对比，然后就知道这个文件有没有改变了。 14、 Expired：WEB服务器表明该实体将在什么时候过期，对于过期了的对象，只有在跟WEB服务器验证了其有效性后，才能用来响应客户请求。 是 HTTP/1.0 的头部。 例如：Expires：Sat, 23 May 2009 10:02:12 GMT 15、 Host：客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号。 例如：Host 16、 If-Match：如果对象的 ETag 没有改变，其实也就意味著对象没有改变，才执行请求的动作。 17、 If-None-Match：如果对象的 ETag 改变了，其实也就意味著对象也改变了，才执行请求的动作。 18、 If-Modified-Since：如果请求的对象在该头部指定的时间之后修改了，才执行请求的动作（比如返回对象），否则返回代码304，告诉浏览器该对象没有修改。 例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT 19、 If-Unmodified-Since：如果请求的对象在该头部指定的时间之后没修改过，才执行请求的动作（比如返回对象）。 20、 If-Range：浏览器告诉 WEB 服务器，如果我请求的对象没有改变，就把我缺少的部分给我，如果对象改变了，就把整个对象给我。 浏览器通过发送请求对象的 ETag 或者 自己所知道的最后修改时间给 WEB 服务器，让其判断对象是否改变了。 总是跟 Range 头部一起使用。 21、 Last-Modified：WEB 服务器认为对象的最后修改时间，比如文件的最后修改时间，动态页面的最后产生时间等等。 例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT 22、 Location：WEB 服务器告诉浏览器，试图访问的对象已经被移到别的位置了，到该头部指定的位置去取。 例如：Location：23、 Pramga：主要使用 Pramga: no-cache，相当于 Cache-Control： no-cache。 例如：Pragma：no-cache 24、 Proxy-Authenticate： 代理服务器响应浏览器，要求其提供代理身份验证信息。 Proxy-Authorization：浏览器响应代理服务器的身份验证请求，提供自己的身份信息。 25、 Range：浏览器（比如 Flashget 多线程下载时）告诉 WEB 服务器自己想取对象的哪部分。 例如：Range: bytes=- 26、 Referer：浏览器向 WEB 服务器表明自己是从哪个 网页/URL 获得/点击 当前请求中的网址/URL。 例如：Referer：27、 Server: WEB 服务器表明自己是什么软件及版本等信息。 例如：Server：Apache/2.0.61 (Unix) 28、 User-Agent: 浏览器表明自己的身份（是哪种浏览器）。 例如：User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/ Firefox/2、0、0、14 29、 Transfer-Encoding: WEB 服务器表明自己对本响应消息体（不是消息体里面的对象）作了怎样的编码，比如是否分块（chunked）。 例如：Transfer-Encoding: chunked 30、 Vary: WEB服务器用该头部的内容告诉 Cache 服务器，在什么条件下才能用本响应所返回的对象响应后续的请求。 假如源WEB服务器在接到第一个请求消息时，其响应消息的头部为：Content-Encoding: gzip; Vary: Content-Encoding那么 Cache 服务器会分析后续请求消息的头部，检查其 Accept-Encoding，是否跟先前响应的 Vary 头部值一致，即是否使用相同的内容编码方法，这样就可以防止 Cache 服务器用自己 Cache 里面压缩后的实体响应给不具备解压能力的浏览器。 例如：Vary：Accept-Encoding 31、 Via： 列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器，他们用什么协议（和版本）发送的请求。 当客户端请求到达第一个代理服务器时，该服务器会在自己发出的请求里面添加 Via 头部，并填上自己的相关信息，当下一个代理服务器收到第一个代理服务器的请求时，会在自己发出的请求里面复制前一个代理服务器的请求的Via 头部，并把自己的相关信息加到后面，以此类推，当 OCS 收到最后一个代理服务器的请求时，检查 Via 头部，就知道该请求所经过的路由。 例如：Via：1.0 :80 (squid/13)

HTTP 请求消息头部实例：

User-Agent：Mozilla/5、0 (Windows; U; Windows NT 5、1; zh-CN; rv:1、8、1、14) Gecko/ Firefox/2、0、0、14

Accept：text/xml,application/xml,application/xhtml+xml,text/html;q=0、9,text/plain;q=0、8,image/png,*/*;q=0、5

Accept-Language：zh-cn,zh;q=0、5

Accept-Encoding：gzip,deflate

Accept-Charset：gb2312,utf-8;q=0、7,*;q=0、7

Keep-Alive：300

Connection：keep-alive

Cookie：userId=C5bYpXrimdmsiQmsBPnE1Vn8ZQmdWSm3WRlEB3vRwTnRtW -- Cookie

If-Modified-Since：Sun, 01 Jun 2008 12:05:30 GMT

Cache-Control：max-age=0

HTTP 响应消息头部实例：

Status：OK - 200 -- 响应状态码，表示 web 服务器处理的结果。

Date：Sun, 01 Jun 2008 12:35:47 GMT

Server：Apache/2、0、61 (Unix)

Last-Modified：Sun, 01 Jun 2008 12:35:30 GMT

Accept-Ranges：bytes

Content-Length

Cache-Control：max-age=120

Expires：Sun, 01 Jun 2008 12:37:47 GMT

Content-Type：application/xml

X-Cache：HIT from 236-41、D、sina、com、cn -- 反向代理服务器使用的 HTTP 头部

Via：1.0 :80 (squid/13)

Connection：close

本节摘自：

HTTP调试工具 fiddler图文使用教程详细介绍

Fiddler可以帮您记录，调试Microsoft Internet Explorer与Web应用程序的交互，找到Web程序运行性能的瓶颈，还有如查看向Web服务器发送cookies的内容，下载内容的大小等功能。

说多一点是，Fiddler站在用户与Web服务器的中间，由它转发请求与响应，因此Fiddler作为一个可检视，可定制的工具，能让您了解交互过程细节，有利于解决Web程序的交互问题。如下列示意图：

Internet Explorer - WinINET? (由Fiddler运行时自动注册) - Fiddler - Web Server

Fiddler可以用于： 性能测试。 如查看页面的大小调试。 在会话选项中，可暂停，编辑HTTP通讯 。

Fiddler不仅可用于Microsoft Internet Explorer，其它浏览器，如Mozilla Firefox，Opera等也适用。 软件界面友好，精于HTTP，可能比NetMon易用，还可用进行扩展。 官方站点上，还有视频教学。

这个工具我已经使用比较长时间了，对我的帮助也挺大，今天我翻译的微软的文章，让更多的朋友都来了解这个不错的工具，也是我第一次翻译文章，不恰当之处请大家大家多多指正。

介绍：

你是不是曾经疑惑过你的web程序和IE是如何交互的？你是不是遇到过一些奇怪的而你又无法解决的性能瓶颈？你是不是对那些发送给服务器端的cookie 和那些你下载下来的被标记为可缓存的内容感到好奇？

Fiddler官方网站及下载地址：微 软的Fiddler能够帮助你回答以上的问题，不但如此，它还是一个http调试代理，它能 够记录所有的你电脑和互联网之间的http通讯，Fiddler 可以也可以让你检查所有的http通讯，设置断点，以及Fiddle 所有的“进出”的数据（指cookie,html,js,css等文件，这些都可以让你胡乱修改的意思）。 Fiddler 要比其他的网络调试器要更加简单，因为它仅仅暴露http通讯还有提供一个用户友好的格式。

Fiddler 包含一个简单却功能强大的基于JScript 事件脚本子系统，他非常灵活性非常棒，可以支持众多的http调试任务。 Fiddler 是用C#写出来的。

。 。 。 。 。 接下来是一大段废话，关于如何安装的，只要一路next，就可以了。 这段话我就跳过，直接切入正题了。

Running Fiddler

当你启动了Fiddler，程序将会把自己作为一个微软互联网服务的系统代理中去。 你可以通过检查代理设置对话框来验证Fiddler是被正确地截取了web请求。 操作是这样的：点击IE设置，工具，局域网设置，最后点击高级。

作为系统代理，所有的来自微软互联网服务（WinInet）的http请求再到达目标Web服务器的之前都会经过Fiddle，同样的，所有的Http响应都会在返回客户端之前流经Fiddler。这样，就能明白Fiddler很多作用了吧！

当你关闭Fiddler的时候，它就会自动从系统注册表中移出，换句话说，当你关闭了Fiddler后，不会占着茅坑不拉屎。

下面，是一个Fillder的用户界面，大家可以参考参考其功能。

用Fiddler来做性能测试 HTTP统计视图通 过显示所有的Http通讯，Fiddler可以轻松的演示哪些用来生成一个页面，通过统计页 面（就是Fiddler左边的那个大框）用户可以很轻松的使用多选，来得到一个WEB页面的“总重量”（页面文件以及相关js,css等）你也可以很轻松 得看到你请求的某个页面，总共请求了多少次，以及多少字节被转化了。

另外，通过暴露HTTP头，用户可以看见哪些页面被允许在客户端或者是代理端进行缓存。 如果要是一个响应没有包含Cache-Control 头，那么他就不会被缓存在客户端。

用Fiddler来调试

Fiddler支持断点调试概念，当你在软件的菜单—rules—automatic breakpoints选项选择beforerequest,或者当这些请求或响应属性能够跟目标的标准相匹配，Fiddler就能够暂停Http通讯， 情切允许修改请求和响应。 这种功能对于安全测试是非常有用的，当然也可以用来做一般的功能测试，因为所有的代码路径都可以用来演习。

Session检查用 户可以在BuilderPage项种来以手工的方式来创建一个HTTP请求（即在 Fiddler右侧的tab的第三个，RequestBUILDER），或者可以使用拖拽操作从Session列表中来移动一个已经存在的请求到 builder page 来再次执行这个请求。 。 。

Fiddler 扩展Fiddler可以使用 framework来对它进行扩展。有2种为Fiddler扩展准备的基本机制：

自定义规则，和规则检查。

使用脚本化的规则来扩展Fiddler

Fiddler支持JScript 引擎，它可以允许用户自动地修改Http请求和响应。 这个引擎能够在可视化界面修改在FiddlerUI中的Session，可以从列表中提取你感兴趣的错误，也可以移除你不感兴趣的Session。

以下的示例代码演示当cookie被加载的时候把界面变成紫色。

static function OnBeforeRequest(){ if ((Cookie)){ oSession[ui-color] = purple; oSession[ui-bold] = cookie; }}

通过加入Inspectors来扩展Fiddler用户可以加入一个Inspector插件对象，来使用下的任何语言来编写Fiddler扩展。 RequestInspectors 和 ResponseInspectors提供一个格式规范的，或者是被指定的（用户自定义）Http请求和响应视图。

默认安装中，Fiddler加入了一下的Inspectors：

Request Inspectors

[RW] Headers—Shows request headers and status.

[RW] TextView—Shows the request body in a text box. （原始的请求body视图）

[RW] HexView—Shows the request body in a hexadecimal view. （body的16进制视图）

[RO] XML—Shows the request body as an XML DOM in a tree view.（以XML方式展示请求）

Response Inspectors

[RW] Transformer—Removes GZip, DEFLATE, and CHUNKED encodings for easier debugging.

[RW] Headers—Shows response headers and status.

[RW] TextView—Shows the response body in a text box.

[RW] HexView—Shows the response body in a hexadecimal view. （16进制视图）

[RO] ImageView—Shows the response body as an Image. Supports all image formats.

[RO] XML—Shows the response body as an XML DOM in a tree view.

[RO] Privacy—Explains the P3P statement in the response headers, if present.（如果在响应头中有关于隐私策略的说明就展示出来）

学习如何通过Fiddler建立一个速度更快的网站。 在这篇文章中，我们将使用Fiddler去探究HTTP的性能，缓存，以及压缩。

如果你要是没有安装和配置过Fiddler， 请从文章的第一篇开始。

HTTP性能总览毫 无疑问用户都喜欢访问速度快的网站。 用户是非常的不耐烦，除非你的网站是没有竞争对手，换句 话就是处于垄断地位的。 如果你的访问者来自世界各地，那你就必须要保证你的网站在执行效率方面要非常好，甚至要更加标准。 作为一个国际化的网络连接点，通 常要受到来自两个方面的压力：高访问量以及低带宽。

在第一次至关重要的访问中，用户必须要下载每一个内容片断，来生成页面，包括JS，CSS，Images，HTML，如果你的页面太难加载（包括IIS接到请求执行并返回给客户端HTML），访问者也许就会离开你的页面！

通过暴露所有的HTTP通讯，Fiddler很容易得向你展示哪些文件经常被用于生成一个页面，

Shift+click 可以在Fiddler左边框的会话列表中多选会话，来计算那些被选会话的“页面总重量”。 那些被转换成字节的数量。

如果你想让你的客户在第一次访问的时候就留下深刻的印象 ，那么最好的，也是唯一的途径就是返回给客户更少的文件。

1 使用更少的图画

2 将所有的CSS浓缩到一个CSS文件中

3 将所有的脚本浓缩到一个JS文件中

4 简化你的页面时间

5 使用HTTP压缩

如果要是你已经对用户的第一次来访的性能进行了优化，那么你可以通过Http 缓存的优势来使得你的网站访问速度更快！

HTTP 缓存介绍 2种方式来提升你的web 应用程序的速度：

减少请求和响应的往返次数

减少请求和响应的往返字节大小。

HTTP 缓存是最好的减少客户端服务器端往返次数的办法。 缓存提供了提供一种机制来保证客户端 或者代理能够存储一些东西，而这些东西将会在稍后的HTTP 响应中用到的。 （即第一次请求了，到了客户端，缓存起来，下次如果页面还要这个JS文件或者CSS文件啥的，就不要到服务器端去取下来了，但是还是要去服 务器上去访问一次，因为请求要对比ETAG值，关于这个值，我将会在下次翻译中介绍其作用）这样，就不用让文件再次跨越整个网络了。

缓存相关的请求头

为了提高性能，微软的IE和其他的web客户端总是想尽办法来维持从远程服务器上下载下来的本地的缓存。

当客户端需要一个资源（html,…），他们有3种可能的动作：

1 发送一个一般的HTTP请求到远程服务器端，请求这个资源。

2 发送一个有条件的HTTP请求到服务器，条件就是如果它不同于本地的缓存版本。

3 如果缓存的拷贝可用，就使用本地的缓存资源。

当发送一个请求，客户也许会使用如下的几个HEADER

Table 1. Client Cache Headers

Pragma: no-cache

The client is unwilling to accept any cached responses from caches along the route and the origin server must be contacted for a fresh copy of the resource.

If-Modified-Since: datetime

The server should return the requested resource only if the resource has been modified since the date-time provided by the client.

If-None-Match: etagvalue

The server should return the requested resource if the ETAG of the resource is different than the value provided by the client. An ETAG is a unique identifier representing a particular version of a file.

1 Pragma：no-cache 表明客户端不愿意接受缓存请求，它需要的是最即时的资源。

2 If-Modified-Since: datetime 表明如果这个资源自从上次被客户端请求，就已经修改了，那么服务器就会返回给客户端最新的。

3 If-None-Match: etagvalue 如果客户端资源的ETAG值跟服务器端不一致了，那么服务器端返回最新的资源。 ETAG就是一个唯一的ID，用来表示一个文件的一个特定的版本。

如 果要是这些有条件的请求，也就是含有If-Modified-Since 或者 If-None-MatchHeader头的请求，服务器将会以HTTP/304 Not Modified 来作为响应，那么客户端就知道可以使用客户端的缓存了。 否则，服务器将会返回一个新的响应并且客户端就会抛弃过期的缓存资源。

你 可以观察2个连贯的请求，来请求同一个图片，你会在Fiddler中发现：在第一个本地缓存 版本中，服务器返回一个含有ETAG的文件，和一个含有最后修改日期的文件，在这个第一次的请求会话中，一个本地的缓存版本已经可以使用了。 这样一来，一 个有条件的请求就被创建出来。 然后你再次请求这个图片的时候，他就就会响应一个本地缓存的文件，当然前提是第一次缓存的图片的ETAG值或者If- Modified-Since 值跟服务器上匹配的话，服务器就响应一个304给客户端。

GET /images/ HTTP/1.1

HTTP/1.1 200 OK

Date: Tue, 08 Mar 2006 00:32:46 GMT

Content-Length: 6171

Content-Type: image/jpeg

ETag: 40c7f76e8d30c31:2fe20

Last-Modified: Thu, 12 Jun 2003 02:50:50 GMT

GET /images/ HTTP/1.1

If-Modified-Since: Thu, 12 Jun 2003 02:50:50 GMT

If-None-Match: 40c7f76e8d30c31:2fe20

HTTP/1.1 304 Not Modified

因为一个HTTP304响应仅仅包含头，没有body,所有它在穿越互联网的时候要比携带了资源的快很多，尽管如此，HTTP/304响应需要一个服务器的往返，但是通过细心的设置响应头，web程序员可以消除这种因素，甚至是有条件的请求。

缓存相关响应头

通常缓存机制是由响应头来控制的。 HTTP规范描述了Header控制缓存，The optional Cache-Control，Expires（过期）。

Table 2. Common Cache-Control Headers

The response may be stored in any cache, including caches shared among many users.

The response may only be stored in a private cache used by a single user.

The response should not be reused to satisfy future requests.

The response should not be reused to satisfy future requests, and should not be written to disk. This is primarily used as a security measure for sensitive responses.

max-age=#seconds

The response may be reused to satisfy future requests within a certain number of seconds.

must-revalidate

The response may be reused to satisfy future requests, but the origin server should first be contacted to verify that the response is still fresh.

Cache-Control头的参数设置：

Public 响应会被缓存，并且在多用户间共享。

Private 响应只能够作为私有的缓存，不能再用户间共享。

No-cache 响应不会被缓存

No-store 响应不会被缓存，并且不会被写入到客户端的磁盘里，这也是基于安全考虑的某些敏感的响应才会使用这个。

Max-age=#seconds 响应将会某个指定的秒数内缓存，一旦时间过了，就不会被缓存。

Must-revalidate 响应会被重用来满足接下来的请求，但是它必须到服务器端去验证它是不是仍然是最新的。

注意：

如果你要想在iis中配置缓存，请参阅温软的知识技术文章：

你可以学习更多关于在中使用缓存的知识文章：

如果你发现你经常在你的网站上更新文件，但是并没有更改文件名字，那你就必须要非常小心地设置 你的缓存生存时间。 例如：如果你要一个图片文件显示当前的年份在网站上，你需要保证这个缓存过期时间不能超过一天，否则一个用户 在12月31号访问你的网站的时候，在1月1号就不能显示正确的日期。

由于某些原因，服务器可能会设置：Progma：no-cache 头，Cache-control:no-cache

Header中的参数：Vary 是一个缓存信号，Vary：User-Agent表示缓存当前的响应，但是仅限于当发送同样的User-Agent 头的时候。 指令 Vary：* 就相当于Cache-Control：no-Cache。

Vary就相当于中的缓存的参数一样，意思是根据什么来缓存，如果要是知道的缓存的使用方法，就很容易明白这个参数的意思。

使用HTTP会话列表，Fiddler用户可以看到在页面里包含的HTTP缓存头。

Fiddler会话列表如果响应不包含Expires或者Cache－Control，那么客户端就会被迫作为一个有条件的请求，来保证所有的资源都是最新的。

有条件的请求和WinInetCache

IE通过MicrosoftwindowsInternetServices来最大程度的利用缓存服务。WinInet允许用户配置缓存的大小和行为，设置缓存进行如下操作：

1打开IE，

2工具选项，选择Inrernet选项，在一般子选项中，临时文件夹内，点击设置

下图就是选村的四种设置：

标记性能问题：你可以使用Fiddler的自定义规则来标记某些你需要的，比如如果某个响应大于25KB，你可以把当前的Session标记为红色，更加醒目。以下代码都是在OnBeforeResponse事件中：

// Flag files over 25KB if (){ oSession[ui-color] = red; oSession[ui-bold] = true; oSession[ui-customcolumn] = Large file; }同样，你也可以标记响应并不指示缓存信息。 // Mark files which do not have caching informationif (!(Expires) !(Cache-Control)){ oSession[ui-color] = purple; oSession[ui-bold] = true; }介绍HTTP压缩所有的目前流行的WEB服务器和浏览器都提供HTTP压缩支持。 HTTP压缩可以非常显著地降 低客户端和服务器端的通讯量。 节省超过50％的HTML，XML，CSS，JS等文件。 一个浏览器发送一个信号给服务器，他可以介绍HTTP压缩过的内 容，并且会把客户端所支持的压缩类型放在请求的Header中，例如：考虑如下的请求：

GET / HTTP/1.1Accept: */*Accept-Language: en-usAccept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; CLR 1.1.4322)Host: 这个Accept－Encoding头表明IE将愿意接受GZIP格式的和DEFLATE格式的压缩响应。

相应的响应如下：

HTTP/1.1 200 OKContent-Type: text/html; charset=utf-8Server: Microsoft-IIS/6.0 --Microsoft-HTTPAPI/1.0X-Powered-By: : Accept-EncodingContent-Encoding: gzipDate: Tue, 15 Feb 2006 09:14:36 GMTContent-Length: 1277Connection: closeCache-Control: private, max-age=3600 你可以使用Fiddler来解压缩这些数据。 实验表明，使 用HTTP压缩能大量减少数据往返， 一个普通的CSS文件甚至能减少80％！当然压缩是以牺牲CPU性能为代价的。 特别是压缩动态文件，但是一般的权宜之策是压缩例如JS，CSS等静态文 件，因为他们在第一次压缩后，就会被存储在服务器上，如果要压缩asp．net动态文件，一定要有个权衡才行

Fiddler(HTTP调试抓包工具)下载地址：

简单两步，为ASP.NET Core应用程序开启gzip+Brotli响应压缩

在开发过程中，优化网络带宽是不可忽视的资源管理策略。 响应压缩技术能有效节省带宽，提高访问速度，特别是在处理文本类型资源如CSS、JavaScript、HTML、XML和JSON时。 微软 Core内置了gzip和Brotli这两种压缩方式，以简化开发者的设置过程。 gzip是一种常见的HTTP协议压缩技术，可将纯文本内容压缩到原大小的40%，从而加快数据传输。 而Brotli，发布于2015年，是Google为提升网络压缩效率而设计的，通常能提供比gzip更高的压缩密度，且压缩与解压缩速度相近。 要判断浏览器是否支持这些压缩，需查看客户端的Accept-Encoding请求头。 例如，Chrome浏览器支持gzip、deflate和br（Brotli）编码。 在 Core中，我们可通过添加依赖注入，配置Startup中的services来启用压缩，设置压缩级别和 MIME 类型，例如针对SVG图像的压缩。 在代码示例中，初始未启用压缩时，一个简单的Action响应为5.3KB，耗时178ms。 启用gzip和Brotli压缩后，请求大小降至214字节，耗时仅6ms，性能提升明显。 通过这些配置，我们可以为 Core应用带来显著的带宽节省和访问速度提升。

服务器如何开启gzip服务器如何开启远程

nginx打开gzip

NGINX的资源压缩原理是通过ngx_http_gzip_module拦截请求，对需要gzip的类型做gzip压缩。这个模块是默认的基础，所以你不需要重新编译就可以打开它。

的响应头中的内容编码是gzip。

2.返回的文件大小明显被压缩了。

1.通过开发者工具直接在浏览器中检查请求头和返回头信息。

2.使用curl命令行curl-i-haccept-encoding:gzip，deflate网站管理员工具中的网页Gzip检测

1.首先检查gzip_types是否包含所需的类型。

2.如果公司有多层缓存机制，确保在每一层都打开gzip压缩。

3.在上打开gzip_static并确认。 服务器上存在gz文件。

gzip在电脑哪个文件夹里？

IIS6已经内建了Gzip压缩的支持，可惜，没有设置更好的管理界面。 所以要打开这个选项，还要费些功夫。

1、如果你需要压缩静态文件（HTML），需要在硬盘上建一个目录，并给它“IUSR_机器名”这个用户的写权限。 如果压缩动态文件（PHP，asp，aspx，ashx）就不需要了，因为它的页面是每次都动态生成的，压缩完就放弃。

2、在IIS管理器中，“网站”节点上面(不是某个具体的站点，而是整个网站)右键－属性，选择“服务”标签，选上启用动态内容压缩，静态内容压缩。

3、在IIS管理器左侧选中“WEB服务器扩展”，新建一个服务器扩展。 名字任意，比如gzip，文件的路径是，并启用这个扩展。

4、停止IIS服务，打开(不停止IIS服务无法编辑该文件)，以关键字“根据需要增加一些要进行压缩的文件后缀，其中HcFileExtensions是静态文件的扩展名，增加js和css等；HcScriptFileExtensions为动态文件的扩展名，增加aspx，ashx等；HcDynamicCompressionLevel改成9，（0－10，9是性价比最高的一个）。

5、启动IIS服务，就已经成功启用gzip压缩了。

如何优化网站服务器提升网站访问速度？

您好，我是仙人掌热点。 网站运营的任何时候，网站访问速度都是至关重要的部分，它是网站友好体验中最基本的一项，如果访问体验都令人不满意，那么后期所做的营销推广模式都有可能徒劳无功，因为网络中客户的选择成本很低，加上普遍客户的耐心都不高，页面访问超过6秒客户就会选择离开，这对于一些流量本来就不高的企业网站来说无疑是雪上加霜。 网站访问速度既然如此重要，今天笔者也要跟大家分享几个关于提升速度体验的方法，虽然网上有很多类似的文章和观点，但是大多数都是网站内部去解析，今天笔者要从服务器方面聊聊如何优化网站服务器提升网站访问速度。

大多数网站运营优化人员都知道通过页面优化来提升访问速度，当你已经完成了优化操作之后，发现没有什么大的改善，此时你就应该去思考是不是其它因素导致访问速度缓慢。 比如：长期使用的服务器性能下降所致，为了保障业务不受影响，你或许应该对正在使用的服务器进行升级和优化了。

一、升级正在使用中的服务器

进行服务器升级工作之前，要考虑多方面的问题，是升级已有的服务器还是购置新的服务器设备须根据实际情况抉择。 首先来说升级现有的服务器设备，一般来说网站运营到后期随着业务不断增加，多平台应用的开发对于服务器性能的要求也逐步提升，长而久之服务器遇到性能瓶颈也是情理之中的事情，对于这种情况，我们可以通过升级服务器(例如增加硬件设备或网络带宽)等相关配置来满足不断扩大的业务需求，那么服务器性能瓶颈问题就可以得到解决。 再来说说购置新的服务器设备，也许有人会问为什么要重新购置呢，升级已有的服务器不可以吗?这里笔者也当然想替大家节省一笔开支，但是根本问题在于大多数企业选购服务器时并不合理，加上网站建设之初为节约成本而选择了扩展性较差的服务器，导致即便是我们对现有的服务器进行升级，其性能提升的强度依然不够。 此时，就需要重新购置服务器配合了，对于服务器的购置也有很多技巧，这里简单的做个推荐，如果用户群体是国内的建议选择国内知名的服务器供应商，若客户群体是遍布全球，大家可以选择香港服务器或美国服务器，除此之外，更重要的是要根据自身行业的特性做出合理的选择。

二、优化正在使用的服务器

不管是完成升级后的服务器，还是新购置的服务器，我们都要对其进行优化，从而提升服务器的性能以及利用率。下面从四个方面跟大家谈谈如何优化服务器：

要点一：尽可能的减少HTTP请求数

从客户访问网站页面到整个页面内容完全展现出来，这其中要花费较多的时间来下载各种Scripts、CSS样式表、Flash以及图片，而每一类下载都相当于一次HTTP请求，这样的请求越多网站被完全加载出来所花的时间会越长，意味着客户端的访问会很慢，那么此时就需要尽可能的减少HTTP请求数，通常我们可以直接把css和js写入到页面中，避免了外部的调用;或者我们可以把CSS文件和JS文件分来，在后台再进行合并，这样客户端浏览器相当于一次请求。 总而言之，减少HTTP请求数我们可以通过减少外部各类文件的数量调用次数来达到其目的。

要点二：降低DNS查询时间

众所周知网络服务器端的域名和IP地址是相互对应的，当客户端发出请求时，计算机还需要通过域名和IP地址的相互转换来判断，而这个转换工作便是域名解析DNS，通常DNS的查询需要10~20毫秒时间，客户端浏览器也只会等待DNS查询结束之后才会加载此域名下的内容。 因此，我们要加快页面的访问速度，就可以从降低DNS查询时间方面去做改善。

要点三：启用服务器Gzip压缩功能

对于大中型网站来说，页面的内容多且比较多样化，单个页面的大小可能是几百K以上了，客户端访问的时候下载会比较慢，此时我们可以采用服务器Gzip页面压缩功能，可以将一个大小为100K的页面文件压缩成25K以下，这样就可以减少网络传输的数量从而提高客户端访问速度。 一般服务器都是可以使用Gzip压缩功能的，并且能够针对JS文件、CSS文件和Html进行压缩，多方面去进行优化网站访问速度。

要点四：推荐大中型网站使用CDN加速工具

CDN加速是目前大型网站普遍使用的页面加速方式，它对于网站优化几乎没有影响的，基本原理是将网站镜像备份到很多服务器节点上，使服务器节点周围的用户访问速度更快，从而提升客户端高速访问网站的体验;但是并不是所有的网站都适合使用CDN加速，一般对于小规模站点个人站的话，就不需要使用CDN加速，毕竟从长期来看这可是一笔不小的开支;建议图片站以及多媒体站点可使用CDN加速。

至此，以上为大家讲到了可以通过优化和升级服务器两个方面提升网站访问速度，如果你的网站目前的访问体验不佳，可以尝试进行以上操作，相信能够帮助大家改善此类问题。

微信视频总是解析异常怎么解决？

我也遇到了类似的问题，服务器上数据开启了Gzip压缩，微信浏览器解析视频数据时候没有按照Gzip压缩后的数据解析。这种问题只出现在Android版本的微信上

其实客户端在向服务器端发送请求的时候，服务端就已经拿到客户端支持哪种压缩格式，服务器估计是判断到微信客户端支持Gzip压缩数据，就给客户端传输了Gzip格式的数据，谁知微信客户端不认

如何启用iis的gzip压缩功能？

IIS6已经内建了Gzip压缩的支持，可惜，没有设置更好的管理界面。 所以要打开这个选项，还要费些功夫。

1、如果你需要压缩静态文件（HTML），需要在硬盘上建一个目录，并给它“IUSR_机器名”这个用户的写权限。 如果压缩动态文件（PHP，asp，aspx，ashx）就不需要了，因为它的页面是每次都动态生成的，压缩完就放弃。

2、在IIS管理器中，“网站”节点上面(不是某个具体的站点，而是整个网站)右键－属性，选择“服务”标签，选上启用动态内容压缩，静态内容压缩。

3、在IIS管理器左侧选中“WEB服务器扩展”，新建一个服务器扩展。 名字任意，比如gzip，文件的路径是，并启用这个扩展。

4、停止IIS服务，打开(不停止IIS服务无法编辑该文件)，以关键字“根据需要增加一些要进行压缩的文件后缀，其中HcFileExtensions是静态文件的扩展名，增加js和css等；HcScriptFileExtensions为动态文件的扩展名，增加aspx，ashx等；HcDynamicCompressionLevel改成9，（0－10，9是性价比最高的一个）。

5、启动IIS服务，就已经成功启用gzip压缩了。

---

---

相关标签： 提升性能、 Accept、 通过、 Encoding、 请求压缩、 提升性能的手段、 web、 主导、

上一篇：掌控AcceptEncoding提高web应用程序的响应

下一篇：深入了解AcceptEncodingHTTP头部优化web传