前言

在 Web 開發(fā)中，性能至關(guān)重要。用戶期望網(wǎng)站快速加載并響應(yīng)迅速，否則他們可能會放棄你的網(wǎng)站并轉(zhuǎn)而尋找其他更快的選擇。壓縮是提高 Web 性能的有效技術(shù)之一，可以通過減小傳輸文件的大小來加快頁面加載速度。

什么是請求壓縮？

請求壓縮是一種通過使用壓縮算法（例如 GZIP 或 Brotli）壓縮 HTTP 請求和響應(yīng)正文以減小其大小的技術(shù)。這樣做的好處如下：減少服務(wù)器和客戶端之間傳輸?shù)臄?shù)據(jù)量縮短頁面加載時間節(jié)省帶寬

Accept-Encoding 請求頭

Accept-Encoding 請求頭允許客戶端向服務(wù)器指示它可以接受哪些壓縮算法。當(dāng)服務(wù)器收到一個包含 Accept-Encoding 頭的請求時，它將使用客戶端指定的算法之一（如果可用）來壓縮響應(yīng)正文。Accept-Encoding 頭的語法如下：```Accept-Encoding: [, ]...```其中 是服務(wù)器支持的壓縮算法，例如：gzipbr (Brotli)deflate客戶端可以指定多個算法，按優(yōu)先級順序排列。服務(wù)器將選擇客戶端最喜歡的算法，如果它可用的話。

啟用請求壓縮

在大多數(shù) Web 服務(wù)器（例如 Apache、Nginx 和 IIS）上，請求壓縮默認(rèn)處于啟用狀態(tài)。但是，你可以檢查配置文件以確保它是啟用的。Apache在 Apache 中，在 .htaccess 文件中添加以下行以啟用請求壓縮：```SetOutputFilter DEFLATE```Nginx在 Nginx 中，在 nginx.conf 文件中添加以下行以啟用請求壓縮：```gzip on;```IIS在 IIS 中，通過 IIS 管理器啟用請求壓縮：1. 打開 IIS 管理器。2. 選擇你的網(wǎng)站或應(yīng)用程序池。3. 在“功能視圖”窗格中，雙擊“HTTP 壓縮”。4. 選中“啟用動態(tài)壓縮”復(fù)選框。

測試請求壓縮

你可以使用不同的工具來測試請求壓縮，例如：WebPageTest（）GTmetrix（）PageSpeed Insights（）這些工具將分析你的網(wǎng)站并提供有關(guān)你正在使用的壓縮算法以及你可以進(jìn)行哪些改進(jìn)的報告。

使用 Content-Encoding 響應(yīng)頭

當(dāng)服務(wù)器使用壓縮算法壓縮響應(yīng)正文時，它將 Content-Encoding 響應(yīng)頭添加到響應(yīng)中。此頭指示客戶端使用的壓縮算法，以便客戶端可以正確解壓縮正文。Content-Encoding 頭的語法如下：```Content-Encoding: ```其中 是服務(wù)器用于壓縮響應(yīng)正文的算法，例如：gzipbrdeflate

瀏覽器支持

所有現(xiàn)代瀏覽器都支持請求和響應(yīng)壓縮。以下是最流行的瀏覽器及其支持的壓縮算法的列表：| 瀏覽器 | GZIP | Brotli ||---|---|---|| Chrome | 支持 | 支持 || Firefox | 支持 | 支持 || Safari | 支持 | 支持 || Edge | 支持 | 支持 || Internet Explorer | 支持 | 不支持 |

最佳實(shí)踐

以下是使用 Accept-Encoding 頭和請求壓縮的一些最佳實(shí)踐：在所有 HTTP 請求中包含 Accept-Encoding 頭。優(yōu)先考慮最有效的壓縮算法，例如 Brotli 和 GZIP。定期測試你的網(wǎng)站以確保啟用并正確配置請求壓縮。考慮使用 HTTP/2，它支持更好的壓縮功能。

結(jié)論

通過使用 Accept-Encoding 頭和請求壓縮，你可以顯著提高 Web 性能。通過減小傳輸文件的大小，你可以加快頁面加載速度、節(jié)省帶寬并為你的用戶提供更好的整體體驗(yàn)。遵循本文中概述的最佳實(shí)踐以有效地利用請求壓縮。

---

Accept-Encoding編碼類型

GZIP，由Jean-loup Gailly和Mark Adler創(chuàng)建，最初是為UNIX系統(tǒng)文件設(shè)計的壓縮技術(shù)，常用的GZIP格式文件在Linux系統(tǒng)中廣泛存在，尤其在互聯(lián)網(wǎng)上，它是一種非常普遍的數(shù)據(jù)壓縮格式。 HTTP協(xié)議中的GZIP編碼是一種旨在提升Web應(yīng)用性能的技術(shù)，對于流量較大的網(wǎng)站，通過GZIP壓縮技術(shù)可以顯著提高頁面加載速度，用戶在訪問時可以更快地看到網(wǎng)頁內(nèi)容。 服務(wù)器通常會啟用這種功能，當(dāng)用戶請求訪問時，服務(wù)器會壓縮內(nèi)容再發(fā)送給瀏覽器，文本內(nèi)容通常能壓縮到原始大小的40%左右，從而加快傳輸速度。 然而，這也增加了服務(wù)器的處理負(fù)擔(dān)。 COMPRESS是Unix系統(tǒng)早期的壓縮工具，它產(chǎn)生的壓縮檔案會附上.Z擴(kuò)展名。 相比GZIP，它在壓縮比例上可能不如后者理想，現(xiàn)在人們通常更傾向于使用GZIP進(jìn)行檔案壓縮，因?yàn)樗芴峁└玫膲嚎s效果。 如果需要將多個文件壓縮，通常會先使用tar命令打包，然后再用GZIP處理。

HTTP Keep-Alive模式是什么?

HTTP協(xié)議中客戶端發(fā)送一個小請求，服務(wù)器響應(yīng)以所期望的信息（例如一個html文件或一副gif圖像）。 服務(wù)器通常在發(fā)送回所請求的數(shù)據(jù)之后就關(guān)閉連接。 這樣客戶端讀數(shù)據(jù)時會返回EOF（-1），就知道數(shù)據(jù)已經(jīng)接收完全了。 1、什么是Keep-Alive模式？我們知道HTTP協(xié)議采用“請求-應(yīng)答”模式，當(dāng)使用普通模式，即非KeepAlive模式時，每個請求/應(yīng)答客戶和服務(wù)器都要新建一個連接，完成之后立即斷開連接（HTTP協(xié)議為無連接的協(xié)議）；當(dāng)使用Keep-Alive模式（又稱持久連接、連接重用）時，Keep-Alive功能使客戶端到服務(wù)器端的連接持續(xù)有效，當(dāng)出現(xiàn)對服務(wù)器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接。

