經過講故事搞定前端網絡知識

本文約6000餘字，閱讀須要10分鐘左右。

寫在最前

有人說，前端工程師的網絡基礎很弱，說不少都是非計算機的，門檻低，其實不能一律而論。可是既然人家吐槽了，那咱們就提升本身唄。

沒有規矩，不成方圓

前端工程師對這句話應該有比較深入的感覺吧，這也多是前端變化真的太 TM 的快了。但變化的這麼快，老是要沉澱下來一些 規矩 吧，否則的話還能不能過了。

那沉澱下來的規矩在哪呢？

規矩有不少，好比：AMD，CMD、Promise 等，均可以看作是一種 規矩 ，下文統一叫標準吧。

有句話是這樣說的:

能夠隨便造庫，可是不要隨便定標準。

也就是說，若是沒有足夠多的人達成共識的話，那麼你造的標準其實並無什麼卵用。

因此，靜下來想一下，咱們從哲學的角度看：

若是沒有標準，那麼這個世界將會變的很是無序和混亂，正由於有了標準，世界才變的有序整齊。

對此咱們能夠類比數據概括法進行推導一下：

咱們將世界的網絡( Internet ——國際互聯網)，進行概括，得出一個結論，若是世界上的網絡沒有約定標準的話，那也將會變的異常混亂。

因此，咱們學習網絡基礎，其實就是在學習當今 Internet 的標準。當咱們學會了標準後，咱們就能夠遵循它，而後去作一些咱們想實現的東西。其實，你會發現，不少東西，都是這個道理。

now，咱們應該就知道要怎麼去提升咱們的網絡基礎了。

咱們要去學習 Internet 的標準，看看它的標準是什麼，爲何要這樣去設計標準，以及這樣寫的好處是什麼，還有這樣設計的編程思想是什麼。

編程思想有時候會給咱們帶來不少不同的感覺。

爲何如今有 MVP 、MVVM 、MVX 等設計模式。那是由於優秀的程序員，去學習 MVC 的經典設計思想後，獲得靈感，而後將一個經典設計思想，擴展出不少更加優秀的設計思想。因此，這也是咱們去學習一個東西的目的，也是一個可以使咱們造成一種自我驅動的一種學習模式。只有這樣，咱們才能不斷進步吧。

---

好了，不胡扯了，那下面我就開始以我我的的學習和看法，去闡述一下 網絡基礎 。

PS：Promise 有 PromiseA/B/C/ 等等社區標準，可是最終選擇了 PromiseA+ 做爲官方標準。

Internet 並不神祕

Internet 真的並不神祕，且聽我說：

想上網，首先你得有網絡設備吧，這裏不必定是要你去買，多是別人給你提供好了，好比運營商拉線子過來了，你就不用買線子了丫(手動滑稽)，還有主機、交換機、路由器等，這些基本組成了 Internet 的網絡設備。

可能一些人不理解每一個設備的做用，可是有一些東西，當你不瞭解的時候，就嘗試使用 代入法 去理解。好比，可能對交換機和路由器不瞭解，可是不去了解，又會對後面的瞭解形成障礙，那麼怎麼辦呢？

咱們能夠把硬件設備當成軟件看待

畢竟硬件裏面也是有編的代碼丫，固然有些沒有代碼，好比線子，集線器，可是咱們能夠認爲裏面寫了個空函數啊，那這樣就能夠從軟件層面理解硬件了。

那再可愛一點:

咱們能夠把完成特定功能的硬件當作是軟件中的功能模塊，有入參，有出參。

再形象點，能夠理解成中間件

數據就是在一個個中間件中進行傳輸，而且在每一箇中間件中作相應的處理，好比封裝，驗證正確性，最後數據展現在了你的眼睛裏。

若是這樣去理解，是否是感受沒有想象中的深奧難懂了呢。

其實咱們的目的就是：

把抽象深奧的知識形象化，而後把形象化的知識抽象成咱們能理解的樣子。

這樣咱們就好像讓咱們可愛的腦子完成了一次 babel 轉譯，真是有趣，這是一個快速理解深奧知識的一個技巧。知識不能學死了，萬變不離其宗，不少地方都是同樣的思想，學會融會貫通是一種很重要的能力。

一道經典題引起的聯想

你能說說三次握手，四次揮手的過程嗎？

相信不少人都會被問到過，這是在考察網絡知識的狀況下，基本少不掉的問題，也說明了這個問題所體現的知識是基礎的，是在考察你的網絡基礎。

