前言

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

目錄

接下來我會講以下內容：

五類 IP 地址

跨域的原因及處理方式

正向代理和反向代理

CDN 帶來的性能優(yōu)化

HTTP 強緩存&協商緩存

五類 IP 地址 TOP

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

IP地址分為五類：

A 類保留給政府機構

B 類分配給中等規(guī)模的公司

C 類分配給任何需要的人

D 類用于用于特殊用途. 又稱做廣播地址

E 類暫時保留

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

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

一. A類地址

第一個八位段為網絡地址，其它為主機地址，第一個八位段首位一定為0；
范圍：1.0.0.1—126.155.255.254；
私有地址和保留地址：
10.X.X.X是私有地址（所謂的私有地址就是在互聯網上不使用，而被用在局域網絡中的地址）。
127.X.X.X是保留地址，用做循環(huán)測試用的。

二. 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個個字節(jié)為主機地址，第一個八位段首位一定為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.當你剛想付款的時候，有一個人發(fā)給你一個鏈接 www.heiheihei.com，你的眼神突然變得正經了，而后毫不猶豫的點了進去。
3.你很正經的觀看 www.heiheihei.com 中的內容，www.heiheihei.com 也沒有閑著，由于沒有同源策略的限制，它向 www.taobao.com 發(fā)起了請求！暗地里為所欲為的做一些為所欲為的事情。

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('***') // 密碼賬號被偷走了 復制代碼

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

跨域解決方案

通過 jsonp 跨域

document.domain + iframe 跨域

location.hash + iframe

window.name + iframe跨域

postMessage 跨域

跨域資源共享（ CORS ）

nginx 代理跨域

nodejs 中間件代理跨域

WebSocket 協議跨域

以上的方法我會挑幾個講

一、JSONP

JSONP 的原理很簡單，就是利用 <script> 標簽沒有跨域限制的漏洞。通過 <script> 標簽指向一個需要訪問的地址并提供一個回調函數來接收數據當需要通訊時。 JSONP 使用簡單且兼容性不錯，但是只限于 get 請求。

