【譯】爲何要了解HTTP

原文地址：Why should I care about HTTP?
原做信息：by Devon Campbell. Dec 15 '18 Originally published at raddevon.com on Dec 14, 2018
關鍵詞：HTTP ,BEGINNERS
wiki地址： wiki

---

「HTTP」是URLs地址開頭的前四個字母，對吧？這就是你構建網站所必需要知道它的緣由。
就像理解二進制(binary)同樣，它也會幫助你理解你在其餘方面不會理解的問題。
他不是你必需要掌握的知識點(material:材質、物料)，可是理解他會使你成爲一個更全面的開發者。
做爲咱們軟件所必需要遵循的基本通訊協議(primary communication protocol)，讓咱們來學習一下HTTP吧！

什麼是HTTP？

HTTP就是超文本傳輸協議(Hypertext Transfer Protocol)，他是一個爲發送和接收（傳輸）web頁面（超文本）而設定的規則（協議）。
儘管它被稱做超文本傳輸協議(HTTP)，但它還能夠被用來發送許多除超文本之外的其餘內容 - 好比，JSON和images。

HTTP是如何工做的？

HTTP通訊發生在客戶端和服務器之間。客戶端發起HTTP請求，服務器響應客戶端的請求。你的web瀏覽器就是一個HTTP客戶端。
當你瀏覽一個web頁面的時候，你的瀏覽器發送一個HTTP請求到一個能響應的服務器上，它（幾乎）就是這麼簡單。

事實上，一個簡單的web頁面一般由多個請求組成。一般狀況下，一個請求由一些HTML發起，而後服務器響應這個HTML請求。
瀏覽器開始渲染這個頁面，緊接着會發起更多渲染這個頁面時所需的其餘資源的請求 —— 像JavaScript文件、CSS文件和圖片等的請求。

請求的部分組成

下邊就是訪問RadDevon.com的主頁時原始請求的樣子：