如今當咱們再次看到這個問題，咱們能夠嘗試向上溯源一下。好比，想一下爲何要有這個過程，爲何要這樣去作，我兩次握手解決不行嗎，我不作第四次揮手不能夠嗎？

這裏有一篇我的認爲還不錯的文章：

跟着動畫學習TCP三次握手和四次揮手

關於三次握手和四次揮手的回答我就不回答了，上面文章已經介紹了比較清楚了。有啥疑問，能夠文末掃我微信二維碼，咱們私聊交流一波( 滑稽臉 )。

數據和電的故事

這是我胡謅的一個故事：

將數據從一個主機 [北京] 傳輸到另外一個主機 [南京] 是一個複雜的過程，不像是輸電那樣，一股腦輸過來就行了，固然輸電也是一門高學問，好比高壓輸電。

可是數據這東西比起電，可複雜多了。

好比，電是中央空調，誰掏錢，我就流向誰，你們都同樣，沒有什麼。基本不會存在像：你這家電好可愛哦，你家的電比我家的電帥多了的這些狀況😂。經過這個小栗子，我主要想說明電沒有隱私，不具備讓用戶損失什麼東西的可能。今晚電壓低了，忍一忍，明天換個大的變壓器，晚上就正常了，用戶也不會說什麼。

相比之下，數據可不同了，數據是一種具備隱私性質的信息，既然具備隱私，那就得保證安全性和完整性，並且不能時而安全，時而不安全，時而完整，時而不完整，因此一下就大大提升了傳輸的複雜程度。

一張圖引起的聯想

下面咱們看一張圖：

首先這張圖展現了目前整個 Internet 的層級結構。我如今也不解釋爲何是這樣的，由於這是標準，已達成共識。可是我想說幾個狀況。

第一個狀況：你確定不止一次看到過這種圖，可是不少人仍是會在面試的時候被問倒，一時想不起來，這種狀況的緣由，基本是當初沒有理解，或者沒有進行形象化的記憶。好比一個血淋淋的事實，就是英語單詞背了那麼多，仍是很快就忘。那麼如今，咱們再看到這個圖時，怎麼保證下一次再也不被問倒了呢？

那就要從記憶學上作文章了，要聯想，要有故事參與進來，帶劇情的那種。OK ，那如今，咱們從這張圖能聯想到什麼？這是一個問題，那麼跟着我開始聯想吧。

第一個角度

從前端角度來聯想，OSI 七層模型到 TCP/IP 四層模型的轉換過程當中，很明顯是作了封裝了。

從中間件的角度來思考，這 7 層或者 4 層，咱們均可以把每一層看作是中間件。數據在中間件之間進行流動，那麼每一次通過一箇中間件，也就意味着會進行一次數據處理。每一箇中間件完成一個特定的功能。 TCP/IP 的四層是將七層的模型包裝了一下，化繁爲簡的哲學。將功能重複性的層合併在同一層，有利於確保每一層的功能相對獨立，屬於更高級別的抽象。隱藏了細節，同時層級之間的功能區別更加明顯。

第二個角度

能夠從 npm 包的角度來思考，你會發如今 TCP/IP 分層結構中，高層級會依賴低層級。就好像是 npm 包，安裝 A 包，你會自動安裝 B 包，B 包又會依賴 C 包。也就是，要想安裝成功 A 包，那麼 B 包, C 包都要參與。OK，那這樣理解的話，我應用層發起的數據流動，必定會依賴傳輸層，網絡層，接口層。因此一些前端工程師只知道發起 ajax 或者 fetch 請求的時候，走了下 http 。對於走不走 tcp , ip ，接口層。不太清楚。因此，看到這裏，我以爲小夥伴仍是要好好理解一下你發起的數據請求是如何在網絡中進行流動的。

HTTP/TCP/IP 三者的聯繫

三者有什麼聯繫，這裏我舉個栗子，雖然不能算準確，但足夠形象。

IP 是以主機爲單位，經過 IP 能找到你所在的城市。

TCP 是以主機的端口爲單位，經過 TCP 能找到你所在城市的你居住的小區。

HTTP 呢，它是以用戶進程爲單位，經過 HTTP 能找到你所在城市所在小區的房間號。

