第2章 簡單的HTTP協議

HTTP協議規定，先從客戶端開始建立通訊，服務端在沒有接收到請求之前不會發送響應。

請求報文由請求方法、請求URI、協議版本、可選的請求首部欄位和內容實體構成的。

響應報文基本上由協議版本、狀態碼、用以解釋狀態碼的原因短語、可選的響應首部欄位以及實體主體構成。

HTTP 是一種不儲存狀態，即無狀態（stateless）協議。

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

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

告知伺服器意圖的HTTP方法

• GET:獲取資源
• POST: 傳輸實體主體
• PUT: 傳輸檔案
• HEAD: 獲取報文首部，用於確認 URI 的有效性及資源更新的日期時間等
• DELETE: 刪除檔案

• OPTIONS: 詢問支援的方法（Allow: GET, POST, HEAD,
  OPTIONS）

• TRACE: 追蹤路徑，TRACE 方法是讓 Web 伺服器端將之前的請求通訊環回給客戶端的方法。
  傳送請求時，在 Max-Forwards 首部欄位中填入數值，每經過一個伺服器端就將該數字減 1，當數值剛好減到
  0 時，就停止繼續傳輸，最後接收到請求的伺服器端則返回狀態碼 200 OK 的響應。
• CONNECT:要求用隧道協議連線代理，主要使用
  SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊
  內容加 密後經網路隧道傳輸

持久連線節省通訊量

HTTP 協議的初始版本中，每進行一次 HTTP 通訊就要斷開一次 TCP

以當年的通訊情況來說，因為都是些容量很小的文字傳輸，所以即使這樣也沒有多大問題。可隨著 HTTP 的
普及，文件中包含大量圖片的情況多了起來。

比如，使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在傳送請求訪問 HTML 頁面資源的同時，也會請
求該 HTML 頁面裡包含的其他資源。因此，每次的請求都會造成無謂的 TCP 連線建立和斷開，增加通訊量的
開銷。

持久連線

為解決上述 TCP 連線的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連線（HTTP Persistent
Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連線的特點是，只要任意
一端沒有明確提出斷開連線，則保持 TCP 連線狀態。

管線化

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

使用Cookie的狀態管理

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

保留無狀態協議這個特徵的同時又要解決類似的矛盾問題，於是引入了 Cookie 技術。Cookie 技術通過在請
求和響應報文中寫入 Cookie 資訊來控制客戶端的狀態。

Cookie 會根據從伺服器端傳送的響應報文內的一個叫做 Set-Cookie 的首部欄位資訊，通知客戶端儲存
Cookie。當下次客戶端再往該伺服器傳送請求時，客戶端會自動在請求報文中加入 Cookie 值後傳送出去

伺服器端發現客戶端傳送過來的 Cookie 後，會去檢查究竟是從哪一個客戶端發來的連線請求，然後對比服務
器上的記錄，最後得到之前的狀態資訊