【前端詞典】進階必備的網路基礎（下）

小生方勤發表於2019-03-06
前端

前言

在上一篇我提到了前端面試頻率較高的幾個網路基礎知識，這一篇我會把上一篇遺留的五個盡力講清楚。如果還沒有來得及看上一篇，那麼現在可以一起看。

目錄

接下來我會講以下內容：

  1. 五類 IP 地址
  2. 跨域的原因及處理方式
  3. 正向代理和反向代理
  4. CDN 帶來的效能優化
  5. HTTP 強快取&協商快取

五類 IP 地址 TOP

網路地址：用於識別主機所在的網路；
主機地址：用於識別該網路中的主機。

IP地址分為五類：

  1. A 類保留給政府機構
  2. B 類分配給中等規模的公司
  3. C 類分配給任何需要的人
  4. D 類用於用於特殊用途. 又稱做廣播地址
  5. E 類暫時保留

各類可容納的地址數目不同。其中A類、B類、和C類這三類地址用於 TCP/IP 節點，其它兩類D類和E類被用於特殊用途。

首先用一張圖給大家一個初步的概念：

【前端詞典】進階必備的網路基礎（下）

一. A類地址

第一個八位段為網路地址，其它為主機地址，第一個八位段首位一定為0；
範圍：1.0.0.1—126.155.255.254；
私有地址和保留地址：
10.X.X.X是私有地址（所謂的私有地址就是在網際網路上不使用，而被用在區域網路中的地址）。
127.X.X.X是保留地址，用做迴圈測試用的。

二. B類地址

第一個八位段和第二個八位段為網路地址，其它為主機地址，第一個八位段首位一定為10；
範圍：128.0.0.1—191.255.255.254。
私有地址和保留地址:
172.16.0.0—172.31.255.255是私有地址
169.254.X.X是保留地址。如果你的IP地址是自動獲取IP地址，而你在網路上又沒有找到可用的DHCP伺服器。就會得到其中一個IP。

三. C類地址

前三個八位段為網路地址，第4個個位元組為主機地址，第一個八位段首位一定為110。
範圍：192.0.0.1—223.255.255.254。
私有地址：
192.168.X.X是私有地址。

四. D類地址

不分網路地址和主機地址，第一個八位段首位一定為1110。
範圍：224.0.0.1—239.255.255.254

五. E類地址

不分網路地址和主機地址，第一個八位段首位一定為11110。
範圍：240.0.0.1—255.255.255.254

跨域的原因及處理方式 TOP

出現跨域的原因是由於 瀏覽器的同源策略 所決定的。

同源策略限制了從同一個源載入的文件或指令碼如何與來自另一個源的資源進行互動。這是一個用於隔離潛在惡意檔案的重要安全機制。

這個說法一如既往的很官方，猶如女神的一句 呵呵，讓人不知所以然。接下來就從 Dom 查詢和介面請求來說明同源策略的必要性。

介面請求(假設沒有同源策略)

我們來看場景：
1.你開啟 www.taobao.com，準備購買你已經新增在購物車的《JavaScript 高階程式設計》。
2.當你剛想付款的時候，有一個人發給你一個連結 www.heiheihei.com，你的眼神突然變得正經了，而後毫不猶豫的點了進去。
3.你很正經的觀看 www.heiheihei.com 中的內容，www.heiheihei.com 也沒有閒著，由於沒有同源策略的限制，它向 www.taobao.com 發起了請求！暗地裡為所欲為的做一些為所欲為的事情。

Dom 查詢(假設沒有同源策略)

1.星期一的早上，你像往常一樣點開淘寶，在淘寶裡逛起了街，不過今天你沒有在意為什麼今天需要登陸。
2. 為什麼需要登入呢？我就假設這是有心之人惡意為之，這個登陸頁面做了什麼呢？我再假設頁面有以下程式碼

// HTML
<iframe name="taobaoo" src="www.taobaoo.com"></iframe>
// JS
// 由於沒有同源策略的限制， Dom 可以直接拿到。
const iframe = window.frames['taobaoo'];
const account = iframe.document.getElementById('***')
const pw = iframe.document.getElementById('***')
// 密碼賬號被偷走了
複製程式碼

從上面兩種情況，我們初步瞭解同源策略確實能規避一些危險，不是說有了同源策略就安全，只是說同源策略是一種瀏覽器最基本的安全機制，畢竟能提高一點攻擊的成本。