經過上面的比喻，是否是發現很是通俗易懂，這就是講故事的魅力，哈哈哈。這個例子也能說明，若是你想找到房間號，那你確定是要先找到城市，而後再找到小區，最後找到房間號。也就是說你想發送 HTTP 成功的話，那必須是 TCP , IP 都要成功，你才能發送 HTTP 成功。

2019年2月3號備註：上面這個 HTTP/TCP/IP 三者的聯繫 的例子舉的很不許確，在此表示道歉。

已有大佬和我進行了交流：

上圖已經給出了正確的解釋，主要緣由是我強行故事了一波，致使有點本末倒置，並且還容易誤導小夥伴，道歉道歉😂。

IP

IP 層是網絡層，定義了不一樣主機之間的尋址方式。簡單點理解，就是經過 IP 地址來找到對應的主機。

TCP/UDP

傳輸層是很是重要的一層，具備承上啓下，向上對應用層提供通訊服務，向下將應用層信息封裝爲網絡信息。

傳輸層鏈接主機之間的進程，同一主機中不一樣進程的網絡通訊經過端口進行區分，因此傳輸層爲主機提供的是端口對端口的服務。

這裏提一下，進程是什麼

能夠這樣理解，當應用程序被調入內存運行後，這個應用程序就能夠被稱爲進程了。

端口不屬於任何應用程序

應用程序經過系統調用與某個端口創建鏈接( Binding )後，纔會肯定這個端口是爲這個進程服務的，數據什麼的都是經過端口來傳輸給進程的。由於端口不屬於任何應用程序，只是在綁定的時候，纔會肯定爲哪一個進程服務。

傳輸層和端口的交互方式

傳輸層傳給該端口的數據都被相應的進程所接收，相應的進程發給傳輸層的數據都從該端口發出。這裏的端口是傳輸層的尋址方式。

端口是軟件級的概念

端口是由 16 位二進制數來表示的正整數，也就意味着一個主機理論上最多有 65535 個傳輸層信道。可是一般都少於 65535 個。 好比說，80 端口，21 端口，8080 端口等，都是默認的端口號，經過這些端口號來完成特定的通訊。

HTTP

HTTP 是構建在 TCP/IP 之上的應用層協議，而 HTTPS 是在 HTTP 之下加入 SSL/TLS 。

簡單介紹下，HTTP 是超文本傳輸協議的英文縮寫，它是 Internet 上最主要的 Web 應用層標準，HTTP 可以傳輸任何格式的數據。

做爲前端工程師，咱們應該從 HTTP 裏學習到什麼呢？

咱們說一個事情，好比面試常常問你，輸入一個 url 後，會發生什麼，其實若是你理解的比較深的話，徹底能夠畫個圖告訴他，固然打電話就只能口述了。

1. 首先你點擊一個 url ，是發起了一次 http 請求
2. http 請求必定會依賴 tcp ，ip 等。也就是意味着你要作 tcp 建連，IP 查詢。
3. 若是你的 url 是域名的話，還須要先去解析域名，也就是 dns 操做。使其變成 ip 地址。這個過程必定是在應用層完成的，由於應用層不完成的話，那 TCP 層就拿不到 IP 地址，那 IP 也就收不到地址數據。因此咱們這樣一推導，也就這知道了 dns 是在應用層完成的。
4. 數據正常傳到接口層後，確定是要傳到對應 IP 地址的服務器的對應端口。也就是 TCP 建聯。TCP 要先建連成功，HTTP 才能進行傳輸。由於是依賴關係，接收方的 HTTP 須要從 TCP 那獲取數據。若是 TCP 建連失敗，那 HTTP 也就不可能建聯成功。
5. 若是都成功了，那就傳輸數據吧。
6. 傳輸完，TCP 鏈接關閉。頁面有了新的數據展現在用戶的面前

看到這，你確定會想，緩存呢，這裏我沒有把緩存考慮進去，今晚緩存無處不在，緩存這個點你們自行填充吧。

下面能夠用一張很酷的圖，展現當輸入 URL 時，整個過程是什麼樣子的。以下圖所示：

HTTP 是一種標準，他有本身的形式，你看看 HTTP 的數據傳輸形式，你大概就能想象到 TCP 大概是什麼樣子的數據傳輸形式了。

網絡請求的數據結構是前端控制的，好比請求的方法，請求的 url ，請求的參數等。那麼響應的數據結構就應該是由服務端來控制了，服務端給咱們必要的返回信息，好比狀態碼，數據，緩存控制等。

