主要特點
| 特點 | 描述 |
|---|---|
| 簡單快速 | 客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。 |
| 靈活 | HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type(數據類型)加以標記 |
| 無連接 | 服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。 |
| 無狀態 | HTTP是一個無狀態協議，這意味着每個請求都是獨立的，Keep-Alive沒能改變這個結果。單平請求時無法記錄上一次和這一次是不是同一個請求，所以引入cookie和session |
報文組成部分
| 報文 | 組成 |
|---|---|
| 請求報文 | 請求行、請求頭、空行、請求體 |
| 響應報文 | 狀態行、響應頭、空行、響應體 |
1.請求行
由3部分組成，分別爲：請求方法、URL（見備註1）以及協議版本，之間由空格分隔
請求方法包括GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE以及擴展方法，當然並不是所有的服務器都實現了所有的方法，部分方法即便支持，處於安全性的考慮也是不可用的
協議版本的格式爲：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1
2.請求頭部
請求頭部爲請求報文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔
常見請求頭如下：
| 請求頭 | 說明 |
|---|---|
| Host | 接受請求的服務器地址，可以是IP:端口號，也可以是域名 |
| User-Agent | 發送請求的應用程序名稱 |
| Connection | 指定與連接相關的屬性，如Connection:Keep-Alive |
| Accept-Charset | 通知服務端可以發送的編碼格式 |
| Accept-Encoding | 通知服務端可以發送的數據壓縮格式 |
| Accept-Language | 通知服務端可以發送的語言 |
3.空行
請求頭部的最後會有一個空行，表示請求頭部結束
4.請求體
就是發過去的數據
1.狀態行
由3部分組成，分別爲：協議版本，狀態碼，狀態碼描述，之間由空格分隔
狀態代碼爲3位數字，200~299的狀態碼錶示成功，300~399的狀態碼指資源重定向，400~499的狀態碼指客戶端請求出錯，500~599的狀態碼指服務端出錯（HTTP/1.1向協議中引入了信息性狀態碼，範圍爲100~199）
例子：
| 狀態碼 | 說明 |
|---|---|
| 200 | 響應成功 |
| 302 | 跳轉，跳轉地址通過響應頭中的Location屬性指定（JSP中Forward和Redirect之間的區別） |
| 400 | 客戶端請求有語法錯誤，不能被服務器識別 |
| 403 | 服務器接收到請求，但是拒絕提供服務（認證失敗） |
| 404 | 請求資源不存在 |
| 500 | 服務器內部錯誤 |
2.響應頭
| 請求頭 | 說明 |
|---|---|
| Server | 服務器應用程序軟件的名稱和版本 |
| Content-Type | 響應正文的類型（是圖片還是二進制字符串） |
| Content-Length | 響應正文長度 |
| Content-Charset | 響應正文使用的編碼 |
| Content-Encoding | 響應正文使用的數據壓縮格式 |
| Content-Language | 響應正文使用的語言 |
3.空行
響應頭部的最後會有一個空行，表示響應頭部結束
4.響應體
返回數據
HTTP方法種類
| 方法名 | 方法用途 |
|---|---|
| GET | 獲取資源 |
| POST | 傳輸資源 |
| PUT | 更新資源 |
| DELETE | 刪除資源 |
| HEAD | 獲得報文頭部 |
持久鏈接
HTTP協議採用“請求-應答”模式，當時用普通模式，即非Keep-Alive模式時，每個請求/應答客戶和服務器都要新建一個鏈接，完成之後立即斷開（HTTP下一爲無連接協議）
但是當使用Keep-Alive模式（持久鏈接、連接重用）時，Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器 的後續請求時，Keep-Alive功能避免了簡歷或者重新建立連接
管線化
默認情況下http協議中每個傳輸層連接只能承載一個http請求和響應，然後結束。
- 管線化機制通過持久鏈接完成，僅HTTP/1.1支持此技術
- 只有Get和HEAD請求可以進行管線化，而POST則有所限制
- 初次創建連接時不起動管線機制，因爲對方（服務器）不一定支持HTTP/1.1版本協議
- 管線化不會影響響應到來的順序
- HTTP/1.1要求服務器端支持管線化，但並不要求服務器端也對相應進行管線化處理，只是要求對於管線化的請求不失敗即可
- 由於上面提到的服務器端問題，開啓管線化很可能並不會帶來大幅度的性能提升，而且很多服務器端和代理程序對管線化的支持並不好，因此Chrome和Firefox默認並不開啓管線化支持
