緩存一直是web開發中提高性能的一個不可或缺的方面。由於web開發的本質實質上就是瀏覽器和服務器通過HTTP協議進行通信的過程。因此，緩存也分爲服務器端緩存和瀏覽器緩存。這裏，我主要討論一下瀏覽器緩存。
瀏覽器緩存的內容往往存儲在瀏覽器本地，而內容則是由Web服務器生成，任何一方都不可能獨立完成這一些列過程，所以，瀏覽器和服務器之間必須有一種溝通的機制，這種溝通機制被稱爲“緩存協商”。而瀏覽器正是通過與服務器的這種溝通機制來實現緩存的。
在HTTP 1.1中，存在着兩種緩存協商機制：Last-Modified和ETag。
Last-Modified
Last-Modified的意思是最後的修改時間，Web服務器首先瀏覽器發送Last-Modified協議頭，告訴瀏覽器發送內容的最後修改時間，當瀏覽器下次請求相同的URL時，會在請求頭部中增加If-Modified-Since標記，標記的值爲服務器上次傳過來的Last-Modified的值，這以爲着瀏覽器在詢問Web服務器：“我請求的內容在這個時間之後是否有更新”。此時，服務器需要檢查瀏覽器請求的內容在這個時間點之後是否有過更新，並犯規給瀏覽器。對於靜態內容，Web服務器可以輕鬆搞定，而對於動態內容，檢查是否有更新的工作需要交給動態程序自己去完成。
ETag
除了Last-Moidfied，HTTP1.1還支持ETag這種緩存協商方法。Etag是一串用來標記服務器需要發給瀏覽器的內容的編碼，它是由Web服務器生成的。比如Apache服務器在發我那個一個靜態文件給瀏覽器時在響應頭中增加了一下標記：ETag:"74177-b-b452413c1bc0"，瀏覽器在獲得這個內容的ETag後，會在下次請求該內容時，在HTTP請求頭中附加以下標記來詢問服務器該內容是否發生變化:If-None-Match:"74177-b-b452413c1bc0"。這時服務器需要重新計算這個內容的ETag值，並與HTTP請求中的ETag進行比較，若相同則返回304狀態碼，若不同則發送新的內容給瀏覽器。需要注意的是HTTP1.1並沒有規定ETag的具體格式和計算方法，因此，Web服務器可以自由定義ETag的格式和計算方法。
對比兩種緩存協商方法，使用基於最後修改時間的緩存協商方法存在着一些不足。比如：當文件頻繁更新，但內容卻並沒有改變時，如果採用Last-Modified緩存協商方法，那麼每次文件的修改時間變化後，不管內容是否變化，瀏覽器都會重新獲取全部內容。這時候，若直接是中ETag協商辦法，則可以避免這些問題。