HTTP協議用於客戶端和服務器端之間的通信
1.1
請求訪問文本等資源的稱爲客戶端，提供資源響應的稱爲服務器端。
在兩臺計算機之間使用HTTP協議進行通信時，在一條通信線路上必有一個爲客戶端，另一個爲服務器端。
使用HTTP協議能明確區分客戶端和服務器端
1.2通過請求和響應的交換達成通信
HTTP協議規定，請求先從客戶端發出，最後服務器響應該請求並返回。看就是說肯定是先從客戶端開始建立通信的，服務器端在沒有接收到請求之前不會發送請求。
ex：
從客戶端發給HTTP服務器端的請求報文
GET/index.htm HTTP/1.1
Host: hackr.jp
起始行開頭的GET表示請求訪問服務器的類型，稱爲方法（method）。隨後的字符串/index.htm指明瞭請求訪問的資源對象，也叫作請求URI（request—URI）。最後的HTTP/1.1，即HTTP的版本號，用來提示客戶端使用的HTTP協議功能。
綜合來看，這段請求內容意思是：請求訪問某臺HTTP服務器上的/index.htm頁面資源
請求報文是由 請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的
接收到請求的服務器，會將請求內容的處理結果以響應的形式返回。
HTTP/1.1 200 OK
Date: Tue,10 Jul 2012 06:50:15 GMT
Content—Length：362
Content—Type ：text/html
<html>
.......
起始行開頭的HTTP/1.1 表示服務器對應的HTTP版本
緊挨着的200 OK 表示請求結果的狀態碼（status code）和原因短語（reason-phrase）。
下一行顯示創建響應的日期時間，是首部字段（header field）的一個屬性
接着以空格分行，之後的內容稱爲資源實體的主體（entity body）
響應報文基本上由協議版本，狀態碼（表示請求成功或者失敗）、用以解釋狀態碼的原因短語、可選的響應首部字段以及實體主體構成。
2.3 HTTP是不保存狀態的協議
HTTP是一種不保存狀態，即無狀態（stateless）協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在HTTP這個級別，協議對於發送過的請求或響應都不做持久化處理。
使用HTTP協議，每當有新的請求發送時，就會有新的響應產生。協議本身並不保留之前一切的請求或報文信息。這是爲了更快地處理大量事物，確保協議的可伸縮性，而特意把HTTP協議設計如此簡單。
HTTP/1.1是無狀態協議，但是爲了實現期望的保持狀態功能，引入了Cookie技術，這樣就可以管理狀態了。
2.5告知服務器意圖的HTTP方法
GET：獲取資源
GET方法用來請求訪問已被URI識別的資源。制定的資源經服務器端解析後返回響應內容。也就是說，如果請求的是文本資源，那就保持原樣返回；如果是像CGI（Common Gateway Interface，通用網管接口）那樣的程序，則返回執行後的結果。
POST：傳輸實體的主體
POST方法用來傳輸實體的主體
雖然用GET方法也能傳輸實體的主體，但是一般不用GET方法進行傳輸，而是用POST方法。雖說兩者功能很像，
但是POST的主要目的不是獲取響應的主體內容。
PUT：傳輸文件
PUT方法用來傳輸文件。就像FTP協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然後保存到請求的URI制定的位置。
但是鑑於HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳文件，存在安全性問題。因此一般的Web網站不採用該方法。若配合Web應用程序的驗證機制，或者架構設計採用REST(REpresentational State Transfer ,表徵狀態轉移)標準的同類Web網站，可能使用PUT方法
HEAD：獲取報文首部
HEAD方法和GET方法一樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間等
DELETE：刪除文件
與PUT方法相反，也不帶驗證
OPTIONS：詢問支持的方法
OPTIONS方法用來查詢針對請求的URI制定的資源支持的方法
TRACE：追蹤路徑
TRACE方法是讓Web服務器端將之前的請求通信環回給客戶端的方法
發送請求時，在Max-ForWords首部字段中填入數值，每經過一個服務器端就將該數字減1，當數值剛好見到0時，就停止繼續傳輸，最後接收到請求的服務器端則返回狀態碼200 OK的響應
客戶端通過TRACE方法可以查詢發送出去的請求是怎樣被加工修改的。這是因爲，請求要想鏈接到源目標服務器可能會通過代理中轉，TRACE方法就是用來確認連接過程中發生的一系列操作。
但是TRACE方法本來就不常用，還容易引發CST（Cross—Site Tracing,跨站追蹤）攻擊
CONNECT：要求用隧道協議連接代理
CONNECT方法要求在於代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。主要使用SSL（Secure Sockets Layer,安全套接層）和TLS（Transport Layer Security,傳輸層安全）協議把通信內容加密後經網絡隧道傳輸。
格式如下：
CONNECT 代理服務器名：端口號 HTTP版本
2.6使用方法下達命令
向請求URI指定的資源發送請求報文時，採用稱爲方法的命令。
方法的作用在於，可以指定請求的資源按期望產生某種行爲。方法中有GET，POST,HEAD等
2.7持久連接節省通信量
2.7.1持久連接
持久連接（HTTP Persisent Connections，也稱爲HTTP keep-alive或者HTTP connetion resue的方法
持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。
持久連接的好處在於減少了TCP連接 的重複建立和斷開所造成的額外開銷，減輕了服務器的負載。另外，減少開銷的那部分時間，使HTTP請求和相應能更早地結束，這樣Web頁面的顯示速度也就相應提高了
在HTTP/1.1中，所有連接默認都是持久連接，但在1.0不是
2.7.2 管線化
持久連接使得多數請求得以管線化（pipelining）方式發送成爲可能。從前發送請求後需等待並受到響應，才能發送下一個請求。管線化技術出現後，不用等待響應也可以直接發送下一個請求
這樣就能夠同時並行發送多個請求。
2.8 使用Cookie的狀態管理
HTTP是無狀態協議，它不對之前發生過的請求和 響應的狀態進行管理。也就是說，無法根據之前的狀態進行本次的請求處理
假設要求登陸認證的Web頁面本身無法進行狀態的管理（不記錄已登陸的狀態），那麼每次跳轉新頁面是不是要再次登陸，就是要在每次請求報文中附加參數來管理登陸狀態。
不可否認，無狀態協議也有優點，不必保存狀態，可以減少服務器CPU及內存資源的消耗。因爲簡單而廣泛應用。
爲了保留無狀態協議這個特徵又要解決問題，引入Cookie技術。Cookie技術通過子啊請求和 響應報文中寫入Cookie信息來控制客戶端狀態。
Cookie會根據從服務區端發送的響應報文內的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加上Cookie值在發送出去。
服務器端發現客戶端發來的Cookie後，會去檢查究竟是從哪一個客戶端發來的連接請求，然後對比服務器記錄，最後得到之前的狀態信息。
（1）請求報文（沒有Cookie信息的狀態）
GET /reader/ HTTP/1.1
Host:hackr.jp
*首部字段中沒有Cookie相關信息
（2）響應報文（服務器端生成Cookie信息）
HTTP/1.1 200 OK
Date:Thu,12 Jul 2012 07:12:20 GMT
Server :Apache
<Set-Cookie:sid=1342077140226724;path=/;expires=Wed,10-Oct-12 07:12：20 GMT>
Content-Type ：text/plain;charset=UTF-8
（3）請求報文（自動發送保存的Cookie信息）
GET/image/HTTP/1.1
Host:hackr.jp
Cookie:sid=1342077140226724
