HTTP協議規定:請求從客戶端觸發,最後服務端響應請求並返回。
1. 客戶端請求
請求報文 = 請求方法(GET,POST,PUT,DELETE..) + 請求URI(例如/index.html) + 協議版本(HTTP/1.1) + 可選的請求首部欄位 + 內容例項
複製程式碼
2. 服務端響應
響應報文 = 協議版本(HTTP/1.1) + 狀態碼 + 解釋性狀態碼的原因短語(ok) + 可選的響應首部欄位 + 實體主體構成
複製程式碼
3. HTTP 是無狀態協議(stateless)
HTTP協議不
對請求和響應之間的通訊狀態進行儲存: 為了更快地處理大量事務,確保協議的可伸縮性。
4. HTTP Method
GET: 獲取資源,指定的資源經伺服器端解析後返回響應內容。
POST: 用來傳輸實體的主體(告訴伺服器資訊)。雖然GET也可以傳輸實體,但一般不用GET而用POST.
PUT: 用於傳輸檔案,像FTP協議的檔案上傳一樣,在請求報文的主體中包含檔案內容,然後儲存到請求的URI指定位置。HTTP/1.1的PUT不帶驗證機制,存在安全問題,因此一般不採用。在REST(Representational State Transfer,表徵狀態轉移)
中可能開放PUT方法。
HEAD: 獲取報文首部。用於確認URI的有效性及資源更新的日期時間等。(同GET一樣,只是不返回報文主體部分)
DELETE: 刪除檔案。刪除請求的URI指定的資源。HTTP/1.1中DELETE也不帶驗證機制,因此一般Web網站不使用。在REST
中可能開放DELETE方法。
OPTIONS: 查詢針對請求URI指定的資源支援的方法。
TRACE: 追蹤路徑,讓Web伺服器端將之前
的請求通訊環回
給客戶端的方法。在傳送請求時,在Max-Forwards
首部欄位中填寫數值,經過一個伺服器-1
,當數值剛好到0
時停止傳輸,最後接收到請求的伺服器返回狀態碼200
。容易引發XST(Cross-Site Tracing,跨站追蹤)
攻擊。
CONNECT: 要求在與代理伺服器通訊時建立隧道,實現用隧道協議進行TCP通訊。主要使用SSL(Secure Sockets Layer,安全套接字)
和TLS(TransportLayer Security, 傳輸層安全)
協議把通訊內容加密後在網路隧道中傳輸。
5. 持久連結節省通訊量
5.1 keep-alive
HTTP是無狀態的,不會保持連線狀態。當一個網站請求量比較大的時候,每次請求都會造成TCP連線建立和斷開,增加通訊量的開銷。HTTP/1.1和部分HTTP/1.0中出現了keep-alive(HTTP Persistent Connection)
,只要任意一段沒有明確提出斷開連線,則保持TCP連線狀態。
在 HTTP/1.1 中, 所有的連線預設都是持久連線。
5.2 管線化(pipelining)
持久連線讓多數請求以管道化的方式傳送成為可能。每一個請求不再需要等待響應結束後再發起另外一個請求,可以並行
傳送多個請求。
6. 使用Cookie進行狀態管理
HTTP是無狀態的,因此無法對之前發生的請求和響應進行管理。而Cookie通過在請求
和響應報文
中寫入Cookie資訊來控制客戶端的狀態。
- 客戶端發起請求(例如包含賬號,密碼)
- 伺服器端接收,校驗,並在
響應報文
內新增Set-Cookie
的首部欄位,儲存相關授權資訊 - 客戶端接收後,在下一次請求中,在
請求報文
的cookie
值中將授權資訊傳遞給伺服器,便於伺服器識別