HTTP 相關

時間 2021-02-17

標籤 css html jquery web 算法編程 json segmentfault 後端跨域欄目 HTTP/TCP 简体版

原文原文鏈接

1. DNS 查詢獲得IP

爲何須要IP: TCP/IP 經過 IP 地址來肯定通訊對象的。
域名和IP地址並用的理由：css
- IP 地址佔內存小。IP 地址長度爲 32 bit（4 字節），域名須要幾十甚至255字節
- IP 地址難記。
- 人使用名稱，路由器使用IP地址。
DNS 解析獲得的IP，只是實體主機的IP，並非要訪問的web應用服務器的IP地址（好比虛擬主機，實體主機會根據域名把鏈接轉發給對應的虛擬主機）
TCP/IP 的結構：html
- TCP/IP ，由一些小的子網，經過路由器鏈接起來組成的大的網絡。
- 網絡中的全部設備都會被分配一個地址，這個地址就是IP地址，經過IP地址，能夠判斷出消息應該發送到哪一個服務器。
- 發送者發出的消息 -> (通過)子網中的集線器 -> （轉發到）最近的路由器 -> 根據消息的目的地判斷下一個路由器的位置 -> 將消息發送到下一個路由器（不斷重複，直到目的地）
實際的IP地址：jquery
- 是一串 32 比特的數字，按照 8 比特(1 字節)爲一組分紅 4 組，分別用十進制表示，而後再用圓點隔開。
- IP 地址的規則中,網絡號和主機號連起來總共 32 比特,但這兩部分的具體結構是不固定的。
- 因此須要用到子網掩碼，子網掩碼的格式是一串與IP地址長度相同的32比特數字,左邊一半都是1，右邊一半都是0。子網掩碼爲1的部分表示網絡號，子網掩碼爲0的部分表示主機號。全 0：表示整個子網。全 1：表示向子網上全部設備發送包，即「廣播。
查詢順序：web
- 瀏覽器緩存
- 本地緩存
- 本地host文件
- 向 dns 域名服務器查詢
優化：使用 dns-prefetch 優化
向 dns 域名服務器查詢的過程：（好比， http://www.a.b.com）算法
- 根域服務器（臺數有限。沒有，則告訴它 .com的IP地址）
- 頂級域名服務器（沒有，則告訴它， http://b.com 的IP地址）
- 二級域名服務器（沒有，則告訴它， http://a.b.com 的IP地址）
- 三級域名服務器（返回 http://www.a.b.com的IP地址）
經過緩存加快DNS 服務器的響應：編程
- 真實互聯網中：一臺DNS 服務器，能夠管理多個域的信息。
- DNS 服務器有緩存功能：並不須要從根域開始查找，經過緩存能夠直接返回響應,接下來的查詢能夠從緩存的位置開始向下進行。相比每次都從根域找起來講,緩存能夠減小查詢所需的時間。
- 信息被緩存後,本來的註冊信息可能會發生改變,這時緩存中的信息就有多是不正確的，所以緩存信息會設置有效期，當緩存中的信息超過有效期後,數據就會從緩存中刪除。
用命令來查看整個DNS 請求過程：http://www.ruanyifeng.com/blo...

2. HTTP 劫持：

分爲 DNS 劫持和內容劫持
DNS 劫持：json
- DNS 服務器收到攻擊，返回假的 IP 地址或者不作任何處理使請求失效。最終的效果就是，特定的網絡不能訪問或者訪問假的網址。
- 解決：（DNS 的劫持是經過攻擊運營商的解析服務器來達到目的的）segmentfault
  - 使用本身的解析服務器或者
  - 在本身的App中將解析好的域名以IP的形式發出去
內容劫持：後端
- 背景：跨域
  - 運營商爲了加快用戶的訪問速度，減小本身的流量損耗作的一個緩存機制。
  - 用戶請求數據，若是緩存池中有，直接返回。
  - 若是沒有，則向服務器發出請求，將返回的數據攔截，先存入緩存池，而後再返回給用戶。
- 產生：惡意篡改服務器的緩存內容
- 解決：這種並很少，目前沒有好的解決方案

3. TCP/IP請求

