關(guān)于緩存(cache)
有了初級教程的基礎(chǔ)，相信大家已經(jīng)能夠做不少事情了。在本章，我們來深入一下，看看如何提高性能和網(wǎng)絡(luò)傳輸效率。首先，需要介紹一下http 1.1（RFC2616）的基礎(chǔ)知識。當(dāng)然，如果你已經(jīng)很熟悉了，可以跳過第一節(jié)。

一、HTTP 1.1的簡要介紹
請求 響應(yīng)
二、緩存(cache)
永久緩存URL 指定對URL的緩存時間 禁止對URL的緩存
三、驗證（validation）和歷史堆棧（History Stack）
四、HTTP頭與meta元素

一、HTTP 1.1的簡要介紹 [TOP]
HTTP 1.1是一個基于文本的互聯(lián)網(wǎng)實體信息交互主流協(xié)議，這里的實體可以是WAP兼容瀏覽器之類的用戶終端，可以是WAP網(wǎng)關(guān)之類的代理服務(wù)器，也可以是Java servlet之類的源服務(wù)器程序。它們之間的交互信息就是兩大類：客戶端對服務(wù)器端的請求（request）和服務(wù)器端對客戶端的響應(yīng)（response）。一次完整的交互包括一個請求和對它的響應(yīng)。

所有的請求和響應(yīng)都采用[RFC822]中定義的標準互聯(lián)網(wǎng)消息格式，框架如下：
* 消息定義
* 沒有或多個消息頭
* CRLF（空行回車）
* 可選的消息本體
其中消息定義不分指定了發(fā)送消息的類型。請求和響應(yīng)都可以包含多個消息頭，用來進一步或者重新定義用戶終端和服務(wù)器之間的交互。CRLF僅僅用來將信息定義和消息本體分開。

1、 請求 [TOP]
在消息定義部分可以這樣定義請求： 請求類型 URL HTTP/1.1
其中請求類型可以是下面的一種：
①. OPTION：返回請求者和相應(yīng)者之間可以使用的通信選項，主要用來檢測服務(wù)器處理能力；
②. GET：獲得以URL標示的文件內(nèi)容或者程序執(zhí)行結(jié)果。服務(wù)器根據(jù)文件名后綴判斷服務(wù)內(nèi)容，比如該URL是靜態(tài)文本還是一個程序；
③. HEAD：除了不返回響應(yīng)的信息本體以外，得到的是跟GET一樣的信息。一般用來測試鏈接的有效性、可達性和近期修改；
④. POST：把消息本體中的消息發(fā)送到一個URL或者其他類似的服務(wù)器端定義行為。通常用來提交一個HTML表單或者一些數(shù)據(jù)操作活動；
⑤. PUT：把消息本體中的消息發(fā)送到一個URL，跟POST類似，但不常用；
⑥. DELETE：刪除URL指定的資源；
⑦. TRACE：調(diào)用一個遠程應(yīng)用層請求消息回路。發(fā)出這個消息的用戶終端除了收到原來的消息內(nèi)容以外，還得到消息在Internet上的傳送路徑。
最常用的請求類型--也是我們在處理WAP應(yīng)用時最關(guān)心的--是GET和POST。假設(shè)有一個WML文檔，我們用UP的瀏覽器去瀏覽的話，就會向服務(wù)器發(fā)出如下GET請求：
GET www.wap86.com/index.wml HTTP/1.1
accept-charset: UTF-8
accept-language: ch
accept: text/vnd.wap.wml, */*, image/bmp, text/html
user-agent: UP.Browser/3.1-UPG1 UP.Link/3.2
host: www.wap86.net
……
其中粗體的部分是HTTP消息頭，這里我們忽略了一些與我們關(guān)系不大的消息頭。
accept-charset: 用戶終端支持的字符集
accept-language: 用戶終端目前使用的語言
accept: 用戶終端可以接受的MIME文件類型
user-agent: 用戶終端供應(yīng)商提供的終端描述信息
host: 請求信息發(fā)送到的域名

2、 響應(yīng) [TOP]
響應(yīng)的消息定義部分一般是這樣的：HTTP/1.1 狀態(tài)碼 狀態(tài)描述在[RFC2616]中定義了近40種不同的狀態(tài)碼（分成5組）。其中最常見的是3個：
200 OK
401 Unauthorized
404 Not Found

繼續(xù)上面那個例子，如果該URL合法的話，服務(wù)器的響應(yīng)會是這樣的：
HTTP/1.1 200 OK
Server: www/5.0
Date: Fri, 26 Oct 2000 12:15:23 GMT
Connection: Keep-Alive
Content-Length: 1211
Content_Type: text/vnd.wap.wml
Last-Modified: Mon, 22 Oct 2000 18:19:24 GMT

<?xml version=”1.0”>
<!<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN”
“http://www./DTD/wml_1.1.xml”>

……
其它內(nèi)容
……

這個響應(yīng)信息里包括了響應(yīng)的數(shù)字代碼和文本描述，然后是一組消息頭。在一個換行符以后就是消息本體，在這里，消息本體就是www.wap86.net/index.wml的源代碼。
Server: 發(fā)出響應(yīng)的服務(wù)器
Date: 響應(yīng)發(fā)出的時間
Connection: 指示用戶終端保持連接
Content-Length: 響應(yīng)信息的長度，從DECK的第一個"<"字符開始計算
Content_Type: 響應(yīng)的MIME類型
Last-Modified: 響應(yīng)中DECK的最后修改時間

當(dāng)用戶終端接收到響應(yīng)以后，會對其狀態(tài)信息和消息頭進行解碼，然后決定對響應(yīng)做出什么樣的動作。如果收到OK響應(yīng)，一般會把消息本體里的內(nèi)容顯示在屏幕上。對于桌面終端，通常是HTML，對于WAP瀏覽器，則是WML。

HTTP是一種很羅嗦的協(xié)議。即使是簡單沒有任何數(shù)據(jù)的請求和響應(yīng)都要產(chǎn)生數(shù)百字節(jié)的消息。WAP通過WAP網(wǎng)關(guān)來解決這個問題。WAP網(wǎng)關(guān)一個很重要的功能就是把所有的HTTP1.1消息轉(zhuǎn)換成無線任務(wù)協(xié)議（Wireless Session Protocol, WSP）的消息格式。這種格式是壓縮的二進制協(xié)議，兼容HTTP1.1。它能解析所有的請求和響應(yīng)消息，并轉(zhuǎn)換成最精簡的BIT序列。

到這里我們已經(jīng)介紹了HTTP1.1的主要內(nèi)容。當(dāng)然HTTP1.1還有很多復(fù)雜的內(nèi)容，但是在這里并不打算多講，如果你有興趣，可以去相關(guān)網(wǎng)站查找它的資料。作者只想大家知道一點：用戶終端和服務(wù)器之間還有比GET和POST請求更多的互動消息，它們一樣有請求和響應(yīng)消息頭，并且可以包含一些信號來影響WAP應(yīng)用程序的執(zhí)行和性能。這正是提高WAP運行效率的秘密所在。

二、緩存（Caching） [TOP]
根據(jù)[RFC2616]的定義，緩存是："程序中響應(yīng)消息的本地儲存區(qū)以及控制這些消息儲存、重新獲取和刪除的子系統(tǒng)。緩存保存可以緩存的響應(yīng)消息以便降低將來的響應(yīng)時間和網(wǎng)絡(luò)帶寬消耗，同樣也適用于請求消息。"

由于WAP信道帶寬的限制，我們在編寫WAP應(yīng)用的時候都希望最大限度地減少消息的傳送量。要做到這一點，就要盡量地使用緩存，經(jīng)常地從緩存中獲得以前的消息。幸運的是目前大多數(shù)WAP設(shè)備都有一定級別的緩存，在默認情況下，會嘗試最大化的緩存。幾乎所有指向URL的響應(yīng)都會被緩存下來。

當(dāng)WAP用戶終端緩存一個響應(yīng)的時候，會保存幾乎所有的信息：URL、響應(yīng)文本、消息頭以及其他可以驗證響應(yīng)的內(nèi)容（參看下一節(jié)"驗證和歷史堆棧"）。每個被緩存的項目都可以根據(jù)它的URL組成部分（域名、路徑、協(xié)議、參數(shù)、端口等等）唯一的識別。

有兩種HTTP消息頭可以讓你控制WML的DECK緩存，對我們最重要的是Cache-Control消息頭。它能夠直接通過請求/響應(yīng)鏈來控制所有的緩存實體。所有的緩存機制都必須遵守這些消息頭的定義。Cach-Control消息頭通常用來屏蔽一個設(shè)備的默認緩存行為。他們在消息鏈中傳遞時必須直接穿過所有的代理服務(wù)器和網(wǎng)關(guān)而不被改變。

* Cache-Control: no-cache。設(shè)定這個選項的URL不能被緩存，包括用戶終端和所有處于內(nèi)容服務(wù)器和用戶終端之間的其他服務(wù)器；
* Cache-Control: max-age=<second>。定義URL保存在設(shè)備緩存中的最長時間。時間到了以后，這個實體會從緩存中清除；
* Expired:<date> 。指定URL在緩存中存放的最后日期期限。[RFC1123]定義了日期的格式，通常是這樣的：Expires: Sun, 29 October 2000 17:30:47 GMT

在寫一個WAP應(yīng)用的時候，你要先假設(shè)用戶終端會盡量最大化緩存以便使向內(nèi)容服務(wù)器獲取信息的動作減少到最少。下面做些解釋：

1、 永久緩存URL [TOP]
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年之久。當(dāng)然，到那個時候，你的手機早就那報廢了。

2、 指定對URL的緩存時間 [TOP]
通常的情況是對一個URL你只需要緩存一段時間。比如股票報價系統(tǒng)，網(wǎng)頁可能需要5分鐘更新一次，那么你只要在DECK的HEAD部分指定Cache-Control: max-age=300就行了。如果用戶在5分鐘以內(nèi)再次檢索該頁面，看到的還是緩存里的網(wǎng)頁。如果在5分鐘以后，就會到服務(wù)器上獲取最新的數(shù)據(jù)。

另外一種控制緩存時間的方法是使用前面提到過的Expires，不過這種方法只能告訴用戶終端：只要過了指定時間，無論什么時候訪問頁面都要刷新。如果你下次要控制時間，只能改變Expires里的時間值。

3、 禁止對URL的緩存 [TOP]
對于快速變化的內(nèi)容，一般都會希望每次都得到最新的數(shù)據(jù)。所以這個時候要完全禁止對相關(guān)網(wǎng)頁的緩存。方法有三種：
* 設(shè)定Cache-Control: no-cache；
* 設(shè)定最大緩存時間為0，Cache-Control: max-age=0；
* 設(shè)定緩存到期日為一個早就過去的日期，Expires: Mon, 1 Jan 1990 00:00:00 GMT。

實際上，后兩種不是最好的選擇。首先這樣會多占用終端的處理時間，因為當(dāng)碰到這個DECK時，終端需要計算一下過期時間。其次，這樣會多占用一些字節(jié)，而且在表達上也不夠清楚。

三、驗證（validation）和歷史堆棧（History Stack）在HTTP1.1中對緩存進一步提出了驗證的概念。驗證的目的就是檢驗緩存項目是否在有效期內(nèi)。由于歷史堆棧的存在，WAP終端上的驗證過程變得有點復(fù)雜。

WAP標準規(guī)定所有的WAP設(shè)備都至少要有可以容納10-個項目的歷史堆棧。當(dāng)用戶按下由<go>或其他轉(zhuǎn)向指令的定義的前行（forward）鏈接時，URL被推（push）入堆棧。如果按下由<prev>定義的后退（backward）鏈接，URL被彈（pop）出。

一般情況下，所有的前行鏈接都會被驗證，而后退鏈接則不會，因為它已經(jīng)在cache里了。可是我們有時候還是希望當(dāng)用戶按下后退鍵時依然能夠得到最新的數(shù)據(jù)。如果終端總是不予驗證的話，那用戶只好找到主菜單再重新進入那個頁面。

幸運的是，我們用Cache-Control：must-revalidate就可以強迫用戶終端在用戶按back時對URL進行驗證。當(dāng)然，進行驗證并不是說該頁面會立刻重新讀取，而是根據(jù)他是否過期來決定。如果沒有過期，驗證的結(jié)果仍然是顯示緩存中的頁面。

如果你需要每次back都重新讀取頁面，用Cache-Control：must-revalidate, no-cache可以實現(xiàn)。另外，把 no-cache換成max-age=300就可以在back時對已緩存了300秒的頁面進行刷新。

四、HTTP頭與meta元素 [TOP]
到這里，大家已經(jīng)知道HTTP消息頭的在WAP頁面的作用了。不過要在WML文檔里設(shè)置這些消息頭，就要用到meta元素，它只能出現(xiàn)在WML文檔<head>段里。下面是幾個消息頭和它們的表示形式：
Expires: Mon, 10 Jan 2000 00:00:00 GMT
Cache-Control: max-age=300
Cache-Control: no-cache

<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"/>