HTTP結構講解——《HTTP權威指南》系列

標籤：過程   代理   單線程   別名   option   本機存放區   開始   掃描   功能   

HTTP結構

第二部分的5章主要介紹了HTTP伺服器，代理，緩衝，網關和機器人應用程式，這些都是Web系統架構的構造模組。

Web伺服器 第五章

Web伺服器會對HTTP請求進行處理並提供響應。術語"web伺服器"可以用來表示Web伺服器的軟體，也可以用來表示提供Web頁面的特定裝置或電腦。

實際的Web伺服器會做些什麼

 

1. 建立串連----接受一個用戶端串連，或者如果不希望與這個用戶端建立串連，就將其關閉

2. 接收請求----從網路中讀取一條HTTP請求報文

3. 處理請求----對請求報文進行解釋，並採取行動

4. 訪問資源----訪問報文中指定的資源

5. 構建響應----建立帶有正確首部的HTTP響應報文

6. 發送響應----將響應回送給用戶端

7. 記錄交易處理過程----將與已完成事務有關的內容記錄在一個記錄檔中

第一步——接受用戶端串連

如果用戶端已經開啟了一條到伺服器的持久串連，可以使用那條串連來發送它的請求。否則，用戶端需要開啟一條新的到伺服器的串連。

處理新串連

用戶端請求一條道web伺服器的TCP串連時，Web伺服器會建立串連，判斷串連的另一端是哪個用戶端，從TCP串連中將IP位址解析出來。一旦新串連建立起來並被接受，伺服器就會將新串連添加到其現存Web伺服器串連列表中，並做好監視串連上資料轉送的準備。

用戶端主機名稱識別

可以用"反向DNS"對大部分Web伺服器進行配置，以便將用戶端IP地址轉換成用戶端主機名稱。但需要注意的是，主機名稱的尋找可能會花費很長時間，這樣會降低Web交易處理的速度。因此，很多大容量Web伺服器要麼會禁止主機名稱解析，要麼只允許對特定內容進行解析。

第二步——接收請求報文

串連上有資料到達時，web伺服器會從網路連接中讀取資料，並將請求報文中的內容解析出來。
解析請求報文時，web伺服器會不定期地從網路上接收輸入資料。網路連接可能隨時都會出現延遲。web伺服器需要從網路中讀取資料，將部分報文資料臨時儲存在記憶體中，直到收到足以進行解析的資料並理解其意義為止。

報文的內部標記法

有些Web伺服器還會用便於進行報文操作的內部資料結構來儲存請求報文，這樣就可以將這些報文的資料存放在一個快速查詢表中，以便快速存取特定首部的具體值了。

串連的輸入/輸出處理結構
不同的Web伺服器結構以不同的方式為請求服務，如下。

• 單線程Web伺服器

• 多進程及多線程Web伺服器

• 複用I/O的伺服器

• 複用的多線程Web伺服器

第三步——處理請求

一旦web伺服器收到了請求，就可以根據方法，資源，首部和可選的主體部分對請求進行處理了。

第四步——對資源的映射以及訪問

Web伺服器是資原始伺服器。他們負責發送預先建立好的內容，比如HTML頁面或者JPEG圖片，以及運行在伺服器上的資源產生程式所產生的動態內容。在web伺服器將內容傳送給用戶端之前，要將請求報文中的URI映射為Web伺服器上適當的內容或內容產生器，以識別出內容的源頭。

docroot
通常，web伺服器的檔案系統會有一個特殊的檔案夾專門用於存放web內容。這個檔案夾被稱為文檔的根目錄(document root)。web伺服器從請求報文中擷取URI，並將其附加在主目錄的後面。

目錄列表
Web伺服器可以接收對目錄URL的請求，其路徑可以解析為一個目錄，而不是檔案。我們可以對大多數Web伺服器進行配置，使其在用戶端請求目錄URL時採取不同的動作。

• 返回一個錯誤

• 不返回目錄，返回一個特殊的預設"索引檔案" (DirectoryIndex index.html home.html)

• 掃描目錄，返回一個包含目錄內容的HTML介面 (在Aapche中可以通過指令Options -Indexes禁止)

第五步——構建響應

一旦web伺服器識別出了資源，就執行要求方法中描述的動作，並返迴響應報文。響應報文中包含了響應狀態代碼，響應首部，如果產生了響應主體的話，還包括響應主體。

第六步——發送響應

Web伺服器通過串連發送資料時也會面臨與接收資料一樣的問題。伺服器要記錄串連的狀態，還要特別注意對持久串連的處理。對非持久串連而言，伺服器應該在發送了整條報文之後，關閉自己這一端的串連。
對持久串連來說，串連可能仍保持開啟狀態，在這種情況下，伺服器要特別小心，要正確的計算Content-Length首部，不然用戶端就無法知道響應什麼時候結束了。

第七步——記錄日誌

當事務結束之後，web伺服器會在記錄檔中添加一個條目，來描述已執行的事務。

代理 第六章

web上的Proxy 伺服器是代表用戶端完成交易處理的中間人。如果沒有Web代理，HTTP用戶端就要直接與HTTP伺服器進行對話，有了Web代理，用戶端就可以與代理進行對話，然後由代理代表用戶端與伺服器進行交流，用戶端仍然會完成事務的處理，但它是通過Proxy 伺服器提供的優質服務來實現的。

代理與網關的區別
嚴格的來說，代理串連的是兩個或多個使用相同協議的應用程式，而網關串連的則是兩個或多個使用不同協議的端點。

代理的應用
Proxy 伺服器可以實現各種有用的功能，他們可以改善安全性，提高效能，節省費用。Proxy 伺服器可以看到並接觸所有流過的HTTP流量，所有代理可以監視流量並對其進行修改，以實現很多有用的增值Web服務。

• 兒童過濾器

• 文檔存取控制

• 安全防火牆

• web緩衝

• 反向 Proxy

• 內容路由器

• 轉碼器

• 匿名者

Proxy 伺服器的部署

可以根據其目標用途，將代理放在任意位置。

• 出口代理

• 訪問(入口)代理

• 反向 Proxy

• 網路交換代理

層次化的代理
可以通過代理階層將代理級聯起來。在代理的階層中，會將報文從一個代理傳給另外一個代理，直到最終抵達原始伺服器為止(然後通過代理傳回用戶端)。

如何使用代理

 

• 修改用戶端的代理配置

• 修改網路，對流量進行攔截並匯入一個代理

• 修改DNS的命名空間，假扮web伺服器的名字和IP地址。

• 修改Web伺服器，伺服器發送重新導向命令

用戶端的代理設定

 

• 手工配置

• 預先配置瀏覽器

• 代理的自動設定 PAC

• WPAD的代理髮行

緩衝 第七章

web緩衝是可以自動儲存常見文檔副本的HTTP裝置。當Web請求抵達緩衝時，如果本地有"已緩衝的"副本，就可以從本機存放區裝置而不是原始伺服器中提取這個文檔。

緩衝可以最佳化一下問題

• 冗餘的資料轉送

• 頻寬瓶頸

• 瞬間擁塞

• 距離時延

命中和未命中的

緩衝無法儲存世界上的每一份文檔。可以用已有的副本為某些到達緩衝的請求提供服務，這被稱為快取命中 (cache hit)，其他一些請求可能因為沒有副本可用，而被轉寄給原始伺服器，這被稱為緩衝未命中(cache miss)。

• 文檔命中率 (說明了阻止了多個通往外部網路的Web事務，有效降低整體時延)

• 位元組命中率 (說明了阻止了多少位元組傳向網際網路，有利於節省頻寬)

再驗證

緩衝可以在任意時刻，以任意頻率對副本進行再驗證。如果驗證過沒有更新則將副本提供給用戶端，這被稱為再驗證命中或緩慢命中，這種方式確實要與原始伺服器進行核對，所以會比單純的快取命中要慢，但它沒有從伺服器中擷取對象資料，所以要比緩衝未命中快一些。

緩衝的處理步驟

 

1. 接收——緩衝從網路中讀取抵達的請求報文

2. 解析——緩衝對報文進行解析，提取出URL和各種首部

3. 查詢——緩衝查看是否有本機複本可用，如果沒有，就擷取一份副本(並將其儲存在本地)

4. 新鮮度檢測——緩衝查看已快取複本是否足夠新鮮，如果不是，就詢問伺服器是否有任何更新

5. 建立響應——緩衝會用新的首部和已緩衝的主體來構建一條響應報文

6. 發送——緩衝通過網路將響應發回給用戶端

7. 日誌——緩衝可選地建立一個記錄檔條目來描述這個事務

保持副本的新鮮 文檔到期 (document expiration)

通過特殊的HTTP Cache-Control: max-age = 484200首部和Expires: Fri, 05,2016, 17:20:30 GMT首部,HTTP讓原始伺服器向每個文檔附加了一個到期日期。在緩衝文檔到期之前，可以以任意頻率使用這些副本，而無需與伺服器聯絡。
HTTP/1.0+的Expires首部使用的是絕對日期而不是相對時間，所以我們更傾向於使用比較新的HTTP/1.1的Cache-Control，絕對日期依賴於電腦時鐘的正確設定。

伺服器再驗證 (server revalidation)

文檔到期並不意味著它和伺服器上目前活躍的文檔有實際的區別，這隻是意味著到了要進行核對的時間了。

1. 如果再驗證顯示內容發生了變化，緩衝會擷取一份新的文檔副本，並將其緩衝在舊文檔的位置上，然後將文檔發送給用戶端。

2. 如果再驗證顯示內容沒有發送變化，緩衝只需要擷取新的首部，包括一個新的到期時間，並對緩衝中的首部進行更新就行了。

用條件方法進行再驗證

HTTP定義了5個條件請求首部，對緩衝再驗證來說最有用的2個首部是If-Modified-Since:date和If-None-Match:tag(只有兩個條件都滿足時，才能返回304響應)。