三次握手（創建鏈接）
- SYN
- ACK ,SYN
- ACK
四次揮手（斷開鏈接）
- FIN, ACK
- ACK
- FIN,ACK
- ACK
TCP 慢啓動：
- TCP慢啓動
  - TCP 三次握手後，如何一開始就發送大量的數據報，很容易致使網絡中路由緩存空間耗盡，從而發生擁塞，因此根據出事的窗口大小逐步增長髮生的數據量，窗口初始化爲1個最大報文段大小，每當有一個報文段被確認，窗口呈指數增加。
- 擁塞避免
  - 窗口（cwnd）不能一直增長，增長到TCP的慢啓動門限（ssthresh），慢啓動階段結束，開始避免擁塞階段，窗口大小呈線性增加。
  - 如何判斷擁塞？發送方沒有在時間間隔內收到接收方的ACK，就認爲網絡擁塞。
  - 發生擁塞後：把啓動門限將爲目前窗口的通常；把目前窗口重置爲1，從新進入慢啓動過程。
- 快速重傳
  - 接收方成功的接受了發送方發送來的M一、M2而且分別給發送了ACK，如今接收方沒有收到M3，而接收到了M4，顯然接收方不能確認M4，由於M4是失序的報文段。若是根據可靠性傳輸原理接收方什麼都不作，可是按照快速重傳算法，在收到M四、M5等報文段的時候，不斷重複的向發送方發送M2的ACK,若是接收方一連收到三個重複的ACK,那麼發送方沒必要等待重傳計時器到期，因爲發送方儘早重傳未被確認的報文段。
  - 把慢啓動門限設置爲當前窗口的一半；把當前窗口設爲慢啓動門限；從新進入擁塞避免階段。
- 快速恢復
  - 快速恢復的數據包守恆原則，即同一個時刻在網絡中的數據包數量恆定，「老」數據包離開後，才能向網絡中發送「新」的數據包。若是發送方收到一個重複的ACK，TCP的ACK機制就代表有一個數據包離開，此時cwnd加1。
  - 當收到3個重複ACK時，把ssthresh設置爲cwnd的一半，把cwnd設置爲ssthresh的值加3，而後重傳丟失的報文段，加3的緣由是由於收到3個重複的ACK，代表有3個「老」的數據包離開了網絡。
  - 再收到重複的ACK時，擁塞窗口增長1。
  - 當收到新的數據包的ACK時，把cwnd設置爲第一步中的ssthresh的值。緣由是由於該ACK確認了新的數據，說明從重複ACK時的數據都已收到，該恢復過程已經結束，能夠回到恢復以前的狀態了，也即再次進入擁塞避免狀態。
UDP:
- UDP，又稱用戶數據協議，屬於網絡傳輸層。
- UDP，提供面向事務的、簡單、不可靠信息傳輸服務。
  - 事務：原子性（要麼都發生，要麼都不發生），持久性（只要事務提交了，它的做用就是永久的），隔離性（各個事務之間是獨立的），一致性（事務先後的狀態是一致的）
- 因爲無需鏈接，資源消耗低，處理快速且靈活，因此常應用在丟一兩個數據包也不會發生重大的影響的場景，好比音頻、視頻。
- DNS服務就是基於它實現的。
- UDP發送數據報的上限決定因素:
  - UDP協議自己，UDP協議中有16位的UDP報文長度，那麼UDP報文長度不能超過2^16=65536；
  - 以太網數據幀的長度，數據鏈路層的最大傳輸單位（MTU）；
  - socket的UDP發送緩存區大小；
  - 在 internet 下使用 UDP 協議，每一個數據報最大的字節數爲： 576（在 Internet 下 MTU 的值爲 576 字節） - 20（IP協議自己封裝包頭佔20個字節） - 8（UDP包頭佔8個字節） = 548
TCP 和 UDP 區別：
- 創建鏈接方式不一樣：
  - UDP不面向鏈接，TCP面向鏈接，全部的會話都基於鏈接完成；
  - TCP 面向鏈接、可靠的、有序的傳輸層協議。UDP面向數據報、不可靠、無序的傳輸協議。
  - 就比如發短信同樣，UDP 只須要知道對方的 ip 地址，將數據報一份一份的發送過去就能夠了，其餘的做爲發送方，都不須要關心。
  - UDP中，一個socket 能夠與多個UDP通訊; TCP中，一個socket只能與一個TCP通訊；每一條TCP鏈接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通訊；
