HTTP 和 HTTPS

標籤：方法   原因   ext   form   rri   字元   資訊隱藏   表示   使用者認證   

一、HTTP協議

 

最近看了一些網路通訊方面的書籍，研究了一下 HTTP 和 TCP/IP，有了一些新的收穫和理解，在這裡做個歸納和總結。

 

（1）什麼是HTTP協議

HTTP (HyperText Transfer Protocol，超文字傳輸通訊協定 (HTTP)) 是一種通訊協定，是指電腦網路中兩台電腦之間進行通訊所必須共同遵守的規定或規則，它允許將超文字標記語言 (HTML)(HTML)文檔從Web伺服器傳送到用戶端，是互連網上應用最為廣泛的一種網路通訊協定。

 

（2）一種無狀態協議

HTTP協議是不儲存狀態的協議，即HTTP是無狀態協議。HTTP協議自身不對請求和響應之間的通訊狀態進行儲存。也就是說在HTTP這個層級，協議對於發送過來的請求或響應都不做持久化處理。

使用HTTP協議，每當有新的請求發送時，就會有對應的新的響應產生。協議本身不保留之前一切的請求或響應報文的資訊。也就是說，無法根據之前的狀態進行本次請求的處理。

無狀態優點： ①更快地處理大量事務，確保協議的延展性。②由於不必儲存狀態，這就可以減少伺服器的CPU及記憶體資源的消耗。

HTTP/1.1雖然是無狀態協議，但為了實現期望的保持狀態功能，引入了Cookie技術。有了Cookie再用HTTP協議通訊，就可以管理狀態了。

Cookie會根據從伺服器端發送的響應報文類中的Set-Cookie的首部欄位資訊，通知用戶端儲存Cookie。當下次用戶端再往伺服器發送請求時，用戶端會自動的請求報文中加入Cookie值後發送出去。伺服器端接收到用戶端發送過來的Cookie後，回去檢查究竟是從哪一個用戶端發來的請求，然後對比伺服器上的記錄，最後得到之前狀態的資訊。

 

（3）HTTP方法

HTTP/1.0 和 HTTP/1.1支援的方法

其中LINK 和 UNLINE 已被HTTP/1.1廢棄，不再支援。

 

（4）HTTP協議的報文

用於HTTP協議互動的資訊被稱為HTTP報文。請求端（用戶端）的HTTP報文叫做請求報文，響應端（伺服器端）的HTTP報文叫做響應報文。HTTP報文本身是由多行資料構成的字串文本。

HTTP報文包括以下三部分：

1. 報文首部

用戶端或伺服器端需處理的請求或響應的內容及屬性。包括：請求行(包含用於請求的方法，請求URI，HTTP版本)，狀態行(包含表明響應結果的狀態代碼，原因短語，HTTP版本)，首部欄位(包含表明請求和響應的各種條件和屬性的各類首部)。

2. 空行

CR+LF，CR(Crriage Return，斷行符號符) 和 LF(Line Feed，分行符號)。

3. 報文主體

應被發送的資料。

請求報文和響應報文的樣本圖：

 

（5）HTTP持久化串連1. 持久串連

HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP串連，增加了通行量的開銷。

為瞭解決上述TCP的問題，HTTP/1.1推出了持久串連（HTTP Persistent Connections，也稱為HTTP keep-alive 或 HTTP connection reuse）的方法。

持久串連的特點是，只要任意一端沒有明確提出中斷連線，則保持TCP串連狀態。

優點：減少了TCP串連的重複建立和斷開所造成的額外開銷，減輕了伺服器端的負載。減少開銷的那部分時間，使HTTP請求和響應能夠更早地結束，這樣Web頁面的顯示速度就相應提高了。

在HTTP/1.1中，所有串連預設都是持久串連，但在HTTP/1.0內並未標準化。

2. 管線化

持久串連使得多數請求以管線化方式發送成為可能。之前發送請求後需等待並收到響應之後，才能發送下一個請求。管線化技術出現後，不用等待響應就可直接發送下一個請求。

 

（6）HTTP結果的狀態代碼

HTTP狀態代碼的職責是當用戶端向服務端發送請求時，描述返回的請求結果。通過狀態代碼，使用者可以知道伺服器是正常的處理了請求，還是出現了錯誤。

每條HTTP響應報文返回時都會攜帶一個狀態代碼，狀態代碼是由一個三位元字和原因短語組成，如200 OK。數位第一位是響應類別(狀態代碼類別)，後兩位無分類。

5種狀態代碼的類別：

 只要遵守狀態代碼類別的定義，及時改變RFC2616總定義的狀態代碼，或伺服器端自行建立裝條碼都沒問題。

幾個常見的狀態代碼：

• 200 OK。  表示從用戶端發來的請求在伺服器端被正常處理了。
• 204 No Content。 表示伺服器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分，也不允許返回任何實體的主體。一般在只需要重用戶端往伺服器發送資訊，而對用戶端不需要發送新資訊內容的情況下使用。
• 301 Moved Permanently。 永久性重新導向。表示請求的資源已被分配了新的URI，以後應使用資源現在所指的URI。也就是說，如果已經把資源對應的URI儲存為書籤了，這是應該按Location首部欄位提示的URI重新儲存。
• 302 Found。 臨時性重新導向。表示請求的資源已被分配了新的URI，希望使用者（本次）能使用新的URI訪問。
• 304 Not Modified。 表示用戶端發送附帶條件的請求時，伺服器端允許請求訪問資源，但未滿足條件的情況。304狀態代碼返回時，不包含任何響應的主體部分。304雖然被劃分在3XX類別中，其實和重新導向沒有關係。
• 400 Bad Request。 表示報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。
• 401 Unauthorized。 表示發送的請求需要通過HTTP認證（BASIC認證，DIGEST認證）的認證資訊。若之前已經進行過1次請求，則表示使用者認證失敗。
• 404 Not Found。 表示伺服器上無法找到請求的資源。除此之外，也可以在伺服器端拒絕請求且不想說明理由時使用。
• 500 Internal Server Error。 表示伺服器端在執行請求時發生了錯誤。也有可能是Web應用存在的bug或某些臨時的故障。
• 503 Service Unavailable。 表示伺服器暫時處於超負載或進行中停機維護，現在無法處理請求。如果事先得知解除以上狀況所需要的時間，最好寫入Retry-After首部欄位再返回給用戶端。

 

（7）常見的疑問

1. HTTP 和 TCP/IP 的區別

TCP/IP協議是傳輸層協議，主要解決資料如何在網路中傳輸，而HTTP是應用程式層協議，主要解決如何封裝資料。

詳細點說就是，我們在傳輸資料的時候，可以只使用 TCP/IP協議，但是那樣的話，如果沒有應用程式層，便無法識別資料內容，如果想要使傳輸的資料有意義，則必須使用到應用程式層協議，應用程式層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用程式層協議。WEB使用HTTP協議作應用程式層協議，以封裝HTTP 文本資訊，然後使用TCP/IP做傳輸層協議將它發到網路上。

 

2. URI、URL、URN 的區別

URI：Uniform Resorce Identifier，統一資源識別項。

URL：Uniform Resource Locator，統一資源定位器。

URN：Uniform Resource Name，統一資源名稱。

URI用字串表標識某一互連網資源，而URL表示資源的地點(互連網上所處的位置)。可見URL是URI的子集。

三者關係圖：

 

