簡單的http 協議

• 簡單實例：

• 客戶端發送給服務器端的報文內容
• 起始行開頭的GET表示請求訪問服務器的類型，稱爲方法（method）。
• 隨後的字符串 /index.htm 指明瞭請求訪問的資源對象，也叫作請求 URI（request-URI）。
• 最後的 HTTP/1.1，即 HTTP 的版本號，用來提示客戶端使用的 HTTP 協議功能。

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

• 響應
• 在起始行開頭的 HTTP/1.1 表示服務器對應的 HTTP 版本。
• 緊挨着的 200 OK 表示請求的處理結果的狀態碼（status code）和緣由短語（reason-phrase）。
• 下一行顯示了建立響應的日期時間，是首部字段（header field）內的一個屬性。
• 接着以一空行分隔，以後的內容稱爲資源實體的主體（entity body）。

響應報文基本上由協議版本、狀態碼（表示請求成功或失敗的數字代碼）、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主
體構成。

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

• HTTP 協議自身不對請求和響應之間的通訊狀態進行保存。
• 也就是說在 HTTP 這個級別，協議對於發送過的請求或響應都不作持久化處理。
• 這是爲了更快地處理大量事務，確保協議的可伸縮性，而特地把 HTTP 協議設計成如此簡單的。

HTTP/1.1 雖然是無狀態協議，但爲了實現指望的保持狀態功能，因而引入了 Cookie 技術。

• 有了 Cookie 再用 HTTP 協議通訊，就能夠管理狀態了。

HTTP 協議使用 URI 定位互聯網上的資源。

• 正是由於 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。

• 若是不是訪問特定資源而是對服務器自己發起請求，能夠用一個 * 來代替請求 URI。
• 下面這個例子是查詢 HTTP 服務器端支持的 HTTP 方法種類。

告知服務器意圖的 HTTP 方法

• GET ：獲取資源
  • 指定的資源經服務器端解析後返回響應內容。
  • 若是請求的資源是文本，那就保持原樣返回；
  • 若是是像 CGI（Common Gateway Interface，通用網關接口）那樣的程序，則返回通過執行後的輸出結果。

POST：傳輸實體主體

• 雖然用 GET 方法也能夠傳輸實體的主體，但通常不用 GET 方法進行傳輸，而是用 POST 方法。
• POST 的主要目的並非獲取響應的主體內容。

PUT：傳輸文件

• 鑑於 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人均可以上傳文件 , 存在安全性問題，所以通常的 Web 網站不使用該方法。
• 當配合 Web 應用程序的驗證機制，或遵照 REST 標準時仍是有可能會開放使用的。

HEAD：得到報文首部

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

DELETE：刪除文件

• HTTP/1.1 的 DELETE 方法自己和 PUT 方法同樣不帶驗證機制，因此通常的 Web 網站也不使用 DELETE 方法。
• 當配合 Web 應用程序的驗證機制，或遵照 REST 標準時仍是有可能會開放使用的。

OPTIONS：詢問支持的方法

TRACE：追蹤路徑

• TRACE 方法是讓 Web 服務器端將以前的請求通訊環回給客戶端的方法。
• 客戶端經過 TRACE 方法能夠查詢發送出去的請求是怎樣被加工修改/ 篡改的。
  • 這是由於，請求想要鏈接到源目標服務器可能會經過代理中轉，TRACE 方法就是用來確認鏈接過程當中發生的一系列操做。
• TRACE 方法原本就不怎麼經常使用，再加上它容易引起XST（Cross-Site Tracing，跨站追蹤）攻擊，一般就更不會用到了。

   

CONNECT：要求用隧道協議鏈接代理

• CONNECT 方法要求在與代理服務器通訊時創建隧道，實現用隧道協議進行 TCP 通訊。
• 主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加 密後經網絡隧道傳輸。

• 向請求 URI 指定的資源發送請求報文時，採用稱爲方法的命令。

持久鏈接節省通訊量

• 三次握手創建鏈接，四次握手斷開

爲解決上述 TCP 鏈接的問題，

• HTTP/1.1 和一部分的 HTTP/1.0 想出了持久鏈接（HTTP Persistent Connections，也稱爲 HTTP keep-alive 或HTTP connection reuse）的方法。
• 持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。
• 持久鏈接旨在創建 1 次 TCP 鏈接後進行屢次請求和響應的交互

• 在 HTTP/1.1 中，全部的鏈接默認都是持久鏈接，但在 HTTP/1.0 內並未標準化。
• 除了服務器端，客戶端也須要支持持久鏈接。

持久鏈接使得多數請求以管線化（pipelining）方式發送成爲可能。

• 從前發送請求後需等待並收到響應，才能發送下一個請求。
• 管線化技術出現後，不用等待響應亦可直接發送下一個請求。

• 與挨個鏈接相比，用持久鏈接可讓請求更快結束。
• 而管線化技術則比持久鏈接還要快。請求數越多，時間差就越明顯。

使用 Cookie 的狀態管理

• 保留無狀態協議這個特徵的同時又要解決相似的矛盾問題，因而引入了 Cookie 技術。
• Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。
• 當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。