CodeGym /Java Blog /Toto sisi /第 3 部分 HTTP/HTTPS
John Squirrels
等級 41
San Francisco

第 3 部分 HTTP/HTTPS

在 Toto sisi 群組發布
本資料是“企業發展概論”系列的一部分。往期文章: 第 3 部分。HTTP/HTTPS - 1你好!今天我們將學習 HTTP 和 HTTPS 協議。但首先,讓我們澄清一點:我們討論的是在 OSI 模型的應用層通過網絡發送數據的協議。您可能還記得我們在之前的一篇文章中了解了 OSI 模型。如果你不記得了,就在這裡

什麼是數據通信協議?

這就是我們所說的約定規則集,允許不同服務的開發人員以其他人可以理解的格式發送信息。例如,您可以使用 Google Chrome 瀏覽器從 Facebook 和 Twitter 獲取信息,因為開發人員使用標準 HTTP 協議發送信息,允許您的瀏覽器處理信息。統一規則對於開發服務器部分的人來說非常方便:有很多庫可以為您轉換信息並使用適當的協議發送它。HTTP 最初被認為是一種用於發送 HTML 頁面的協議。很長一段時間都是這樣使用的,但是現在程序員經常用它來發送字符串和媒體文件。總的來說,這個協議被普遍接受,通用性強,而且真的很容易上手。現在我們將研究如何使用它。

HTTP的結構

我們應該立即註意到 HTTP 協議只包含文本。我們最感興趣的是這篇文章的結構。每條消息由三部分組成:
  1. 起始行——這定義了一些內務處理數據。
  2. 標頭——這些描述了消息參數。
  3. 正文——這是消息的內容。正文必須用空行與標題分開。
HTTP 協議用於向服務器發送請求並從服務器接收響應。請求和響應的參數略有不同。

下面是一個簡單的 HTTP 請求:


GET / HTTP/1.1
Host: codegym.cc
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)
起始行表示:
  • GET — 請求的方法
  • / — 請求的路徑
  • HTTP/1.1——協議版本
然後是標題:
  • 主機- 請求發送到的主機
  • User-Agent——發送請求的客戶端
郵件正文丟失。在 HTTP 請求中,只需要起始行和“主機”標頭。現在,讓我們一步一步地查看所有內容。HTTP 請求必須包含一些方法。其中有九個:GET、POST、PUT、OPTIONS、HEAD、PATCH、DELETE、TRACE、CONNECT。最常見的是 GET 和 POST。這兩種方法一開始就足夠了。 GET — 此方法從服務器請求內容。因此,使用 GET 方法的請求沒有消息體。但如果需要,您可以通過路徑(在起始行中)按以下格式傳遞參數:

https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2
其中 codegym.cc是主機, /send是請求的路徑,而 ? 是一個分隔符,表示後面跟著查詢參數。最後,鍵值對(“鍵=值”)被列出,由一個符號分隔。 POST — 此方法在服務器上發布信息。POST 請求可以發送各種信息:作為“key=value”對的參數、JSON、HTML 代碼,甚至文件。所有信息都在郵件正文中發送。例如:

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

{
  "Id": 12345,
  "User": "John"
}
請求發送到codegym.cc/user/create/json,協議版本為HTTP/1.1。“Accept”表示客戶端希望收到的響應格式。“Content-Type”表示請求中發送的消息體的格式。“Content-Length”是正文中的字符數。一個 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 已創建——請求已被接收並成功處理,導致新資源或實例的創建。
  • 301 永久移動 - 請求的資源已永久移動。對它的後續請求應該使用新地址。
  • 307 Temporary Redirect — 資源已臨時移動。目前,可以使用自動轉發訪問它。
  • 403 Forbidden——理解請求,但需要授權。
  • 404 Not Found——服務器沒有在這個地址找到資源。
  • 501 Not Implemented——服務器不支持響應請求所需的功能。
  • 505 HTTP Version Not Supported — 服務器不支持指定版本的 HTTP 協議。
除了響應狀態代碼之外,還會發送狀態描述。這有助於闡明每個特定狀態的含義。 HTTP 協議非常實用:它提供了大量的標頭,您可以使用這些標頭非常靈活地安排客戶端和服務器之間的通信。對所有請求和響應標頭、請求方法和響應狀態代碼進行全面考慮對於一篇文章來說太多了。如果需要,可以閱讀協議的官方規範,它描述了所有的細微差別。習慣上在80端口上使用HTTP協議,所以當你看到一個以80端口結尾的URL時,你可以確信你需要使用HTTP訪問它。隨著技術的發展和個人數據開始通過 Internet 發送,有必要考慮如何為客戶端發送到服務器的信息提供額外的保護。這種想法的結果就是 HTTPS 協議。

HTTPS 和 HTTP 的區別

在語法方面,HTTPS 與 HTTP 協議相同。也就是說,它使用相同的起始行和標題。唯一的區別是額外的加密和默認端口 (443)。HTTPS 加密介於 HTTP 和 TCP 之間,即介於應用層和傳輸層之間。如果您忘記了那是什麼意思,請查看有關 OSI 模型的文章。今天的加密標準是 TLS。我們不會過多地討論這個話題,但請記住,加密發生在信息到達傳輸層之前. 在 HTTPS 中,除了發送請求的主機和端口之外,所有信息絕對是加密的。將服務器切換為使用 HTTPS 協議而不是 HTTP 不需要更改服務器代碼。此功能在 servlet 容器中啟用,我們將在後續文章中討論。這就是今天的全部內容。其實,等一下。要處理一些 HTTP 請求,請打開 Google Chrome,按 F12,然後選擇“網絡”選項卡。您的瀏覽器發送/接收的所有請求和響應都將顯示在這裡。 第 4 部分。Maven 的基礎知識 第 5 部分。Servlet 和 Java Servlet API。編寫一個簡單的 Web 應用程序 第 6 部分。Servlet 容器 第 7 部分。介紹 MVC(模型-視圖-控制器)模式
留言
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION