介紹 HTTP

HTTP 協議用於客戶端和伺服器端之間的通訊。請求訪問資源的一端被稱為客戶端， 而提供資源響應的一端被稱為伺服器端。

HTTP 是一種不儲存狀態的協議，即無狀態（stateless） 協議，它不對之前發生過的請求和響應的狀態進行管理。也就是說， 無法根據之前的狀態進行本次的請求處理。

HTTP 報文

用於 HTTP 協議互動的資訊被稱為 HTTP 報文。 請求端（客戶端） 的 HTTP 報文叫做請求報文， 響應端（伺服器端） 的 HTTP 報文叫做響應報文。

HTTP 報文字身是由多行（用 CR+LF 作換行符） 資料構成的字串文字。HTTP 報文大致可分為報文首部和報文主體兩塊。報文首部和報文主體由最初出現的空行（CR+LF）來劃分。

• 請求報文的報文首部由請求行、首部欄位和其他組成。請求行由請求方法、 請求 URI、協議版本組成
• 響應報文的報文首部由狀態行、首部欄位和其他組成。狀態行由協議版本、狀態碼、 用以解釋狀態碼的原因短語組成

其他 可能包含 HTTP 的 RFC 裡未定義的首部（Cookie 等）。

HTTP 報文的結構如下圖所示：

請求報文及響應報文的結構如下圖所示：

請求方法

請求方法是請求訪問伺服器的型別。

請求方法的作用是：告知伺服器端，請求的意圖。

• GET ： 獲取資源
• POST： 傳輸資源實體的主體（entity body）
• PUT： 傳輸檔案
• DELETE： 刪除檔案
• HEAD： 獲得報文首部

HEAD 方法和 GET 方法一樣， 只是HEAD 方法的響應不返回報文主體部分。HEAD 方法用於確認 URI 的有效性及資源更新的日期時間等。

狀態碼 & 原因短語

響應報文的狀態碼用來表示客戶端傳送的 HTTP 請求的處理結果、 標記伺服器端的處理是否正常、 通知客戶端出現的錯誤等。

狀態碼以 3 位數字組成。數字中的第一位指定了響應類別，後兩位無分類。響應類別有以下 5 種。

• 1XX：Informational（資訊性狀態碼） 通知客戶端，接收的請求正在處理
• 2XX Success（成功狀態碼） 通知客戶端，請求被正常處理完畢
• 3XX Redirection（重定向狀態碼） 通知客戶端，需要進行附加操作
• 4XX Client Error（客戶端錯誤狀態碼） 通知客戶端，伺服器無法處理請求
• 5XX Server Error（伺服器錯誤狀態碼） 通知客戶端，伺服器處理請求出錯

2XX Success（成功狀態碼） 通知客戶端，請求被正常處理完畢

• 200 OK：該狀態碼代表伺服器接收的請求已成功處理。
• 204 No Content：該狀態碼代表伺服器接收的請求已成功處理， 但在返回的響應報文中不含報文主體部分。

3XX Redirection（重定向狀態碼） 通知客戶端，需要進行附加操作。表明瀏覽器需要執行某些特殊的處理以正確處理請求

• 301 Moved Permanently：永久性重定向。 該狀態碼錶示請求的資源已被分配了新的 URI，希望使用者以後使用新的 URI 訪問，新的 URI 在 Location 響應首部欄位中指定。
• 302 Found：臨時性重定向。 該狀態碼錶示請求的資源已被分配了新的 URI，希望使用者本次使用新的 URI 訪問，新的 URI 在 Location 響應首部欄位中指定。

4XX Client Error（客戶端錯誤狀態碼） 通知客戶端，伺服器無法處理請求

• 400 Bad Request：該狀態碼錶示請求報文中存在語法錯誤。 當錯誤發生時， 需修改請求的內容後再次傳送請求。
• 403 Forbidden：該狀態碼錶明對請求資源的訪問被伺服器拒絕了。 伺服器端沒有必要給出拒絕的詳細理由， 但如果想作說明的話， 可以在報文主體部分
  對原因進行描述， 這樣就能讓使用者看到了。
• 404 Not Found：該狀態碼錶明伺服器上無法找到請求的資源。
• 405 Method Not Allowed：該狀態碼錶明伺服器接收到了不支援的 HTTP 方法。當響應返回該狀態碼，同時響應也會返回 Allow 實體首部欄位來通知客戶端，伺服器端能夠支援 Request-URI 指定資源的所有 HTTP 方法。

5XX Server Error（伺服器錯誤狀態碼） 伺服器處理請求出錯

• 500 Internal Server Error：該狀態碼錶明伺服器端在執行請求時發生了錯誤。
• 502 Bad Gateway：通常是伺服器作為閘道器或代理時返回的錯誤碼，表示伺服器自身工作正常，訪問後端伺服器發生了錯誤。
• 503 Service Unavailable：該狀態碼錶明伺服器暫時處於超負載或正在進行停機維護， 現在無法處理請求。 如果事先得知解除以上狀況需要的時間， 最好寫入 RetryAfter 首部欄位再返回給客戶端。

Cookie 技術

HTTP 是一種不儲存狀態的協議，即無狀態（stateless） 協議，它不對之前發生過的請求和響應的狀態進行管理。也就是說， 無法根據之前的狀態進行本次的請求處理。如果我們要求必須登入認證才能訪問資源，那麼每次跳轉新頁面不是要再次登入，就是需要每次請求時在請求報文中附加引數來管理登入狀態。於是引入
了 Cookie 技術。

Cookie 的工作機制是使用者識別及狀態管理。 Web 網站為了管理使用者的狀態會通過 Web 瀏覽器， 把一些資料臨時寫入使用者的計算機內。 接著當用戶訪問該 Web 網站時， 可通過通訊方式取回之前發放的 Cookie。Cookie 技術通過在請求和響應報文中寫入 Cookie 資訊來管理客戶端的狀態。

• 客戶端：客戶端（Web 瀏覽器）會根據伺服器端傳送的響應報文內的 Set-Cookie 響應首部欄位，儲存 Cookie。當下次客戶端再往該伺服器傳送請求時， 客戶端會自動在請求報文中加入 Cookie 首部欄位後再將請求報文傳送出去。
• 伺服器端：
  • 伺服器端發現客戶端傳送過來的 Cookie 後， 會去檢查究竟是從哪一個客戶端發來的連線請求， 然後對比伺服器上的記錄， 最後得到之前的狀態資訊。
  • 如果伺服器端發現客戶端傳送過來的請求報文中沒有 Cookie 首部欄位，那麼伺服器端會生成 Cookie 資訊，在響應報文中加入 Set-Cookie 首部欄位後，伺服器端將響應報文傳送給客戶端。

參考資料

《圖解HTTP》