HTTP：每一個Web開發人員必須知道的協議 - 第2部分

 

在我以前的文章中，咱們介紹了一些HTTP的基礎知識，例如URL方案，狀態代碼和請求/響應頭。以此做爲咱們的基礎，咱們將介紹HTTP的更好的方面，如鏈接處理，身份驗證和HTTP緩存。這些主題至關普遍，但咱們將介紹最重要的位。

 

HTTP鏈接

必須在客戶端和服務器之間創建鏈接，才能相互通訊，而HTTP使用可靠的TCP傳輸協議進行鏈接。默認狀況下，Web流量使用TCP端口80. TCP流被分解爲IP數據包，並確保這些數據包始終以正確的順序到達。HTTP是經過TCP的應用層協議，它是經過IP。

HTTPS是HTTP的安全版本，在稱爲TLS或SSL（傳輸層安全或安全套接字層）的HTTP和TCP之間插入一個附加層。HTTPS默認經過端口443進行通訊，本文稍後將會看到HTTPS。

 

HTTP鏈接被識別<source-IP, source-port>和<destination-IP, destination-port>。在客戶端上，HTTP應用程序由<IP, port>元組標識。創建兩個端點之間的鏈接是一個多步驟的過程，涉及到以下：

 

• 經過DNS從主機名解析IP地址
• 創建與服務器的鏈接
• 發送請求
• 等待迴應
• 關閉鏈接

服務器負責始終使用正確的標頭和響應進行響應。

 

在HTTP / 1.0中，全部鏈接在單個事務以後都被關閉。所以，若是客戶端想要從同一臺服務器請求三個獨立的映像，則它會與遠程主機創建三個單獨的鏈接。從上圖能夠看出，這可能會引入大量的網絡延遲，從而產生一個次優的用戶體驗。

爲了減小鏈接創建的延遲，HTTP / 1.1引入了持久鏈接，長時間的鏈接保持打開，直到客戶端關閉它們。HTTP / 1.1中的持久鏈接是默認鏈接，而且單個事務鏈接須要客戶端設置Connection: close請求頭。這將通知服務器在發送響應後關閉鏈接。

除了持續鏈接以外，瀏覽器/客戶端也採用一種稱爲並行鏈接的技術來最大限度地減小網絡延遲。並行鏈接的古老概念涉及建立一個鏈接池（一般以六個鏈接爲限）。若是客戶端須要從網站下載6個資產，客戶端將進行六個並行鏈接來下載這些資產，從而致使更快的週轉時間。對於串行鏈接來講，這是一個巨大的改進，客戶端只有在完成先前資產的下載後才下載資產。

並行鏈接與持續鏈接相結合，是今天解決網絡延遲最小化以及在客戶端上創造平滑體驗的答案。有關HTTP鏈接的深刻處理，請參閱HTTP規範的「 鏈接」部分。

服務器端鏈接處理

服務器主要監聽傳入鏈接，並在收到請求時處理它們。業務涉及：

• 創建一個套接字開始偵聽端口80（或其餘端口）
• 接收請求並解析消息
• 處理響應
• 設置響應頭
• 將響應發送給客戶端
• 若是Connection: close發現請求標頭，請關閉鏈接

固然，這並非詳盡的操做列表。大多數應用程序/網站須要知道誰發出請求以建立更多的自定義響應。這是識別和認證的領域。

識別和認證

HTTP是經過TCP的應用層協議，它是經過IP。

幾乎必須知道誰鏈接到服務器來跟蹤應用程序或站點的使用狀況以及用戶的通常交互模式。識別的前提是爲了提供個性化的體驗來定製響應; 固然，服務器必須知道用戶是誰才能提供該功能。

服務器能夠經過幾種不一樣的方式來收集這些信息，大多數網站都使用這些方法的混合：

• 請求頭：From，Referer，User-Agent-咱們在看到這些標題1部分。
• Client-IP - 客戶端的IP地址
• 胖網址 - 經過修改URL並重定向到每一個點擊上的不一樣URL來存儲當前用戶的狀態; 每一個點擊基本上累積狀態。
• 餅乾 - 最流行和非侵入性的方法。

Cookie容許服務器經過Set-Cookie響應頭附加任意信息以用於外發響應。一個cookie設置有一個或多個name = value對，以分號（;）分隔，如同Set-Cookie: session-id=12345ABC; username=nettuts。

服務器也能夠限制cookie來具體的domain和path，它可使他們執着與expires價值。Cookie是由瀏覽器向服務器提出的每一個請求自動發送，並在瀏覽器確保了只有domain-和path特異性餅乾請求中發送。請求頭Cookie: name=value [; name2=value2]用於將這些Cookie發送到服務器。