- 數據發送方式不一樣：
  - TCP，是創建在兩端鏈接之上的協議，因此理論上發送的數據流不存在大小的限制。若是用TCP發送了一段很大的數據，可能會被截斷成好幾段，接受方依次的接收。
  - UDP，自己發送的就是一份一份的數據報，因此有上限。
- 數據有序性的不一樣：
  - TCP保證有序，UDP不保證有序；
  - 對於 TCP 來講，自己 TCP 有着超時重傳、錯誤重傳、還有等等一系列複雜的算法保證了 TCP 的數據是有序的，假設你發送了數據一、二、3，則只要發送端和接收端保持鏈接時，接收端收到的數據始終都是一、二、3。
  - 而 UDP 協議則要奔放的多，不管 server 端不管緩衝池的大小有多大，接收 client 端發來的消息老是一個一個的接收。而且因爲 UDP 自己的不可靠性以及無序性，若是 client 發送了一、二、3 這三個數據報過來，server 端接收到的多是任意順序、任意個數三個數據報的排列組合。
- 可靠性的不一樣：
  - TCP自己是可靠的協議，UDP是不可靠的協議；
  - TCP 內部的不少算法機制讓他保持鏈接的過程當中是很可靠的。好比：TCP 的超時重傳、錯誤重傳、TCP 的流量控制、阻塞控制、慢熱啓動算法、擁塞避免算法、快速恢復算法等等。因此 TCP 是一個內部原理複雜，可是使用起來比較簡單的這麼一個協議。
  - UDP 是一個面向非鏈接的協議，UDP 發送的每一個數據報帶有本身的 IP 地址和接收方的 IP 地址，它自己對這個數據報是否出錯，是否到達不關心，只要發出去了就行了。
- TCP面向字節流，其實是TCP把數據當作一連串無結構的字節流;UDP是面向報文的；UDP沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如IP電話，實時視頻會議等）
- TCP首部開銷20字節;UDP的首部開銷小，只有8個字節；
- 使用場景:
  - 使用UDP的場景：對實時性要求高、多點通訊；
  - 對實時性要求高：好比實時會議，實時視頻這種狀況下，若是使用 TCP，當網絡很差發生重傳時，畫面確定會有延時，甚至越堆越多。若是使用 UDP 的話，即便偶爾丟了幾個包，可是也不會影響什麼，這種狀況下使用 UDP 比較好；
  - 多點通訊：TCP 須要保持一個長鏈接，那麼在涉及多點通信的時候，確定須要和多個通訊節點創建其雙向鏈接，而後有時在NAT環境下，兩個通訊節點創建其直接的 TCP 鏈接不是一個容易的事情，而 UDP 能夠無需保持鏈接，直接發就能夠了，因此成本會很低，並且穿透性好。這種狀況下使用 UDP 也是沒錯的。

4.五層intel 協議棧：

應用層（dns，https）
傳輸層（tcp，udp）
網絡層（ip，arp）ip尋址【不懂這個，https://blog.csdn.net/wenqian...】
鏈路層（ppp）封裝成幀
物理層

5. HTTP 請求：

構成：
- 請求報文由請求頭和請求體組成；請求頭包含請求行（方法，URL，協議）和請求頭字段；
- 響應報文由響應頭和響應體組成；響應頭包含狀態行（協議，狀態碼，狀態碼緣由短語）和響應頭字段；
- 在頭以後，以一個空行（兩個換行符）爲分隔;
經常使用的請求頭和響應頭有哪些？
- 請求頭：
  - Accept-Encoding/Accept-Language/Accept-chart
  - connection：keep-Alive/close
  - referer: 請求的原始URL
  - origin：請求的協議和域名
  - host：發送目的地的協議和域名
  - cookie：cookie值
  - if-modified-since：對應服務器的last-modified
  - if-no-match：對應服務端的etag
  - cache-control:控制緩存的時效性
  - Access-Control-Request-Method
  - Access-Control-Request-Headers
  - user-agent:客戶端標識，多數瀏覽器這個字段比較複雜，差異十分微妙。
- 響應頭：
  - content-type/content-encoding/content-language
  - cache-control
  - Max-age：客戶端的本地資源應該緩存多少秒，開啓了Cache-Control後有效
  - last-modified
  - etag
  - connection：keep-Alive/close
  - Keep-Alive: timeout=50,max=100。保持鏈接不斷時須要的一些信息。
  - set-cookie：設置cookie。
  - Acccess-Control-Allow-origin
  - Server：服務器的一些相關信息