跨域解決方案

  1. 通過 jsonp 跨域
  2. document.domain + iframe 跨域
  3. location.hash + iframe
  4. window.name + iframe跨域
  5. postMessage 跨域
  6. 跨域資源共享（ CORS ）
  7. nginx 代理跨域
  8. nodejs 中介軟體代理跨域
  9. WebSocket 協議跨域

以上的方法我會挑幾個講

一、JSONP

JSONP 的原理很簡單，就是利用 <script> 標籤沒有跨域限制的漏洞。通過 <script> 標籤指向一個需要訪問的地址並提供一個回撥函式來接收資料當需要通訊時。 JSONP 使用簡單且相容性不錯，但是隻限於 get 請求。

function jsonp(url, jsonpCallback, success) {
  let script = document.createElement('script')
  script.src = url
  script.async = true
  script.type = 'text/javascript'
  window[jsonpCallback] = function(data) {
    success && success(data)
  }
  document.body.appendChild(script)
}
jsonp('http://xxx', 'callback', function(value) {
  console.log(value)
})
複製程式碼

二、CORS

CORS 需要瀏覽器和後端同時支援。瀏覽器會自動進行 CORS 通訊，實現 CORS 通訊的關鍵是後端。只要後端實現了 CORS，就實現了跨域。 服務端設定 Access-Control-Allow-Origin 就可以開啟 CORS。 該屬性表示哪些域名可以訪問資源，如果設定萬用字元則表示所有網站都可以訪問資源。

三、nginx 代理跨域

利用 Nginx 反向代理實現跨域。

虛擬主機的配置

server {
    listen 8080;                         # 監聽的埠
    server_name  192.168.1.1;            # 配置訪問域名
    root  /data/toor;                    # 站點根目錄
    error_page 502 404 /page/404.html;   # 錯誤頁面
    location ^~ /api/  {                        # 使用 /api/ 代理 proxy_pass 的值
        proxy_pass http://192.168.20.1:8080;    # 被代理的應用伺服器 HTTP 地址
    }
}
複製程式碼

複製程式碼以上簡單的配置就可以實現反向代理的功能，跨域的問題也就解決了。

在 Vue 中就可以使用 proxyTable 這個屬性進行相關的配置來解決跨域問題帶來的煩惱。配置如下：

proxyTable: {
    '/weixin': {
        target: 'http://192.168.48.11:8100/', // 介面的域名 
        secure: false,      // 如果是 https 介面，需要配置這個引數
        changeOrigin: true, // 如果介面跨域，需要進行這個引數配置
        pathRewrite: {
            '^/weixin': ''
        }
    },
},
複製程式碼

正向代理和反向代理 TOP

正向代理

  1. 代理客戶;
  2. 隱藏真實的客戶，為客戶端收發請求，使真實客戶端對伺服器不可見;
  3. 一個區域網內的所有使用者可能被一臺伺服器做了正向代理，由該臺伺服器負責 HTTP 請求;
  4. 意味著同伺服器做通訊的是正向代理伺服器;

反向代理

  1. 代理伺服器;
  2. 隱藏了真實的伺服器，為伺服器收發請求，使真實伺服器對客戶端不可見;
  3. 負載均衡伺服器，將使用者的請求分發到空閒的伺服器上;
  4. 意味著使用者和負載均衡伺服器直接通訊，即使用者解析伺服器域名時得到的是負載均衡伺服器的 IP ;

共同點

  1. 都是做為伺服器和客戶端的中間層
  2. 都可以加強內網的安全性，阻止 web 攻擊
  3. 都可以做快取機制

具體的應用可以看我寫的這一篇文章 【前端詞典】和媳婦講代理後的意外收穫

CDN 帶來的效能優化 TOP

CDN的全稱是 Content Delivery Network，即內容分發網路。CDN 是構建在網路之上的內容分發網路，依靠部署在各地的邊緣伺服器，通過中心平臺的負載均衡、內容分發、排程等功能模組，使使用者就近獲取所需內容，降低網路擁塞，提高使用者訪問響應速度和命中率。CDN 的關鍵技術主要有內容儲存和分發技術。

舉個例子

在淘寶購物
我們在淘寶購物，大部分個人賣家只是在一個地方發貨，江浙滬以外的地方好像收貨都比較慢。