http 1.0中默認(rèn)是關(guān)閉的，需要在http頭加入Connection: Keep-Alive，才能啟用Keep-Alive；http 1.1中默認(rèn)啟用Keep-Alive，如果加入Connection: close ，才關(guān)閉。 目前大部分瀏覽器都是用http1.1協(xié)議，也就是說默認(rèn)都會發(fā)起Keep-Alive的連接請求了，所以是否能完成一個完整的Keep-Alive連接就看服務(wù)器設(shè)置情況。

2、啟用Keep-Alive的優(yōu)點(diǎn)從上面的分析來看，啟用Keep-Alive模式肯定更高效，性能更高。 因?yàn)楸苊饬私?釋放連接的開銷。 下面是RFC 2616上的總結(jié)：

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）還指出：單用戶客戶端與任何服務(wù)器或代理之間的連接數(shù)不應(yīng)該超過2個。 一個代理與其它服務(wù)器或代碼之間應(yīng)該使用超過2 * N的活躍并發(fā)連接。 這是為了提高HTTP響應(yīng)時間，避免擁塞（冗余的連接并不能代碼執(zhí)行性能的提升）。

3、回到我們的問題（即如何判斷消息內(nèi)容/長度的大小？）Keep-Alive模式，客戶端如何判斷請求所得到的響應(yīng)數(shù)據(jù)已經(jīng)接收完成（或者說如何知道服務(wù)器已經(jīng)發(fā)生完了數(shù)據(jù)）？我們已經(jīng)知道了，Keep-Alive模式發(fā)送玩數(shù)據(jù)HTTP服務(wù)器不會自動斷開連接，所有不能再使用返回EOF（-1）來判斷（當(dāng)然你一定要這樣使用也沒有辦法，可以想象那效率是何等的低）！下面我介紹兩種來判斷方法。

3.1、使用消息首部字段Conent-Length故名思意，Conent-Length表示實(shí)體內(nèi)容長度，客戶端（服務(wù)器）可以根據(jù)這個值來判斷數(shù)據(jù)是否接收完成。但是如果消息中沒有Conent-Length，那該如何來判斷呢？又在什么情況下會沒有Conent-Length呢？請繼續(xù)往下看……

3.2、使用消息首部字段Transfer-Encoding當(dāng)客戶端向服務(wù)器請求一個靜態(tài)頁面或者一張圖片時，服務(wù)器可以很清楚的知道內(nèi)容大小，然后通過Content-length消息首部字段告訴客戶端需要接收多少數(shù)據(jù)。 但是如果是動態(tài)頁面等時，服務(wù)器是不可能預(yù)先知道內(nèi)容大小，這時就可以使用Transfer-Encoding：chunk模式來傳輸數(shù)據(jù)了。 即如果要一邊產(chǎn)生數(shù)據(jù)，一邊發(fā)給客戶端，服務(wù)器就需要使用Transfer-Encoding: chunked這樣的方式來代替Content-Length。

chunk編碼將數(shù)據(jù)分成一塊一塊的發(fā)生。 Chunked編碼將使用若干個Chunk串連而成，由一個標(biāo)明長度為0的chunk標(biāo)示結(jié)束。 每個Chunk分為頭部和正文兩部分，頭部內(nèi)容指定正文的字符總數(shù)（十六進(jìn)制的數(shù)字）和數(shù)量單位（一般不寫），正文部分就是指定長度的實(shí)際內(nèi)容，兩部分之間用回車換行(CRLF)隔開。 在最后一個長度為0的Chunk中的內(nèi)容是稱為footer的內(nèi)容，是一些附加的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、消息長度的總結(jié)其實(shí)，上面2中方法都可以歸納為是如何判斷http消息的大小、消息的數(shù)量。 RFC 2616對消息的長度總結(jié)如下：一個消息的transfer-length（傳輸長度）是指消息中的message-body（消息體）的長度。 當(dāng)應(yīng)用了transfer-coding（傳輸編碼），每個消息中的message-body（消息體）的長度（transfer-length）由以下幾種情況決定（優(yōu)先級由高到低）：

任何不含有消息體的消息（如1XXX、204、304等響應(yīng)消息和任何頭(HEAD，首部)請求的響應(yīng)消息），總是由一個空行（CLRF）結(jié)束。 如果出現(xiàn)了Transfer-Encoding頭字段 并且值為非“IDEntity”，那么transfer-length由“chunked” 傳輸編碼定義，除非消息由于關(guān)閉連接而終止。 如果出現(xiàn)了Content-Length頭字段，它的值表示entity-length（實(shí)體長度）和transfer-length（傳輸長度）。如果這兩個長度的大小不一樣（i.e.設(shè)置了Transfer-Encoding頭字段），那么將不能發(fā)送Content-Length頭字段。并且如果同時收到了Transfer-Encoding字段和Content-Length頭字段，那么必須忽略Content-Length字段。 如果消息使用媒體類型“multipart/byteranges”，并且transfer-length 沒有另外指定，那么這種自定界（self-delimiting）媒體類型定義transfer-length 。除非發(fā)送者知道接收者能夠解析該類型，否則不能使用該類型。 由服務(wù)器關(guān)閉連接確定消息長度。（注意：關(guān)閉連接不能用于確定請求消息的結(jié)束，因?yàn)榉?wù)器不能再發(fā)響應(yīng)消息給客戶端了。）

為了兼容HTTP/1.0應(yīng)用程序，HTTP/1.1的請求消息體中必須包含一個合法的Content-Length頭字段，除非知道服務(wù)器兼容HTTP/1.1。 一個請求包含消息體，并且Content-Length字段沒有給定，如果不能判斷消息的長度，服務(wù)器應(yīng)該用用400 (bad request) 來響應(yīng)；或者服務(wù)器堅持希望收到一個合法的Content-Length字段，用 411 (length required)來響應(yīng)。

所有HTTP/1.1的接收者應(yīng)用程序必須接受“chunked” transfer-coding (傳輸編碼)，因此當(dāng)不能事先知道消息的長度，允許使用這種機(jī)制來傳輸消息。 消息不應(yīng)該夠同時包含 Content-Length頭字段和non-identity transfer-coding。 如果一個消息同時包含non-identity transfer-coding和Content-Length ，必須忽略Content-Length 。

5、HTTP頭字段總結(jié)最后我總結(jié)下HTTP協(xié)議的頭部字段。

