轉載自個人博客0pt1mus
HTTP協議用於客戶端和服務端之間的通信
HTTP協議和TCP/IP協議族內的其他衆多協議相同，用於客戶端和服務器之間的通信。
請求訪問文本或圖像等資源的一端稱爲客戶端，而提供資源響應的一端稱爲服務器端。
有時候，按實際情況，兩臺計算機作爲客戶端和服務器端的角色有可能會互換。但就僅從一條通信線路來說，服務器端和客戶端的角色是確定的，而用HTTP協議能夠明確區分那端是客戶端，哪端是服務器端。
通過請求和相應的交換達成通信
請求報文是由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的。
響應報文基本上由協議版本、狀態碼（表示請求成功或失敗的數字代碼）、用以解釋狀態碼的原因短語、可選的響應首部字段以及實體主體構成。
HTTP是不保存狀態的協議（對用戶的登陸狀態不進行保存）
HTTP是一種不保存狀態，即無狀態（stateless）協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在HTTP這個級別，協議對於發送過的請求或響應都不做持久化處理。
使用HTTP協議，每當有新的請求發送時，就會有對應的新響應產生。協議本身並不保留之前一切的請求或響應報文的信息。這是爲了更快地處理大量事務，確保協議的可伸縮性，而特意把HTTP協議設計成如此簡單的。
HTTP/1.1雖然是無狀態協議，但爲了實現期望的保持狀態功能，於是引入了Cookie技術。有了Cookie再用HTTP協議通信，就可以管理狀態了。
請求URL定位資源
在WWW上，每一信息資源都有統一的且在網上唯一的地址，該地址就叫URL（Uniform Resource Locator,統一資源定位符），它是WWW的統一資源定位標誌，就是指網絡地址。
URL由三部分組成：資源類型、存放資源的主機域名、資源文件名。也可認爲由四部分組成：協議、主機、端口、路徑。
protocal://hostname[:port]/path/[;parameters][?query]#fragment
注：帶方括號[]的爲可選項，默認的port爲80
告知服務器意圖的HTTP方法
GET：獲取資源
GET方法用來請求訪問已被URI識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說，如果請求的資源是文本，那就保持原樣返回，如果是向CGI（Common Gateway Interface，通用網關接口）那樣的程序，則返回經過執行後的輸出結果。
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相反的方法。DELETE方法按請求URI刪除指定的資源。
但是，HTTP/1.1的DELETE方法本身和PUT方法一樣不帶驗證機制，所以一般的Web網站也不使用DELETE方法，當配合Web應用程序的驗證機制，或遵守REST標準時還是有可能開放使用的。
OPTIONS：詢問支持的方法
OPTIONS方法用來查詢針對URI指定的資源支持的方法。
TRACE：追蹤路徑
TRACE方法是讓Web服務器端將之前的請求通信環回給客戶端的方法。
CONNECT：要求用隧道協議連接代理
CONNECT方法要求在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。主要使用SSL（Secure Sockets Layer，安全套接層）和TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密後經網絡隧道傳輸。
重要的是GET方法和POST方法的區別
持久連接節省通信量
HTTP通信一次，進行一次TCP的連接與斷開，若HTTP傳輸的信息很多，每次都要進行TCP連接與斷開，造成了無謂的通信量開銷。
持久連接
爲解決上述的TCP連接問題，HTTP/1.1和一部分的HTTP/1.0相處了持久連接（HTTP Persistent Connections，也稱爲HTTP keep-alive或HTTP connection reuse）的方法。持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。
持久連接的好處在於減少了TCP連接的重複建立和斷開造成的額外開銷，減輕了服務器端的負載。另外，減少開銷的那部分時間，使HTTP請求和響應能夠更早地結束，這樣Web頁面的顯示速度也就相應提高了。
在HTTP/1.1中，所有的連接默認都是持久連接，但在HTTP/1.0內並未標準化。雖然有一部分服務器通過非標準的手段實現了持久連接，但服務器端不一定能夠支持持久連接。毫無疑問，除了服務器端，客戶端也需要支持持久連接。
管線化
持久連接使得多數請求以管線化（pipelining）方式發送稱爲可能。從前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。這樣就能夠做到同時並行發送多個請求，而不需要一個接一個地等待響應了。
使用Cookie的狀態管理
HTTP是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理。也就是說，無法根據之前的狀態進行本次的請求處理。
爲了保留無狀態協議這個特徵的同事又要解決類似的矛盾問題，於是引入了Cookie技術。Cookie技術通過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
Cookie會根據從服務器端發送的響應報文內的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。
服務器端發現客戶端發送過來的Cookie後，會去檢查究竟是從哪一個客戶端發來的連接請求，然後對比服務器上的記錄，最後得到之前的狀態信息。