在京東購物
而我們在京東上買自營產品的話，它會根據我們的收貨地點，在全國範圍內找離我們最近、送達最快的倉庫，不管我們在江浙滬，還是新疆西藏內蒙古，我們的收貨時間都會大大減少。京東建立的倉儲系統，就類似於 CDN。

CDN的優勢

  1. CDN 節點解決了跨運營商和跨地域訪問的問題，訪問延時大大降低；
  2. 大部分請求在 CDN 邊緣節點完成，CDN 起到了分流作用，減輕了源站的負載。

訪問速度快是電商網站取勝的必要法寶之一。

CDN 的工作模式

比如我們 SHEIN 主站的根伺服器中國深圳，CDN 伺服器在美國加州，歐洲法國，印度等三個地方（真實的細緻很多）。

沒有 CDN 伺服器

那麼全球 6000 萬使用者請求的資源都是從中國深圳的機房發出的，這樣一位美國加州的使用者在開啟首頁的延時可能足夠她畫一個精緻的妝容了。（PS: 深圳前端團隊在招前端開發，有需求的可以私信我）

有 CDN 伺服器

此時還是這位加州的使用者想開啟 SHEIN 打算購買一件晚禮服參加晚會。這次她視線還沒有移到梳妝檯，首頁就已經開啟了，然後她就開心的購物了。

這就是因為 CDN 伺服器。

美國加州的 CDN 伺服器，已經將根節點的資源複製過來了。並且我們有個機制，CDN 節點的資源十分鐘會回源更新一次。所以在使用者請求資源的時候是不會回源到深圳的根伺服器請求的。這樣不會出現使用者在請求資源的時候，因為回源而導致的網路延時。

CDN 的核心點有兩個: 一個是快取，一個是回源。

關鍵技術

  1. 內容釋出：它藉助於建立索引、快取、流分裂、組播（Multicast）等技術，將內容釋出或投遞到距離使用者最近的遠端服務點（POP）處；
  2. 內容路由：它是整體性的網路負載均衡技術，通過內容路由器中的重定向（DNS）機制，在多個遠端 POP 上均衡使用者的請求，以使使用者請求得到最近內容源的響應；
  3. 內容交換：它根據內容的可用性、伺服器的可用性以及使用者的背景，在POP的快取伺服器上，利用應用層交換、流分裂、重定向（ICP、WCCP）等技術，智慧地平衡負載流量；
  4. 效能管理：它通過內部和外部監控系統，獲取網路部件的狀況資訊，測量內容釋出的端到端效能（如包丟失、延時、平均頻寬、啟動時間、幀速率等），保證網路處於最佳的執行狀態。

前端往往認為 CDN 是不需要了解的知識。可是我們前端工程首先是軟體工程師。多瞭解一些東西肯定是有益的。

CDN & 靜態資源

靜態資源本身具有訪問頻率高、承接流量大的特點，因此靜態資源載入速度始終是前端效能的一個非常關鍵的指標。CDN 是靜態資源提速的重要手段。

淘寶

【前端詞典】進階必備的網路基礎（下）

京東

【前端詞典】進階必備的網路基礎（下）

掘金

【前端詞典】進階必備的網路基礎（下）
我們隨手開啟一個網站點開一個靜態資源，可以看到它都是從 CDN 伺服器上請求來的。可以看出 "靜態資源走 CDN" 是最佳實踐。

CDN & Cookie

Cookie 是緊跟域名的。同一個域名下的所有請求，都會攜帶相同的 Cookie。

但是如果我們只是請求一張圖片，我們在請求中還要攜帶一個笨重的 Cookie 來回的跑，Cookie 中的資訊和圖片又是沒有關聯的，這種情況就很讓人頭痛了。Cookie 雖然小，但是隨著請求的越來越多，這種的不必要的 Cookie 帶來的開銷將是無法想象的……

靜態資源往往並不需要 Cookie 攜帶什麼認證資訊。把靜態資源和主頁面置於不同的域名下，就可以完美地避免請求中攜帶不必要的 Cookie。

看起來是一個不起眼的小細節，但帶來的效用卻是驚人的。電商網站靜態資源的流量之龐大，如果沒把這個多餘的 Cookie 拿下來，不僅使用者體驗會大打折扣，每年因效能浪費導致的開銷也會非常之高。

