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