🐲【1】ShutdownHTTP系列-基礎篇

Shutdown HTTP系列介紹

以前，有位大佬和我說過這麼一句話："網絡知識在必定程度上決定了你的上限"。前端

對HTTP只知其一;不知其二的我，上限真的這麼低嗎...就不能花點時間好好整理整理嗎 🤔️？git

此次請給霖呆呆一個機會，跟着個人腳步👣從1開始學習它。另外我整理的HTTP系列基本都會附有一個面試時的淺答與深答的的配套答案，淺答是爲了讓大家更好的記住，深答保證你確實理解了淺答中的知識點。github

整個系列下來，讓咱們完全 Shutdown HTTP ！！！💪面試

系列思惟導圖：數據庫

系列目錄：瀏覽器

《🐲【1】Shutdown HTTP系列-基礎篇》「本篇」
《🐲【2】Shutdown HTTP系列-HTTP報文篇》
《🐲【3】Shutdown HTTP系列-Cookie篇》
《🐲【4】Shutdown HTTP系列-HTTPS篇》
《🐲【5】Shutdown HTTP系列-CCPG篇》
《🐲【6】Shutdown HTTP面試系列》

全部文章內容均被收入GitHub我的博客：niubility-coding-js 快來給我Star呀😊~緩存

本篇目錄

經過閱讀本篇文章你能夠學習到：安全

HTTP概述
HTTP特色及缺點
HTTP請求方法
HTTP狀態碼

（請注意，帶有🌟標示的都是必需要掌握的哦）服務器

1. HTTP概述

HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是因特網上應用最爲普遍的一種網絡傳輸協議。markdown

設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法，它是一個基於 TCP/IP 通訊協議來傳輸數據的應用層協議。

要注意的點就是：

一句話概述HTTP
HTTP經典的幾個版本
HTTP存在的位置

1.1 一句話概述HTTP

【面試時問起：一句話概述HTTP協議】🌟🌟🌟🌟

「HTTP 是一個在計算機世界裏專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範。」

（HTTP一般跑在TCP/IP協議棧之上，依靠IP協議實現尋址和路由、TCP協議實現可靠數據傳輸、DNS協議實現域名查找、SSL/TLS協議實現安全通訊。固然，WebSocket、HTTPDNS依賴於HTTP。——「進擊的前端工程師」HTTP的世界觀(附HTTP/3中文翻譯)-童歐巴）

1.2 HTTP經典的幾個版本

初版 「HTTP/0.9」 於「1990年」問世，並無做爲正式的標準被創建。
做爲正式的標準被創建是 「HTTP/1.0」，於「1996年5月」發佈。(比霖呆呆大了4個月)
目前主流的版本是 「HTTP/1.1」，於「1997年1月」發佈。
「2015年5月」 正式發佈「HTTP/2」。(不叫HTTP/2.0，是由於標準委員會不打算髮布子版本，下一個版本直接是HTTP/3)

1.3 HTTP存在的位置

處於 TCP/IP 網絡分層模型中的第一層「應用層」。

應用層的其它協議還有：

FTP：文件傳輸協議，用來在客戶機和FTP服務器之間傳輸文件。
DNS域名系統：提供域名到IP地址之間的解析服務。
SMTP：郵件發送協議，用戶經過SMTP服務器發送郵件。
DHCP：動態主機配置協議，DHCP服務器爲客戶機動態分配IP地址。
POP3：郵件接收協議，用於從POP3服務器接收郵件。

【面試時問起通常答前面三個就夠了】🌟🌟

2. HTTP特色及缺點

2.1 HTTP特色

常問知識點，重要指數：🌟🌟🌟🌟🌟

HTTP協議支持客戶端/服務端模式，也是一種請求/響應模式的協議。
靈活可擴展：一個是語義上的自由，只規定了基本格式，其它的各部分沒有嚴格的限制；第二個它容許傳輸任意類型的數據對象，例如文本、圖片、音頻等，傳輸的類型由Content-Type加以標記。
可靠傳輸，HTTP 基於 TCP/IP，所以把這一特性繼承了下來。
無狀態，也就是說HTTP請求不具有保存以前發送過的請求或響應的功能，每一次請求都是獨立無關的。

若是還要的話，能夠答一下「持久鏈接」：