HTTP 強快取&協商快取 TOP

快取是一種儲存資源副本並在下次請求時直接使用該副本的技術。 當 web 快取發現請求的資源已經被儲存，它會攔截請求，返回該資源的拷貝，而不會去源伺服器重新下載。
這樣帶來的好處是緩解伺服器端壓力，提升效能(獲取資源的耗時更短了)。對於網站來說，快取是達到高效能的重要組成部分。
快取大致可歸為兩類：私有快取與共享快取。
共享快取能夠被多個使用者使用；
私有快取只能用於單獨使用者；

HTTP 協議主要是通過請求頭當中的一些欄位來和伺服器進行通訊，從而採用不同的快取策略。
HTTP 通過快取將伺服器資源的副本保留一段時間，這段時間稱為新鮮度限值。這在一段時間內請求相同資源不會再通過伺服器。
HTTP 協議中 Cache-Control 和 Expires 可以用來設定新鮮度的限值。

強快取 ( Cache-Control 和 Expires )

強快取主要是採用響應頭中的 Cache-Control 和 Expires 兩個欄位進行控制的。

其中 Expires 是 HTTP 1.0 中定義的，它指定了一個絕對的過期時期。而 Cache-Control 是 HTTP 1.1 時出現的快取控制欄位。

Cache-Control:max-age 定義了一個最大使用期。 就是從第一次生成文件到快取不再生效的合法生存日期。由於Expires是HTTP1.0時代的產物，因此設計之初就存在著一些缺陷，如果本地時間和伺服器時間相差太大，就會導致快取錯亂。

這兩個欄位同時使用的時候 Cache-Control 的優先順序會更高一點。

這兩個欄位的效果是類似的，客戶端都會通過對比本地時間和伺服器返回的生存時間來檢測快取是否可用。如果快取沒有超出它的生存時間，客戶端就會直接採用本地的快取。如果生存日期已經過了，這個快取也就宣告失效。接著客戶端將再次與伺服器進行通訊來驗證這個快取是否需要更新。

Cache-Control 通用訊息頭欄位被用於在 http 請求和響應中通過指定指令來實現快取機制。

在請求頭中使用 Cache-Control 時，它可選的值有：

指令 說明
no-cache 使用代理伺服器的快取之前提交原始伺服器驗證，驗證通過才能使用
no-store 在客戶端或是代理伺服器都不快取請求或響應的任何內容
max-age=[秒] 告知伺服器客戶端可接受資源的存在最大時間
max-stale(=[秒]) 可接受（代理伺服器快取的）過期資源，引數可省略
min-fresh=[秒] 可接受（代理伺服器快取的）資源更新時間小於指定時間
no-transform 代理伺服器不可以更改媒體型別
only-if-cached 客戶端只接受已快取的響應，若快取不命中，則返回 504 錯誤
cache-extension 自定義擴充套件值，若伺服器不知別該指令，就直接忽略

在響應頭中使用 Cache-Control 時，它可選的值有：

指令 說明
public 表明該資源可以給多個使用者使用
private(= name) 該資源是私有資源，指定的使用者可以使用的快取
no-cache 強制每次請求直接傳送給源伺服器，而不經過本地快取版本的校驗。
no-store 在客戶端或是代理伺服器都不快取請求或響應的任何內容
no-transform 代理伺服器不可以更改媒體型別
must-revalidate 可快取但必須再向源伺服器進行請求確認
proxy-revalidate 要求快取伺服器返回快取的時候向源伺服器進行請求確認
max-age=[秒] 告知客戶端該資源在規定時間內是新鮮的，無需向伺服器確認
s-maxage=[秒] 告知快取服務該資源在規定時間內是新鮮的，無需向伺服器確認
cache-extension 自定義擴充套件值，若伺服器不識別該指令，就直接忽略

可快取性

  1. public：響應可以被任何物件（客戶端、代理伺服器等）快取
  2. private：只能被單個使用者快取，不能作為共享快取
  3. no-cache：使用快取副本之前，需要將請求提交給原始伺服器進行驗證，驗證通過才可以使用
  4. only-if-cached：客戶端只接受已快取的響應，並且不向原始伺服器檢查是否有更新的拷貝

