HTTP

本文主要介紹面試可能會問到的關於http方面的問題。都是比較基礎的問題，需要自己理解記憶，面試的時候能回答出來即可。更深入的問題，以後可能會再列舉補充。

1. HTTP協議的主要特點

其特點主要有四個：簡單快速、靈活、無連線、無狀態。

• 簡單快速：統一資源服，資源地址是固定的，請求資源只需要傳送對應的路徑和方法。
• 靈活：HTTP允許傳輸任意型別的資料物件。同一個http協議可以完成不同資料型別的傳輸。
• 無連線：每次處理完請求之後，連結就會斷開，不會一直處於連結狀態。
• 無狀態：無狀態是指協議對於事務處理沒有記憶能力，簡單說就是每次請求處理完斷開後，沒有記錄資訊，客戶端再次請求，服務端也不能識別是否是同一個客戶端。

2. HTTP報文的組成部分

報文分為：請求報文、響應報文。

請求報文包括：

• 請求行：主要包括請求方法、頁面地址、協議版本。
• 請求頭：由key/value 組成，告訴服務端需要的資源型別。
• 空行：表示請求頭結束，下邊的都是請求體內容。
• 請求體：包括請求的一些資料。

響應報文：響應行、響應頭、空行、響應體與請求報文相差不多，就不做詳細解釋了。

3. HTTP方法

    主要列舉常見的以及常用的方法。 
    GET：請求資源； 
    POST：傳輸資源； 
    HEAD：獲取報文首部資料； 
    PUT：更新資源；（應用不多） 
    DELETE
 
：刪除資源；（應用更少）

4. POST和GET的區別

    1、GET 在瀏覽器回退時是無害的，而POST會再次提交請求。 
    2、GET 請求會被瀏覽器主動快取，POST不會，除非手動設定。 
    3、GET 請求引數會被完整保留在瀏覽器歷史記錄中，POST不會儲存。 
    4、GET 請求在URL中傳遞的引數是有長度限制的，POST不會限制。 
    5、GET 引數通過URL傳遞，POST 放在 Reques Body 中。 
    6、GET 產生的URL 地址可以收藏，POST 不可以。 
    7、GET 請求只能進行 url 編碼，而POST 支援多種編碼方式。 
    8
 
、對引數的資料型別，GET只接受ASCII 字元，POST沒有限制。 
    9、GET比POST更不安全，GET的引數都暴露在URL上，不能用來傳遞敏感資訊。 
    以上的區別，選擇性的記幾條，以前五條為主。

5. HTTP狀態碼

狀態碼錶示服務端返回的響應狀態碼。

    HTTP狀態碼由三個十進位制數字組成，第一個十進位制數字定義了狀態碼的型別，後兩個數字沒有分類的作用。HTTP狀態碼共分為5種類型： 
    分類 分類描述 
    1** ： 資訊，伺服器收到請求，需要請求者繼續執行操作 
    2** ： 成功，操作被成功接收並處理 
    3** ： 重定向，需要進一步的操作以完成請求 
    4** ：客戶端錯誤，請求包含語法錯誤或無法完成請求 
    5** ：伺服器錯誤，伺服器在處理請求的過程中發生了錯誤

常見的狀態碼主要有：
200：請求成功。一般用於GET與POST請求
206：部分內容。伺服器成功處理了部分GET請求
301：永久移動。請求的資源已被永久的移動到新URI，返回資訊會包括新的URI，瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替
302：臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI
304：未修改。所請求的資源未修改，伺服器返回此狀態碼時，不會返回任何資源。客戶端通常會快取訪問過的資源，通過提供一個頭資訊指出客戶端希望只返回在指定日期之後修改的資源
400：客戶端請求的語法錯誤，伺服器無法理解
401：請求要求使用者的身份認證
403：伺服器理解請求客戶端的請求，但是拒絕執行此請求
404：伺服器無法根據客戶端的請求找到資源（網頁）。通過此程式碼，網站設計人員可設定”您所請求的資源無法找到”的個性頁面
500：伺服器內部錯誤，無法完成請求
503：由於超載或系統維護，伺服器暫時的無法處理客戶端的請求。延時的長度可包含在伺服器的Retry-After頭資訊中
更多更詳細的請參考菜鳥教程HTTP教程http狀態碼

6. 什麼是持久連線？管線化？

持久連線
HTTP協議採用”請求-應答“模式，當使用普通模式，即非持久連線（Keep-Alive）模式時，每個請求/應答客戶端和服務端都要重新建立連線，完成之後立即斷開。（HTTP為無連線協議）

當使用Keep-Alive模式（又稱持久連線，連線重用）時，Keep-Alive 功能使客戶端到服務端的連線持續有效，當出現對伺服器的後續請求時，Keep-Alive 功能避免了建立或者重新建立連線。（http 1.1版本支援）

管線化
在使用持久連線的情況下，某個連線上的訊息傳遞類似於這樣：
請求1->響應1->請求2->響應2->請求3->響應3

管線化就是將請求和響應都進行打包，即：
請求1->請求2->請求3->響應1->響應2->響應3

管線化特點：

管線化機制通過持久連線完成，僅HTTP1.1版本支援。
只有GET 和 HEAD 請求可以進行管線化，POST有限制。
初次建立連線時不應啟動管線機制，因為伺服器不一定支援HTTP1.1版本的協議
管線化不會影響到響應的順序。
HTTP1.1要求服務端支援管線化，但並不要求服務端也對響應進行管線化處理，只是要求對於管線化的請求不是白即可。
由於上面提到的服務端問題，開啟管線化可能並不會帶來大幅度的效能提升，而且很多服務端和代理程式對管線化的支援並不好，因此現代瀏覽器預設並未開啟管線化支援。
對於管線化，能簡單回答出是什麼和有什麼特點即可。