HTTP狀態碼

在 web 編程中，狀態碼是很是重要的事情。

設置狀態碼的目的是什麼？

是爲了讓開發人員和用戶知道服務器是正常處理了請求仍是出現了錯誤。瞭解目的，對於咱們去了解狀態碼爲何會這樣分，是很是必要的事情，至少內心不那麼感受到陌生了。

而在狀態碼中，有一個系列很是重要，那就是 3XX 系列。

301 ，302 的區別

302 臨時重定向

臨時重定向，意識是當服務端關閉的時候，客戶端發起 url 請求，是不能成功的。它還須要向服務端發起請求，讓服務端重定向到目標網址，也就是返回 location ，而後再轉到目標網址。

PS: 思考一下，爲何會有 302 ？

301 永久重定向

永久重定向，是即便服務端關閉了，瀏覽器端發起 url 請求，也能夠不通過服務端而直接轉到目標網址。除非清理緩存，不然之後再次訪問都是直接訪問另外一個地址。

HTTP 請求方法

能夠這樣理解，HTTP 就比如一個對象參數，裏面有 Method ，表明 HTTP 的請求方法，用來告訴服務器，客戶端訪問你的 url 的目的是什麼，是獲取信息，上傳數據仍是刪除信息。一般用到的最多就是 GET 和 POST 。常常用的 GET 和 POST 就不說了，這裏說一下 OPTIONS ：

OPTIONS 是爲客戶端提供一種查詢 URL 地址中有哪些可用的訪問方式的方法。

PS: 留給思考，這個 OPTIONS 的使用場景是什麼呢？

POST 和 PUT 的區別：

POST：POST的數據，服務器必須保證數據被完整的保存，而且不容許出現重複的 POST 數據提交。一般在 HTML 中經過表單來提交數據。

PUT： PUT 容許客戶端提交重複的數據，當提交重複的數據時，會用新提交的數據覆蓋掉服務器已有的數據。

PS: 這裏推薦一本我讀過的書籍 《圖解HTTP》寫的很不錯，圖文並茂，簡單易懂，值得閱讀。

HTTP是怎麼在服務端走的

看下面我畫的一張圖，這是服務器端程序、Web 服務器、客戶端之間的關係：

上圖是主流的模式，Web 服務器僅起到橋樑的做用，即將瀏覽器的 HTTP 請求解碼，轉換成服務器端程序可以識別的接口調用方式，而後服務器端程序會將生成的返回封裝成 HTTP Response ，並返回給用戶。

注意1：

在服務端，用戶發的請求，若是是爲了獲取靜態資源的話，通常是不通過服務器端程序的，直接經過服務端的緩存機制，返回資源給用戶，好比 Nginx 的靜態資源緩存。不走服務端程序，會大大提升響應速度。

注意2：

服務端通常都是在公司的內網，外網是沒法訪問的，發起 HTTP 請求，其實大多數狀況下都是先經過 Nginx 進行反向代理，同時也是負責流量轉發，將不一樣的請求轉發給內網特定的服務器。

Socket

Socket 在漢語中是指孔或插座的意識，顧名思義，插上了就能夠通訊了。Socket 一開始是做爲 BSD UNIX 的進程通訊機制，而後逐漸成爲主流操做系統共同遵照的網絡編程標準。

Socket 是什麼

Socket 是一個通訊鏈的句柄，能夠用來實現不一樣虛擬機或不一樣計算機之間的通訊，也能夠實現相同主機內的不一樣進程之間的通信。

Socket 的組成

Socket = IP 地址 + 端口 + 協議

IP 地址 + 端口 + 協議 組成一個惟一標識，用來標識一個通訊鏈路。

能夠看到，Socket 實際上是對 TCP/IP 進行了高度封裝，屏蔽了不少網絡細節。這樣可使開發者更好地進行網絡編程。其實就是咱們寫個高度封裝內部細節的函數，經過傳參來完成指定的行爲。

能夠這麼說，全部的 TCP/UDP 等編程，基本都是按照 Socket 協議標準來進行編程的，換句話說，Socket 是一套標準，就比如 DOM ，全部語言均可以按照 DOM 的接口標準來實現本身的邏輯。

Socket 有本身的原語，開發者能夠按照 Socket 的原語在不一樣語言下的實現方式來進行網絡編程。

談談 WebSocket

WebSocket 是什麼？

