一、ETag簡(jiǎn)介

ETag(EntityTags)是URL的tag，用來標(biāo)示URL對(duì)象是否改變，這樣可利用客戶端（例如瀏覽器）的緩存。由服務(wù)器首先產(chǎn)生ETag，客戶端通過將該記號(hào)傳回服務(wù)器要求服務(wù)器驗(yàn)證其（客戶端）緩存。服務(wù)器使用它來判斷頁面是否已經(jīng)被修改，如果未修改返回304，而不必重新傳輸整個(gè)對(duì)象。

二、現(xiàn)在站點(diǎn)sitemap存在的問題

1.發(fā)現(xiàn)更新不及時(shí)

當(dāng)站點(diǎn)或其sitemap發(fā)生更新時(shí)，百度難以及時(shí)發(fā)現(xiàn)并響應(yīng)，因?yàn)榘俣入y以無時(shí)無刻地持續(xù)檢查站點(diǎn)內(nèi)容和sitemap是否更新。

2.全量抓取，消耗帶寬

現(xiàn)在百度對(duì)站點(diǎn)sitemap的抓取會(huì)將sitemap文件完整下來，鑒于sitemap文件一般較大，而這種可能存在多次，故比較消耗網(wǎng)站的流量和帶寬。

三、ETag作用

HTTP1.1用Etag來判斷請(qǐng)求的文件是否被修改，主要為了解決Last-Modified無法解決的一些問題

1、一些文件也許會(huì)周期性的更改，但是他的內(nèi)容并不改變(僅僅改變的修改時(shí)間)，這個(gè)時(shí)候并不希望客戶端認(rèn)為這個(gè)文件被修改了重新GET;

2、某些文件修改非常頻繁， 1秒內(nèi)修改了N次，If-Modified-Since能檢查到的粒度是秒級(jí)的，這種修改無法判斷

3、某些服務(wù)器不能的得到文件的修改時(shí)間；

為此，HTTP1.1引入了Etag.但標(biāo)準(zhǔn)并沒有規(guī)定Etag的內(nèi)容是什么或者說要怎么實(shí)現(xiàn)，規(guī)定的是Etag需要放在雙引號(hào)內(nèi)。Etag由服務(wù)器端生成，客戶端通過If-Match或者說If-None-Match這個(gè)條件判斷請(qǐng)求來驗(yàn)證資源是否修改。我們常見的是使用If-None-Match.請(qǐng)求一個(gè)文件的流程可能如下：

次請(qǐng)求：

1.客戶端發(fā)起HTTP GET請(qǐng)求一個(gè)文件；

2.服務(wù)器處理請(qǐng)求，返回文件內(nèi)容和一堆Header，當(dāng)然包括Etag(例如”1ec5-502264e2ae4c0″)(假設(shè)服務(wù)器支持Etag生成和已經(jīng)開啟了Etag).狀態(tài)碼200，如下圖所示，請(qǐng)求百度首頁時(shí)，成功得到百度logo圖片文件bd_logo1.png，狀態(tài)碼200，大小8.1KB，返回的Header中包括ETag（“1ec5-502264e2ae4c0”）。

第二次請(qǐng)求：

1.客戶端發(fā)起HTTP GET請(qǐng)求一個(gè)文件，這個(gè)時(shí)候客戶端同時(shí)發(fā)送一個(gè)If-None-Match頭，這個(gè)頭的內(nèi)容是我們次請(qǐng)求時(shí)服務(wù)器返回的Etag：1ec5-502264e2ae4c0。

2.服務(wù)器判斷發(fā)送過來的Etag和計(jì)算出來的Etag是匹配的，不返回200，返回304，讓客戶端繼續(xù)使用本地緩存。如圖所示這次對(duì)bd_logo1.png的請(qǐng)求，服務(wù)器只返回了Header沒有返回內(nèi)容，大小僅為349B。

四、站點(diǎn)啟用ETag的好處

1.對(duì)sitemap啟用ETag后，百度可以更快速地響應(yīng)sitemap的更新，沒有更改內(nèi)容的情況下，服務(wù)器只發(fā)回304應(yīng)答頭，對(duì)流量的消耗極小，在每個(gè)head平均227B大小的通常情形下，一整天二十四小時(shí)每秒都回應(yīng)的流量消耗僅為18.7M。

2.現(xiàn)在站長(zhǎng)平臺(tái)對(duì)每個(gè)站點(diǎn)的sitemap主動(dòng)抓取次數(shù)設(shè)有上限，且這項(xiàng)功能沒有對(duì)所有站開放，如果您的站點(diǎn)sitemap啟用了ETag，并通過了測(cè)試，那么可以用很小的流量享受百度及時(shí)更新您的sitemap的功能，以便于百度更好地收錄您網(wǎng)站的內(nèi)容。