識別用戶的最佳方式是要求他們註冊並登陸，但實現此功能須要開發人員以及用戶的一些努力。

像OAuth這樣的技術簡化了這種類型的功能，但它仍然須要用戶贊成才能正常工做。認證在這裏扮演着重要的角色，它多是識別和驗證用戶的惟一方法。

認證

HTTP確實支持稱爲基自己份驗證的基本形式的身份驗證，以及更安全的摘要身份驗證。

在基自己份驗證中，服務器最初使用WWW-Authenticate響應頭和401 Unauthorized狀態碼拒絕客戶端的請求。看到此標題後，瀏覽器會顯示登陸對話框，提示輸入用戶名和密碼。該信息以Authentication請求頭中的base-64編碼格式發送。若是憑據有效，服務器如今能夠驗證請求並容許訪問。某些服務器也可能發送Authentication-Info包含其餘身份驗證詳細信息的標頭。

 

 

基本認證的推論是代理認證。代替Web服務器，中間代理請求受權挑戰。代理髮送Proxy-Authenticate帶有407 Unauthorized狀態碼的標頭。做爲回報，客戶端應該經過Proxy-Authorization請求頭發送憑據。

Digest認證與Basic相似，並使用WWW-Authenticate與Authorization頭部相同的握手技術，但Digest使用更安全的散列函數來加密用戶名和密碼（一般使用MD5或KD摘要功能）。雖然Digest認證應該比Basic更安全，但因爲其簡單性，網站一般使用基本認證。爲了減輕安全問題，Basic Auth與SSL結合使用。

安全HTTP

HTTPS協議在網絡上提供安全鏈接。知道您使用HTTPS的最簡單的方法是檢查瀏覽器的地址欄。HTTPs的安全組件涉及在HTTP和TCP之間插入一層加密/解密。這是安全套接字層（SSL）或改進的傳輸層安全（TLS）。

SSL使用強大的加密形式，使用RSA和公鑰加密。因爲安全交易在網絡上很是重要，因此基於標準的公鑰基礎設施（PKI）的推出已經進行了好久。

現有的客戶機/服務器不須要改變他們處理消息的方式，由於大部分的辛勤工做都發生在SSL層。所以，您可使用基自己份驗證開發Web應用程序，並經過切換到https://協議自動獲取SSL的優勢。可是，要使Web應用程序經過HTTPS工做，您須要在服務器上部署一個正常的數字證書。

證書

就像您須要身份證以顯示您的身份同樣，Web服務器須要一個數字證書來識別本身。證書（或「證書」）由證書頒發機構（CA）頒發，並在網絡上保證您的身份。CA是PKI的守護者。最多見的證書形式是X.509 v3標準，其中包含如下信息：

• 證書頒發者
• 用於證書的算法
• 建立此證書的主題名稱或組織
• 該主題的公鑰信息
• 認證機構簽名，使用指定的簽名算法

當客戶端經過HTTPS發出請求時，它首先嚐試在服務器上找到證書。若是找到證書，它將嘗試根據其已知的CA列表進行驗證。若是它不是列出的CA之一，它可能會向用戶顯示一個對話框，警告網站的證書。

一旦證書被驗證，SSL握手是完整的，安全的傳輸是有效的。

HTTP緩存

廣泛贊成，作一樣的工做兩次是浪費的。這是HTTP緩存概念的指導原則，HTTP緩存是HTTP網絡基礎設施的基礎。因爲大多數操做都是經過網絡進行的，因此緩存有助於節省時間，成本和帶寬，並提供改進的網絡體驗。

緩存在網絡基礎架構中的幾個地方使用，從瀏覽器到源服務器。取決於它所在的位置，緩存能夠分爲：

• 私人：在瀏覽器中，緩存用戶名，密碼，URL，瀏覽歷史記錄和網頁內容。它們一般小並且對用戶具體。
• 公共：部署爲服務器和客戶端之間的緩存代理。這些更大，由於它們服務於多個用戶。一般的作法是在客戶端和源服務器之間保留多個緩存代理。這有助於爲常常訪問的內容提供服務，同時仍然容許不常常須要的內容訪問服務器。

 

 

緩存處理

無論高速緩存位於何處，維護緩存的過程很是類似：

• 接收請求消息。
• 解析 URL和標題。
• 查找本地副本; 不然，在本地獲取和存儲
• 進行新鮮度檢查以肯定緩存中內容的年齡; 僅在必要時才提出刷新內容的請求。
• 從緩存的主體和更新的標頭建立響應。
• 將響應發送回客戶端。
• （可選）記錄事務。

