【知識梳理】3.5HTTP協議類

1.HTTP協議的主要特色

• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
• 靈活:HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• 無鏈接:無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
• 無狀態:HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

2.HTTP報文的組成部分

• 請求報文：請求行（包含HTTP方法、頁面地址、HTTP協議、版本）、請求頭（key-value值，告訴服務端我要什麼內容，什麼類型）、空行（分隔請求頭和請求體）、請求體
• 響應報文：響應行、響應頭、空行、響應體

3.HTTP方法

• GET：獲取資源
• POST:傳輸資源
• HEAD：獲取報文首部
• PUT：更新資源
• DELETE：刪除資源

4.POST和GET的區別

• GET在瀏覽器回退時是無害的，而POST會再次提交申請（*）；
• GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置（*）；
• GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留（*）；
• GET請求在url中傳輸的參數是有參數限制的（2kb），而POST沒有限制（*）；
• GET參數經過url傳遞，POST放在request body中（*）。
• GET產生的URL地址能夠被收藏，而POST不能夠；
• 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制；
• GET比POST更不安全，由於參數直接暴露在url上，因此不能用來傳遞敏感信息；
• GET請求只能進行url編碼，而POST支持多種編碼方式；

爲了不CSRF攻擊，將GET請求改成了POST請求。

5.HTTP狀態碼

• 1**:指示信息，表示請求已接收，繼續處理；
• 2**:成功，表示請求已被成功接收；
• 3**:重定向，要完成請求必須進行更進一步的操做；
• 4**:客戶端錯誤，請求有語法錯誤或請求沒法實現；
• 5**:服務器錯誤，服務器未能實現合法的請求。

200 OK：客戶端請求成功；

206 Partial Content：客戶發送了一個帶有Range頭的GET請求，服務器完成了它；（常見於用Vedio標籤播放一個視頻地址，或使用audio播放一個音頻地址，當視頻、音頻文件很大的時候，基本返回206）

301 Moved Permanently：所請求的頁面已經轉移至新的url;

302 Found：所請求的頁面已經 臨時 轉移至新的url；

304 Not Modified：客戶端有緩衝的文檔併發出了一個條件性的請求，服務器告訴客戶，原來緩衝的文檔還能夠繼續使用。

400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解；（少）

401 Unauthorized：請求未經受權，這個狀態碼必須和www-Authenticate報文域一塊兒使用；（少）

403 Forbidden：對被請求頁面的訪問被禁止；（多，例如在頁面中有一個地址，不能直接訪問，只能經過服務器訪問）

404 Not Found：請求資源不存在；

500 Internal Server Error：服務器發生不可預期的錯誤，原來緩衝的文檔還能夠繼續使用；

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

補充：XMLHttpRequest 的狀態，XMLHttpRequest.readyState 0: 請求未初始化；

1: 服務器鏈接已創建；
2: 請求已接收；
3: 請求處理中；
4: 請求已完成，且響應已就緒；(xmlhttp.readyState==4 && xmlhttp.status==200)

6.持久鏈接

持久鏈接（Connection:keep-alive，HTTP/1.1版本支持，HTTP/1.0版本不支持）
HTTP協議採用「請求-應答」模式，當使用普通模式，即非Keep-Alive模式時，每一個請求/應答客戶和服務器都要新建一個鏈接，完成以後當即斷開鏈接（HTTP協議爲無鏈接的協議）。

當時用Keep-Alive模式（又稱持久鏈接、鏈接重用）時，Keep-Alive功能使客戶端到服務器端的鏈接持續有效，當出現對服務器的後續請求時，Keep-Alive功能避免了創建或從新創建鏈接。

7.管線化(持久鏈接的狀況下)

在使用持久鏈接的狀況下，
某個鏈接上消息的傳遞相似於：請求1->響應1->請求2->響應2->請求3->響應3。（->表示中間未斷開）
某個鏈接上的消息變成了相似這樣：請求1->請求2->請求3->響應1->響應2->響應3。（打包請求，打包響應）

HTTP管線化是將多個HTTP要求（request）整批提交的技術，而在傳送過程當中不需先等待服務端的迴應。管線化機制須經過永久鏈接（persistent connection）完成，僅HTTP/1.1支持此技術（HTTP/1.0不支持），而且只有GET和HEAD要求能夠進行管線化，而POST則有所限制。此外，初次建立鏈接時也不該啓動管線機制，由於對方（服務器）不必定支持HTTP/1.1版本的協議。

管線化特色(原理：把請求和響應打包)

1.管線化機制經過持久鏈接完成，僅HTTP/1.1支持此技術（*）； 2.只有GET和HEAD請求能夠進行管線化，而POST則有所限制（*）； 3.初次鏈接時不該啓動管線機制，由於對方（服務器）不必定支持HTTP/1.1版本的協議（*）； 4.管線化不會影響響應到來的順序，如上面的例子所示，響應返回的順序並未改變； 5.HTTP/1.1要求服務器端支持管線化，但並不要求服務器端也對響應進行管線化處理，只是要求對於管線化的請求不失敗便可；6.由優於上面提到的服務器端問題，開啓管線化極可能並不會帶來大幅度的性能提高，並且不少服務器端和代理程序對管線化的支持並很差，所以現代瀏覽器Chrome和Firefox默認並未開啓管線化支持。