1、 Accept：告訴WEB服務(wù)器自己接受什么介質(zhì)類型，*/* 表示任何類型，type/* 表示該類型下的所有子類型，type/sub-type。 2、 Accept-Charset： 瀏覽器申明自己接收的字符集

Accept-Encoding： 瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate）

Accept-Language：瀏覽器申明自己接收的語言

語言跟字符集的區(qū)別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等。 3、 Accept-Ranges：WEB服務(wù)器表明自己是否接受獲取其某個實(shí)體的一部分（比如文件的一部分）的請求。 bytes：表示接受，none：表示不接受。 4、 Age：當(dāng)代理服務(wù)器用自己緩存的實(shí)體去響應(yīng)請求時，用該頭部表明該實(shí)體從產(chǎn)生到現(xiàn)在經(jīng)過多長時間了。 5、 Authorization：當(dāng)客戶端接收到來自WEB服務(wù)器的 WWW-Authenticate 響應(yīng)時，用該頭部來回應(yīng)自己的身份驗(yàn)證信息給WEB服務(wù)器。 6、 Cache-Control：請求：no-cache（不要緩存的實(shí)體，要求現(xiàn)在從WEB服務(wù)器去取）

max-age：（只接受 Age 值小于 max-age 值，并且沒有過期的對象）

max-stale：（可以接受過去的對象，但是過期時間必須小于 max-stale 值）

min-fresh：（接受其新鮮生命期大于其當(dāng)前 Age 跟 min-fresh 值之和的緩存對象）

響應(yīng)：public(可以用 Cached 內(nèi)容回應(yīng)任何用戶)

private（只能用緩存內(nèi)容回應(yīng)先前請求該內(nèi)容的那個用戶）

no-cache（可以緩存，但是只有在跟WEB服務(wù)器驗(yàn)證了其有效后，才能返回給客戶端）

max-age：（本響應(yīng)包含的對象的過期時間）

ALL: no-store（不允許緩存） 7、 Connection：請求：close（告訴WEB服務(wù)器或者代理服務(wù)器，在完成本次請求的響應(yīng)后，斷開連接，不要等待本次連接的后續(xù)請求了）。

keepalive（告訴WEB服務(wù)器或者代理服務(wù)器，在完成本次請求的響應(yīng)后，保持連接，等待本次連接的后續(xù)請求）。

響應(yīng)：close（連接已經(jīng)關(guān)閉）。

keepalive（連接保持著，在等待本次連接的后續(xù)請求）。

Keep-Alive：如果瀏覽器請求保持連接，則該頭部表明希望 WEB 服務(wù)器保持連接多長時間（秒）。 例如：Keep-Alive：300 8、 Content-Encoding：WEB服務(wù)器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應(yīng)中的對象。 例如：Content-Encoding：gzip 9、Content-Language：WEB 服務(wù)器告訴瀏覽器自己響應(yīng)的對象的語言。 10、Content-Length： WEB 服務(wù)器告訴瀏覽器自己響應(yīng)的對象的長度。 例如：Content-Length: 11、Content-Range： WEB 服務(wù)器表明該響應(yīng)包含的部分對象為整個對象的哪個部分。 例如：Content-Range: bytes -/ 12、Content-Type： WEB 服務(wù)器告訴瀏覽器自己響應(yīng)的對象的類型。 例如：Content-Type：application/xml 13、ETag：就是一個對象（比如URL）的標(biāo)志值，就一個對象而言，比如一個 html 文件，如果被修改了，其 Etag 也會別修改，所以ETag 的作用跟 Last-Modified 的作用差不多，主要供 WEB 服務(wù)器判斷一個對象是否改變了。 比如前一次請求某個 html 文件時，獲得了其 ETag，當(dāng)這次又請求這個文件時，瀏覽器就會把先前獲得的 ETag 值發(fā)送給WEB 服務(wù)器，然后 WEB 服務(wù)器會把這個 ETag 跟該文件的當(dāng)前 ETag 進(jìn)行對比，然后就知道這個文件有沒有改變了。 14、 Expired：WEB服務(wù)器表明該實(shí)體將在什么時候過期，對于過期了的對象，只有在跟WEB服務(wù)器驗(yàn)證了其有效性后，才能用來響應(yīng)客戶請求。 是 HTTP/1.0 的頭部。 例如：Expires：Sat, 23 May 2009 10:02:12 GMT 15、 Host：客戶端指定自己想訪問的WEB服務(wù)器的域名/IP 地址和端口號。 例如：Host 16、 If-Match：如果對象的 ETag 沒有改變，其實(shí)也就意味著對象沒有改變，才執(zhí)行請求的動作。 17、 If-None-Match：如果對象的 ETag 改變了，其實(shí)也就意味著對象也改變了，才執(zhí)行請求的動作。 18、 If-Modified-Since：如果請求的對象在該頭部指定的時間之后修改了，才執(zhí)行請求的動作（比如返回對象），否則返回代碼304，告訴瀏覽器該對象沒有修改。 例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT 19、 If-Unmodified-Since：如果請求的對象在該頭部指定的時間之后沒修改過，才執(zhí)行請求的動作（比如返回對象）。 20、 If-Range：瀏覽器告訴 WEB 服務(wù)器，如果我請求的對象沒有改變，就把我缺少的部分給我，如果對象改變了，就把整個對象給我。 瀏覽器通過發(fā)送請求對象的 ETag 或者 自己所知道的最后修改時間給 WEB 服務(wù)器，讓其判斷對象是否改變了。 總是跟 Range 頭部一起使用。 21、 Last-Modified：WEB 服務(wù)器認(rèn)為對象的最后修改時間，比如文件的最后修改時間，動態(tài)頁面的最后產(chǎn)生時間等等。 例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT 22、 Location：WEB 服務(wù)器告訴瀏覽器，試圖訪問的對象已經(jīng)被移到別的位置了，到該頭部指定的位置去取。 例如：Location：23、 Pramga：主要使用 Pramga: no-cache，相當(dāng)于 Cache-Control： no-cache。 例如：Pragma：no-cache 24、 Proxy-Authenticate： 代理服務(wù)器響應(yīng)瀏覽器，要求其提供代理身份驗(yàn)證信息。 Proxy-Authorization：瀏覽器響應(yīng)代理服務(wù)器的身份驗(yàn)證請求，提供自己的身份信息。 25、 Range：瀏覽器（比如 Flashget 多線程下載時）告訴 WEB 服務(wù)器自己想取對象的哪部分。 例如：Range: bytes=- 26、 Referer：瀏覽器向 WEB 服務(wù)器表明自己是從哪個 網(wǎng)頁/URL 獲得/點(diǎn)擊 當(dāng)前請求中的網(wǎng)址/URL。 例如：Referer：27、 Server: WEB 服務(wù)器表明自己是什么軟件及版本等信息。 例如：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 服務(wù)器表明自己對本響應(yīng)消息體（不是消息體里面的對象）作了怎樣的編碼，比如是否分塊（chunked）。 例如：Transfer-Encoding: chunked 30、 Vary: WEB服務(wù)器用該頭部的內(nèi)容告訴 Cache 服務(wù)器，在什么條件下才能用本響應(yīng)所返回的對象響應(yīng)后續(xù)的請求。 假如源WEB服務(wù)器在接到第一個請求消息時，其響應(yīng)消息的頭部為：Content-Encoding: gzip; Vary: Content-Encoding那么 Cache 服務(wù)器會分析后續(xù)請求消息的頭部，檢查其 Accept-Encoding，是否跟先前響應(yīng)的 Vary 頭部值一致，即是否使用相同的內(nèi)容編碼方法，這樣就可以防止 Cache 服務(wù)器用自己 Cache 里面壓縮后的實(shí)體響應(yīng)給不具備解壓能力的瀏覽器。 例如：Vary：Accept-Encoding 31、 Via： 列出從客戶端到 OCS 或者相反方向的響應(yīng)經(jīng)過了哪些代理服務(wù)器，他們用什么協(xié)議（和版本）發(fā)送的請求。 當(dāng)客戶端請求到達(dá)第一個代理服務(wù)器時，該服務(wù)器會在自己發(fā)出的請求里面添加 Via 頭部，并填上自己的相關(guān)信息，當(dāng)下一個代理服務(wù)器收到第一個代理服務(wù)器的請求時，會在自己發(fā)出的請求里面復(fù)制前一個代理服務(wù)器的請求的Via 頭部，并把自己的相關(guān)信息加到后面，以此類推，當(dāng) OCS 收到最后一個代理服務(wù)器的請求時，檢查 Via 頭部，就知道該請求所經(jīng)過的路由。 例如：Via：1.0 :80 (squid/13)

HTTP 請求消息頭部實(shí)例：

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 響應(yīng)消息頭部實(shí)例：

Status：OK - 200 -- 響應(yīng)狀態(tài)碼，表示 web 服務(wù)器處理的結(jié)果。

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 -- 反向代理服務(wù)器使用的 HTTP 頭部

Via：1.0 :80 (squid/13)

Connection：close

本節(jié)摘自：

HTTP調(diào)試工具 fiddler圖文使用教程詳細(xì)介紹

Fiddler可以幫您記錄，調(diào)試Microsoft Internet Explorer與Web應(yīng)用程序的交互，找到Web程序運(yùn)行性能的瓶頸，還有如查看向Web服務(wù)器發(fā)送cookies的內(nèi)容，下載內(nèi)容的大小等功能。

說多一點(diǎn)是，F(xiàn)iddler站在用戶與Web服務(wù)器的中間，由它轉(zhuǎn)發(fā)請求與響應(yīng)，因此Fiddler作為一個可檢視，可定制的工具，能讓您了解交互過程細(xì)節(jié)，有利于解決Web程序的交互問題。如下列示意圖：

Internet Explorer - WinINET? (由Fiddler運(yùn)行時自動注冊) - Fiddler - Web Server

Fiddler可以用于： 性能測試。 如查看頁面的大小調(diào)試。 在會話選項(xiàng)中，可暫停，編輯HTTP通訊 。

Fiddler不僅可用于Microsoft Internet Explorer，其它瀏覽器，如Mozilla Firefox，Opera等也適用。 軟件界面友好，精于HTTP，可能比NetMon易用，還可用進(jìn)行擴(kuò)展。 官方站點(diǎn)上，還有視頻教學(xué)。

這個工具我已經(jīng)使用比較長時間了，對我的幫助也挺大，今天我翻譯的微軟的文章，讓更多的朋友都來了解這個不錯的工具，也是我第一次翻譯文章，不恰當(dāng)之處請大家大家多多指正。

介紹：

你是不是曾經(jīng)疑惑過你的web程序和IE是如何交互的？你是不是遇到過一些奇怪的而你又無法解決的性能瓶頸？你是不是對那些發(fā)送給服務(wù)器端的cookie 和那些你下載下來的被標(biāo)記為可緩存的內(nèi)容感到好奇？

Fiddler官方網(wǎng)站及下載地址：微 軟的Fiddler能夠幫助你回答以上的問題，不但如此，它還是一個http調(diào)試代理，它能 夠記錄所有的你電腦和互聯(lián)網(wǎng)之間的http通訊，F(xiàn)iddler 可以也可以讓你檢查所有的http通訊，設(shè)置斷點(diǎn)，以及Fiddle 所有的“進(jìn)出”的數(shù)據(jù)（指cookie,html,js,css等文件，這些都可以讓你胡亂修改的意思）。 Fiddler 要比其他的網(wǎng)絡(luò)調(diào)試器要更加簡單，因?yàn)樗鼉H僅暴露http通訊還有提供一個用戶友好的格式。

Fiddler 包含一個簡單卻功能強(qiáng)大的基于JScript 事件腳本子系統(tǒng)，他非常靈活性非常棒，可以支持眾多的http調(diào)試任務(wù)。 Fiddler 是用C#寫出來的。

。 。 。 。 。 接下來是一大段廢話，關(guān)于如何安裝的，只要一路next，就可以了。 這段話我就跳過，直接切入正題了。

Running Fiddler

當(dāng)你啟動了Fiddler，程序?qū)炎约鹤鳛橐粋€微軟互聯(lián)網(wǎng)服務(wù)的系統(tǒng)代理中去。 你可以通過檢查代理設(shè)置對話框來驗(yàn)證Fiddler是被正確地截取了web請求。 操作是這樣的：點(diǎn)擊IE設(shè)置，工具，局域網(wǎng)設(shè)置，最后點(diǎn)擊高級。

作為系統(tǒng)代理，所有的來自微軟互聯(lián)網(wǎng)服務(wù)（WinInet）的http請求再到達(dá)目標(biāo)Web服務(wù)器的之前都會經(jīng)過Fiddle，同樣的，所有的Http響應(yīng)都會在返回客戶端之前流經(jīng)Fiddler。這樣，就能明白Fiddler很多作用了吧！

當(dāng)你關(guān)閉Fiddler的時候，它就會自動從系統(tǒng)注冊表中移出，換句話說，當(dāng)你關(guān)閉了Fiddler后，不會占著茅坑不拉屎。

下面，是一個Fillder的用戶界面，大家可以參考參考其功能。

用Fiddler來做性能測試 HTTP統(tǒng)計視圖通 過顯示所有的Http通訊，F(xiàn)iddler可以輕松的演示哪些用來生成一個頁面，通過統(tǒng)計頁 面（就是Fiddler左邊的那個大框）用戶可以很輕松的使用多選，來得到一個WEB頁面的“總重量”（頁面文件以及相關(guān)js,css等）你也可以很輕松 得看到你請求的某個頁面，總共請求了多少次，以及多少字節(jié)被轉(zhuǎn)化了。

另外，通過暴露HTTP頭，用戶可以看見哪些頁面被允許在客戶端或者是代理端進(jìn)行緩存。 如果要是一個響應(yīng)沒有包含Cache-Control 頭，那么他就不會被緩存在客戶端。

用Fiddler來調(diào)試

Fiddler支持?jǐn)帱c(diǎn)調(diào)試概念，當(dāng)你在軟件的菜單—rules—automatic breakpoints選項(xiàng)選擇beforerequest,或者當(dāng)這些請求或響應(yīng)屬性能夠跟目標(biāo)的標(biāo)準(zhǔn)相匹配，F(xiàn)iddler就能夠暫停Http通訊， 情切允許修改請求和響應(yīng)。 這種功能對于安全測試是非常有用的，當(dāng)然也可以用來做一般的功能測試，因?yàn)樗械拇a路徑都可以用來演習(xí)。

Session檢查用 戶可以在BuilderPage項(xiàng)種來以手工的方式來創(chuàng)建一個HTTP請求（即在 Fiddler右側(cè)的tab的第三個，RequestBUILDER），或者可以使用拖拽操作從Session列表中來移動一個已經(jīng)存在的請求到 builder page 來再次執(zhí)行這個請求。 。 。

Fiddler 擴(kuò)展Fiddler可以使用 framework來對它進(jìn)行擴(kuò)展。有2種為Fiddler擴(kuò)展準(zhǔn)備的基本機(jī)制：

自定義規(guī)則，和規(guī)則檢查。

使用腳本化的規(guī)則來擴(kuò)展Fiddler

Fiddler支持JScript 引擎，它可以允許用戶自動地修改Http請求和響應(yīng)。 這個引擎能夠在可視化界面修改在FiddlerUI中的Session，可以從列表中提取你感興趣的錯誤，也可以移除你不感興趣的Session。

以下的示例代碼演示當(dāng)cookie被加載的時候把界面變成紫色。

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

通過加入Inspectors來擴(kuò)展Fiddler用戶可以加入一個Inspector插件對象，來使用下的任何語言來編寫Fiddler擴(kuò)展。 RequestInspectors 和 ResponseInspectors提供一個格式規(guī)范的，或者是被指定的（用戶自定義）Http請求和響應(yīng)視圖。

默認(rèn)安裝中，F(xiàn)iddler加入了一下的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進(jìn)制視圖）

[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進(jìn)制視圖）

[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.（如果在響應(yīng)頭中有關(guān)于隱私策略的說明就展示出來）

學(xué)習(xí)如何通過Fiddler建立一個速度更快的網(wǎng)站。 在這篇文章中，我們將使用Fiddler去探究HTTP的性能，緩存，以及壓縮。

如果你要是沒有安裝和配置過Fiddler， 請從文章的第一篇開始。

HTTP性能總覽毫 無疑問用戶都喜歡訪問速度快的網(wǎng)站。 用戶是非常的不耐煩，除非你的網(wǎng)站是沒有競爭對手，換句 話就是處于壟斷地位的。 如果你的訪問者來自世界各地，那你就必須要保證你的網(wǎng)站在執(zhí)行效率方面要非常好，甚至要更加標(biāo)準(zhǔn)。 作為一個國際化的網(wǎng)絡(luò)連接點(diǎn)，通 常要受到來自兩個方面的壓力：高訪問量以及低帶寬。

在第一次至關(guān)重要的訪問中，用戶必須要下載每一個內(nèi)容片斷，來生成頁面，包括JS，CSS，Images，HTML，如果你的頁面太難加載（包括IIS接到請求執(zhí)行并返回給客戶端HTML），訪問者也許就會離開你的頁面！

通過暴露所有的HTTP通訊，F(xiàn)iddler很容易得向你展示哪些文件經(jīng)常被用于生成一個頁面，

Shift+click 可以在Fiddler左邊框的會話列表中多選會話，來計算那些被選會話的“頁面總重量”。 那些被轉(zhuǎn)換成字節(jié)的數(shù)量。

如果你想讓你的客戶在第一次訪問的時候就留下深刻的印象 ，那么最好的，也是唯一的途徑就是返回給客戶更少的文件。

1 使用更少的圖畫

2 將所有的CSS濃縮到一個CSS文件中

3 將所有的腳本濃縮到一個JS文件中

4 簡化你的頁面時間

5 使用HTTP壓縮

如果要是你已經(jīng)對用戶的第一次來訪的性能進(jìn)行了優(yōu)化，那么你可以通過Http 緩存的優(yōu)勢來使得你的網(wǎng)站訪問速度更快！

HTTP 緩存介紹 2種方式來提升你的web 應(yīng)用程序的速度：

減少請求和響應(yīng)的往返次數(shù)

減少請求和響應(yīng)的往返字節(jié)大小。

HTTP 緩存是最好的減少客戶端服務(wù)器端往返次數(shù)的辦法。 緩存提供了提供一種機(jī)制來保證客戶端 或者代理能夠存儲一些東西，而這些東西將會在稍后的HTTP 響應(yīng)中用到的。 （即第一次請求了，到了客戶端，緩存起來，下次如果頁面還要這個JS文件或者CSS文件啥的，就不要到服務(wù)器端去取下來了，但是還是要去服 務(wù)器上去訪問一次，因?yàn)檎埱笠獙Ρ菶TAG值，關(guān)于這個值，我將會在下次翻譯中介紹其作用）這樣，就不用讓文件再次跨越整個網(wǎng)絡(luò)了。

緩存相關(guān)的請求頭

為了提高性能，微軟的IE和其他的web客戶端總是想盡辦法來維持從遠(yuǎn)程服務(wù)器上下載下來的本地的緩存。

當(dāng)客戶端需要一個資源（html,…），他們有3種可能的動作：

1 發(fā)送一個一般的HTTP請求到遠(yuǎn)程服務(wù)器端，請求這個資源。

2 發(fā)送一個有條件的HTTP請求到服務(wù)器，條件就是如果它不同于本地的緩存版本。

3 如果緩存的拷貝可用，就使用本地的緩存資源。

當(dāng)發(fā)送一個請求，客戶也許會使用如下的幾個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 表明如果這個資源自從上次被客戶端請求，就已經(jīng)修改了，那么服務(wù)器就會返回給客戶端最新的。

3 If-None-Match: etagvalue 如果客戶端資源的ETAG值跟服務(wù)器端不一致了，那么服務(wù)器端返回最新的資源。 ETAG就是一個唯一的ID，用來表示一個文件的一個特定的版本。

如 果要是這些有條件的請求，也就是含有If-Modified-Since 或者 If-None-MatchHeader頭的請求，服務(wù)器將會以HTTP/304 Not Modified 來作為響應(yīng)，那么客戶端就知道可以使用客戶端的緩存了。 否則，服務(wù)器將會返回一個新的響應(yīng)并且客戶端就會拋棄過期的緩存資源。

你 可以觀察2個連貫的請求，來請求同一個圖片，你會在Fiddler中發(fā)現(xiàn)：在第一個本地緩存 版本中，服務(wù)器返回一個含有ETAG的文件，和一個含有最后修改日期的文件，在這個第一次的請求會話中，一個本地的緩存版本已經(jīng)可以使用了。 這樣一來，一 個有條件的請求就被創(chuàng)建出來。 然后你再次請求這個圖片的時候，他就就會響應(yīng)一個本地緩存的文件，當(dāng)然前提是第一次緩存的圖片的ETAG值或者If- Modified-Since 值跟服務(wù)器上匹配的話，服務(wù)器就響應(yīng)一個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

因?yàn)橐粋€HTTP304響應(yīng)僅僅包含頭，沒有body,所有它在穿越互聯(lián)網(wǎng)的時候要比攜帶了資源的快很多，盡管如此，HTTP/304響應(yīng)需要一個服務(wù)器的往返，但是通過細(xì)心的設(shè)置響應(yīng)頭，web程序員可以消除這種因素，甚至是有條件的請求。

緩存相關(guān)響應(yīng)頭

通常緩存機(jī)制是由響應(yīng)頭來控制的。 HTTP規(guī)范描述了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頭的參數(shù)設(shè)置：

Public 響應(yīng)會被緩存，并且在多用戶間共享。

Private 響應(yīng)只能夠作為私有的緩存，不能再用戶間共享。

No-cache 響應(yīng)不會被緩存

No-store 響應(yīng)不會被緩存，并且不會被寫入到客戶端的磁盤里，這也是基于安全考慮的某些敏感的響應(yīng)才會使用這個。

Max-age=#seconds 響應(yīng)將會某個指定的秒數(shù)內(nèi)緩存，一旦時間過了，就不會被緩存。

Must-revalidate 響應(yīng)會被重用來滿足接下來的請求，但是它必須到服務(wù)器端去驗(yàn)證它是不是仍然是最新的。

注意：

如果你要想在iis中配置緩存，請參閱溫軟的知識技術(shù)文章：

你可以學(xué)習(xí)更多關(guān)于在中使用緩存的知識文章：

如果你發(fā)現(xiàn)你經(jīng)常在你的網(wǎng)站上更新文件，但是并沒有更改文件名字，那你就必須要非常小心地設(shè)置 你的緩存生存時間。 例如：如果你要一個圖片文件顯示當(dāng)前的年份在網(wǎng)站上，你需要保證這個緩存過期時間不能超過一天，否則一個用戶 在12月31號訪問你的網(wǎng)站的時候，在1月1號就不能顯示正確的日期。

由于某些原因，服務(wù)器可能會設(shè)置：Progma：no-cache 頭，Cache-control:no-cache

Header中的參數(shù)：Vary 是一個緩存信號，Vary：User-Agent表示緩存當(dāng)前的響應(yīng)，但是僅限于當(dāng)發(fā)送同樣的User-Agent 頭的時候。 指令 Vary：* 就相當(dāng)于Cache-Control：no-Cache。

Vary就相當(dāng)于中的緩存的參數(shù)一樣，意思是根據(jù)什么來緩存，如果要是知道的緩存的使用方法，就很容易明白這個參數(shù)的意思。

使用HTTP會話列表，F(xiàn)iddler用戶可以看到在頁面里包含的HTTP緩存頭。

Fiddler會話列表如果響應(yīng)不包含Expires或者Cache－Control，那么客戶端就會被迫作為一個有條件的請求，來保證所有的資源都是最新的。

有條件的請求和WinInetCache

IE通過MicrosoftwindowsInternetServices來最大程度的利用緩存服務(wù)。WinInet允許用戶配置緩存的大小和行為，設(shè)置緩存進(jìn)行如下操作：

1打開IE，

2工具選項(xiàng)，選擇Inrernet選項(xiàng)，在一般子選項(xiàng)中，臨時文件夾內(nèi)，點(diǎn)擊設(shè)置

下圖就是選村的四種設(shè)置：

標(biāo)記性能問題：你可以使用Fiddler的自定義規(guī)則來標(biāo)記某些你需要的，比如如果某個響應(yīng)大于25KB，你可以把當(dāng)前的Session標(biāo)記為紅色，更加醒目。以下代碼都是在OnBeforeResponse事件中：

// Flag files over 25KB if (){ oSession[ui-color] = red; oSession[ui-bold] = true; oSession[ui-customcolumn] = Large file; }同樣，你也可以標(biāo)記響應(yīng)并不指示緩存信息。 // Mark files which do not have caching informationif (!(Expires) !(Cache-Control)){ oSession[ui-color] = purple; oSession[ui-bold] = true; }介紹HTTP壓縮所有的目前流行的WEB服務(wù)器和瀏覽器都提供HTTP壓縮支持。 HTTP壓縮可以非常顯著地降 低客戶端和服務(wù)器端的通訊量。 節(jié)省超過50％的HTML，XML，CSS，JS等文件。 一個瀏覽器發(fā)送一個信號給服務(wù)器，他可以介紹HTTP壓縮過的內(nèi) 容，并且會把客戶端所支持的壓縮類型放在請求的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格式的壓縮響應(yīng)。

相應(yīng)的響應(yīng)如下：

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來解壓縮這些數(shù)據(jù)。 實(shí)驗(yàn)表明，使 用HTTP壓縮能大量減少數(shù)據(jù)往返， 一個普通的CSS文件甚至能減少80％！當(dāng)然壓縮是以犧牲CPU性能為代價的。 特別是壓縮動態(tài)文件，但是一般的權(quán)宜之策是壓縮例如JS，CSS等靜態(tài)文 件，因?yàn)樗麄冊诘谝淮螇嚎s后，就會被存儲在服務(wù)器上，如果要壓縮asp．net動態(tài)文件，一定要有個權(quán)衡才行

Fiddler(HTTP調(diào)試抓包工具)下載地址：

簡單兩步，為ASP.NET Core應(yīng)用程序開啟gzip+Brotli響應(yīng)壓縮

在開發(fā)過程中，優(yōu)化網(wǎng)絡(luò)帶寬是不可忽視的資源管理策略。 響應(yīng)壓縮技術(shù)能有效節(jié)省帶寬，提高訪問速度，特別是在處理文本類型資源如CSS、JavaScript、HTML、XML和JSON時。 微軟 Core內(nèi)置了gzip和Brotli這兩種壓縮方式，以簡化開發(fā)者的設(shè)置過程。 gzip是一種常見的HTTP協(xié)議壓縮技術(shù)，可將純文本內(nèi)容壓縮到原大小的40%，從而加快數(shù)據(jù)傳輸。 而Brotli，發(fā)布于2015年，是Google為提升網(wǎng)絡(luò)壓縮效率而設(shè)計的，通常能提供比gzip更高的壓縮密度，且壓縮與解壓縮速度相近。 要判斷瀏覽器是否支持這些壓縮，需查看客戶端的Accept-Encoding請求頭。 例如，Chrome瀏覽器支持gzip、deflate和br（Brotli）編碼。 在 Core中，我們可通過添加依賴注入，配置Startup中的services來啟用壓縮，設(shè)置壓縮級別和 MIME 類型，例如針對SVG圖像的壓縮。 在代碼示例中，初始未啟用壓縮時，一個簡單的Action響應(yīng)為5.3KB，耗時178ms。 啟用gzip和Brotli壓縮后，請求大小降至214字節(jié)，耗時僅6ms，性能提升明顯。 通過這些配置，我們可以為 Core應(yīng)用帶來顯著的帶寬節(jié)省和訪問速度提升。

服務(wù)器如何開啟gzip服務(wù)器如何開啟遠(yuǎn)程

nginx打開gzip

NGINX的資源壓縮原理是通過ngx_http_gzip_module攔截請求，對需要gzip的類型做gzip壓縮。這個模塊是默認(rèn)的基礎(chǔ)，所以你不需要重新編譯就可以打開它。

的響應(yīng)頭中的內(nèi)容編碼是gzip。

2.返回的文件大小明顯被壓縮了。

1.通過開發(fā)者工具直接在瀏覽器中檢查請求頭和返回頭信息。

2.使用curl命令行curl-i-haccept-encoding:gzip，deflate網(wǎng)站管理員工具中的網(wǎng)頁Gzip檢測

1.首先檢查gzip_types是否包含所需的類型。

2.如果公司有多層緩存機(jī)制，確保在每一層都打開gzip壓縮。

3.在上打開gzip_static并確認(rèn)。 服務(wù)器上存在gz文件。

gzip在電腦哪個文件夾里？

IIS6已經(jīng)內(nèi)建了Gzip壓縮的支持，可惜，沒有設(shè)置更好的管理界面。 所以要打開這個選項(xiàng)，還要費(fèi)些功夫。

1、如果你需要壓縮靜態(tài)文件（HTML），需要在硬盤上建一個目錄，并給它“IUSR_機(jī)器名”這個用戶的寫權(quán)限。 如果壓縮動態(tài)文件（PHP，asp，aspx，ashx）就不需要了，因?yàn)樗捻撁媸敲看味紕討B(tài)生成的，壓縮完就放棄。

2、在IIS管理器中，“網(wǎng)站”節(jié)點(diǎn)上面(不是某個具體的站點(diǎn)，而是整個網(wǎng)站)右鍵－屬性，選擇“服務(wù)”標(biāo)簽，選上啟用動態(tài)內(nèi)容壓縮，靜態(tài)內(nèi)容壓縮。

3、在IIS管理器左側(cè)選中“WEB服務(wù)器擴(kuò)展”，新建一個服務(wù)器擴(kuò)展。 名字任意，比如gzip，文件的路徑是，并啟用這個擴(kuò)展。

4、停止IIS服務(wù)，打開(不停止IIS服務(wù)無法編輯該文件)，以關(guān)鍵字“根據(jù)需要增加一些要進(jìn)行壓縮的文件后綴，其中HcFileExtensions是靜態(tài)文件的擴(kuò)展名，增加js和css等；HcScriptFileExtensions為動態(tài)文件的擴(kuò)展名，增加aspx，ashx等；HcDynamicCompressionLevel改成9，（0－10，9是性價比最高的一個）。

5、啟動IIS服務(wù)，就已經(jīng)成功啟用gzip壓縮了。

如何優(yōu)化網(wǎng)站服務(wù)器提升網(wǎng)站訪問速度？

您好，我是仙人掌熱點(diǎn)。 網(wǎng)站運(yùn)營的任何時候，網(wǎng)站訪問速度都是至關(guān)重要的部分，它是網(wǎng)站友好體驗(yàn)中最基本的一項(xiàng)，如果訪問體驗(yàn)都令人不滿意，那么后期所做的營銷推廣模式都有可能徒勞無功，因?yàn)榫W(wǎng)絡(luò)中客戶的選擇成本很低，加上普遍客戶的耐心都不高，頁面訪問超過6秒客戶就會選擇離開，這對于一些流量本來就不高的企業(yè)網(wǎng)站來說無疑是雪上加霜。 網(wǎng)站訪問速度既然如此重要，今天筆者也要跟大家分享幾個關(guān)于提升速度體驗(yàn)的方法，雖然網(wǎng)上有很多類似的文章和觀點(diǎn)，但是大多數(shù)都是網(wǎng)站內(nèi)部去解析，今天筆者要從服務(wù)器方面聊聊如何優(yōu)化網(wǎng)站服務(wù)器提升網(wǎng)站訪問速度。

大多數(shù)網(wǎng)站運(yùn)營優(yōu)化人員都知道通過頁面優(yōu)化來提升訪問速度，當(dāng)你已經(jīng)完成了優(yōu)化操作之后，發(fā)現(xiàn)沒有什么大的改善，此時你就應(yīng)該去思考是不是其它因素導(dǎo)致訪問速度緩慢。 比如：長期使用的服務(wù)器性能下降所致，為了保障業(yè)務(wù)不受影響，你或許應(yīng)該對正在使用的服務(wù)器進(jìn)行升級和優(yōu)化了。

一、升級正在使用中的服務(wù)器

進(jìn)行服務(wù)器升級工作之前，要考慮多方面的問題，是升級已有的服務(wù)器還是購置新的服務(wù)器設(shè)備須根據(jù)實(shí)際情況抉擇。 首先來說升級現(xiàn)有的服務(wù)器設(shè)備，一般來說網(wǎng)站運(yùn)營到后期隨著業(yè)務(wù)不斷增加，多平臺應(yīng)用的開發(fā)對于服務(wù)器性能的要求也逐步提升，長而久之服務(wù)器遇到性能瓶頸也是情理之中的事情，對于這種情況，我們可以通過升級服務(wù)器(例如增加硬件設(shè)備或網(wǎng)絡(luò)帶寬)等相關(guān)配置來滿足不斷擴(kuò)大的業(yè)務(wù)需求，那么服務(wù)器性能瓶頸問題就可以得到解決。 再來說說購置新的服務(wù)器設(shè)備，也許有人會問為什么要重新購置呢，升級已有的服務(wù)器不可以嗎?這里筆者也當(dāng)然想替大家節(jié)省一筆開支，但是根本問題在于大多數(shù)企業(yè)選購服務(wù)器時并不合理，加上網(wǎng)站建設(shè)之初為節(jié)約成本而選擇了擴(kuò)展性較差的服務(wù)器，導(dǎo)致即便是我們對現(xiàn)有的服務(wù)器進(jìn)行升級，其性能提升的強(qiáng)度依然不夠。 此時，就需要重新購置服務(wù)器配合了，對于服務(wù)器的購置也有很多技巧，這里簡單的做個推薦，如果用戶群體是國內(nèi)的建議選擇國內(nèi)知名的服務(wù)器供應(yīng)商，若客戶群體是遍布全球，大家可以選擇香港服務(wù)器或美國服務(wù)器，除此之外，更重要的是要根據(jù)自身行業(yè)的特性做出合理的選擇。

二、優(yōu)化正在使用的服務(wù)器

不管是完成升級后的服務(wù)器，還是新購置的服務(wù)器，我們都要對其進(jìn)行優(yōu)化，從而提升服務(wù)器的性能以及利用率。下面從四個方面跟大家談?wù)勅绾蝺?yōu)化服務(wù)器：

要點(diǎn)一：盡可能的減少HTTP請求數(shù)

從客戶訪問網(wǎng)站頁面到整個頁面內(nèi)容完全展現(xiàn)出來，這其中要花費(fèi)較多的時間來下載各種Scripts、CSS樣式表、Flash以及圖片，而每一類下載都相當(dāng)于一次HTTP請求，這樣的請求越多網(wǎng)站被完全加載出來所花的時間會越長，意味著客戶端的訪問會很慢，那么此時就需要盡可能的減少HTTP請求數(shù)，通常我們可以直接把css和js寫入到頁面中，避免了外部的調(diào)用;或者我們可以把CSS文件和JS文件分來，在后臺再進(jìn)行合并，這樣客戶端瀏覽器相當(dāng)于一次請求。 總而言之，減少HTTP請求數(shù)我們可以通過減少外部各類文件的數(shù)量調(diào)用次數(shù)來達(dá)到其目的。

要點(diǎn)二：降低DNS查詢時間

眾所周知網(wǎng)絡(luò)服務(wù)器端的域名和IP地址是相互對應(yīng)的，當(dāng)客戶端發(fā)出請求時，計算機(jī)還需要通過域名和IP地址的相互轉(zhuǎn)換來判斷，而這個轉(zhuǎn)換工作便是域名解析DNS，通常DNS的查詢需要10~20毫秒時間，客戶端瀏覽器也只會等待DNS查詢結(jié)束之后才會加載此域名下的內(nèi)容。 因此，我們要加快頁面的訪問速度，就可以從降低DNS查詢時間方面去做改善。

要點(diǎn)三：啟用服務(wù)器Gzip壓縮功能

對于大中型網(wǎng)站來說，頁面的內(nèi)容多且比較多樣化，單個頁面的大小可能是幾百K以上了，客戶端訪問的時候下載會比較慢，此時我們可以采用服務(wù)器Gzip頁面壓縮功能，可以將一個大小為100K的頁面文件壓縮成25K以下，這樣就可以減少網(wǎng)絡(luò)傳輸?shù)臄?shù)量從而提高客戶端訪問速度。 一般服務(wù)器都是可以使用Gzip壓縮功能的，并且能夠針對JS文件、CSS文件和Html進(jìn)行壓縮，多方面去進(jìn)行優(yōu)化網(wǎng)站訪問速度。

要點(diǎn)四：推薦大中型網(wǎng)站使用CDN加速工具

CDN加速是目前大型網(wǎng)站普遍使用的頁面加速方式，它對于網(wǎng)站優(yōu)化幾乎沒有影響的，基本原理是將網(wǎng)站鏡像備份到很多服務(wù)器節(jié)點(diǎn)上，使服務(wù)器節(jié)點(diǎn)周圍的用戶訪問速度更快，從而提升客戶端高速訪問網(wǎng)站的體驗(yàn);但是并不是所有的網(wǎng)站都適合使用CDN加速，一般對于小規(guī)模站點(diǎn)個人站的話，就不需要使用CDN加速，畢竟從長期來看這可是一筆不小的開支;建議圖片站以及多媒體站點(diǎn)可使用CDN加速。

至此，以上為大家講到了可以通過優(yōu)化和升級服務(wù)器兩個方面提升網(wǎng)站訪問速度，如果你的網(wǎng)站目前的訪問體驗(yàn)不佳，可以嘗試進(jìn)行以上操作，相信能夠幫助大家改善此類問題。

微信視頻總是解析異常怎么解決？

我也遇到了類似的問題，服務(wù)器上數(shù)據(jù)開啟了Gzip壓縮，微信瀏覽器解析視頻數(shù)據(jù)時候沒有按照Gzip壓縮后的數(shù)據(jù)解析。這種問題只出現(xiàn)在Android版本的微信上

其實(shí)客戶端在向服務(wù)器端發(fā)送請求的時候，服務(wù)端就已經(jīng)拿到客戶端支持哪種壓縮格式，服務(wù)器估計是判斷到微信客戶端支持Gzip壓縮數(shù)據(jù)，就給客戶端傳輸了Gzip格式的數(shù)據(jù)，誰知微信客戶端不認(rèn)

如何啟用iis的gzip壓縮功能？

IIS6已經(jīng)內(nèi)建了Gzip壓縮的支持，可惜，沒有設(shè)置更好的管理界面。 所以要打開這個選項(xiàng)，還要費(fèi)些功夫。

1、如果你需要壓縮靜態(tài)文件（HTML），需要在硬盤上建一個目錄，并給它“IUSR_機(jī)器名”這個用戶的寫權(quán)限。 如果壓縮動態(tài)文件（PHP，asp，aspx，ashx）就不需要了，因?yàn)樗捻撁媸敲看味紕討B(tài)生成的，壓縮完就放棄。

2、在IIS管理器中，“網(wǎng)站”節(jié)點(diǎn)上面(不是某個具體的站點(diǎn)，而是整個網(wǎng)站)右鍵－屬性，選擇“服務(wù)”標(biāo)簽，選上啟用動態(tài)內(nèi)容壓縮，靜態(tài)內(nèi)容壓縮。

3、在IIS管理器左側(cè)選中“WEB服務(wù)器擴(kuò)展”，新建一個服務(wù)器擴(kuò)展。 名字任意，比如gzip，文件的路徑是，并啟用這個擴(kuò)展。

4、停止IIS服務(wù)，打開(不停止IIS服務(wù)無法編輯該文件)，以關(guān)鍵字“根據(jù)需要增加一些要進(jìn)行壓縮的文件后綴，其中HcFileExtensions是靜態(tài)文件的擴(kuò)展名，增加js和css等；HcScriptFileExtensions為動態(tài)文件的擴(kuò)展名，增加aspx，ashx等；HcDynamicCompressionLevel改成9，（0－10，9是性價比最高的一個）。

5、啟動IIS服務(wù)，就已經(jīng)成功啟用gzip壓縮了。

---

---

相關(guān)標(biāo)簽： 提升性能、 Accept、 通過、 Encoding、 請求壓縮、 提升性能的手段、 web、 主導(dǎo)、

上一篇：掌控AcceptEncoding提高web應(yīng)用程序的響應(yīng)

下一篇：深入了解AcceptEncodingHTTP頭部優(yōu)化web傳