請求/響應實體：
- 請求實體：參數的序列化形式（a=1&b=2），或表單對象（Form Date 對象）
- 響應實體：服務端須要傳給客戶端的內容
http請求方法？
- get（獲取數據）
- post (傳輸數據)
- put (傳輸文件，不安全)
- delete ()
- head (獲取報文首部，沒有實體，用於確認UTI的有效性及資源的更新日期)
- patch ()
- options (詢問支持的方法，非簡單緩存的時候會用到)
- connect (創建管道化)
get和post的區別？
- get 傳輸數據是在url中傳輸的，因此大小有限制；
- get 能夠用於分享；
- get 會主動緩存；
狀態碼？
- 1** ：狀態；101用於切換協議；
- 2**：成功；200---請求成功；204--服務器成功處理了請求，但不須要返回任何實體內容；
- 3**：301---永久重定向，302---臨時重定向，304---緩存成功；
- 4**：請求錯誤；400---請求報文錯誤；401---需認證/認證失敗；403----無訪問資源權限；404----無請求的資源；
- 5**：服務器錯誤；500--服務端錯誤；503 -- 服務不可用
URL後面的#是什麼？
- 表明網頁中的一個位置；
- http請求中不包含；
- 改變#後面的內容，瀏覽器滾動到相應的位置，不會從新加載頁面；
- 改變#後面的內容，會改變瀏覽器的訪問歷史；
- ？和& 是傳參的分隔符；
請求體的格式：content-type設置爲，application/json；application/x-www-form-urlencoded；multipart/form-data；text/xml；
xhr.setRequestHeader('content-type', 'application/x-www-form-urlencoded');

6. 長鏈接、短鏈接、長輪詢、短輪詢

長鏈接與短鏈接
1. HTTP協議是基於請求/響應模式的，所以只要服務端給了響應，本次HTTP鏈接就結束了。
2. TCP是一種雙向的通道，能夠保持一段時間不關閉，所以TCP鏈接纔有真正的長鏈接何短鏈接。
3. HTTP協議是應用層協議，TCP是傳輸層協議，只有負責傳輸的這一層才須要創建鏈接。
4. HTTP請求和HTTP響應都是經過TCP鏈接這個通道來回傳輸的。
5. 短鏈接：
  鏈接只保持在數據傳輸過程當中，請求發起，鏈接創建，數據返回。鏈接斷開。
  適用於一些實時數據請求，配合輪詢進行新舊數據的更替。（用的不多）
6. 長鏈接：
  鏈接發起後，在請求關閉鏈接前客戶端與服務器保持鏈接，實質是保持這個通訊管道，以後進行復用，避免了頻繁的鏈接請求，提升了效率。
7. 如何設置長鏈接：
  在http請求頭中設置Connection: keep-alive;
  只有在HTTP1.1中才有長鏈接，並且默認長鏈接，HTTP1.0中是短鏈接。
  Connection還能夠設置爲close。
8. 長鏈接的好處：
  多個HTTP請求能夠複用同一個TCP鏈接，節省了不少TCP鏈接創建和斷開的消耗。（前一個請求返回後纔會再發請求，HTTP2相似管道的，沒有收到返回就再次發送請求。）
9. 長鏈接並非永久鏈接的，若是再超時時間後，這個鏈接沒有HTTP請求發出，那這個長鏈接就會被斷掉。
長輪詢與短輪詢
1. 輪詢：在一個循環內不斷髮起請求來獲得數據的機制。只要有請求的地方，均可以實現輪詢。
2. 短輪詢：一個循環內，不斷髮起請求，每一次請求都樂基返回結果，根據新舊數據對比決定是否使用這個結果；
3. 長輪詢：在請求的過程當中，若是服務端數據沒有更新，則將這個鏈接掛起，直到服務器推送新的數據，而後再進入循環週期。長輪詢請求掛起會致使資源浪費。
4. 無論是長輪詢仍是短輪詢，都不太適用於訪問量過大的狀況，由於每一個服務器所能承載的TCP鏈接數是有上限的，這種輪詢很容易把鏈接數頂滿。
長短輪詢和長短鏈接的區別：
1. 決定的方式：
  長短鏈接，在HTTP請求頭和響應頭中設置，須要兩邊都設置哦；
  長短輪詢，根據服務端的處理方式決定，與客戶端沒有關係；
