1.HTTP簡介 http是用於客戶端與服務端之間的通信 實際情況中客戶端與服務端角色有可能互換，但從一條通信線路來說伺服器端和客戶端角色是確定的，http協議知道那個是服務端那個是客戶端呢。 http協議規定，請求從客戶端發出，服務端響應請求並返回。服務端沒有接受請求時是不會發送響應。 客戶端發送 ...
1.HTTP簡介
http是用於客戶端與服務端之間的通信
實際情況中客戶端與服務端角色有可能互換，但從一條通信線路來說伺服器端和客戶端角色是確定的，http協議知道那個是服務端那個是客戶端呢。
http協議規定，請求從客戶端發出，服務端響應請求並返回。服務端沒有接受請求時是不會發送響應。
客戶端發送給伺服器端的請求報文中內容
GET:請求類型，稱之為方法（method);
/index.htm:請求的資源對象，也叫作URI（request-URI）;
HTTP/1.1:http的版本號
伺服器端相應內容如下
2.HTTP是無狀態協議
http協議不保存請求和響應信息
每當有新的請求發送時，就會有對應的新響應產生，協議本身不保留之前一切的請求或響應報文的信息，這是為了更快的處理大量事務，確保協議的可伸縮性，而特意把HTTP協議涉及成如此簡單的。
雖然HTTP協議是無狀態協議，但是為了實現期望的保持狀態功能，於是引入了Cookie技術，有了Cookie就可以管理狀態了。
3.HTTP協議的方法
GET:獲取資源
GET方法用來請求訪問已被URI識別的資源，指定的資源經伺服器端解析後返回相應內容。
POST:傳輸實體主體
post方法用來傳輸實體的主體，雖然get方法也可以傳輸實體的主體，但是一般情況不使用get方法傳輸，而是使用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方法相反，用於請求刪除指定文件，情況與put方法一樣。
OPTIONS:詢問支持的方法
options方法用來查詢針對請求URI的資源支持的方法。
TRACE:追蹤路徑
trace方法是讓web伺服器端將之前的請求通信環回給客戶端的方法。發送請求時，在Max-Forwards首部欄位中填入數值，沒經過一個伺服器端就將該數字減1，當數值剛好減到0時，就停止繼續傳輸，最後接收到請求的伺服器端則放回狀態碼200OK的響應。
客戶端通過trace方法可以查詢發出的請求時怎樣被加工修改/竄改的，但是它容易引發XST攻擊，通常不會用到。
CONNECT:要求用隧道協議連接代理
它要求在於代理伺服器通信是建立隧道，實現用隧道協議進行TCP通信，主要使用SSL（安全套接字）和TLS（傳輸層安全）協議把通信內容加密後經網路隧道傳輸
connect方法格式：
3.持久連接節省通信量
之前通信情況都是傳輸較小的文本，所以問題不大，隨著HTTP的普及，文檔中包含大量圖片的情況多了起來，比如一個瀏覽器瀏覽一個包含多張圖片的頁面時，也會請求html頁面中包含的其他資源，每次請求都會造成無謂的TCP連接的建立和斷開，增加通信量的開銷。
為瞭解決上述TCP連接的問題，HTTP/1.1提出了持久連接的方法。持久連接的特點就是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。
管線化
持久連接是的多數請求以管線化方式發送成為可能。之前發送請求後需等待並受到響應才能發送下一個請求，管線化技術出現後不用等待響應可直接發送下一個請求。這樣就可以做到同時並行發送多個請求，而不需要一個接一個的等待響應。
4.Cookie狀態管理
Cookie技術通過請求和響應報文中寫入Cookie信息來控制客戶端的狀態
Cookie通過響應報文中的Set-Cookie的首部欄位信息，通知客戶端保存Cookie，當下次客戶端再次發往伺服器請求時，客戶端會自動在請求報文中加入cookie值。伺服器端發現客戶端發送來得Cookie後，檢查從哪個客戶端發來的連接請求，然後對比伺服器的記錄，最後得到狀態信息。
