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

五類 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 & 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 請求和響應中通過指定指令來實現緩存機制。

可緩存性

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 來處理緩存，反而會有更大的開銷。