1、ETag簡介
ETag(EntityTags)是URL的tag，用來標(biāo)示URL對象是不是轉(zhuǎn)變，這樣可獨霸客戶端（例如瀏覽器）的緩存。由處事器首先產(chǎn)生ETag，客戶端經(jīng)過過程將該記號傳回處事器請求處事器驗證其（客戶端）緩存。處事器操作它來剖斷頁面是不是已經(jīng)被改削，若是未改削返回304，而沒需要從頭傳輸全數(shù)對象。
2、此刻站點sitemap存在的問題問題
1.創(chuàng)造更新不實時
當(dāng)站點或其sitemap產(chǎn)生更新時，百度難以實時創(chuàng)造并響應(yīng)，由于百度難以無時無刻地延續(xù)搜檢站點內(nèi)容和sitemap是不是更新。
2.全量抓取，破耗帶寬
此刻百度對站點sitemap的抓取會將sitemap文件完整下載下來，鑒于sitemap文件個別較大，而這類下載可能存在多次，故斗勁破耗網(wǎng)站的流量和帶寬。
3、ETag浸染
HTTP1.1用Etag來剖斷請求的文件是不是被改削，重要為體味決Last-Modified沒法解決的一些問題問題
1、一些文件或許會周期性的更改，可是他的內(nèi)容實在不轉(zhuǎn)變(僅僅轉(zhuǎn)變的改削時刻)，這個時辰實在不但愿客戶端感觸這個文件被改削了從頭GET;
2、某些文件改削很是頻仍， 1秒內(nèi)改削了N次，If-Modified-Since能搜檢到的粒度是秒級的，這類改削沒法剖斷
3、某些處事器不能切確的獲得文件的最后改削時刻；
為此，HTTP1.1引入了Etag.但標(biāo)準(zhǔn)并沒有規(guī)定Etag的內(nèi)容是甚么或者說要若何實現(xiàn)，唯一規(guī)定的是Etag需要放在雙引號內(nèi)。Etag由處事器端天生，客戶端經(jīng)過過程If-Match或者說If-None-Match這個條件剖斷請求來驗證本錢是不是改削。我們常見的是操作If-None-Match.請求一個文件的流程可能以下：
第一次請求：
1.客戶端倡導(dǎo)HTTP GET請求一個文件；
2.處事器措置請求，返回文件內(nèi)容和一堆Header，當(dāng)然搜羅Etag(例如"1ec5-502264e2ae4c0")(假定處事器撐持Etag天生和已經(jīng)開啟了Etag).狀態(tài)碼200，以下圖所示，初度請求百度首頁時，成功獲得百度logo圖片文件bd_logo1.png，狀態(tài)碼200，巨細(xì)8.1KB，返回的Header中搜羅ETag（“1ec5-502264e2ae4c0”）。
第二次請求：
1.客戶端倡導(dǎo)HTTP GET請求一個文件，這個時辰客戶端同時發(fā)送一個If-None-Match頭，這個頭的內(nèi)容就是我們第一次請求時處事器返回的Etag：1ec5-502264e2ae4c0
2.處事器剖斷發(fā)送過去的Etag和計較出來的Etag是匹配的，不返回200，返回304，讓客戶端持續(xù)操作當(dāng)?shù)鼐彺?。如圖所示此次對bd_logo1.png的請求，處事器只返回了Header沒有返回內(nèi)容，巨細(xì)僅為349B。
4、站點啟用ETag的好處
1.對sitemap啟用ETag后，百度可以更快速地響應(yīng)sitemap的更新，沒有更改內(nèi)容的景象下，處事器只發(fā)回304應(yīng)對頭，對流量的破耗極小，在每個head均勻227B巨細(xì)的凡是景象形象下，一成天二十四小時每秒都回應(yīng)的流量破耗僅為18.7M。
2.此刻站長平臺對每個站點的sitemap主動抓取次數(shù)設(shè)有上限，且這項功效沒有對所有站凋謝，若是您的站點sitemap啟用了ETag，并經(jīng)過過程了測試，那么便可以用很小的流量享受百度實時更新您的sitemap的功效，以便于百度更好地收錄您網(wǎng)站的內(nèi)容。