到期

  1. max-age=<seconds>：快取儲存的最大週期，超過這個時間快取被認為過期(單位秒)。與 Expires 相反，時間是相對於請求的時間
  2. s-maxage=<seconds>：覆蓋 max-age 或者 Expires 頭，但是僅適用於共享快取(比如各個代理)，並且私有快取中它被忽略
  3. max-stale[=<seconds>]：表明客戶端願意接收一個已經過期的資源。可選的設定一個時間(單位秒)，表示響應不能超過的過時時間
  4. min-fresh=<seconds>：表示客戶端希望在指定的時間內獲取最新的響應

重新驗證和重新載入

  1. must-revalidate：快取必須在使用之前驗證舊資源的狀態，並且不可使用過期資源。
  2. proxy-revalidate：與 must-revalidate 作用相同，但它僅適用於共享快取（例如代理），並被私有快取忽略

其他

  1. no-store：徹底得禁用緩衝，本地和代理伺服器都不緩衝，每次都從伺服器獲取
  2. no-transform：不得對資源進行轉換或轉變。Content-Encoding, Content-Range, Content-Type 等 HTTP 頭不能由代理修改。

協商快取 ( Last-Modified 和 Etag )

協商快取機制下，瀏覽器需要向伺服器去詢問快取的相關資訊，進而判斷是重新發起請求、下載完整的響應，還是從本地獲取快取的資源。
如果服務端提示快取資源未改動（Not Modified），資源會被重定向到瀏覽器快取，這種情況下網路請求對應的狀態碼是 304。

Last-Modified 和 If-Modified-Since

基於資源在伺服器修改時間的驗證快取過期機制

當客戶端再次請求該資源的時候，會在其請求頭上附帶上 If-Modified-Since 欄位，值就是第一次獲取請求資源時響應頭中返回的 Last-Modified 值。如果資源未過期，命中快取，伺服器就直接返回 304 狀態碼，客戶端直接使用本地的資源。否則，伺服器重新傳送響應資源。從而保證資源的有效性。

Etag 和 If-None-Match

基於服務資源校驗碼的驗證快取過期機制

伺服器返回的報文響應頭的 Etag 欄位標示伺服器資源的校驗碼（例如檔案的 hash 值），傳送到客戶端瀏覽器，瀏覽器收到後把資原始檔快取起來並且快取 Etag 值，當瀏覽器再次請求此資原始檔時，會在請求頭 If-None-Match 欄位帶上快取的 Etag 值。
伺服器收到請求後，把請求頭中 If-None-Match 欄位值與伺服器端資原始檔的驗證碼進行對比，如果匹配成功直接返回 304 狀態碼，從瀏覽器本地快取取資原始檔。如果不匹配，伺服器會把新的驗證碼放在請求頭的 Etag 欄位中，並且以 200 狀態碼返回資源。

需要注意的是當響應頭中同時存在 Etag 和 Last-Modified 的時候，會先對 Etag 進行比對，隨後才是 Last-Modified

Etag 的問題
相同的資源，在兩臺伺服器產生的 Etag 是不是相同的，所以對於使用伺服器叢集來處理請求的網站來說，Etag 的匹配概率會大幅降低。所在在這種情況下，使用 Etag 來處理快取，反而會有更大的開銷。

參考

  1. 《圖解 HTTP》
  2. 《計算機網路基礎》
  3. blog.csdn.net/qzcsu/artic…
  4. segmentfault.com/a/119000001…
  5. developer.mozilla.org/zh-CN/docs/…

前端詞典系列

《前端詞典》這個系列會持續更新，每一期我都會講一個出現頻率較高的知識點。希望大家在閱讀的過程當中可以斧正文中出現不嚴謹或是錯誤的地方，本人將不勝感激；若通過本系列而有所得，本人亦將不勝欣喜。

如果你覺得我的文章寫的還不錯，可以關注我的微信公眾號，公眾號裡會提前劇透呦。

【前端詞典】進階必備的網路基礎（下）

你也可以新增我的微信 wqhhsd， 歡迎交流。

下期預告

【前端詞典】F5 同 Ctrl+F5 的區別你可瞭解

傳送門

  1. 【前端詞典】和媳婦講代理後的意外收穫
  2. 【前端詞典】滾動穿透問題的解決方案
  3. 繼承（一） - 原型鏈你真的懂嗎？
  4. 【前端詞典】繼承（二） - 回的八種寫法·面試必問
  5. 【前端詞典】進階必備的網路基礎（上）

相關文章