GET / HTTP/2
Host: raddevon.com
User-Agent: curl/7.54.0
Accept: */*

當你在地址欄輸入「raddevon.com」並按下回車後，你的瀏覽器就會發送這個請求到個人主機上，如下是部份內容：

• GET —— 請求方法。它告訴服務器這個請求想要作什麼。這個請求但願服務器可以返回一些數據。MDN有一個很好的請求方法參照表。

• / —— 咱們請求的資源地址。因爲咱們請求的主頁就在服務器的根目錄下，因此「/」就是咱們請求資源的地址。

• HTTP/2 —— 協議。這說明了該特殊請求是基於http/2.0版本的協議發出的。

另外三行就是頭信息，他們告知接收請求的服務器更多關於這個請求的信息。

• Host是很是明顯的。 他用來識別目標主機。

• User-Agent 用來識別發送請求的客戶端，我例子中是用一個簡單的Unix命令行看成請求客戶端發送的這個curl的請求。當你用瀏覽器發起一個請求的時候，這裏就會展現瀏覽器的名字和版本。

• Accept 告訴服務器，客戶端能夠接收的響應類型

這個網頁中講述了更多在你的網絡請求中能夠用到的請求頭，我這裏僅僅是本次請求發生時用到的。你甚至能夠本身建立請求頭來給服務器發送額外的信息。

除了頭部信息之外，你的請求可能還會有一個身體。當一個表格被提交後，他的數據一般放在請求體中被髮送給服務器。

我爲何須要去理解HTTP？

理解HTTP是怎麼工做的，特別的，理解各類各樣的請求狀態碼和他們各自的意思，能幫助你解決本身程序的問題、恰當的處理錯誤。
瞭解到你頁面中用的每個資源（腳本、圖片、樣式表、等等）都表示一個單獨的請求也能夠幫你優化本身程序的性能。

這篇文章幫助到你了嘛？個人目標是去幫助人們逐漸深刻到web開發領域裏來。🤬🔜🤩註冊Rad Devon網站會獲得一個免費輔導課程，讓我來幫你想下一步該怎麼作。

下圖中展現瞭如何去查看瀏覽器爲應用程序發起的請求。你瀏覽器的開發者工具能夠展現全部的請求、響應狀態、甚至請求頭和響應體。
下圖是一個例子，在Chrom開發者工具的「Network」面板中展現了Chrome瀏覽器爲RadDevon.com發起的請求。

當你第一次切換到"Network"面板時，他多是空的。你能夠從新刷新頁面，他就會捕獲頁面重載時全部的請求。

每一行表示一個瀏覽器渲染這個頁面時所發起的請求，若是你點擊其中一條請求，你會看到幾個關於這個請求的選項卡，裏邊包含不少這個請求的信息。
下圖是返回Red Devon主頁HTML文件的主要請求的response響應信息選項卡。

請求是如何影響性能的？

一個完整的請求所花費的時間是這個請求到達服務器的時間、服務器準備響應的時間、響應返回的時間 的時間和。
每個請求都會有額外的多於請求返回的數據所須要花費的時間的開銷。若是你能夠減小你頁面中資源的大小、減小請求次數，你就能夠減小加載頁面時所花費的時間總數。

想象一下，你正在幫助某我的烘培一個蛋糕。你須要成爲他們的「跑步者」（譯者注：能夠想象成中國飯店中「跑堂」、「傳菜」的。），
在他們專一於烘焙時提供給他們任何他們所須要的東西。他們開始要求你把麪粉拿過來，你走向櫥櫃，拿到麪粉，而後把它帶回來（給烘培者someone）。

接下來，他們要求你把可可粉拿過來，你略微生氣的走向櫥櫃，拿到可可粉，把它們帶回來。如今，他們又跟你要發酵粉。
好吧，這有一點荒謬。若是他們要求你把櫥櫃中全部他們所須要的東西都拿過來，而你就能夠簡單的一次性把這些東西都拿過來，這樣豈不是更好嗎？

好了，儘管這樣可能會花費你更多一點的時間去把全部的東西都拿回來，由於它們可能更重一點。但這樣總比你三次所花費的時間要少一點。
你也可讓過程更快，若是你只是拿夠他們須要的物品的數量而不是拖着每個超過五磅的袋子。若是他們根本就不須要可可粉的話，這也可使速度加快。

這是當你優化你的web程序性能時可能用到的相同的方法。試着用下邊的順序進行優化：

1. 消除沒必要要的請求經過刪除一些你根本不須要的圖片和腳本。

2. 減小重量經過優化圖片和壓縮代碼。

3. 減小請求的數量經過分別合併全部的js和css到一個對應的文件中。

調出你開發者工具的「Time」列去檢查哪個請求讓你的頁面變慢的。

理解HTTP不只僅能幫助咱們提升頁面性能，還可以使你的程序更可用、更容易調試。
當程序行爲不符合預期時，可能就是請求的緣由，這就使得可以理解 「Network」 面板展現給你的調試信息很是有價值。HTTP狀態碼是一個開始的好地方。

HTTP狀態碼都是什麼？

HTTP狀態碼是由服務器連同其餘響應一塊兒返回給HTTP客戶端的。用來告知客戶端請求是否成功。若是請求失敗，就會返回相應的失敗信息。如下就是狀態碼在Chrome開發者工具中的亞子：

狀態碼由三位數的數字組成，如下是幾類狀態碼和他們各自表明的意思：

• 100– 1開頭的響應表示」信息響應「，就我我的而言還歷來沒有看到過100這個狀態碼，我確信有這個狀態碼，可是我不肯定他們是否常見。

• 200– 表示請求成功而且沒有任何錯誤警告。服務端完成了你請求的任務、而且返回了你須要的數據。

• 300– 表示你的請求被重定向了，這個響應也能夠算是成功的，由於服務端此時是知道你請求資源的地址。即便不是你所請求的那個地址。

• 400– 400類的狀態碼是客戶端錯誤碼，他表示請求的一些內容不是服務端所指望的。好比你可能發送了一個url參數，可是這個參數不被你所請求的端點支持。若是狀態碼是4開頭的，那你可能在響應內容中得不到任何有用的信息。

• 500– 500類的狀態碼是服務端的錯誤碼，他表示請求已經完成，可是在服務端出了一些問題。跟400類的錯誤同樣，當狀態碼爲5開頭時，你也許不能獲得任何有用的數據。

以上涵蓋了幾種狀態碼的類別。可是每一類狀態碼內部都有更具體的含義。
MDN有一個很棒的文章講解了每個狀態碼的含義.他甚至能夠幫你精確你將來應用程序中的問題，他也能夠更智能地幫你解決你程序中失敗的請求。

好比說，若是一個請求的狀態碼是400，那是由於你的用戶在經過參數傳遞給API的表單中輸入了無效的數據，你可能想展現一個錯誤的信息以告訴他們怎麼去提供有效的數據。
另外一方面，若是你獲得了500的錯誤，意味着服務端發生錯誤，這樣可能你的用戶不能作任何事情去糾正他。

爲何狀態碼老是不可靠的？

理解狀態碼有利於調試並解決咱們程序中的錯誤，但問題是他們老是不可靠的，緣由以下。

當開發者寫服務器端代碼時，他們有充足的自由決定權去選擇對他們來講有意義的錯誤碼。
上面只是關於每一類狀態碼所表明的意思的描述，可是並不意味着在每個應用程序中都會按照這個含義去實現。事實上，他們確實沒有。

你可能獲得一個響應體中包含有用數據的500的響應，或者你可能獲得一個包含錯誤信息的200響應。
每個應用程序都是一個獨特的雪花，因此在你寫前端程序時，只要確保你知道實際返回的是什麼意思便可。

從理解HTTP中快速取得成功

即便你在不瞭解HTTP的狀況下一直在構建web，但大體理解HTTP依舊是頗有價值的。
你將會有一個更好的工具去提升你的網站性能，你能夠更輕鬆的解決來自服務器的問題、你也能夠調試那些你可能沒法調試的問題。

這是一個不錯的好處套件，做爲交換，您能夠閱讀一些內容，並在瀏覽器的開發工具中進行一些探索。

---

做者信息

Devon Campbell
我幫助人們遠離他們像屎同樣的工做併成爲一個web開發者。

@raddevon twitter github raddevon.com