function jsonp(url, jsonpCallback, success) {let script = document.createElement('script')script.src = urlscript.async = truescript.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; # 監(jiān)聽的端口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

正向代理

代理客戶;

隱藏真實的客戶，為客戶端收發(fā)請求，使真實客戶端對服務器不可見;

一個局域網內的所有用戶可能被一臺服務器做了正向代理，由該臺服務器負責 HTTP 請求;

意味著同服務器做通信的是正向代理服務器;

反向代理

代理服務器;

隱藏了真實的服務器，為服務器收發(fā)請求，使真實服務器對客戶端不可見;

負載均衡服務器，將用戶的請求分發(fā)到空閑的服務器上;

意味著用戶和負載均衡服務器直接通信，即用戶解析服務器域名時得到的是負載均衡服務器的 IP ;

共同點

都是做為服務器和客戶端的中間層

都可以加強內網的安全性，阻止 web 攻擊

都可以做緩存機制

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

CDN 帶來的性能優(yōu)化 TOP

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

舉個例子

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

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

CDN的優(yōu)勢

CDN 節(jié)點解決了跨運營商和跨地域訪問的問題，訪問延時大大降低；

大部分請求在 CDN 邊緣節(jié)點完成，CDN 起到了分流作用，減輕了源站的負載。

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

CDN 的工作模式

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

沒有 CDN 服務器

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

有 CDN 服務器

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

這就是因為 CDN 服務器。

美國加州的 CDN 服務器，已經將根節(jié)點的資源復制過來了。并且我們有個機制，CDN 節(jié)點的資源十分鐘會回源更新一次。所以在用戶請求資源的時候是不會回源到深圳的根服務器請求的。這樣不會出現用戶在請求資源的時候，因為回源而導致的網絡延時。

CDN 的核心點有兩個: 一個是緩存，一個是回源。

關鍵技術

內容發(fā)布：它借助于建立索引、緩存、流分裂、組播（Multicast）等技術，將內容發(fā)布或投遞到距離用戶最近的遠程服務點（POP）處；

內容路由：它是整體性的網絡負載均衡技術，通過內容路由器中的重定向（DNS）機制，在多個遠程 POP 上均衡用戶的請求，以使用戶請求得到最近內容源的響應；

內容交換：它根據內容的可用性、服務器的可用性以及用戶的背景，在POP的緩存服務器上，利用應用層交換、流分裂、重定向（ICP、WCCP）等技術，智能地平衡負載流量；

性能管理：它通過內部和外部監(jiān)控系統(tǒng)，獲取網絡部件的狀況信息，測量內容發(fā)布的端到端性能（如包丟失、延時、平均帶寬、啟動時間、幀速率等），保證網絡處于最佳的運行狀態(tài)。

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

CDN & 靜態(tài)資源

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

淘寶

京東

掘金

我們隨手打開一個網站點開一個靜態(tài)資源，可以看到它都是從 CDN 服務器上請求來的。可以看出 "靜態(tài)資源走 CDN" 是最佳實踐。

CDN & Cookie

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

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

靜態(tài)資源往往并不需要 Cookie 攜帶什么認證信息。把靜態(tài)資源和主頁面置于不同的域名下，就可以完美地避免請求中攜帶不必要的 Cookie。

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

HTTP 強緩存&協商緩存 TOP

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

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 的優(yōu)先級會更高一點。

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

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	強制每次請求直接發(fā)送給源服務器，而不經過本地緩存版本的校驗。
no-store	在客戶端或是代理服務器都不緩存請求或響應的任何內容
no-transform	代理服務器不可以更改媒體類型
must-revalidate	可緩存但必須再向源服務器進行請求確認
proxy-revalidate	要求緩存服務器返回緩存的時候向源服務器進行請求確認
max-age=[秒]	告知客戶端該資源在規(guī)定時間內是新鮮的，無需向服務器確認
s-maxage=[秒]	告知緩存服務該資源在規(guī)定時間內是新鮮的，無需向服務器確認
cache-extension	自定義擴展值，若服務器不識別該指令，就直接忽略

可緩存性

public：響應可以被任何對象（客戶端、代理服務器等）緩存

private：只能被單個用戶緩存，不能作為共享緩存

no-cache：使用緩存副本之前，需要將請求提交給原始服務器進行驗證，驗證通過才可以使用

only-if-cached：客戶端只接受已緩存的響應，并且不向原始服務器檢查是否有更新的拷貝

到期

max-age=<seconds>：緩存存儲的最大周期，超過這個時間緩存被認為過期(單位秒)。與 Expires 相反，時間是相對于請求的時間

s-maxage=<seconds>：覆蓋 max-age 或者 Expires 頭，但是僅適用于共享緩存(比如各個代理)，并且私有緩存中它被忽略

max-stale[=<seconds>]：表明客戶端愿意接收一個已經過期的資源。可選的設置一個時間(單位秒)，表示響應不能超過的過時時間

min-fresh=<seconds>：表示客戶端希望在指定的時間內獲取最新的響應

重新驗證和重新加載

must-revalidate：緩存必須在使用之前驗證舊資源的狀態(tài)，并且不可使用過期資源。

proxy-revalidate：與 must-revalidate 作用相同，但它僅適用于共享緩存（例如代理），并被私有緩存忽略

其他

no-store：徹底得禁用緩沖，本地和代理服務器都不緩沖，每次都從服務器獲取

no-transform：不得對資源進行轉換或轉變。Content-Encoding, Content-Range, Content-Type 等 HTTP 頭不能由代理修改。

協商緩存 ( Last-Modified 和 Etag )

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

Last-Modified 和 If-Modified-Since

基于資源在服務器修改時間的驗證緩存過期機制

當客戶端再次請求該資源的時候，會在其請求頭上附帶上 If-Modified-Since 字段，值就是第一次獲取請求資源時響應頭中返回的 Last-Modified 值。如果資源未過期，命中緩存，服務器就直接返回 304 狀態(tài)碼，客戶端直接使用本地的資源。否則，服務器重新發(fā)送響應資源。從而保證資源的有效性。

Etag 和 If-None-Match

基于服務資源校驗碼的驗證緩存過期機制

服務器返回的報文響應頭的 Etag 字段標示服務器資源的校驗碼（例如文件的 hash 值），發(fā)送到客戶端瀏覽器，瀏覽器收到后把資源文件緩存起來并且緩存 Etag 值，當瀏覽器再次請求此資源文件時，會在請求頭 If-None-Match 字段帶上緩存的 Etag 值。
服務器收到請求后，把請求頭中 If-None-Match 字段值與服務器端資源文件的驗證碼進行對比，如果匹配成功直接返回 304 狀態(tài)碼，從瀏覽器本地緩存取資源文件。如果不匹配，服務器會把新的驗證碼放在請求頭的 Etag 字段中，并且以 200 狀態(tài)碼返回資源。

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

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

參考

《圖解 HTTP》

《計算機網絡基礎》

blog.csdn.net/qzcsu/artic…

segmentfault.com/a/119000001…

developer.mozilla.org/zh-CN/docs/…

前端詞典系列

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

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

你也可以添加我的微信 wqhhsd， 歡迎交流。

下期預告

【前端詞典】F5 同 Ctrl+F5 的區(qū)別你可了解

傳送門

【前端詞典】和媳婦講代理后的意外收獲

【前端詞典】滾動穿透問題的解決方案

繼承（一） - 原型鏈你真的懂嗎？

【前端詞典】繼承（二） - 回的八種寫法·面試必問

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

《新程序員》：云原生和全面數字化實踐50位技術專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的【前端词典】进阶必备的网络基础（下）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。