概念：創建一次TCP鏈接便可進行屢次請求或響應的交互
產生緣由：HTTP的初始版本是每進行一次HTTP通訊就要斷開一次TCP鏈接，下次再進行的時候又要從新鏈接斷開。再現在請求的資源愈來愈大，每次請求若是都有無謂TCP鏈接和斷開是很大的開銷。
特色：只要有一方沒有明確的提出斷開鏈接，則保持TCP鏈接狀態。
優勢：減小了TCP鏈接和斷開的形成的額外開銷，減輕了服務端的負載，Web頁面加載變快
注意點：在HTTP/1.1中全部的鏈接默認都是持久鏈接的(也就是首部字段 Connection: keep-alive，如果想要關閉則將值設置爲 close)，可是HTTP/1.0並未標準化

（另外其實還有一個管線化的特色，同時並行發送多個請求，而沒必要等前一個請求完畢才能發送下一個。可是由於各類緣由被各大廠商廢棄了）

2.2 HTTP的缺點

常問知識點，重要指數：🌟🌟🌟🌟🌟

簡單來講：

明文傳輸(不加密)，內容可能被竊聽。
沒法驗證報文的完整性，內容可能被篡改。
不驗證通訊方的身份，有可能遭遇假裝。
無狀態，它是缺點也是優勢吧，分不一樣的場景。
隊頭阻塞。

詳細來講：

明文傳輸(不加密)，內容可能被竊聽。協議裏的報文不使用二進制數據，而是文本形式
沒法驗證報文的完整性，內容可能被篡改。這裏說的完整性也就是指信息的準確度由於接收方或者發送方沒有辦法確認對方發送過來的數據在中間有沒有被篡改
不驗證通訊方的身份，有可能遭遇假裝。由於HTTP協議中不會對通訊方進行確認任何人均可以發送請求，並且服務器它對收到的請求也不會進行確認，只要收到了請求就會返回一個響應(固然這個只是在發送端的IP地址或者端口號沒被Web服務器設定限制訪問的前提下)
無狀態，不具有保存以前發送過的請求或響應的功能。它是缺點也是優勢吧：
- 對於一些長鏈接的場景須要保存上下文信息，以避免傳輸重複的數據。
- 對於一些應用只是爲了獲取數據不須要保存上下文信息，無狀態減小了網絡開銷。
隊頭阻塞：
- 其根本緣由在於HTTP是基於請求-響應的模型，在同一個TCP長鏈接中，前一個請求沒有獲得響應，後面的請求就會被阻塞。
- 用併發鏈接和域名分片來解決了這個問題。但並非從HTTP自己的層面來解決的，只是增長了 TCP 鏈接，分攤風險而已。
- HTTP/2中的多路複用從HTTP自己的層面解決了這個問題
- 和TCP隊頭阻塞的區別：TCP傳輸的單位是數據包，它的隊頭阻塞表示的是前一個報文沒有收到便不會將下一個報文上傳給HTTP。而HTTP隊頭阻塞是在請求-響應層面，前一個請求尚未處理完，後面的請求就被阻塞。

3. HTTP請求方法

3.1 方法種類

常問知識點，重要指數：🌟🌟🌟🌟🌟

GET：獲取資源，冪等操做
HEAD：獲取報文首部，和GET很像可是不返回報文主體，冪等操做
POST: 建立或更新資源，非冪等操做
PUT: 建立或更新資源自己，冪等操做
PATCH：對資源進行局部更新，非冪等操做
DELETE：刪除資源，和PUT功能相反，冪等操做

OPTIONS：查詢服務器端支持的HTTP方法種類(冪等操做)：

請求	OPTIONS * HTTP/1.1 Host: lindaidai.wang
響應	HTTP/1.1 200 OK Allow: GET, POST, HEAD, OPTIONS (返回服務器支持的方法)

CONNECT：創建鏈接隧道，用於代理服務器，冪等操做
TRACE：追蹤請求，查詢發出去的請求是怎樣被加工/篡改的，冪等操做。容易引起XST跨站追蹤攻擊。

3.2 HTTP中的冪等是什麼意思

重要指數：🌟🌟🌟🌟

(先讓咱們來了解一下它的概念)

這東西其實很好理解，你只要記住：若是一個方法重複執行屢次，產生的效果是同樣的，那麼這個方法就是冪等的。「它本質上意味着成功執行請求的結果與其執行次數無關。」

讓咱們來具體看看每一項的分析：