另外3個條件首部包括If-Unmodified-Since(在進行部分檔案的傳輸時，擷取檔案的其餘部分之前要確保檔案未發生變化，此時這個首部是非常有用的)，If-Range(支援對不完整文檔的緩衝)和If-Match(用於與web伺服器打交道時的並發控制)

If-Modified-Since:Date 再驗證

如果從指定日期之後文檔被修改過了，就執行請求的方法。可以與Last-Modified伺服器響應首部配合使用，只有在內容被修改後與已緩衝版本有所不同時才去擷取內容。

If-None-Match:實體標籤再驗證
有些情況下僅使用最後修改日期進行再嚴重是不夠的

• 有些文檔可能會被周期性地重寫(比如，從一個後台進程中寫入)，但實際包含的資料常常是一樣的。經內容沒有變化，但修改日期會發生變化。

• 有些文檔可能被修改了，但所做修改並不重要，不需要讓世界範圍內的緩衝都重裝資料(比如對拼字或注釋的修改)

• 有些伺服器無法準確地判定其頁面的最後修改日期

• 有些伺服器提供的文檔會在亞秒間隙發生變化(比如，即時監視器)，對這些伺服器來說，以一秒為粒度的修改日期可能就不夠用了

為瞭解決這些問題，HTTP允許使用者對被稱為實體標籤(ETag)的“版本標識符”進行比較。實體標籤是附加到文檔上的任意標籤(引用字串)。
當發行者對文檔進行修改時，可以修改文檔的實體標籤來說明這個新的版本，這樣，如果實體標籤被修改了，緩衝就可以用If-None-Match條件首部來GET文檔的新副本了。

控制緩衝的能力

伺服器可以通過HTTP定義的幾種方式來指定在文檔到期前可以將其緩衝多長時間。按照優先順序遞減的順序，伺服器可以：

• Cache-Control: no-store

• Cache-Control: no-cache

• Cache-Control: must-revalidate

• Cache-Control: max-age

• 附加一個Expires日期首部到響應中去

• 不附加到期資訊，讓緩衝確定自己的到期日期

整合點：網關，隧道及中繼 第八章 網關 gateway

HTTP擴充和介面的發展是由使用者需求驅動的。要在web上發布更複雜的資源的需求出現時，單個應用程式無法處理所有這些能想到的資源。

為瞭解決這個問題，開發人員提出了網關的概念，網關可以作為某種翻譯器使用，他可以自動將HTTP流量轉換為其他協議，這樣HTTP用戶端無需瞭解其他協議，就可以與其他應用程式層序進行互動了。

可以用一個斜杠來分割用戶端和伺服器端協議，並以此對網關進行描述
<用戶端協議>/<伺服器端協議>

CGI Common Gateway Interface

CGI是一個標準介面集，web伺服器可以用它來裝載程式以響應對特定URL的HTTP請求，並收集程式的輸出資料，將其放在HTTP響應中回送。

隧道

web隧道允許使用者通過http串連發送非http流量，這樣就可以在http上捎帶其他協議資料了。使用web隧道最常見的原因就是要在http串連中嵌入非http流量，這樣，這類流量就可以穿過只允許web流量通過的防火牆了。

中繼 relay

中繼是沒有完全遵循http規範的簡單http代理。中繼負責處理http中建立串連的部分，然後對位元組進行盲轉寄。

Web機器人 第九章

Web爬蟲是一種機器人，它們會遞迴地對各種資訊性Web網站進行遍曆，擷取第一個Web頁面，然後擷取那個頁面指向的所有web頁面，然後是那些頁面指向的所有頁面，以此類推。遞迴地跟蹤這些web連結的機器人會沿著HTML超連結建立的網路"爬行"，所有稱其為爬蟲(crawler)或蜘蛛(spider)。

爬蟲 根集

在把爬蟲放出去之前，需要給他一個起始點。爬蟲開始訪問的URL初始集合被稱作根集(root set)。

避免環路

機器人必須知道他們到過何處，以避免環路(cycle)的出現。

麵包屑留下的痕迹

管理大規模web爬蟲對其訪問過的地址進行管理時使用的一些有用的技術

• 樹和散列表

• 有損的存在位元影像

• 檢查點

• 分類

別名

由於URL“別名”的存在，即使使用了正確的資料結構，有時也很難分辨出以前是否訪問過某個頁面，如果兩個URL看起來不一樣，但實際指向的是同一資源，就稱這兩個URL互為"別名"。

避免迴圈和重複的一些方法

 

• 正常化URL

• 廣度優先的爬行

• 節流

• 限制URL大小

• URL/網站黑名單

• 模式檢測

• 內容指紋

• 人工監視

機器人的HTTP 虛擬機器主機

機器人實現者要支援Host首部，隨著虛擬機器主機的流行，請求中不包含Host首部的話，可能會使機器人將錯誤的內容與一個特定的URL關聯起來。

條件請求

對時間戳記或實體標籤進行比較，看看它們最近擷取的版本是否已經升級以減少擷取未更新的內容。

HTTP結構講解——《HTTP權威指南》系列