2. 實現的方式：
  長短鏈接，經過協議來規定和實現的；
  長短輪詢，是服務器經過編程的方式手動掛起請求來實現的。

7. HTTP版本：

HTTP 1.0：
- 短鏈接，發送一次數據後就斷開TCP鏈接
HTTP 1.1:
- 默認是長鏈接，能夠用connection:keep-alive/close 來設置
- 服務器和瀏覽器都要支持
- 長鏈接，在請求關閉鏈接前客戶端與服務器保持鏈接。
- 若是長鏈接在超時時間後，這個http沒有發送請求，那麼此時這個長鏈接就會被斷開。
- Connection:keep-alive Keep-Alive: timeout=60，表示空閒時間爲60s。
- Connection:keep-alive，不設置超時時間，就是永久有效。
- TCP鏈接默認閒置時間是2小時，通常設置爲30分鐘足夠了。
- http鏈接保持時間是由服務端的消息頭connection字段和keep-alive字段定的。
HTTP 2.0:
- 首部壓縮。對消息頭採用HPACK進行壓縮傳輸，節省消息頭佔用的網絡流量（HTTP1.1帶有大量的冗餘頭信息）
- 二進制傳輸。採用二進制格式傳輸數據（HTTP1.1是問二八年格式），在協議解析和優化擴展上帶來更多優點和可能。
- 多路複用。採用多路複用的單一長鏈接
- 服務端推送。主動把客戶端可能須要的推送給客戶端。
- 請求優先級。若是流被賦予了優先級，它就會基於這個優先級來處理，由服務器決定須要多少資源來處理該請求。
- HTTP2，在底層傳輸機制上徹底重構，採用Frame，包含frame-header和frame-data，每一個frame header都有一個stream-ID，每次請求/響應使用不一樣的stream-ID，從而實現多路複用。
- server-push，當服務端主動推送某個資源的時候，便會發送一個frame-type爲push—promise的frame，裏面有push需新建的stream-id，客戶端接收到後發現是push—promise，就準備好接收。
HTTP 3.0：
- https://www.jianshu.com/p/bb3...
- QUIC（quick udp internet connections），基於 UDP 的傳輸層協議，提供像TCP同樣的可靠性。
- HHTP/2，雖然，不一樣流之間相互獨立，可是數據仍是一幀一幀的發送和接受的，一旦一個包丟失，後面的就會阻塞。QUIC，基於UDP，讓不一樣的流之間真正實現相互獨立傳輸，互不干擾。
- 切換網絡時的鏈接保持。基於 TCP的協議，切換網絡後，IP會變，所以鏈接會斷開。基於 UDP，則能夠內建與 TCP 不一樣的鏈接標識方法，從而在網絡完成切換後，恢復以前與服務器的鏈接。
- 目前TCP與SSL/TLS(1.0,1.1,1.2)每次建連須要TCP三次握手+安全握手，須要4~5個RRT。QUIC 實現零RTT創建鏈接。
- 鏈接：
- - client -> server: 發送一個 hello package
  - server -> client: 安全證書和對應客戶端的惟一的SYN cookie
  - client：解碼，保存 SYN cookie【此時使用了一個RRT】
  - client 若是解碼失敗。lient -> server: 要求從新發送安全證書，並將SYN cookie附加到這個請求包中，以便讓服務器驗證請求的正確性和有效性。【此時，創建鏈接須要2個RTT。】
  - client -> server:加密一個Hello Packet併發送。不用等恢復，繼續發送數據包。
  - server：接到Hello包以後，用本身現有的祕鑰解碼，若是解碼不成功，將把客戶端的鏈接當作第一次鏈接，重發安全證書等信息。同上介紹的同樣。此時，一般會有2個RTT，極端狀況下是3個RTT。
  - 服務器成功解碼以後，驗證了客戶端的安全性以後，就能夠繼續處理接下來收到的數據包。此時延時是0個RTT。

適用場景：

- 長距離傳輸

收集網絡（wifi切4G）
強求的頁面資源數較多，兵法的鏈接數多
要求加密傳輸