GET方法用於獲取資源，不該該有反作用，因此它是「冪等」的。例如：GET http://lindaidai.wang/account/123，不會改變資源的狀態，不管是調用一次仍是N次都沒有反作用。可是要注意了，這裏指的是「調用多少次都沒有反作用」，而不是每次GET的結果都相同。由於你想一想有可能直接去改了數據庫的這條數據，那麼下次獲取到的可能就不相同了，可是它自己並無產生反作用，因此知足冪等。
HEAD方法GET狀況同樣，只不過它只用於獲取報文首部，不返回報文主體，因此它也是「冪等」的。
POST和PUT很容易讓人混淆，以前我老是簡單的認爲：POST表示建立資源，PUT表示更新資源；可是實際上它們均可用於建立和更新資源，只不過本質的差異就在於冪等性上。POST所對應的URI並不是建立資源的自己，而是「資源的接收者」。例如：POST http://lindaidai.wang/articles的語義是在http://lindaidai.wang/articles下建立一篇帖子，HTTP響應中應包含帖子的建立狀態以及帖子的URI。兩次相同的POST請求會在服務器端建立兩份資源，它們具備不一樣的URI，因此POST是「非冪等」的。
PUT方法所對應的URI是要建立或者更新「資源自己」。這點很容易讓人誤會它不是冪等的，但其實它是「冪等」的。例如：PUT http://lindaidai.wang/accout/321 的語義是建立或者更新ID爲321的帖子。第一次PUT方法執行以後，其在服務器上生成的資源，不能被後續的PUT方法更改，因此對同一URI進行屢次PUT的反作用和一次PUT是相同的，於是它是「冪等」的。
DELETE方法用於刪除資源，有反作用(意思就是會修改服務器上的資源內容)，但它倒是「冪等」的。由於例如：DELETE http://lindaidai.wang/accout/321調用一次和調用N次對系統產生的反作用是相同的，都是爲了刪掉ID爲321的帖子。所以，調用者能夠屢次調用或刷新頁面而沒必要擔憂引發錯誤。
OPTIONS這個很好理解，只是爲了獲取服務器支持的方法，我知道的通常是使用了代理而後進行一個預請求的時候會用到。它是「冪等」的。

【面試時答法】

一個方法是否是冪等，其實就是判斷一個方法重複執行屢次，產生的效果是否是同樣的，若是是冪等的話，它本質上意味着成功執行請求的結果和它的執行次數無關。我所知道的，只有「POST」和「PATCH」是非冪等的，其它都是冪等操做。

3.3 GET和POST的區別

不用我多說，常問知識點，重要指數：🌟🌟🌟🌟🌟

(這裏我用的是三元總結的一份答案+本身的一些理解)

從緩存的角度上說，GET會被瀏覽器主動緩存下來，留下歷史記錄，可是POST不會。
從編碼的角度上說，GET只能進行URL編碼，它只能接收ASCII字符，可是POST沒有限制。
從參數的角度上說，GET通常放在URL上傳遞參數，POST放在請求體裏，更適合傳遞敏感信息。
從冪等的角度上說，GET是冪等的，而POST不是。
不過據我瞭解的，其實GET和POST本質上都是TCP鏈接，並沒有差異。可是因爲HTTP的規定和瀏覽器/服務器的限制，致使它們在應用過程當中體現出一些不一樣。
還有能夠從TCP的角度上說，GET請求會把請求報文一次性發出去，可是POST會分爲兩個TCP數據包。首先發送的是header部分，如果服務器響應100(continue)，則會發送body部分，固然「火狐」瀏覽器除外，它的 POST 請求只發一個 TCP 包。

（這時候面試官可能還會追加着問你：既然POST要分爲兩個TCP數據包發送，那GET是否是會比POST更有效啊）

你能夠這樣回答：

首先，GET和POST都有它們本身的語義的，最好不要混用
另外，雖說POST會分爲兩個數據包發送，可是其實在網絡條件好的狀況下，發一次包和發兩次包的相差的時間基本能夠被無視了。而且在網絡條件差的狀況下，兩次包的TCP在驗證數據包的完整性上還有更大的優勢。
再者，也並非全部的瀏覽器的POST請求都會發送兩次TCP數據包的，好比火狐就不會。

3.4 支持度

OPTIONS、CONNECT、TRACE只在HTTP/1.1以上被支持
LINK、UNLINK在HTTP/1.1中被廢棄

3.5 服務端收到不支持的方法會如何處理

當服務端收到不支持的方法時，會返回 405 Method Not Allowed，而且會把全部支持的方法寫入響應報文首部字段Allow中返回。

4. HTTP狀態碼

