wap開發(fā)中如何有效的利用緩存減少消息的傳送量
更新時(shí)間:2010年06月25日 17:43:30 作者:
由于WAP信道帶寬的限制,我們?cè)诰帉慦AP應(yīng)用的時(shí)候都希望最大限度地減少消息的傳送量。
要做到這一點(diǎn),就要盡量地使用緩存,經(jīng)常地從緩存中獲得以前的消息。幸運(yùn)的是目前大多數(shù)WAP設(shè)備都有一定級(jí)別的緩存,在默認(rèn)情況下,會(huì)嘗試最大化的緩存。幾乎所有指向URL的響應(yīng)都會(huì)被緩存下來(lái)。
根據(jù)[RFC2616]的定義,緩存是:"程序中響應(yīng)消息的本地儲(chǔ)存區(qū)以及控制這些消息儲(chǔ)存、重新獲取和刪除的子系統(tǒng)。緩存保存可以緩存的響應(yīng)消息以便降低將來(lái)的響應(yīng)時(shí)間和網(wǎng)絡(luò)帶寬消耗,同樣也適用于請(qǐng)求消息。"
當(dāng)WAP用戶終端緩存一個(gè)響應(yīng)的時(shí)候,會(huì)保存幾乎所有的信息:URL、響應(yīng)文本、消息頭以及其他可以驗(yàn)證響應(yīng)的內(nèi)容(參看下一節(jié)"驗(yàn)證和歷史堆棧")。每個(gè)被緩存的項(xiàng)目都可以根據(jù)它的URL組成部分(域名、路徑、協(xié)議、參數(shù)、端口等等)唯一的識(shí)別。
有兩種HTTP消息頭可以讓你控制WML的DECK緩存,對(duì)我們最重要的是Cache-Control消息頭。它能夠直接通過(guò)請(qǐng)求/響應(yīng)鏈來(lái)控制所有的緩存實(shí)體。所有的緩存機(jī)制都必須遵守這些消息頭的定義。Cach-Control消息頭通常用來(lái)屏蔽一個(gè)設(shè)備的默認(rèn)緩存行為。他們?cè)谙㈡溨袀鬟f時(shí)必須直接穿過(guò)所有的代理服務(wù)器和網(wǎng)關(guān)而不被改變。
<meta http-equive="Expires" content=" Mon, 10 Jan 2000 00:00:00 GMT"/>
<meta http-equive="Cache-Control" content="max-age=300"/>
<meta http-equive="Cache-Control" content="no-cache"/>
* Cache-Control: no-cache。設(shè)定這個(gè)選項(xiàng)的URL不能被緩存,包括用戶終端和所有處于內(nèi)容服務(wù)器和用戶終端之間的其他服務(wù)器;
* Cache-Control: max-age=<second>。定義URL保存在設(shè)備緩存中的最長(zhǎng)時(shí)間。時(shí)間到了以后,這個(gè)實(shí)體會(huì)從緩存中清除;
* Expired:<date> 。指定URL在緩存中存放的最后日期期限。[RFC1123]定義了日期的格式,通常是這樣的:Expires: Sun, 29 October 2000 17:30:47 GMT
在寫一個(gè)WAP應(yīng)用的時(shí)候,你要先假設(shè)用戶終端會(huì)盡量最大化緩存以便使向內(nèi)容服務(wù)器獲取信息的動(dòng)作減少到最少。下面做些解釋:
1、 永久緩存URL
WAP用戶終端通常會(huì)盡量長(zhǎng)地在它的緩存中保存存取過(guò)的URL,這個(gè)"盡量長(zhǎng)"在Phone.com瀏覽器中的定義是大約30天。不過(guò),也許你會(huì)想把一個(gè)URL的緩存時(shí)間盡量延長(zhǎng),比如你公司的LOGO,這樣每次打開頁(yè)面的時(shí)間就會(huì)減少。用下面兩種方法能夠很簡(jiǎn)單地實(shí)現(xiàn):
* 指定一個(gè)離現(xiàn)在很遠(yuǎn)的過(guò)期日,比如:Expires: Tue, 01 Jan 2002 00:00:00 GMT;
* 指定一個(gè)很大的緩存時(shí)間,如:Cache-Control: max-age=3153600。這個(gè)例子可以讓URL緩存一年。用戶終端允許的最大整數(shù)是2,147,483,647,所以你可以讓一個(gè)URL保存超過(guò)68年之久。當(dāng)然,到那個(gè)時(shí)候,你的手機(jī)早就那報(bào)廢了。
2、 指定對(duì)URL的緩存時(shí)間
通常的情況是對(duì)一個(gè)URL你只需要緩存一段時(shí)間。比如股票報(bào)價(jià)系統(tǒng),網(wǎng)頁(yè)可能需要5分鐘更新一次,那么你只要在DECK的HEAD部分指定Cache-Control: max-age=300就行了。 如果用戶在5分鐘以內(nèi)再次檢索該頁(yè)面,看到的還是緩存里的網(wǎng)頁(yè)。如果在5分鐘以后,就會(huì)到服務(wù)器上獲取最新的數(shù)據(jù)。
另外一種控制緩存時(shí)間的方法是使用前面提到過(guò)的Expires,不過(guò)這種方法只能告訴用戶終端:只要過(guò)了指定時(shí)間,無(wú)論什么時(shí)候訪問(wèn)頁(yè)面都要刷新。如果你下次要控制時(shí)間,只能改變Expires里的時(shí)間值。
3、 禁止對(duì)URL的緩存
對(duì)于快速變化的內(nèi)容,一般都會(huì)希望每次都得到最新的數(shù)據(jù)。所以這個(gè)時(shí)候要完全禁止對(duì)相關(guān)網(wǎng)頁(yè)的緩存。方法有三種:
* 設(shè)定Cache-Control: no-cache;
* 設(shè)定最大緩存時(shí)間為0,Cache-Control: max-age=0;
* 設(shè)定緩存到期日為一個(gè)早就過(guò)去的日期,Expires: Mon, 1 Jan 1990 00:00:00 GMT。
實(shí)際上,后兩種不是最好的選擇。首先這樣會(huì)多占用終端的處理時(shí)間,因?yàn)楫?dāng)碰到這個(gè)DECK時(shí),終端需要計(jì)算一下過(guò)期時(shí)間。其次,這樣會(huì)多占用一些字節(jié),而且在表達(dá)上也不夠清楚。
WAP標(biāo)準(zhǔn)規(guī)定所有的WAP設(shè)備都至少要有可以容納10-個(gè)項(xiàng)目的歷史堆棧。當(dāng)用戶按下由<go>或其他轉(zhuǎn)向指令的定義的前行(forward)鏈接時(shí),URL被推(push)入堆棧。如果按下由<prev>定義的后退(backward)鏈接,URL被彈(pop)出。
一般情況下,所有的前行鏈接都會(huì)被驗(yàn)證,而后退鏈接則不會(huì),因?yàn)樗呀?jīng)在cache里了??墒俏覀冇袝r(shí)候還是希望當(dāng)用戶按下后退鍵時(shí)依然能夠得到最新的數(shù)據(jù)。如果終端總是不予驗(yàn)證的話,那用戶只好找到主菜單再重新進(jìn)入那個(gè)頁(yè)面。
幸運(yùn)的是,我們用Cache-Control:must-revalidate就可以強(qiáng)迫用戶終端在用戶按back時(shí)對(duì)URL進(jìn)行驗(yàn)證。當(dāng)然,進(jìn)行驗(yàn)證并不是說(shuō)該頁(yè)面會(huì)立刻重新讀取,而是根據(jù)他是否過(guò)期來(lái)決定。如果沒(méi)有過(guò)期,驗(yàn)證的結(jié)果仍然是顯示緩存中的頁(yè)面。
如果你需要每次back都重新讀取頁(yè)面,用Cache-Control:must-revalidate, no-cache可以實(shí)現(xiàn)。另外,把 no-cache換成max-age=300就可以在back時(shí)對(duì)已緩存了300秒的頁(yè)面進(jìn)行刷新。
根據(jù)[RFC2616]的定義,緩存是:"程序中響應(yīng)消息的本地儲(chǔ)存區(qū)以及控制這些消息儲(chǔ)存、重新獲取和刪除的子系統(tǒng)。緩存保存可以緩存的響應(yīng)消息以便降低將來(lái)的響應(yīng)時(shí)間和網(wǎng)絡(luò)帶寬消耗,同樣也適用于請(qǐng)求消息。"
當(dāng)WAP用戶終端緩存一個(gè)響應(yīng)的時(shí)候,會(huì)保存幾乎所有的信息:URL、響應(yīng)文本、消息頭以及其他可以驗(yàn)證響應(yīng)的內(nèi)容(參看下一節(jié)"驗(yàn)證和歷史堆棧")。每個(gè)被緩存的項(xiàng)目都可以根據(jù)它的URL組成部分(域名、路徑、協(xié)議、參數(shù)、端口等等)唯一的識(shí)別。
有兩種HTTP消息頭可以讓你控制WML的DECK緩存,對(duì)我們最重要的是Cache-Control消息頭。它能夠直接通過(guò)請(qǐng)求/響應(yīng)鏈來(lái)控制所有的緩存實(shí)體。所有的緩存機(jī)制都必須遵守這些消息頭的定義。Cach-Control消息頭通常用來(lái)屏蔽一個(gè)設(shè)備的默認(rèn)緩存行為。他們?cè)谙㈡溨袀鬟f時(shí)必須直接穿過(guò)所有的代理服務(wù)器和網(wǎng)關(guān)而不被改變。
<meta http-equive="Expires" content=" Mon, 10 Jan 2000 00:00:00 GMT"/>
<meta http-equive="Cache-Control" content="max-age=300"/>
<meta http-equive="Cache-Control" content="no-cache"/>
* Cache-Control: no-cache。設(shè)定這個(gè)選項(xiàng)的URL不能被緩存,包括用戶終端和所有處于內(nèi)容服務(wù)器和用戶終端之間的其他服務(wù)器;
* Cache-Control: max-age=<second>。定義URL保存在設(shè)備緩存中的最長(zhǎng)時(shí)間。時(shí)間到了以后,這個(gè)實(shí)體會(huì)從緩存中清除;
* Expired:<date> 。指定URL在緩存中存放的最后日期期限。[RFC1123]定義了日期的格式,通常是這樣的:Expires: Sun, 29 October 2000 17:30:47 GMT
在寫一個(gè)WAP應(yīng)用的時(shí)候,你要先假設(shè)用戶終端會(huì)盡量最大化緩存以便使向內(nèi)容服務(wù)器獲取信息的動(dòng)作減少到最少。下面做些解釋:
1、 永久緩存URL
WAP用戶終端通常會(huì)盡量長(zhǎng)地在它的緩存中保存存取過(guò)的URL,這個(gè)"盡量長(zhǎng)"在Phone.com瀏覽器中的定義是大約30天。不過(guò),也許你會(huì)想把一個(gè)URL的緩存時(shí)間盡量延長(zhǎng),比如你公司的LOGO,這樣每次打開頁(yè)面的時(shí)間就會(huì)減少。用下面兩種方法能夠很簡(jiǎn)單地實(shí)現(xiàn):
* 指定一個(gè)離現(xiàn)在很遠(yuǎn)的過(guò)期日,比如:Expires: Tue, 01 Jan 2002 00:00:00 GMT;
* 指定一個(gè)很大的緩存時(shí)間,如:Cache-Control: max-age=3153600。這個(gè)例子可以讓URL緩存一年。用戶終端允許的最大整數(shù)是2,147,483,647,所以你可以讓一個(gè)URL保存超過(guò)68年之久。當(dāng)然,到那個(gè)時(shí)候,你的手機(jī)早就那報(bào)廢了。
2、 指定對(duì)URL的緩存時(shí)間
通常的情況是對(duì)一個(gè)URL你只需要緩存一段時(shí)間。比如股票報(bào)價(jià)系統(tǒng),網(wǎng)頁(yè)可能需要5分鐘更新一次,那么你只要在DECK的HEAD部分指定Cache-Control: max-age=300就行了。 如果用戶在5分鐘以內(nèi)再次檢索該頁(yè)面,看到的還是緩存里的網(wǎng)頁(yè)。如果在5分鐘以后,就會(huì)到服務(wù)器上獲取最新的數(shù)據(jù)。
另外一種控制緩存時(shí)間的方法是使用前面提到過(guò)的Expires,不過(guò)這種方法只能告訴用戶終端:只要過(guò)了指定時(shí)間,無(wú)論什么時(shí)候訪問(wèn)頁(yè)面都要刷新。如果你下次要控制時(shí)間,只能改變Expires里的時(shí)間值。
3、 禁止對(duì)URL的緩存
對(duì)于快速變化的內(nèi)容,一般都會(huì)希望每次都得到最新的數(shù)據(jù)。所以這個(gè)時(shí)候要完全禁止對(duì)相關(guān)網(wǎng)頁(yè)的緩存。方法有三種:
* 設(shè)定Cache-Control: no-cache;
* 設(shè)定最大緩存時(shí)間為0,Cache-Control: max-age=0;
* 設(shè)定緩存到期日為一個(gè)早就過(guò)去的日期,Expires: Mon, 1 Jan 1990 00:00:00 GMT。
實(shí)際上,后兩種不是最好的選擇。首先這樣會(huì)多占用終端的處理時(shí)間,因?yàn)楫?dāng)碰到這個(gè)DECK時(shí),終端需要計(jì)算一下過(guò)期時(shí)間。其次,這樣會(huì)多占用一些字節(jié),而且在表達(dá)上也不夠清楚。
WAP標(biāo)準(zhǔn)規(guī)定所有的WAP設(shè)備都至少要有可以容納10-個(gè)項(xiàng)目的歷史堆棧。當(dāng)用戶按下由<go>或其他轉(zhuǎn)向指令的定義的前行(forward)鏈接時(shí),URL被推(push)入堆棧。如果按下由<prev>定義的后退(backward)鏈接,URL被彈(pop)出。
一般情況下,所有的前行鏈接都會(huì)被驗(yàn)證,而后退鏈接則不會(huì),因?yàn)樗呀?jīng)在cache里了??墒俏覀冇袝r(shí)候還是希望當(dāng)用戶按下后退鍵時(shí)依然能夠得到最新的數(shù)據(jù)。如果終端總是不予驗(yàn)證的話,那用戶只好找到主菜單再重新進(jìn)入那個(gè)頁(yè)面。
幸運(yùn)的是,我們用Cache-Control:must-revalidate就可以強(qiáng)迫用戶終端在用戶按back時(shí)對(duì)URL進(jìn)行驗(yàn)證。當(dāng)然,進(jìn)行驗(yàn)證并不是說(shuō)該頁(yè)面會(huì)立刻重新讀取,而是根據(jù)他是否過(guò)期來(lái)決定。如果沒(méi)有過(guò)期,驗(yàn)證的結(jié)果仍然是顯示緩存中的頁(yè)面。
如果你需要每次back都重新讀取頁(yè)面,用Cache-Control:must-revalidate, no-cache可以實(shí)現(xiàn)。另外,把 no-cache換成max-age=300就可以在back時(shí)對(duì)已緩存了300秒的頁(yè)面進(jìn)行刷新。
相關(guān)文章
HTML5 移動(dòng)頁(yè)面自適應(yīng)手機(jī)屏幕寬度詳解
這篇文章主要介紹了HTML5 移動(dòng)頁(yè)面自適應(yīng)手機(jī)屏幕寬度的相關(guān)資料,需要的朋友可以參考下2016-09-09詳細(xì)講解計(jì)算機(jī)網(wǎng)絡(luò)——應(yīng)用層
這不同類型的網(wǎng)絡(luò)應(yīng)用有不同的通信規(guī)則,因此應(yīng)用層協(xié)議是多種多樣的,比如DNS、FTP、Telnet、SMTP、HTTP、RIP、NFS等協(xié)議都是用于解決其各自的一類問(wèn)題2021-08-08Git基礎(chǔ)學(xué)習(xí)之分支操作的示例詳解
這篇文章主要為大家詳細(xì)介紹了Git基礎(chǔ)學(xué)習(xí)中分支的基本操作,文中的示例代碼講解詳細(xì),對(duì)我們了解Git有一定的幫助,感興趣的小伙伴可以跟隨小編一起學(xué)習(xí)一下2022-10-10Git恢復(fù)之前版本的三種方法之reset、revert、rebase詳解
這篇文章主要介紹了Git恢復(fù)之前版本的三種方法之reset、revert、rebase解讀,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-03-03搜索歷史基本原理實(shí)現(xiàn)即時(shí)自動(dòng)補(bǔ)全聯(lián)想搜索技巧
這篇文章主要為大家介紹了搜索歷史基本原理實(shí)現(xiàn)即時(shí)自動(dòng)補(bǔ)全聯(lián)想搜索技巧示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-02-02游戲開發(fā)進(jìn)階Unity網(wǎng)格(Mesh\動(dòng)態(tài)合批\骨骼動(dòng)畫\蒙皮)
本篇文章是進(jìn)階篇文章主要講解游戲開發(fā)進(jìn)階,主要包含的技術(shù)有Mesh,動(dòng)態(tài)合批,骨骼動(dòng)畫,蒙皮下面一起進(jìn)入U(xiǎn)nity網(wǎng)格探險(xiǎn)之旅吧2021-09-09