8. HTTPS：

特色：
- 請求前，會創建 ssl 鏈接，確保接下來的通訊都是加密的，沒法被輕易截取。
- 須要後端的支持（後端須要申請證書等）
- 開銷比 http 更大
加密算法：
- 對稱加密：
  - 特色：加密、解密用的同一把鑰匙。
  - 優勢：速度快、適合大量數據
  - 缺點：需同步密鑰，安全性差
- 非對稱加密：
  - 特色：公鑰+私鑰。
  - 優勢：安全
  - 缺點：速度快、適合少許數據
- hash 加密：將任意長度的二進制值映射爲固定長度的二進制值（成爲哈希值）。經常使用於檢驗數據的完整性，有沒有被篡改（md5）
過程：
- client -> server: 客戶端支持的加密算法和 hash 算法。
- server - > client: 從中挑選出服務端支持的加密算法和 hash 算法，以及證書。
- client: 驗證證書的有效性，並得到公鑰。生成一個隨機數R
- client -> server: 公鑰加密R，R加密握手消息，握手消息的hash值。
- server：私鑰解密獲得R，用R解密獲得握手消息，求握手消息的hash值，對比兩個 hash值是否一致。
- server - > client: R加密握手消息，握手消息的hash值。
- client：解密握手消息，求hash值，而後對比，一致則後續的消息都用這個R 加密。

9. HTTP緩存機制：

強制緩存：
- 瀏覽器斷定本地緩存可用，就直接使用，不會發起 http請求。
- 只考慮是否過時，可是沒有考慮服務端數據是否更新，致使可能獲得的不是最新數據。
協商緩存：
- 向服務端發送http請求肯定緩存是否有效，有效返回304，則使用緩存，不可用，則返回200和數據，將新數據緩存並使用新數據。
- 強制緩存不可用時，才用？
使用緩存的策略：
- 頻繁變更的資源：cache-control：no-cache；etag/last-modified
- 不常變更的資源： cache-control： max-age = 很大的數，在文件名中加入動態字符（hash/版本號），更新時更新動態字符，致使以前的強制緩存失效（只是不用了）
HTTP 1.0：
- 強制緩存：
  - expires：相對時間，對應服務端的時間。
  - 例子：Expires：Fri, 30 Oct 1998 14:19:41
- 協商緩存：
  - if-modified-sice：請求頭。
  - last-modified：響應頭。在服務器端設置的文件最後修改事件。
HTTP 1.1：
- 強制緩存：
  - cache-control：
    - public：響應可被客戶端和代理服務器緩存。
    - private：響應只可被客戶端緩存。
    - max-age = 30：30s後緩存過時，需從新發送請求。
    - s-maxage = 30：30s後緩存過時，在代理服務器中覆蓋 max-age。
    - no-store：不緩存
    - no-cache：不使用 cache-control 來控制緩存。
    - max-stale = 30：過時30s內仍可用。
    - min-fresh =30：30s內獲取最新響應。
  - max-age 中保存的是絕對時間，時間由瀏覽器計算。
  - 比 http1.0 的進步：時間是對於瀏覽器而言的，若是瀏覽器和服務器時間不一致也沒用關係。
- 協商緩存：
  - if-none-match：請求頭。
  - etag：響應頭。是文件的特殊標識（通常都是hash生成的）
  - 比 http1.0 的進步：
    - last-modified：最小單位是s；負載均衡的服務器，各個服務器生成的時間可能不一致；文件內容不變可是修改日期變了會致使緩存失效。
    - etag：精度高；性能差一點（須要計算 hash值）；優先級更高。
用戶的不一樣操做使用的緩存：
- 打開網頁：查找硬盤中是否有。
- 普通刷新（F5）：tab未關閉，內存可用，沒有采起硬盤找。
- 強制刷新（ctrl+F5）：不適用緩存。

10. CDN：

