動態頁面的瀏覽器緩存
我們知道,對于WEB頁面中的JS和CCS,并不會每次都請求完整的內容,有時候會直接利用本地的緩存;而對頁面本身,卻往往會去加載完整內容,對于服務器來說可能每次也要生成完整的內容,并送到客戶端;同樣的,對于一些http接口,每次調用也會去重新生成數據,瀏覽器也會重新加載完整的數據;
但有這樣一些頁面,雖然是動態的但變動頻率較小,且對于同一用戶重復調用可能很多(比如說個人管理后臺或者新聞首頁面),我們希望像js或者ccs那樣在客戶端緩存起來.并且,在我們希望的時候,可以更新客戶端備份的那個頁面,或者接口數據.是否可以做到呢;
事實上,瀏覽器可以緩存js,就一定能緩存我們的動態頁面;
先研究下js是如何緩存起來的:
用firebug看一下js的加載:
先強刷(ctrl+F5)一下 http://ilab.iteye.com/ 頁面,觀看js的加載如圖
狀態為200 , 查一下200的含意 :
請求成功(其后是對GET和POST請求的應答文檔。)
這是對js文件的完整加載;
再直接F5刷新下 http://ilab.iteye.com/ ,觀看js的加載如圖
狀態為304,再查一下304的含意:
未按預期修改文檔。客戶端有緩沖的文檔并發出了一個條件性的請求(一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔)。服務器告訴客戶，原來緩沖的文檔還可以繼續使用。
此時其實并沒有從服務端加載完整文件而是去讀的本地緩存;
從304的描述來看,我們知道,請求依然發出,并由服務端告知瀏覽器,掉用緩存;
我們可以總結出兩點:
1.
由于服務端只是返回簡單的頭信息,并沒有生成完整頁面,所以雖然請求依然發出,對于瀏覽器和服務器來說都更快更輕松了;
2.
我們可以控制瀏覽器去更新緩存;)
具此,我們可以得出結論,對于某此動態頁面來說,完全可以充分利用瀏覽器緩存來降低服務器壓力,提升客戶端速度;
----------------------------------分隔線 ----------------------------------------
現在我們來看下要怎么做;
由于對文檔的描述在http頭信息中,并且依據304的描述,我們知道,這個屬性和 Modified Time有關,我們比對下普通的頁面和js的頁面的respose的頭信息的不同:
我們發現,多了個Last-Modified的屬性;
再比對請求,
發現,多了If-Modified-Since;
武斷的推測一下(或者認真的讀下http協議的文檔):我們可以這樣認為:
1.第一次請求成功返回202;
2.假如返回頭信息有Last-Modified屬性 則存入瀏覽器緩存;
3.再次請求,假如請求的為緩存頁面,則頭信息中加入 If-Modified-Since;
4.服務端通過If-Modified-Since(即上次響應中Last-Modified的值)來判斷是否需要更新,否的話返回304;
5.假如返回304,則瀏覽器則讀緩存;
按照這個原理我們通過 HttpServletResponse, HttpServletRequest來償試實現下:
對任意一個頁面先來句
Java代碼
- getResponse().addHeader("Last-Modified", "hello kitty");
然后再次請求該頁面時,我們就可以發現請求中就有了 If-Modified-Since 屬性
Java代碼
- getRequest().getHeader("if-modified-since");
通過這句代碼,拿到具體值;
假如判斷為不用更新則直接返回304
Java代碼
- getResponse().setStatus(HttpServletResponse.SC_NOT_MODIFIED);
并且立即結束返回,不用繼續執行;
對于取到的if-modified-since,即是上次存入的Last-Modified,里面的值到是可以很隨意,你除了放時間,也可以放memberId;
--------------------------------分隔線 ----------------------------------
實現問題也解決了;
最后一個問題,是怎么保證接口,或者頁面的動態性;也就是說怎么通過Last-Modified或者if-modified-since來判斷頁面不需要更新;
考慮最簡單的情況,這個接口或者頁面僅提供和用戶相關的不同信息,并且該信息一但建立則不會改變;
那對于此接口,假如參數中包含memberId屬性,則一但具有if-modified-since值,則永遠返回304;因為對于不同url,瀏覽器均會進行緩存;
假如memberId屬性在cookie中,url一致,那么,在Last-Modified中存入memberId,判斷時于cookie或者session中url比對,相同則認為是正確的緩存返回304;
現在,新的問題來了,用戶的相關信息更新了;
假如這個更新頻率不是那么頻繁,那么想辦法做個更新機制還是合理的;你需要一個地方在服務端記錄用戶接口信息的版本號了,從if-modified-since中取得上次的版本號,然后進行比對,如果相同,則返回304;
在某些情況下,獲取更新記錄信息要比計算合成完整信息并利用帶寬將數據傳給客戶端代價小得多,此時你可以試下WEB服務動態接口的靜態緩存;
【編輯推薦】