這是 HTML5 定義的一種新的標準協議，實現了瀏覽器與服務器的全雙工通訊。咱們能夠將 WebSocket 理解爲 Web + Socket ，它是一種雙工通訊。

什麼是雙工通訊？

就是在同一時刻，我既能夠扮演通訊雙方的發送方，也能夠扮演通訊雙方的接收方。

爲何會出現 WebSocket

在 WebSocket 出來以前，前端的 Web 通訊基本就靠 HTTP ，可是 HTTP ( 1 或者 2 ) 請求自己有一些缺陷，好比：

1. 首部信息冗餘，每次發送請求，都要攜帶大量冗餘信息。
2. 不能實現雙工通訊。

因此在這個技術背景下，WebSocket 技術出現了，彌補了 HTTP 的缺陷。可是咱們又不能不用 HTTP ，由於已經用的場景太多了，因此就綜合了一下，讓 WebSocket 協議是在 HTTP 協議之上的。這樣就能夠作到平穩過渡到新的通訊協議上了。

WebSocket 的通訊原理

WebSocket 是創建在 HTTP 之上的，也就意味着你要創建 WebSocket 的話，須要走一次 HTTP ，走完後，你的 WebSocket 就創建起長鏈接了。而後只要不是主動斷開的，就會保持好客戶端和服務端之間的鏈接，不會使其斷開。當有數據傳輸的時候，會直接進行傳輸，再也不發起 HTTP 請求。

前端使用 WebSocket 很簡單，就那麼幾個 API ，可自行去查看。可是咱們要清楚每一個 API 究竟發生了什麼事情，只有理解了背後的那些真相，咱們纔算是真正理解了 WebSocket 。

WebSocket 優勢

1. 支持推送功能，服務端能夠向客戶端推送數據。
2. 減小通訊量，一方面是 WebSocket 的首部信息很小，另外一方面是不須要頻繁進行 HTTP 鏈接了，能夠進行持久鏈接。

這裏推薦一篇文章，寫的挺不錯，能夠看看：

WebSocket 是什麼原理？爲何能夠實現持久鏈接？

C/S 和 B/S 架構

對於前端工程師來講，仍是要去了解一下 web 架構的發展演變的，提到發展演變，不得不說一下 C/S 和 B/S 架構。

C/S

C/S ，即 Client/Server ，當前網絡編程的主流架構模型。 Clent 是客戶端的意識，S 是 服務端的意識。

B/S

即 Browser/Server ，是使用 Web 瀏覽器做爲客戶端的應用軟件。

從上面介紹咱們能夠推斷出，C/S 中的 C 有不少，好比 APP ，桌面應用等。可是 B/S 中的 B 只特指瀏覽器。

問題來了，B/S 結構與 C/S 結構相比，有什麼區別或者說有什麼優點呢？

B/S 的優缺點

優勢

第一： 最顯而易見的就是，B/S 部署升級快，無需應用程序更新，由於 B/S 系統的全部應用程序都是部署在服務器上的，不須要更新客戶端軟件。因此不少 APP 內都內嵌 H5 ，Hybrid 。 由於不須要審覈，能夠直接發佈。爲何不須要審覈呢，是由於前端的跨域限制，JS 是沒法獲取設備其餘信息的，不須要擔憂安全問題，也就不用審覈了。

第二： 跨平臺，由於操做系統都支持 Web 瀏覽器，因此只須要在瀏覽器中運行就行了。

缺點

安全性要求高，B/S 架構是創建在廣域網上的，面向全部用戶。經過 url 就能夠訪問服務器端資源，因此安全性要求要比 C/S 要高。

備註

1. 沒有寫過多細節，一些細節自行去理解吧，也能夠私聊我技術交流。
2. 本文在總體上闡述了一個前端工程師應該要去掌握的網絡知識。
3. 本文字數還行，看着應該不怎麼累( 笑哭臉 )。

參考鏈接

關於TCP/IP，必須知道的十個知識點

文末總結

讀到這，咱們會發現，網絡知識沒有那麼神祕，認真去學習，你也能夠搞定前端網絡知識。

交流

掘金系列技術文章彙總以下，以爲不錯的話，點個 star 鼓勵一下，也能夠 github 關注我一波，持續輸出精品文章。

github.com/godkun/blog

我是源碼終結者，歡迎技術交流，歡迎關注個人掘金博客，不按期分享知識。

對了，還差了什麼，固然是祝各位小夥伴豬年大吉吧！！