前言
在不那麼遙遠的一些年以前，一個在江湖中行走的前端，只需要瞭解“前端三劍客”就足以找到一份工作。很多前端只限於 CSS，HTML、JS，網路基礎，資料結構之類的都不甚瞭解。不過這個時期的前端也是最受鄙視的時期，這個時期前端的大量工作依賴於後端，且不需要動畫效果和互動效果。
現如今前端圈已經發生翻天覆地的變化，Vue，React，ES6，HTML5，CSS3，Webpack, PostCss 等技術層出不窮。作為一個有格局的前端，對網路基礎定是要了然於心的。
如果你對網路基礎還不太瞭解，以下的內容可以給你提供一個思路；如果你對此已經瞭然於心，以下的內容煩請批評指正。
入題
任何事物的誕生，最初都是服務於極少數人的。漸漸地被這極少數人推而廣之，我們大眾就開始接觸瞭解它，網際網路是如此，麻將亦是如此。不管是網際網路還是麻將，它們都增強了人與人之間的交流。 接下來我會講以下內容：
- 五層因特網協議棧
- HTTP 與 HTTPS 的區別
- TCP/IP 協議
- 三次握手和四次揮手
- DNS 域名解析
- 五類 IP 地址
- 跨域的原因及處理方式
- 正向代理和反向代理
- CDN 帶來的效能優化
- HTTP 強快取&協商快取
這一篇我會講 1 ~ 5, 6 ~ 10 我會在下一篇講。
五層因特網協議棧 TOP
五層因特網協議棧這個知識點對你來說或許有點枯燥，不過當你對這個協議棧有了一個初步的瞭解之後，你之前的某些疑問就會很明朗。
一、應用層
應用層( application-layer ）的任務是通過應用程式間的互動來完成特定網路應用。應用層協議定義的是應用程式（程式：主機中正在執行的程式）間的通訊和互動的規則。對於不同的網路應用需要不同的應用層協議。在網際網路中應用層協議很多，如域名系統 DNS，支援全球資訊網應用的 HTTP 協議，支援電子郵件的 SMTP 協議等等。
我們把應用層互動的資料單元稱為報文
域名系統
域名系統( Domain Name System )是因特網的一項核心服務，它作為可以將域名和 IP 地址相互對映的一個分散式資料庫，能夠使人更方便的訪問網際網路，而不用去記住能夠被機器直接讀取的 IP 數串。
http 協議
超文字傳輸協議（ HyperText Transfer Protocol ）是網際網路上應用最為廣泛的一種網路協議。所有的 WWW（全球資訊網） 檔案都必須遵守這個標準。
二、傳輸層
傳輸層(transport layer)的主要任務就是負責向兩臺主機程式之間的通訊提供通用的資料傳輸服務。應用程式利用該服務傳送應用層報文。
傳輸層常用的兩種協議
- 傳輸控制協議-TCP：提供面向連線的，可靠的資料傳輸服務。
- 使用者資料協議-UDP：提供無連線的，盡最大努力的資料傳輸服務（不保證資料傳輸的可靠性）。
TCP（Transmisson Control Protocol）
- TCP 是面向連線的（需要先建立連線）；
- 每一條 TCP 連線只能有兩個端點，每一條 TCP 連線只能是一對一；
- TCP提供可靠交付的服務。通過TCP連線傳送的資料，無差錯、不丟失、不重複、並且按序到達；
- TCP 提供全雙工通訊。TCP 允許通訊雙方的應用程式在任何時候都能傳送資料。TCP 連線的兩端都設有傳送快取和接收快取，用來臨時存放雙方通訊的資料；
- 面向位元組流。TCP 中的“流”（Stream）指的是流入程式或從程式流出的位元組序列。
UDP（User Datagram Protocol）
- UDP 是無連線的；
- UDP 是盡最大努力交付，即不保證可靠交付，因此主機不需要維持複雜的連結狀態；
- UDP 是面向報文的；
- UDP 沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如直播，實時視訊會議等）；
- UDP 支援一對一、一對多、多對一和多對多的互動通訊；
- UDP 的首部開銷小，只有 8 個位元組，比 TCP 的 20 個位元組的首部要短。
- 單工資料傳輸只支援資料在一個方向上傳輸
- 半雙工資料傳輸允許資料在兩個方向上傳輸，但是，在某一時刻，只允許資料在一個方向上傳輸，它實際上是一種切換方向的單工通訊；
- 全雙工資料通訊允許資料同時在兩個方向上傳輸，因此，全雙工通訊是兩個單工通訊方式的結合，它要求傳送裝置和接收裝置都有獨立的接收和傳送能力。
三、網路層
網路層的任務就是選擇合適的網間路由和交換結點，確保計算機通訊的資料及時傳送。在傳送資料時，網路層把運輸層產生的報文段或使用者資料包封裝成分組和包進行傳送。在 TCP/IP 體系結構中，由於網路層使用 IP 協議，因此分組也叫 IP 資料包 ，簡稱資料包。
網際網路是由大量的異構（heterogeneous）網路通過路由器（router）相互連線起來的。網際網路使用的網路層協議是無連線的網際協議（Intert Prococol）和許多路由選擇協議，因此網際網路的網路層也叫做網際層或 IP 層。
四、資料鏈路層
資料鏈路層(data link layer)通常簡稱為鏈路層。兩臺主機之間的資料傳輸，總是在一段一段的鏈路上傳送的，這就需要使用專門的鏈路層的協議。
在兩個相鄰節點之間傳送資料時，資料鏈路層將網路層接下來的 IP 資料包組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。每一幀包括資料和必要的控制資訊（如同步資訊，地址資訊，差錯控制等）。
在接收資料時，控制資訊使接收端能夠知道一個幀從哪個位元開始和到哪個位元結束。
五、物理層
在物理層上所傳送的資料單位是位元。 物理層(physical layer)的作用是實現相鄰計算機節點之間位元流的透明傳送，儘可能遮蔽掉具體傳輸介質和物理裝置的差異。使其上面的資料鏈路層不必考慮網路的具體傳輸介質是什麼。“透明傳送位元流”表示經實際電路傳送後的位元流沒有發生變化，對傳送的位元流來說，這個電路好像是看不見的。 在網際網路使用的各種協議中最重要和最著名的就是 TCP/IP 兩個協議。
同 OSI 七層協議模型、TCP/IP 四層模型的區別
-
OSI 七層模型
OSI七層協議模型主要是：
應用層（Application）、表示層（Presentation）、會話層（Session）、傳輸層（Transport）、網路層（Network）、資料鏈路層（Data Link）、物理層（Physical）。 -
TCP/IP四層模型
TCP/IP是一個四層的體系結構，主要包括：
應用層、傳輸層、網路層和鏈路層。
各層對應
以下一張圖很好的說明了這三種協議的區別
HTTP 與 HTTPS 的區別 TOP
| 區別 | HTTP | HTTPS |
|---|---|---|
| 協議 | 執行在 TCP 之上，明文傳輸，客戶端與伺服器端都無法驗證對方的身份 | 身披 SSL( Secure Socket Layer )外殼的 HTTP，執行於 SSL 上，SSL 執行於 TCP 之上， 是新增了加密和認證機制的 HTTP。 |
| 埠 | 80 | 443 |
| 資源消耗 | 較少 | 由於加解密處理，會消耗更多的 CPU 和記憶體資源 |
| 開銷 | 無需證書 | 需要證書，而證書一般需要向認證機構購買 |
| 加密機制 | 無 | 共享金鑰加密和公開金鑰加密並用的混合加密機制 |
| 安全性 | 弱 | 由於加密機制，安全性強 |
對稱加密與非對稱加密
對稱金鑰加密是指加密和解密使用同一個金鑰的方式，這種方式存在的最大問題就是金鑰傳送問題，即如何安全地將金鑰發給對方；
而非對稱加密是指使用一對非對稱金鑰，即公鑰和私鑰，公鑰可以隨意釋出，但私鑰只有自己知道。傳送密文的一方使用對方的公鑰進行加密處理，對方接收到加密資訊後，使用自己的私鑰進行解密。
由於非對稱加密的方式不需要傳送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，非常的慢.
綜上：我們還是用對稱加密來傳送訊息，但對稱加密所使用的金鑰我們可以通過非對稱加密的方式傳送出去。
HTTP2
HTTP2 可以提高了網頁的效能。
在 HTTP1 中瀏覽器限制了同一個域名下的請求數量（Chrome 下一般是六個），當在請求很多資源的時候，由於隊頭阻塞當瀏覽器達到最大請求數量時，剩餘的資源需等待當前的六個請求完成後才能發起請求。
HTTP2 中引入了多路複用的技術，這個技術可以只通過一個 TCP 連線就可以傳輸所有的請求資料。多路複用可以繞過瀏覽器限制同一個域名下的請求數量的問題，進而提高了網頁的效能。
TCP/IP 協議 TOP
負責傳輸的 IP 協議
按層次分，IP（Internet Protocol）網際協議位於網路層，IP 協議的作用是把各種資料包傳送給對方。而要保證確實傳送到對方那裡，則需要滿足各類條件，其中兩個重要的條件是 IP 地址和 MAC 地址（Media Access Control Address）。
IP 地址和 MAC 地址： 指明瞭節點被分配到的地址，MAC 地址是指網路卡所屬的固定地址，IP 地址可以和 MAC 地址進行配對。IP 地址可變換，但 MAC 地址基本上不會更改。
使用 ARP 協議憑藉 MAC 地址進行通訊
- IP 間的通訊依賴 MAC 地址。
- ARP 是一種用以解釋地址的協議，根據通訊方的 IP 地址就可以反查出對應方的 MAC 地址。
TCP 協議如何保持傳輸的可靠性
TCP提供一種面向連線的、可靠的位元組流服務。
1. 面向連線
意味著兩個使用 TCP 的應用（通常是一個客戶和一個伺服器）在彼此交換資料之前必須先建立一個 TCP 連線。在一個 TCP 連線中，僅有兩方進行彼此通訊；
2. 位元組流服務
意味著兩個應用程式通過 TCP 連線交換 8bit 位元組構成的位元組流，TCP 不在位元組流中插入記錄識別符號。
TCP 之所以可靠，大體上由於以下原因：
- 資料包校驗：目的是檢測資料在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段並且不給出響應，這時 TCP 傳送資料端超時後會重發資料；
- 對失序資料包重排序：既然 TCP 報文段作為 IP 資料包來傳輸，而 IP 資料包的到達可能會失序，因此 TCP 報文段的到達也可能會失序。TCP 將對失序資料進行重新排序，然後才交給應用層；
- 丟棄重複資料：對於重複資料，能夠丟棄重複資料；
- 應答機制：當 TCP 收到發自 TCP 連線另一端的資料，它將傳送一個確認。這個確認不是立即傳送，通常將推遲幾分之一秒；
- 超時重發：當 TCP 發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段；
- 流量控制：TCP 連線的每一方都有固定大小的緩衝空間。TCP 的接收端只允許另一端傳送接收端緩衝區所能接納的資料，這可以防止較快主機致使較慢主機的緩衝區溢位，這就是流量控制。
TCP/IP 通訊傳輸流
借用圖解 HTTP 一書中的圖文：
TCP 三次握手和四次揮手 TOP
TCP（Transmission Control Protocol 傳輸控制協議）是一種面向連線的、可靠的、基於位元組流的傳輸層通訊協議，由 IETF 的 RFC793 定義。
三次握手
建立連線時，向伺服器發出連線請求報文，這是報文首部中的同部位 SYN = 1，同時選擇一個初始序列號 seq = x ，客戶端程式進入了 SYN-SENT （同步已傳送狀態）狀態,等待伺服器確認；
第二次握手：
伺服器收到 syn 包後，如果同意連線，則發出確認報文; 確認報文 ACK = 1，SYN = 1，確認號是 ack = x + 1，同時也要為自己初始化一個序列號 seq = y，此時伺服器程式進入了 SYN-RCVD（同步收到）狀態；
第三次握手：
客戶端收到伺服器的 SYN+ACK 包，要向伺服器給出確認。確認報文的 ACK = 1，ack = y + 1，自己的序列號 seq = x + 1，此時，TCP 連線建立，客戶端進入 ESTABLISHED （已建立連線）狀態。
完成三次握手，客戶端與伺服器開始傳送資料。
注：
seq:"sequance" 序列號；
ack:"acknowledge" 確認號；
SYN:"synchronize" 請求同步標誌；
ACK:"acknowledge" 確認標誌；
FIN:"Finally" 結束標誌。
未連線佇列
在三次握手協議中，伺服器維護一個未連線佇列，該佇列為每個客戶端的SYN包（syn=j）開設一個條目，該條目表明伺服器已收到SYN包，並向客戶端發出確認，正在等待客戶端的確認包。這些條目所標識的連線在伺服器處於 SYN_RECV狀態，當伺服器收到客戶端的確認包時，刪除該條目，伺服器進入ESTABLISHED狀態。
建立一個連線需要三次握手，而終止一個連線要經過四次揮手，這是由 TCP 的半關閉（half-close）造成的。
四次揮手
客戶端程式發出連線釋放報文，並且停止傳送資料。釋放資料包文首部 FIN=1，其序列號為 seq = u（等於前面已經傳送過來的資料的最後一個位元組的序號加1），此時，客戶端進入 FIN-WAIT-1（終止等待1）狀態。
第二次揮手：
伺服器收到連線釋放報文，發出確認報文，ACK = 1，ack = u + 1，並且帶上自己的序列號 seq = v，此時，服務端就進入了 CLOSE-WAIT（關閉等待）狀態。
TCP 伺服器通知高層的應用程式，客戶端向伺服器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有資料要傳送了，但是伺服器若傳送資料，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個 CLOSE-WAIT 狀態持續的時間。
客戶端收到伺服器的確認請求後，此時，客戶端就進入 FIN-WAIT-2（終止等待2）狀態，等待伺服器傳送連線釋放報文（在這之前還需要接受伺服器傳送的最後的資料）。
第三次揮手：
伺服器將最後的資料傳送完畢後，就向客戶端傳送連線釋放報文，FIN = 1，ack = u + 1，由於在半關閉狀態，伺服器很可能又傳送了一些資料，假定此時的序列號為 seq = w，此時，伺服器就進入了 LAST-ACK（最後確認）狀態，等待客戶端的確認。
第四次揮手：
客戶端收到伺服器的連線釋放報文後，必須發出確認，ACK = 1，ack = w + 1，而自己的序列號是 seq = u + 1，此時，客戶端就進入了 TIME-WAIT（時間等待）狀態。
注意此時 TCP 連線還沒有釋放，必須經過 2MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的 TCB 後，才進入 CLOSED 狀態。
伺服器只要收到了客戶端發出的確認，立即進入 CLOSED 狀態。同樣，撤銷 TCB 後，就結束了這次的 TCP 連線。
可以看到，伺服器結束 TCP 連線的時間要比客戶端早一些。
四次的原因
這是因為服務端的 LISTEN 狀態下的 SOCKET 當收到 SYN 報文的建連請求後，它可以把 ACK 和 SYN（ACK 起應答作用，而 SYN 起同步作用）放在一個報文裡來傳送。 但關閉連線時，當收到對方的 FIN 報文通知時，它僅僅表示對方沒有資料傳送給你了；但未必你所有的資料都全部傳送給對方了，所以你未必會馬上會關閉 SOCKET ,也即你可能還需要傳送一些資料給對方之後，再傳送 FIN 報文給對方來表示你同意現在可以關閉連線了，所以它這裡的 ACK 報文和 FIN 報文多數情況下都是分開傳送的.
由於 TCP 連線是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的資料傳送任務後就能傳送一個 FIN 來終止這個方向的連線。收到一個 FIN 只意味著這一方向上沒有資料流動，一個 TCP 連線在收到一個 FIN 後仍能傳送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
DNS 域名解析 TOP
當你在瀏覽器的位址列輸入 https://juejin.im 後會發生什麼，大家在心中肯定是有一個大概的，這裡我將 DNS 域名解析 這個步驟詳細的講一遍。在講概念之前我先放上一張經典的圖文供大家思考一分鐘。
查詢域名對應的 IP 地址的具體過程
- 瀏覽器搜尋自己的 DNS 快取（瀏覽器維護一張域名與 IP 地址的對應表）；如果沒有命中，進入下一步；
- 搜尋作業系統中的 DNS 快取；如果沒有命中，進入下一步；
- 搜尋作業系統的 hosts 檔案（ Windows 環境下，維護一張域名與 IP 地址的對應表）；如果沒有命中，進入下一步；
- 作業系統將域名傳送至 LDNS （本地區域名伺服器），LDNS 查詢自己的 DNS 快取（一般命中率在 80% 左右），查詢成功則返回結果，失敗則發起一個迭代 DNS 解析請求：
- LDNS向 Root Name Server（根域名伺服器，如com、net、im 等的頂級域名伺服器的地址）發起請求，此處，Root Name Server 返回 im 域的頂級域名伺服器的地址；
- LDNS 向 im 域的頂級域名伺服器發起請求，返回 juejin.im 域名伺服器地址；
- LDNS 向 juejin.im 域名伺服器發起請求，得到 juejin.im 的 IP 地址；
- LDNS 將得到的 IP 地址返回給作業系統，同時自己也將 IP 地址快取起來；作業系統將 IP 地址返回給瀏覽器，同時自己也將 IP 地址快取起來。
DNS Prefetch
即 DNS 預獲取，是前端優化的一部分。一般來說，在前端優化中與 DNS 有關的有兩點：
- 減少 DNS 的請求次數
- 進行 DNS 預獲取
典型的一次 DNS 解析需要耗費 20-120 毫秒，減少DNS解析時間和次數是個很好的優化方式。DNS Prefetching 是讓具有此屬性的域名不需要使用者點選連結就在後臺解析，而域名解析和內容載入是序列的網路操作，所以這個方式能減少使用者的等待時間，提升使用者體驗。
五類 IP 地址 TOP
詳見 下一篇
跨域的原因及處理方式 TOP
詳見下一篇
正向代理和反向代理 TOP
詳見下一篇
CDN 帶來的效能優化 TOP
詳見下一篇
HTTP 強快取&協商快取 TOP
詳見下一篇
如果你看完了，還不過癮的話；我推薦你看下我寫的兩篇關於繼承的文章，看完之後，想必你會有一個新的認識。
【前端詞典】繼承（一） - 面試官問的你都會嗎？
【前端詞典】繼承（二） - 回的八種寫法·面試必問
參考
- 《圖解 HTTP》
- 《計算機網路基礎》
- blog.csdn.net/qzcsu/artic…
- segmentfault.com/a/119000001…
- developer.mozilla.org/zh-CN/docs/…
前端詞典系列
《前端詞典》這個系列會持續更新，每一期我都會講一個出現頻率較高的知識點。希望大家在閱讀的過程當中可以斧正文中出現不嚴謹或是錯誤的地方，本人將不勝感激；若通過本系列而有所得，本人亦將不勝欣喜。
如果你覺得我的文章寫的還不錯，可以關注我的微信公眾號，公眾號裡會提前劇透呦。
你也可以新增我的微信 wqhhsd， 歡迎交流。
下期預告
【前端詞典】進階必備的網路基礎（下）