一、HTTP協(xié)議的主要特點

簡單快速? ? 資源固定

靈活? ? 通過一個HTTP協(xié)議可完成不同數(shù)據(jù)類型的傳輸

無連接? ? 連接一次即斷開

無狀態(tài)? ? 不區(qū)分身份

二、HTTP報文組成部分

請求報文：? ? 請求行（HTTP方法/頁面地址/HTTP協(xié)議/版本）? ? 請求頭（KEY/VALUE）? ? 空行? ? 請求體

響應報文：? ? 狀態(tài)行（HTTP協(xié)議/版本/狀態(tài)碼）? ? 響應頭（KEY/VALUE）? ? 空行? ? 響應體

三、HTTP方法

GET? ? 獲取資源

POST? ? 傳輸資源

PUT? ? 更新資源

DELETE? ? 刪除資源

HEAD? ? 獲得報文首部

TRACE

OPTIONS

四、POST和GET區(qū)別

GET在瀏覽器回退時是無害的，而POST會再次提交請求

GET產生的URL地址可以被收藏，而POST不可以

GET請求會被瀏覽器主動緩存，而POST不可以

GET只能進行URL編碼，而POST支持多種編碼方式

GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留

GET請求在URL中傳送的參數(shù)有長度限制，而POST沒有

對參數(shù)的數(shù)據(jù)類型，GET只接收ASCII字符，而POST沒有限制

GET比POST更不安全，因為參數(shù)直接暴漏在URL上，所以不能用來傳遞敏感信息

GET參數(shù)通過RUL傳遞，POST放在Request body中

五、HTTP狀態(tài)碼

1xx? ? 指示信息，表示請求已接收，繼續(xù)處理

2xx? ? 成功? ? 表示請求已被成功接收

200 OK? ? 客戶端請求成功

206 Partial Content? ? 客戶端發(fā)送了 一個帶有Range頭的GET請求，服務器反成了它，一般用于音頻、視頻

3xx? ? 重定向? ? 要完成請求必須進行更進一步的操作

301 Moved Permanently? ? 所請求的頁面已轉移至新的URL

302 Found? ? 所請求的頁面已臨時轉移至新的URL

304 Not Modified? ? 客戶端有緩存的文檔并發(fā)出了一個條件性請求，服務器告訴客戶端原來緩存的文檔還可以繼續(xù)使用

4xx? ? 客戶端錯誤? ? 請求有語法錯誤或請求無法實現(xiàn)

400 Bad Request? ? 客戶端請求有語法錯誤，不能被服務器所理解

401 Unauthorized? ? 請求未經授權，這個狀態(tài)嗎必須和WWW-Authenticate抱頭域一起使用

403 Forbidden? ? 被請求頁面的訪問被禁止

404 Not Found? ? 請求資源不存在

5xx? ? 服務器錯誤? ? 服務器未能實現(xiàn)合法的請求

500 Internal Server Error? ? 服務器發(fā)生不可預期的錯誤，原來緩存的文檔還可以繼續(xù)使用

503 Server Unavailable? ? 請求未完成，服務器臨時過載或宕機，一段時間后可能恢復正常

六、HTTP持久連接

HTTP協(xié)議采用“請求-應答”模式，當使用普通模式，即非Keep-Alive模式時，每個請求/應答客戶和服務器都要新建一個連接，完成之后立即斷開連接（HTTP協(xié)議為無連接的協(xié)議）

當使用Keep-Alive模式（又稱持久連接、連接重用）時，Keep-Alive功能使客戶端到服務端的連接持久有效，當出現(xiàn)對服務器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接

七、管線化

在持有連接的情況下，某個連接消息的傳遞類似于：

? ? 請求1 → 響應1?→ 請求2?→ 響應2?→ 請求3?→ 響應3

某個連接上的消息變成了類似這樣：

? ? 請求1?→ 請求2?→ 請求3?→ 響應1?→ 響應2?→ 響應3

管線化機制通過持久化連接完成，僅HTTP/1.1支持此技術

只有GET和HEAD請求可已進行管線化，而POST自有所限制

初次創(chuàng)建連接不應啟動管線機制，因為對方不一定支持

管線化不會影響響應到來的順序