固然，服務器負責始終使用正確的標頭和響應進行響應。若是一個文檔沒有改變，服務器應該用一個304 Not Modified。若是緩存的副本已過時，它應該生成一個新的響應，更新的響應頭並返回200 OK。若是資源被刪除，它應該回來404 Not Found。這些響應有助於調整緩存，並確保過期的內容不會被保留。

緩存控制頭

並行鏈接與持續鏈接相結合，是今天解決網絡延遲最小化的答案。

如今咱們已經瞭解了緩存如何工做，如今是查看啓用緩存基礎架構的請求和響應頭。保持內容清新和更新是緩存的主要職責之一。爲了保持緩存的副本與服務器一致，HTTP提供了一些簡單的機制，即文檔過時和服務器從新驗證。

文件到期

HTTP容許源服務器使用和響應頭鏈接每一個文檔的到期日期。這有助於客戶端和其餘緩存服務器知道文檔有效和新鮮的時間。只要文檔的年齡在到期日期以內，緩存便可提供副本。一旦文檔過時，緩存必須與服務器檢查較新的副本，並相應地更新其本地副本。Cache-ControlExpires

Expires是一箇舊的HTTP / 1.0響應頭，將該值指定爲絕對日期。這隻有當服務器時鐘與客戶端同步時纔有用，這是一個可怕的假設。與Cache-Control: max-age=<s>HTTP / 1.1中引入的較新的頭文件相比，此標題不太有用。在這裏，max-age是從建立響應時間開始的相對年齡（以秒爲單位）。所以，若是文檔在一天後過時，則過時標題應爲Cache-Control: max-age=86400。

服務器從新驗證

一旦緩存文檔過時，緩存必須從新驗證服務器，以檢查文檔是否已更改。這被稱爲服務器從新驗證，而且用做文檔陳舊的查詢機制。只是由於緩存的副本已過時並不意味着服務器實際上具備較新的內容。從新驗證只是確保緩存保持新鮮的方法。因爲到期時間（如之前的服務器響應中所指定），緩存不須要與服務器檢查每個請求，從而節省帶寬，縮短網絡流量。

文檔到期和服務器從新驗證的組合是很是有效的機制，它容許分佈式系統維護有效期的副本。

若是知道內容頻繁更改，則能夠減小到期時間 - 容許系統更頻繁地從新同步。

從新驗證步驟能夠經過兩種請求標頭來實現：If-Modified-Since和If-None-Match。前者用於基於日期的驗證，然後者使用實體標籤（ETag），即內容的散列。這些標頭使用從先前服務器響應獲取的日期或ETag值。在狀況下If-Modified-Since，使用Last-Modified響應頭; 由於If-None-Match它是ETag響應頭。

控制可達性

文檔的有效期應由生成文檔的服務器定義。若是是報紙網站，首頁應該在一天以後過時（有時甚至每一個小時！）。HTTP提供Cache-Control和Expires響應標頭來設置文檔的到期時間。如前所述，Expires是基於絕對日期，而不是用於控制緩存的可靠解決方案。

該Cache-Control標題是更爲有用，有幾個不一樣的價值觀來約束客戶應如何緩存響應：

• 緩存控制：無緩存：容許客戶端存儲文檔; 可是，它必須在每一個請求上從新驗證服務器。有一個稱爲Pragma：no-cache的HTTP / 1.0兼容性頭，其工做方式相同。
• 緩存控制：無存儲：這是一個更強大的指令，客戶端根本不存儲文檔。
• 緩存控制：必須從新驗證：這將告訴客戶端繞過其新鮮度計算，並始終使服務器從新生效。若是服務器不可用，則不容許提供緩存的響應。
• 緩存控制：max-age：設置從響應生成時起的相對過時時間（以秒爲單位）。

另外，若是服務器沒有發送任何Cache-Control標題，客戶端能夠自由使用本身的啓發式到期算法來肯定新鮮度。

限制客戶的新鮮度

可訪問性不只限於服務器。也能夠從客戶端指定。這容許客戶對它願意接受的內容施加約束。這能夠經過相同的Cache-Control標題，儘管有幾個不一樣的值：

• 緩存控制：min-fresh = <s>：文檔必須至少爲ss秒以上。
• 緩存控制：MAX-陳舊或緩存控制：MAX-陳舊= <S> ：該文檔不能從緩存中提供，若是它已通過時了長於<S>秒。
• 緩存控制：max-age = <s>：緩存不能返回緩存長於<s>秒的文檔。
• Cache-Control：無緩存或Pragma：no-cache：除非已被從新驗證，客戶端將不會接受緩存的資源。

HTTP緩存其實是一個很是有趣的話題，而且有一些很是複雜的算法來管理緩存的內容。要深刻了解此主題，請參閱HTTP規範的緩存部分