重要指數：🌟🌟🌟🌟🌟

（又是個硬核的知識點啊...這裏霖呆呆就只列舉一些經常使用的）

1xx 信息性

「請求已經接收到，須要進一步處理才能完成，可是HTTP/1.0 不支持。」

101 Switching Protocols ：在HTTP升級爲WebSocket時，若是服務器贊成變動，則返回 101。

2xx 成功狀態

「成功處理請求。」

200 OK ：請求成功，一般返回的數據中帶有響應體。
204 No Content：意思和200同樣，不過返回的數據中不帶有響應體。
206 Partial Content：客戶端進行了範圍請求且服務端正常處理，響應報文的首部應該還有Content-Range字段指定實體的範圍。使用場景爲HTTP分塊下載和斷點續傳。

3xx 重定向

「重定向狀態，資源位置發生變更，須要從新請求。」

301 Moved Permanently：永久重定向，最新的URI爲響應報文首部的 Location 字段。場景是：例如你的網站換了地址了，以前的地址不用了，若用戶仍是從以前的地址進的話則會返回301且在Location中帶上最新的URI。且瀏覽器默認會作緩存優化，減小服務器壓力，在第二次訪問的時候自動訪問重定向的那個地址。
302 Found：臨時重定向，和301不一樣，它表示請求的資源臨時被移動到了別的URI上，由於是暫時的，因此不會被緩存。
303 See Other：臨時重定向，請求的資源臨時被移動到了別的URI上，可是明確表示客戶端應該使用GET方法獲取資源。
304 Not Modefied：客戶端帶條件請求時雖未知足條件可是也容許返回該資源，它雖然被劃分在3xx中，但其實和重定向沒有關係。場景例如：協商緩存成功就會返回304 Not Modefied，表示請求的資源在服務器上並未發送改變，告訴請求者可使用緩存。(能夠看個人這篇文章哦《霖呆呆你來講說瀏覽器緩存吧》)
307 Temprary Redirect：臨時重定向，可是比302更加明確，重定向的請求方法和實體都不容許變更。場景例如：HSTS協議，強制客戶端使用https創建鏈接，好比你的網站從HTTP升級到了HTTPS，而你仍是經過http://xxx訪問的話，就會返回307 Internal Redirect。(能夠試一下juejin.cn)

三種臨時重定向簡單比較：

302 Found，基本的臨時重定向
303 See Other，明確表示客戶端應該使用GET方法
307 Temprary Redirect，請求方法和實體都不容許變更

4xx 客戶端錯誤

「客戶端出現錯誤。」

400 Bad Request：請求報文中存在語法錯誤，可是沒有具體指出是哪裏。
401 Unauthorized：須要有經過HTTP認證的認證信息或者表示用戶認證失敗。
403 Forbidden：請求資源被拒絕，緣由是：好比法律禁止、信息敏感。
404 Not Found：請求資源未找到，表示沒在服務器上找到相應的資源。

5xx 服務端出現錯誤

「服務端出現錯誤。」

500 Internal Server Error：服務器內部錯誤，可是沒有具體指出是哪裏，和400有點像。
501 Not Implemented：表示客戶端請求的功能還不支持
502 Bad GateWay：服務器自身是正常的，可是代理服務器沒法獲取到合法響應(點外賣時外賣小哥沒送)
503 Service Unavailable：服務器內部處於超負載狀態或進行停機維護(就像是本店今天不開張)

參數文章

後語

你盼世界，我盼望你無bug。這篇文章就介紹到這裏。

能夠發現，在基礎篇中，主要的都是一些概念題，花個10分鐘左右就能看完了。不須要咱們像學習 RSA握手、ECDHE握手、數字簽名那些知識點同樣，拼命的理解。更多的都是一些硬核知識，須要咱們緊緊記住。

這個系列文章的最後我都會送給你們一段情話來表達我對你們的感謝：

"世界上有兩句語言最浪漫動人"

"第一句是「我愛你」"

"第二句是「你寫的文章真好看」"

"看官你看這樣好很差？"

"之後您說第二句"

"而後我說第一句"

啊啊啊啊...太提莫的撩了我都受不了我本身...

喜歡「霖呆呆」的小夥還但願能夠關注霖呆呆的公衆號 LinDaiDai 或者掃一掃下面的二維碼👇👇👇.

我會不定時的更新一些前端方面的知識內容以及本身的原創文章🎉

你的鼓勵就是我持續創做的主要動力 😊.