如果是一個人，我們會想到他的姓名和住址。URL類似於住址，它告訴你一種尋找目標的方式（在這個例子中，是通過街道地址找到一個人）。要知道，上述定義同時也是一個URI。相對地，我們可以把一個人的名字看作是URN；因此可以用URN來唯一標識一個實體。由於可能存在同名（姓氏也相同）的情況，所以更準確地說，人名這個例子並不是十分恰當。更為恰當的是書籍的ISBN碼和產品在系統內的序號，儘管沒有告訴你用什麼方式或者到什麼地方去找到目標，但是你有足夠的資訊來檢索到它。

 

二、HTTPS 協議（1）為什麼要使用HTTPS

 上面已經介紹了HTTP協議，雖然HTTP協議用的很普遍，但是它也有些不足。列舉如下：

• 通訊使用明文(不加密)，內容可能會被竊聽。
• 不驗證通訊方的身份，因此有可能遭遇偽裝。
• 無法驗證報文的完整性，所以有可能已遭篡改。

這些問題不僅在HTTP上出現，其他未加密的協議中也會存在這類問題。

為了統一解決上述這些問題，需要在HTTP上在加入加密處理和認證等機制。我們把添加了加密及認證機制的HTTP稱為HTTPS(HTTP Secure)。 

簡單的說，其實  HTTPS = HTTP  +  加密  +  認證  +  完整性保護。

經常會在Web的登入頁面和購物結算介面使用HTTPS通訊。使用HTTPS通訊時，不再用http://，而是改用https://。當瀏覽器訪問HTTPS通訊有效Web網站時，瀏覽器的地址欄會出現一個帶鎖的標記。

 

（2）特殊的HTTP

HTTPS並非是應用程式層的一種新協議。只是HTTP通訊介面部分用SSL（Secure Socker Layer）和 TLS（Transport Layer Security）協議代替而已。

通常，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL 和 TCP 通訊了。簡言之，所謂HTTPS，其實就是身披 SSL 協議這層外殼的HTTP。

TLS/SSL 是獨立於HTTP的協議，是介於 TCP 和 HTTP 之間的一層安全性通訊協定，不影響原有的 TCP 協議和 HTTP 協議，所以使用 HTTPS 基本上不需要對 HTTP 頁面進行太多的改造。不光是HTTP協議，其他運行在應用程式層的SMTP 和 Telnet等協議均可配合SSL協議的使用。

 

（3）為什麼不都使用HTTPS

既然HTTPS那麼完全可靠，那為何所有的Web網站不一直使用HTTPS？

主要是因為以下幾個原因：

1. 與純文字通訊相比，加密通訊會消耗更多的CPU及記憶體資源。

如果每次通訊都加密，會消耗相當多的資源，平攤到一台電腦上時，能處理的請求數量必定會隨之減少。因此，如果是非敏感資訊還是用HTTP通訊，只有在包含個人敏感性資料時，才利用HTTPS加密通訊。特別是每當那些訪問量較多的Web網站在進行加密處理時，並非對所有內容都進行加密處理，而是僅對那些需要資訊隱藏時才會加密，以節約資源。

2. 節約購買認證的開銷。

要進行HTTPS通訊，認證是必不可少的。而使用的認證必須向認證機構（CA）購買。認證價格根據不同的認證機構略有不同，一年幾百到幾千的都有，那些購買認證並不合算的服務以及一些個人網站，可能只會選擇採用HTTP的通訊方式。

3. HTTPS使用SSL時，它的處理速度會變慢。

SSL的慢有兩種，一是通訊慢，二是大量消耗CPU及記憶體等資源，導致處理速度變慢。和HTTP相比，網路負載可能會慢2到100倍。除去和TCP串連、發送HTTP請求和響應以外，還必須進行SSL通訊，因此整體上處理通行量不可避免會增加。SSL必須進行加密處理。在伺服器和用戶端都需要進行加密和解密的運算處理。因此，比起HTTP會更多地消耗伺服器和用戶端的硬體資源，導致負載增強。當然，可以通過使用SSL加速器這種硬體來改善該問題。

 

本文主要收集整理自《圖解HTTP》

HTTP 和 HTTPS