CDN = 鏡像 + 緩存 + 總體負載均衡
做用：將網站的內容發佈到離用戶更近的網絡‘邊緣’，提升響應速度。
緩存內容：靜態資源（css，js，圖片，靜態網頁。用戶從主站服務器請求到動態內容，再從CDN上下載靜態數據）
工做流程：
- 瀏覽器向本地的DNS服務器請求對該域名的解析，DNS系統會最終將解析權交給CNAME指向的CDN專用DNS服務器。
- CDN的DNS服務器將CDN的全局負載均衡設備IP地址返回用戶。
- 用戶向CDN的全局負載設備發起內容URL訪問請求。
- CDN的全局負載設備根據用戶的IP地址，以及用戶請求的內推URL,選擇一臺用戶所屬區域的區域負載均衡設備，告訴用戶向這臺設備發起請求。
- 區域負載均衡設備會爲用戶選擇一臺合適的緩存服務器提供服務，選擇的依據包括：根據用戶IP地址，判斷哪一臺服務器距用戶最近；根據用戶所請求的URL中攜帶的內容名稱，判斷哪一臺服務器上有用戶所需內容；查詢各個服務器當前的負載狀況，判斷哪一臺服務器尚有服務能力。基於以上這些條件的綜合分析以後，區域負載均衡設備會向全局負載均衡設備返回一臺緩存服務器的IP地址。
- 用戶向緩存服務器發起請求，緩存服務器響應用戶請求，將用戶所需內容傳送到用戶終端。若是這個節點中請求的文件不存在，就會再回到源站去獲取這個文件，而後再返回給用戶。
特色：
- 「分佈式存儲」：將中心平臺的內容分發到各地的邊緣服務器，使用戶可以就近獲取所需內容，下降網絡用時，提升用戶訪問響應速度和命中率。利用了索引、緩存等技術。
- 「負載均衡」：對全部發送的請求進行訪問調度，肯定提供給用戶的最終實際訪問地址。
- 「內容管理」：負責對存儲內容的監管、數據分析等。
爲何使用：
- 服務器的帶寬有限，若是超過限制，網頁半天都反應不過來。而CDN能夠經過不一樣的域名來加載文件，從而使下載文件的併發鏈接數大大增長。
- jquery 一類的庫文件，若是訪問你網站的用戶的瀏覽器以前在訪問別的網站時經過和你相同的CDN已經加載了jquery，因爲該文件已經被緩存，就不用從新下載了。
- CDN，具備更好的可用性，更低的網絡延遲和丟包率。
- CDN能提供本地的數據中心，那些遠離網站主服務器的用戶也能就近很快下載文件。
- 不少商業付費的CDN能提供使用報告，這能夠做爲你本身網站分析報告的補充。
- CDN可以分配負載，節省帶寬，提升網站的性能，下降網站託管的成本，一般是免費的。
- 大型Web應用對速度的追求並無止步於僅僅利用瀏覽器緩存，由於瀏覽器緩存始終只是爲了提高二次訪問的速度，對於首次訪問的加速，咱們須要從網絡層面進行優化，最多見的手段就是CDN
CDN 的缺點：
- 在開發階段若是處在斷網環境下，CDN文件是沒法加載的。
- 不夠靈活。好比你只使用jquery庫的一小部分，若是使用CDN上提供的文件就沒辦法進行拆分，仍是得下載原來的大小，反而沒有本身拆分後加載速度來得快。
- 儘管一些流行的CDN文件事先緩存過的概率較大，但並非必定的，一些移動設備的緩存可能很小並且效率很低，CDN的優點就不明顯了，特別是當你能夠在本地服務器上存放比CDN文件更小的文件時。
- 因爲地理、法律、政策和商業上的阻隔，你所在的地區可能屏蔽了一些流行的免費CDN服務的域名或者IP地址。
- CDN會有出故障的時候，這時候要有備用方案，也就是你的本地文件，這種處於穩定考慮的冗餘會增大開發工做量和複雜度。
- 若是安全性對你的網站很重要，就不要使用公共的CDN，由於當你遠程從CDN請求文件時，你的訪問來源信息也被髮送過去，一些遠程的js文件可能被修改用來蒐集你的用戶或者系統信息，而當你使用https協議時，能選擇的CDN就更加有限。
如何使用：
- 1.將靜態資源部署到不一樣網絡線路的服務器中，以加速對應網絡中CDN節點無緩存時溯源的速度。
- 2.加載靜態資源時使用與頁面不一樣的域名，一方面是便於接入爲CDN而設置的智能DNS解析服務，另外一方面由於靜態資源和主頁面不一樣域，這樣加載資源的HTTP請求就不會帶上主頁面中的Cookie等數據，較少了數據傳輸量，又進一步加快網絡訪問。