Http權威指南筆記(十四)-內容協商與轉碼

現在很多國際化的一些Web服務都會根據不同地區使用的語言不同,返回不同語言的頁面內容展示給用戶。而這裏面就涉及到本篇介紹的內容——內容協商與轉碼。

1 內容協商的技術

目前的內容協商技術主要有3種——客戶端驅動協商、服務器驅動協商和透明協商(也就是中間代理商進行選擇和判斷)。這三類大致歸納如下:

技  術 工作原理 優  點 缺  點
客戶端驅動 客戶端發起請求,服務器發送可選項的列表,客戶端選擇 在服務器端的實現最容易。客戶端可以選擇最合適的內容 增加了時延:爲了獲得正確的內容,至少要發送兩次請求
服務器驅動 服務器檢查客戶端的請求首部集並決定提供哪個版本的頁面 比客戶端驅動的協商方式要快。HTTP 提供了 q 值機制,允許服務器近似匹配,還提供了 Vary 首部供服務器告知下游的設備如何對請求估值 如果結論不是很明確(比如首部集不匹配),服務器要做猜測
透明 某個中間設備(通常是緩存代理)代表客戶端進行請求協商 免除了 Web 服務器的協商開銷。“比客戶端驅動的協商要快 關於如何進行透明協商,還沒有正式的規範

下面就以上三種內容協商技術進行一些介紹。

2 客戶端驅動的協商

該種協商技術的基本原理和過程就是:客戶端發起請求的時候,先請求一次服務器可以提供服務的列表,然後客戶端選擇一個最合適自己的版本進行請求。這種協商方式,服務器實現簡單,而且客戶端也能夠尋找到最適合自己的版本,但是缺點也是顯而易見。每次爲了獲取一份內容都需要發送兩次請求。這樣會給用戶感覺請求速度很慢。
其中具體的實現原理上:服務器有兩種選擇,一種是直接正常響應一個HTML頁面,在裏面包含有各個版本的描述和連接地址。另外一種就是直接返回300 Multiple Choices 響應代碼,然後由用戶進行選擇。

3 服務器驅動的協商

這種協商技術,服務器需要依賴於客戶端在請求中提供足夠多的信息以便讓服務器知道該返回什麼版本的內容給客戶端。這種協商技術相較於客戶端驅動的協商,只需要一次請求即可,可以大大降低用戶等待時間。但是主要技術點就在於客戶端怎麼給服務器提供足夠多的可用於判斷返回版本的信息。

在HTTP中,提供了不少用於協商內容的頭部集。如下:

首  部 描  述 實體首部
Accept 告知服務器發送何種媒體類型 Content-Type
Accept-Language 告知服務器發送何種語言 Content-Language
Accept-Charset 告知服務器發送何種字符集 Content-Type
Accept-Encoding 告知服務器採用何種編碼 Content-Encoding

這裏最後一欄提供了響應信息中對應的一些實體信息頭部。一般可以配合客戶端一起使用。

這種協商技術雖然減少了用戶等待時間,提交了效率。但是有個需要解決的問題是:返回的版本不一定是客戶端最適合的版本。比如:服務器端只有英文、中文兩種語言的內容。但是客戶端給到的Accept-Language中卻是需要西班牙語,這個時候服務器可能就不知道應該返回哪個版本了。也行用戶在中文和英文中對英文更加熟悉,那他就可能希望返回英文版本,也有可能對中文更加熟悉呢。這個時候服務器就需要客戶端提供更多的信息,用於匹配更加合適的版本。在HTTP中提供了一個質量值用於描述偏好信息,如:
Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0
這裏我們爲每一種語言定義了一個q值。用於表示我們的偏好信息。其中q的取值範圍爲(0~1),數值越大,代表優先級越高,同時該值的對排列順序並沒有要求。比如上述例子中,nl優先級就要高於en。

4 透明協商

透明協商的機制利用中間代理實現。假定代理了解了客戶端的需要,可以代表客戶端與服務器進行協商,並將協商後的內容進行緩存。下次客戶端在獲取的時候,就能直接提供需要的內容。但是在服務器這端,爲了支持該特性,需要告知代理服務器需要進行哪些請求首部的檢查,以便達到和客戶端進行最佳匹配的目的。HTTP中定義的Vary首部即可用於此處的實現。如:
Vary: User-Agent, Cookie

這裏的Vary字段說明,需要根據User-AgentCookie兩個首部進行內容篩選匹配,最終確定出一份最合適的文檔。

中間代理緩存爲了實現上面的功能,就必須對同一份內容的不同形式進行緩存。比如同一份文檔存在英語和法語兩種語言,中間緩存的代理就需要更加客戶端的需求緩存兩份文檔,以便滿足不同客戶端的需求。如果篩選標準在多一些,從不同的緯度進行判斷,如上述的列子。這個時候緩存代理就需要緩存成倍的內容。所以這個也會消耗掉大量測存儲空間。

5 轉碼

我們前面討論的都是假設服務器存在滿足客戶端需求的文檔。然而,如果服務器沒有能滿足客戶端需求的文檔會怎麼樣呢?服務器可以給出一個錯誤響應。但理論上,服務器可以把現存的文檔轉換成某種客戶端可用的文檔。這種選項稱爲轉碼。常見的轉碼類型如下:

  1. 格式轉換
    格式轉換是指將數據從一種格式轉換成另一種格式,使之可以被客戶端查看。通過 HTML 到 WML 的轉換,無線設備就可以訪問通常供桌面客戶端查看的文檔了。通過慢速連接訪問 Web 頁面的客戶端並不需要接收高分辨率圖像,如果通過格式轉換降低圖像分辨率和顏色來減小圖像文件大小的話,這類客戶端就能更容易地查看圖像比較豐富的頁面了。
  2. 信息綜合
    從文檔中提取關鍵的信息片段稱爲信息綜合(information synthesis),這是一種有用的轉碼操作。這種操作的例子包括根據小節標題生成文檔的大綱,或者從頁面中刪除廣告和商標。
  3. 內容注入
    前面描述的兩類轉碼通常會減少 Web 文檔的內容,但還有另一類轉換會增加文檔的內容,即內容注入轉碼。內容注入轉碼的例子有自動廣告生成器和用戶追蹤系統。

現在大多數的Web服務器,也是通過動態注入生成不同的頁面,從而替代以前的單獨保存各種不同版本的靜態資源。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章