簡單HTTP協議
[HTTP協議用於客戶端和服務器端之間的通信]
請求訪問文本或圖像等資源的一段稱爲客戶端。
提供資源響應的一端稱爲服務器端。
兩臺計算機之間使用HTTP協議，在一條線路上，必然有一端是客戶端，一段是服務器端
客戶端和服務器端可能互換。使用HTTP協議可以明確區分客戶端和服務器端。
[通過請求和響應的交換達成通信]
HTTP協議規定，請求從客戶端發送，最後服務器端響應請求並返回。
發送請求：
GET /index.htm HTTP/1.1
Host: hackr.jp假設這是從客戶端發送給某個個HTTP服務器的請求報文的內容。
起始GET表示請求訪問服務器的類型，稱爲方法(method)。隨後的字符串/index.htm指明瞭請求訪問的資源對象，也叫請求URI(request-URI)。最後的HTTP/1.1表示HTTP的版本號，用來提示客戶端使用的HTTP協議功能。
請求報文是由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成.
服務器將請求內容的處理結果以響應的方式返回。
200 OK表示的是狀態碼(status code)和原因短語(reason-phrase)。下一行顯示了創建響應的日期時間，是首部字段(header field)內的一個屬性.
接着以一個空行分隔，之後的內容稱爲資源實體的主體(entitybody).
響應報文基本上由協議版本、狀態碼(表示請求成功/失敗的數字代碼)、用以解釋狀態碼的原因短語、可選的響應首部字段以及實體主體構成。
[HTTP是不保存狀態的協議]
HTTP是一種不保存狀態，即無狀態(stateless)協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。HTTP這個級別，協議對於發送過的請求或響應都不作持久化處理。
使用HTTP協議，每當有新的請求發送，就有對應的新響應產生。協議本身並不保留之前一切的請求或響應報文的信息。爲了更快的處理事務，確保協議的可伸縮性。
HTTP/1.1雖然是無狀態協議，但爲了實現期望的保持狀態功能，引入了Cookie技術，有了Cookie再用HTTP協議通信，就可以管理狀態。
[請求URI定位資源]
當客戶端請求資源發送請求時，URI需要將作爲請求報文中的請求URI包含在內。
除此之外，如果不是訪問特定的資源而是對服務器本身發起請求，可以用*來代替請求URI。如查詢HTTP服務器支持的HTTP方法種類。
OPTIONS * HTTP/1.1[告知服務器意圖的HTTP方法
HTTP/1.1使用方法
[GET:獲取資源]
GET方法用來請求訪問已被URI標識的資源。指定的資源經服務器端解析後返回響應內容。如富請求的資源是文本，就返回文本，如果是CGI(Common Gateway Interface,通用網關接口)那樣的程序，則返回經過執行後的輸出結果。
Instance
[POST:傳輸實體主體]
一般用POST來傳輸實體主體而不是GET。POST的主要目的不是獲取響應的主體內容。
[PUT:傳輸文件]
PUT方法用來傳輸文件，像FTP協議的文件上傳一樣，要求在請求報文的主題包含文件內容，然後保存到請求URI指定的位置。
HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳文件，存在安全性問題，Web網站一般不實用該方法。若配合Web應用程序的驗證機制，或架構機制採用REST(REpresentational State Transfer,表徵狀態轉移)標準的同類Web網站，可能會開放使用PUT方法。
[HEAD:獲取報文首部]
HEAD方法和GET方法一樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間。
[DELETE:刪除文件]
DELETE方法用於來刪除文件，與PUT相反。DELETE方法按請求URI來刪除指定的資源。
HTTP/1.1的DELETE方法本身和PUT方法一樣不帶驗證機制。當配合Web應用程序的驗證機制，或遵循REST標準還是可能開放使用。
[OPTIONS:詢問支持的方法]
OPTIONS方法用來查詢針對請求URI指定的資源支持的方法(就比如上面所提到的)。
[TRACE:追蹤路徑]
TRACE方法是讓Web服務器端將之前的請求通信環回給客戶端的方法。
發送請求時，在Max-Forwards首部字段中填入數值，每經過一個服務器端就將該數字減1，當數值剛好減到0時，就停止繼續傳輸。最後接收到請求的服務器端則返回狀態碼200OK的響應。
客戶端通過TRACE的方法可以查詢發送出去的請求是怎樣被加工/修改/篡改的。請求想要連接到源目標服務器可能會通過代理中轉。TRACE就是用來確認連接過程中發生的一系列操作。
TRACE方法容易引發XST(Cross-Site Tracing, 跨站追蹤)攻擊。
[CONNECT:要求用隧道協議連接代理]
CONNECT方法要求在與代理服務器通信。主要使用SSL(Secure Sockets Layer, 安全套接層)和TLS(Transport Layer Security, 傳輸層安全)協議把通信內容加密經網絡隧道傳輸。
[使用方法下達命令]
向請求URI指定的資源發送請求報文時，採用稱爲方法的命令。
方法的作用在於，可以指定請求的資源按期望產生行爲。
| 方法 | 說明 | 支持的HTTP協議 |
|---|---|---|
| GET | 獲取資源 | 1.0、1.1 |
| POST | 傳輸實體主體 | 1.0、1.1 |
| PUT | 傳輸文件 | 1.0、1.1 |
| HEAD | 獲得報文首部 | 1.0、1.1 |
| DELETE | 刪除文件 | 1.0、1.1 |
| OPTIONS | 詢問支持的方法 | 1.1 |
| TRACE | 追蹤路徑 | 1.1 |
| CONNECT | 要求用隧道協議連接代理 | 1.1 |
| LINK | 建立和資源之間的聯繫 | 1.0 |
| UNLINE | 斷開連接關係 | 1.0 |
[持久連接節省通信量]
HTTP協議的初始版本匯中，每次HTTP通信就要斷開一次TCP連接。
[持久連接]
持久連接(HTTP Persistent Connections, 稱爲HTTP keep-alive或HTTP connection reuse)的方法。持久連接的特點：只要任意一段沒有明確提出斷開鏈接，則保持TCP連接狀態。
好處：減少了TCP連接的重複建立和斷開所造成的額外開銷，減輕了服務器端的負載。相應的提高了速度。
在HTTP/1.1中，所有的連接默認都是持久連接。HTTP/1.0未標準化、
[管線化]
持久連接使多數請求以管線化(pipelining)方式發送成爲可能。從前發送請求後等待並收到響應，才能發送下一個請求。管線化技術不用等待直接發送下一個請求。
請求數越多，管線化效果越明顯。
[使用Cookie的狀態管理]
HTTP是無狀態協議，他不對之前發生的請求和響應的狀態管理，無法根據之前的狀態進行本次的請求處理。
由於不保存狀態，可以減少服務器的CPU及內存資源的消耗。
Cookie技術通過在請求和響應報文中寫入Cookie的首部字段信息，通知客戶端保存Cookie,當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送。
服務器端發現客戶端發送來的Cookie後，檢查來源，然後對比服務器上的記錄，最後得到之前的狀態信息。
例如：
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724