第 3 部分. HTTP/HTTPS 協議

本資料是「企業發展概論」系列的一部分。上一篇文章：

關於網路；
關於軟體架構。

你好！今天我們將了解HTTP和HTTPS協定。但首先，讓我們澄清一點：我們正在討論 OSI 模型應用層網路上的資料傳輸協定。您還記得，我們在之前的一篇文章中討論了 OSI 模型。如果你不記得了，就在這裡。第 3 部分. HTTP/HTTPS 協定 - 1

什麼是資料傳輸協議

這是普遍接受的協議的名稱，不同服務的開發人員透過該協議以單一形式發送訊息。例如，使用Google Chrome，您可以從Facebook和Twitter獲取訊息，因為開發人員使用標準HTTP協定傳輸訊息，而您的瀏覽器可以處理它。統一的規則對於伺服器端開發人員本身來說也非常方便：有許多程式庫可以為您轉換資訊並使用所需的協定發送它。HTTP 最初被設想為傳輸 HTML 頁面的協定。很長一段時間都是這種情況，但現在程式設計師經常透過它傳輸字串和媒體檔案。總體而言，該協議通用且靈活，並且非常易於使用。現在讓我們弄清楚如何做到這一點。

HTTP結構

值得注意的是，HTTP 協定僅由文字組成。嗯，我們最感興趣的是這段文本所在的結構。每條訊息由三個部分組成：

起始線—定義服務資料。
標頭 - 訊息參數的描述。
訊息正文（Body）－訊息資料。必須用空白行與標題分隔。

使用HTTP協議，您可以向伺服器發送請求（請求）並從伺服器接收回應（回應）。請求和回應的參數略有不同。

簡單的 HTTP 請求是什麼樣的

GET / HTTP/1.1
Host: javarush.com
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)

起始行包含：

GET－請求方法；
/ ——請求路徑（path）；
HTTP/1.1 - 資料傳輸協定的版本。

然後按照標題操作：

Host－請求所寄送的主機；
User-Agent是發送請求的客戶端。

沒有訊息正文。在 HTTP 請求中，只需要起始行和 Host 標頭。現在讓我們按順序看一下一切。HTTP 請求必須包含某種方法。總共有九個：GET、POST、PUT、OPTIONS、HEAD、PATCH、DELETE、TRACE、CONNECT。最常見的是 GET 和 POST。一開始這兩種方法就夠了。 GET - 從伺服器請求內容。因此，使用 GET 方法的請求沒有訊息正文。但如果有必要，您可以透過以下格式的路徑發送參數： https://cdn.javarush.com/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value1&name2=value1&name2=value1&name2=value1&name2=value1&name2=value1&name2=value ）這裡： javarush .com — 主機， /send — 請求路徑， ? — 指示後面跟著請求參數的分隔符號。最後，參數以 key=value 格式列出，並以 & 符號分隔。 POST - 在伺服器上發布資訊。POST 請求可以傳輸各種資訊：key=value 格式的參數、JSON、HTML 程式碼，甚至檔案。所有資訊都在訊息正文中傳輸。例如：

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: javarush.com

{
  "Id": 12345,
  "User": "John"
}

請求發送到javarush.com/user/create/json，協定版本為HTTP/1.1。Accept指定客戶端期望接收什麼回應格式，Content-Type指定以什麼格式傳送訊息體。內容長度 - 正文中的字元數。HTTP 請求可以包含許多不同的標頭。更多細節可以在協議規範中找到。

HTTP 回應

伺服器收到請求後，進行處理並向客戶端發送回應：

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>

回應中的起始行包含協定版本（HTTP/1.1）、狀態代碼（200）、狀態描述（OK）。標題表明內容的類型和長度。回應正文包含瀏覽器將繪製到 HTML 頁面中的 HTML 程式碼。

回應狀態代碼

訊息正文和標頭的一切都很清楚，但值得對狀態代碼說幾句話。回應狀態代碼始終為三位數字，代碼的第一位數字表示回應的類別：

1xx - 資訊性的。請求已收到，伺服器準備繼續；
2xx - 成功。請求已被接收、理解並處理；
3xx - 重定向。必須執行以下步驟來處理請求；
4xx - 客戶端錯誤。請求包含錯誤或不符合協議；
5xx - 伺服器錯誤。儘管請求的組成正確，但伺服器無法處理該請求；

程式碼中的第二個和第三個數字詳細說明了答案。例如：

200 OK－請求已收到並成功處理；
201 Created — 請求已收到並成功處理，導致建立新資源或其實例；
301 Moved Permanently - 所要求的資源已永久移動，後續對其的請求必鬚髮生在新地址；
307 暫時重定向 - 資源已暫時移動。目前，您可以使用自動重定向來存取它；
403 Forbidden－請求明確，但需要授權；
404 Not Found－伺服器沒有找到該位址的資源；
501 Not Implemented - 伺服器不支援回應此請求的功能；
505 HTTP Version Not Supported - 伺服器不支援指定版本的 HTTP 協定。

除了回應狀態代碼之外，還會發送狀態描述，以便直觀地了解特定狀態的含義。HTTP協定非常實用：它提供了大量的標頭，使用它們可以在客戶端和伺服器之間建立靈活的通訊。所有請求和回應標頭、請求方法和回應狀態代碼不能在一篇文章中考慮。如果有必要，您可以閱讀官方協議規範，其中描述了所有細微差別。HTTP 協定通常在連接埠 80 上使用，因此當您看到以連接埠 80 結尾的位址時，可以確定應該透過 HTTP 存取它。隨著技術的發展和個人資料在互聯網上的活躍移動，我們不得不考慮如何為客戶端傳輸到伺服器的資訊提供額外的保護。結果就是 HTTPS 協定。

HTTPS 和 HTTP 有什麼差別

HTTPS 在語法上與 HTTP 協定相同，即，它使用相同的起始行和標頭。唯一的區別是額外的加密和預設連接埠 (443)。HTTPS 在 HTTP 和 TCP 之間（即應用層和傳輸層之間）進行加密。如果您忘記了它是什麼，請查看有關 OSI 模型的文章。現代加密標準是 TLS。我們不會太深入地討論這個主題，但請記住，加密發生在訊息到達傳輸層之前。HTTPS 絕對加密除請求發送到的主機和連接埠之外的所有資訊。要將伺服器切換為使用HTTPS協定而不是HTTP，我們不需要更改伺服器程式碼。這個功能在 servlet 容器中啟用，我們將在下面的文章中討論。這就是今天的全部內容。不過，等等。若要偵測 HTTP 要求，請開啟 Google Chrome，按 F12，選擇「網路」標籤。您的瀏覽器發送/接收的所有請求和回應都將顯示在此。第 4 部分：Maven 基礎知識第 5 部分：Servlet。寫一個簡單的 Web 應用程式第 6 部分. Servlet 容器第 7 部分. 介紹 MVC（模型-視圖-控制器）模式第 8 部分. 編寫一個小型 spring-boot 應用程序

留言

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION