HTTP協議用於客戶端和服務端之間的通訊

應用HTTP協議時，必定是一段擔任客戶端，另一端擔任伺服器端

且HTTP協議可以明確區分哪端是客戶端或伺服器端

2.1 請求和響應

請求必定由客戶端發出，肯定是先從客戶端開始建立通訊，服務端在沒有接收到請求之前不會發送響應

客戶端傳送給HTTP伺服器端請求報文的格式：

GET /index.html HTTP/1.1
Host: hackr.jp

..........

上面的報文：

請求方法（method）:GET

請求URI: /index/html

協議版本：HTTP/1.1

可選的請求首部欄位：Host: hackr.jp

內容實體

響應報文的構成：

2.2 HTTP協議

HTTP協議是stateless的協議（無狀態），自身不對請求和響應之間的通訊狀態儲存

為了儲存狀態：引入了Cookie技術

2.3 如何定位資源

HTTP使用URI定位資源

客戶端請求訪問資源傳送請求時，URI要將請求URI包含在內

指定方式:

如果是對伺服器本身發起請求，則可以用*代替URI:

OPTIONS * HTTP/1.1

此例子為查詢HTTP伺服器端支援的HTTP方法種類

2.4 請求報文中的method

用於告知伺服器:客戶端的意圖

其中LINK,UNLINK已經被HTTP/1.1廢棄了

GET

用於來請求訪問已經被URI識別的資源，如果請求的是文字，則原樣返回，如果是類似CGI的程式，則返回執行後的輸出結果

POST

用於傳輸實體的主體

GET也可以傳輸實體的主體，但是一般是使用POST（用於傳輸資料）

PUT

用於傳輸檔案，但是不帶驗證機制，所以一般不用

要求在請求報文的主體中包含檔案內容，儲存到請求URI指定的位置

響應：請求執行成功但是沒有資料返回

HEAD

獲取報文首部

用於確認URI的有效性以及資源更新的日期時間等

DELETE

刪除檔案，（不帶驗證機制所以一般也不用）

OPTIONS

查詢支援的方法

TARCE

追蹤路徑

在Max-Forwards首部欄位填入數值，經過一個伺服器端就減1，減為0時，停止傳輸，最後接收到請求的服務端返回狀態碼200 OK的響應

CONNECT

2. 5 HTTP/1.1：持久連線

早期的HTTP通訊：

持久連線可以在建立一次TCP連線後進性多次請求和響應的互動，節省通訊量

只要任意一端沒有明確提出斷開連線，就保持TCP連線狀態

減少了TCP連線的重複建立和斷開造成的額外開銷，減輕伺服器負載，減少開銷時間，讓HTTP請求響應更早結束

HTTP/1.1中所有連線預設都是持久連線

2.5.2 管線化

管線化使得傳送請求後無需等待響應即可傳送下一請求

Cookie

通過在請求和響應報文中寫入Cookie資訊來控制客戶端的狀態

HTTP是無狀態協議，不對之前發生過的請求和響應的狀態做管理

Cookie通過在請求和響應報文中寫入Cookie資訊來控制客戶端的狀態

根據從伺服器端傳送的響應報文中的set-Cookie首部欄位資訊，通知客戶端儲存Cookie

，下一次客戶端再次傳送請求時（向該服務端），會自動在請求報文中寫入Cookie值

伺服器接收後會根據Cookie對比自己的記錄