寫在開頭
大家好，這裏是lionLoveVue，基礎知識決定了編程思維，學如逆水行舟，不進則退。金三銀四，爲了面試也還在慢慢積累知識，Github上面可以直接查看所有前端知識點梳理，github傳送門，覺得不錯，點個Star★，好運連連，Offer終究鼠於你，持續更新中。另外，也可以關注微信公衆號：小獅子前端Vue，源碼以及資料今後都會放在裏面。
一直想着成爲一個up主，正值時間挺多的，4月份左右面試的面經我會製作視頻去分享，趕快捧個場吧。嗶哩嗶哩：一百個Chocolate
HTTP 協議類
題目
-
HTTP協議的主要特點
-
HTTP報文的組成部分
-
HTTP方法
-
POST和GET的區別
-
HTTP狀態碼
-
什麼是持久連接
-
什麼是管線化
HTTP協議的主要特點
- 簡單快速 （每個資源URL是固定的，一個圖片或頁面地址，統一資源符，只需輸入URL即可訪問）
- 靈活 （在HTTP協議頭部head部分有一個數據類型，通過http協議可以完成不同數據類型的傳輸）
- 無連接 （連接一次會斷掉，不會保持連接）
- 無狀態 （客戶端和服務端連接兩次，不能區分兩次連接者身份）
HTTP報文的組成部分
- 請求行：包含方法、頁面地址、HTTP協議版本
- 請求頭：key-value值，告訴服務端需要什麼內容，要注意什麼類型
- 空行：告訴服務端請求頭結束，接下來是請求體部分了
- 請求體：數據部分
同理，響應報文
請求示例
以上第一行就是請求行，包含GET方法 / 表示首頁 HTTP/1.1 表示HTTP協議版本
後面內容都是請求頭，都是key-value鍵值對
空行在這裏沒有顯示出來，然後對於請求體就是一些數據部分了。
響應示例
第一行是狀態行，包含HTTP協議版本，協議狀態碼200
下面就是響應頭了，也是鍵值對的形式
下面會有一個空行，類似下面這種效果（下面這條分割橫線）
HTTP方法
| 方法 | 作用 |
|---|---|
| GET | 獲取資源 |
| POST | 傳輸資源 |
| PUT | 更新資源 |
| DELETE | 刪除資源 |
| HEAD | 獲取報文首部 |
POST和GET的區別（重點前5條）
-
get在瀏覽器回退時是無害的，而post會再次提交請求
-
get請求會被瀏覽器主動緩存，而post不會，除非手動設置
-
get請求參數會被完整保留在瀏覽器歷史記錄裏，而post中的參數不會被保留
-
get請求在URL中傳送的參數是有長度限制的，而POST沒有限制
-
get參數通過URL傳遞，post放在Request body中
-
get請求只能進行url編碼，而post支持多種編碼方式
-
對參數的數據類型，get只接受ASCALL字符，而post沒有限制
-
get比post更不安全，因爲參數直接暴露在URL上，所以不能用來傳遞敏感信息
-
get產生的URL地址可以被收藏，而post不可以
HTTP狀態碼
- 1xx：指示信息——表示請求已接收，繼續處理
- 2xx：成功——表示請求已經被成功接收
- 3xx：重定向——要完成請求必須進行更進一步的操作
- 4xx：客戶端錯誤——請求有語法錯誤或請求無法實現
- 5xx：服務器錯誤——服務器未能實現合法的請求
一般答完上述基本ok了，如果問的詳細一點的話，就多加一點知識上去：
200 OK：客戶端請求成功206 Partial Content：客戶發送了一個帶有Range（範圍）頭的GET請求，服務器完成了它（比如客戶端請求0-1w字節，服務器就會返回206,常見播放視頻和音頻地址，文件過大時一般返回206）
301 Moved Permanently：所請求的頁面已經轉移至新的URL302 Found：所請求的頁面已經臨時轉移至新的URL304 Not Modified：客戶端有緩衝的文檔併發出一個條件性的請求，服務器告訴客戶，原來緩衝的文檔還可以繼續使用
400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解401 Unauthorized：請求未經授權，這個狀態碼必須和WWW-Authenticate報頭域一起使用403 Forbidden：請求訪問的頁面被禁止（比如頁面只能通過服務端去訪問）404 Not Found：請求資源不存在
500 Internal Server Error：服務器發生不可預料的錯誤但原來緩衝的文檔還可以繼續使用503 Server Unavailable：請求未完成，服務器臨時過載或當機，一段時候後可能恢復正常
什麼是持久連接
HTTP協議採用“請求-應答”模式，當使用普通模式，即非 Keep-Alive 模式時，每個請求 / 應答客戶和服務器都要新建一個連接，完成之後立即斷開連接（HTTP協議爲無連接的協議）
當使用 Keep-Alive模式（又稱持久連接、連接重用）時，Keep-Alive 功能使客戶端到服務端的連接持續有效，當出現對服務器的後續請求時，Keep-Alive 功能避免了建立或者重新建立連接
PS：只有HTTP 1.1 版本才支持持久連接，1.0不支持。
什麼是管線化（加分點）
在使用持久連接的情況下，某個連接上消息的傳遞類似於
請求1->響應1->請求2->響應2->請求3->響應3
某個連接上的消息類似變成了這樣：
請求1->請求2->請求3->響應1->響應2->響應3
（將請求打包一起發送，然後服務器一起打包回來響應）
拓展知識：
- 管線化機制通過持久連接完成，僅
HTTP / 1.1支持此技術（重點） - 只有
get和head請求可以進行管線化，而post有所限制（重點） - 初次創建連接時不應啓動管線機制，因爲對方（服務器）不一定支持
HTTP /1.1版本的協議（重點） - 管線化不會影響響應到來的順序，如上面的例子所示，響應返回的順序並未改變
HTTP / 1.1要求服務器端支持管線化，但並不要求服務器端也對響應進行管線化處理，只是要求對於管線化的請求不失敗即可- 由於上面提到的服務器端的問題，開啓管線化很可能並不會帶來大幅度的性能提升，而且很多服務器端和代理程序對管線化的支持並不好，因此現代瀏覽器如
Chrome和Firefox默認並未開啓管線化支持
結尾
如若本文有瑕疵需修改的地方，請提出來，謝謝您的貢獻！
歡迎關注微信公衆號：小獅子前端Vue
謝謝您的支持！✿✿ヽ(°▽°)ノ✿
學如逆水行舟，不進則退