【前端词典】进阶必备的网络基础（下）
前言
在上一篇我提到了前端面試頻率較高的幾個網絡基礎知識，這一篇我會把上一篇遺留的五個盡力講清楚。如果還沒有來得及看上一篇，那么現在可以一起看。
目錄
接下來我會講以下內容：
五類 IP 地址 TOP
網絡地址：用于識別主機所在的網絡；
主機地址：用于識別該網絡中的主機。
IP地址分為五類：
各類可容納的地址數目不同。其中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. 為什么需要登錄呢？我就假設這是有心之人惡意為之，這個登陸頁面做了什么呢？我再假設頁面有以下代碼
從上面兩種情況，我們初步了解同源策略確實能規避一些危險，不是說有了同源策略就安全，只是說同源策略是一種瀏覽器最基本的安全機制，畢竟能提高一點攻擊的成本。
跨域解決方案
以上的方法我會挑幾個講
一、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; # 監聽的端口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
正向代理
反向代理
共同點
具體的應用可以看我寫的這一篇文章 【前端詞典】和媳婦講代理后的意外收獲
CDN 帶來的性能優化 TOP
CDN的全稱是 Content Delivery Network，即內容分發網絡。CDN 是構建在網絡之上的內容分發網絡，依靠部署在各地的邊緣服務器，通過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，降低網絡擁塞，提高用戶訪問響應速度和命中率。CDN 的關鍵技術主要有內容存儲和分發技術。
舉個例子
在淘寶購物
我們在淘寶購物，大部分個人賣家只是在一個地方發貨，江浙滬以外的地方好像收貨都比較慢。
在京東購物
而我們在京東上買自營產品的話，它會根據我們的收貨地點，在全國范圍內找離我們最近、送達最快的倉庫，不管我們在江浙滬，還是新疆西藏內蒙古，我們的收貨時間都會大大減少。京東建立的倉儲系統，就類似于 CDN。
CDN的優勢
訪問速度快是電商網站取勝的必要法寶之一。
CDN 的工作模式
比如我們 SHEIN 主站的根服務器中國深圳，CDN 服務器在美國加州，歐洲法國，印度等三個地方（真實的細致很多）。
沒有 CDN 服務器
那么全球 6000 萬用戶請求的資源都是從中國深圳的機房發出的，這樣一位美國加州的用戶在打開首頁的延時可能足夠她畫一個精致的妝容了。（PS: 深圳前端團隊在招前端開發，有需求的可以私信我）
有 CDN 服務器
此時還是這位加州的用戶想打開 SHEIN 打算購買一件晚禮服參加晚會。這次她視線還沒有移到梳妝臺，首頁就已經打開了，然后她就開心的購物了。
這就是因為 CDN 服務器。
美國加州的 CDN 服務器，已經將根節點的資源復制過來了。并且我們有個機制，CDN 節點的資源十分鐘會回源更新一次。所以在用戶請求資源的時候是不會回源到深圳的根服務器請求的。這樣不會出現用戶在請求資源的時候，因為回源而導致的網絡延時。
CDN 的核心點有兩個: 一個是緩存，一個是回源。
關鍵技術
前端往往認為 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 | 自定義擴展值，若服務器不識別該指令，就直接忽略 |
可緩存性
到期
重新驗證和重新加載
其他
協商緩存 ( 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 來處理緩存，反而會有更大的開銷。
參考
前端詞典系列
《前端詞典》這個系列會持續更新，每一期我都會講一個出現頻率較高的知識點。希望大家在閱讀的過程當中可以斧正文中出現不嚴謹或是錯誤的地方，本人將不勝感激；若通過本系列而有所得，本人亦將不勝欣喜。
如果你覺得我的文章寫的還不錯，可以關注我的微信公眾號，公眾號里會提前劇透呦。
你也可以添加我的微信 wqhhsd， 歡迎交流。
下期預告
【前端詞典】F5 同 Ctrl+F5 的區別你可了解
傳送門
總結
以上是生活随笔為你收集整理的【前端词典】进阶必备的网络基础（下）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2019 阿里云峰会·北京站正式启动，互
- 下一篇： web前端—面试2