圖解HTTP協定學習02

通過請求和響應的交換達成通信

請求封包

下面則是從用戶端發送給某個 HTTP 伺服器端的請求封包中的内容。

起始行開頭的GET表示請求通路伺服器的類型，稱為方法（method）。随後的字元串 /index.htm 指明了請求通路的資源對象，

也叫做請求 URI（request-URI）。最後的 HTTP/1.1，即 HTTP 的版本号，用來提示用戶端使用的 HTTP 協定功能。綜合來看，這段請求内容的意思是：請求通路某台 HTTP 伺服器上的/index.htm 頁面資源。

請求封包由請求方法、請求URI、協定版本、可選請求首部字段和内容實體構成的

響應封包

在起始行開頭的 HTTP/1.1 表示伺服器對應的 HTTP 版本。緊挨着的 200 OK 表示請求的處理結果的狀态碼（status code）和原因

短語（reason-phrase）。下一行顯示了建立響應的日期時間，是首部字段（header field）内的一個屬性。接着以一空行分隔，之後的内容稱為資源實體的主體（entity body）

響應封包基本上由協定版本、狀态碼(表示請求成功或失敗的數字代碼)、用以解釋狀态碼的短語、可選的響應首部字段以及實體主體構成

HTTP是不儲存狀态的協定

使用 HTTP 協定，每當有新的請求發送時，就會有對應的新響應産生。協定本身并不保留之前一切的請求或響應封包的資訊。這是為了更快地處理大量事務，確定協定的可伸縮性，而特意把 HTTP 協定設計成如此簡單的。可是随着web的發展，因無狀态而導緻業務處理變得棘手了。比如登入購物網站，即使跳轉到該站的其他頁面，也需要能夠保持登入狀态。針對這個執行個體，網站為了能夠掌握出是誰發送的請求，需要儲存使用者的狀态；引入了Cookie技術。

請求URI定位資源

告知伺服器意圖的HTTP方法

GET：擷取資源

POST：傳輸實體主體

PUT：傳輸檔案

HEAD：獲得封包首部，但是傳回封包主體

DELETE：删除檔案

OPTIONS：詢問支援的方法

TRACE:追蹤路徑

TRACE 方法是讓 Web 伺服器端将之前的請求通信環回給用戶端的方法。發送請求時，在 Max-Forwards 首部字段中填入數值，每經過一個伺服器端就将該數字減 1，當數值剛好減到 0 時，就停止繼續傳輸，最後接收到請求的伺服器端則傳回狀态碼 200 OK 的響應。

CONNECT:要求用隧道協定連接配接代理

CONNECT 方法要求在與代理伺服器通信時建立隧道，實作用隧道協定進行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協定把通信内容加 密後經網絡隧道傳輸。

持久連接配接節省通信量

HTTP協定的初始版本中，沒進行一次HTTP通信就要斷開一次TCP連接配接

以當年的通信情況來看，因為都是些容量很小的文本傳輸，是以即使這樣沒有多大問題。比如，使用浏覽器浏覽一個包含多張圖檔的 HTML頁面時，在發送請求通路 HTML頁面資源的同時，也會請求該 HTML頁面裡包含的其他資源。是以，每次的請求都會造成無謂的 TCP 連接配接建立和斷開，增加通信量的開銷。

持久連接配接

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

這樣做減少了TCP連接配接的重複建立和斷開所造成的的額外開銷，減輕了伺服器端的負載。另外，減少開銷的那部分時間，使HTTP請求和響應能夠更早的結束，這樣Web頁面的顯示速度也就相應提高了。在 HTTP/11 中，所有的連接配接預設都是持久連接配接。

管線化

持久連接配接使得多數請求以管線化（pipelining）方式發送成為可能。從前發送請求後需等待并收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。這樣就能夠做到同時并行發送多個請求，而不需要一個接一個地等待響應了。

使用Cookie的狀态管理

HTTP 是無狀态協定，它不對之前發生過的請求和響應的狀态進行管理也就是說無法根據之前的狀态進行本次的請求處理。不可否認，無狀态協定當然也有它的優點。由于不必儲存狀态，自然可減少伺服器的 CPU 及記憶體資源的消耗。

保留無狀态協定這個特征的同時又要解決類似的沖突問題，于是引入了 Cookie 技術。Cookie 技術通過在請求和響應封包中寫入 Cookie 資訊來控制用戶端的狀态。

Cookie 會根據從伺服器端發送的響應封包内的一個叫做 Set-Cookie 的首部字段資訊，通知用戶端儲存 Cookie。當下次用戶端再往該伺服器發送請求時，用戶端會自動在請求封包中加入 Cookie 值後發送出去。

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

流程如下

1請求封包（沒有 Cookie 資訊的狀态）

2.響應封包（服務端生成Cookie資訊）

3.請求封包（自動發送儲存的Cookie資訊）