碼上快樂

相關內容    簡體    繁體

企業CDN緩存加速原理解密

本文轉載自   查看原文   2019-07-23 13:09   578 

1.1 CDN（網站加速）

 

1.1.1 什么是CDN

CDN的全稱Content Delivery Network，即內容分發網絡。其基本思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快，更穩定。通過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統能夠實時地根據網絡流量和各節點的連接，負債情況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容，解決Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。

產生背景：

BGP機房雖然可以提升用戶體驗但是價格昂貴，那么CDN的誕生可以提供比BGP機房對於用戶更好的體驗（讓地區的同一線路訪問當地的同一線路的網站），BGP機房和普通機房價格將近5-10倍的價格差。CDN使用單線的機房，根據用戶的線路以及位置為用戶選擇靠近用戶的位置以及相同的運營商線路，即提升了用戶體驗價格又降下來了。

CDN的價值：為客戶省錢，同時提升用戶體驗。

 

1.1.2 CDN的特點

（1）本地Cache加速提高了企業站點（尤其含有大量圖片和靜態頁面站點）的訪問速度，並大大提高以上性質站點的穩定性（省錢，用戶體驗提升）。

（2）鏡像服務消除了不同運營商之間互聯的瓶頸造成的影響，實現了跨運營商的網絡加速，保證不同網絡中的用戶都能得到良好的訪問質量。

（3）遠程加速遠程訪問用過戶根據DNS負載均衡技術智能自動選擇Cache服務器，選擇最快的Cache服務器，加快遠程訪問的速度。

（4）帶寬優化自動生成服務器的遠程Mirror（鏡像）cache服務器，遠程用戶訪問時從cache服務器上讀取數據，減少遠程訪問的帶寬，分擔網絡流量，減輕原站點WEB服務器負載等功能。

 
  1. [root@web01 ~]# curl -I www.163.com
  2. HTTP/1.1 200 OK
  3. Expires: Wed, 02 Aug 2017 01:07:33 GMT
  4. Date: Wed, 02 Aug 2017 01:06:13 GMT
  5. Server: nginx
  6. Content-Type: text/html; charset=GBK
  7. Transfer-Encoding: chunked
  8. Vary: Accept-Encoding,User-Agent,Accept
  9. Cache-Control: max-age=80
  10. Age: 43
  11. X-Via: 1.1 fzhwtxz28:9 (Cdn Cache Server V2.0), 1.1 wangtong40:9 (Cdn Cache Server V2.0)
  12. Connection: keep-alive

(5)集群抗攻擊廣泛分布的CDN節點加上節點之間的智能冗余機制，可以有效地預防黑客入侵以及降低各種DDOS攻擊對網站的影響，同時保證較好的服務質量。

 

1.1.3 使用CDN的基本要求

要加速的業務應該存在獨立的域名，例如：www.yunjisuan.com，業務內容圖片，附件JS，CSS等靜態元素。 
正常的DNS解析范例： 
我們DNS服務器上的加速前的A記錄。

 
  1. A records
  2. www.yunjisuan.com IN A 124.106.0.21(服務器IP)
  4. 刪除上面的記錄：
  5. www.yunjisuan.com IN A 124.106.0.21(服務器IP)
  7. 然后，做下面的別名解析：
  8. CNAME records
  9. www.yunjisuan.com IN CNAME bbs
 

1.1.4 CDN服務提供商架構的關鍵元素

  • DNS和智能DNS集群
  • Cache集群
  • 用戶源站（cdn服務的客戶）
  • 外圍（計費，日志分析，存儲，protal展示）
 

1.1.5 智能DNS

image_1d1acc12911pqkvq15kv13uq158r9.png-156.5kB

 

1.1.6 CDN的原理

image_1d1accesjldh17pu1fl4d5lm1om.png-335.2kB

 

1.1.7 CDN的用途

企業或門戶網站的圖片，視頻，css，js，html等靜態數據的緩存

大網站會把全站首頁靜態化放CDN，推廣頁面。

支持動態加速

 

1.1.8 CDN架構圖

image_1d1acd4g8q1hkt5asfbn3gs513.png-122.4kB

 

1.1.9 CDN計費

CDN用多少交多少錢，這和IDC機房先購買固定帶寬是有區別的。

計費方式說明：當前的計費方式為95%值計費方式，即取查詢時間段中，所有帶寬數據點，按帶寬大小從低到高排序后，取第95%個點所對應的值作為計費帶寬。如一段時間內有N（N=100）個帶寬數據點，將這些點從低到高排序，第N*95%（100*95%=95）個點對應的帶寬大小為該計費帶寬的值。

 

CDN案例：有的時候我們源站負載很高（Web服務以及存儲）

排查： 
1）分析Web日志。IP來源誰 
2）有可能CDN頻繁來抓數據（a，源站更新頻繁，b，CDN的緩存經常倒騰數據，c，命中率要高於98%）。CDN遇到404 403錯誤，是不緩存的，會向后請求源站 
3）CDN公司增加緩存節點（一增加就是幾百台級別）。抓源站，告訴CDN抓自己的服務器，不要老抓源站。

 

1.1.10 CDN后台

image_1d1aceb3j1pgs1mro18qcbo91m6a1g.png-195.8kB

image_1d1aceht91m1i1ps211u3bf915bn1t.png-186.5kB

 

CDN刪除違規圖片流程

1，CDN通知源站刪除圖片

2，源站運維從CDN提供的后台管理頁面提交刪除后的圖片的位置的URL進行更新。

image_1d1acf4nt1bbu6191hqo173oj12a.png-101.8kB

 

源站更新了圖片，那么CDN怎么更新？

1）源站更新，CDN不知道也不專注， 
外部用戶觸發：用戶會請求元素，這個元素CDN第一次沒有，CDN會去源站請求。 
內部編輯觸發：源站更新時，通過CDN接口推送到CDN

 

1.1.11 CDN價格

30-100/M/月

 

1.1.12 如何選擇CDN公司

網宿，chinacache（藍訊），快網，帝聯

 

1.1.13 跨機房分布式部署技術

image_1d1acg7hiphm1t6e1pof1r1olgf2n.png-250.9kB

 

1.1.14 其他問題

（1）CDN節點宕機，企業網站人員如何知道？ 
不能可自主知道，只能通過： 
1，CDN節點宕機地區的用過戶反饋（其他地區都是好的，就這里有問題） 
2，基調網絡，博瑞，分布式測試

image_1d1acgnf911716hp1vocb6cjei34.png-210.2kB

 

附錄1：CDN流量暴高如何分析與解決企業案例

 

1.1：列舉案例：

 

（1）實際案例一

凌晨三點某公司（網站業務）的一個IDC機房帶寬流量突然從平時高峰期150M猛增至1000M，如下圖：

image_1d1achhjrvl1hie1k87dvu1f553h.png-79kB

該故障的影響：直接導致數百台服務器無法連接，該機房全部業務中斷。

 

（2）實際案例二：

某年某月某日夜接到學生緊急求助，公司網站（Web游戲業務）平時幾十M帶寬，結果突然跑滿100M，持續100M已經很久。事后，該學生的總結開頭如下：

凌晨一點接到報警短信，網站無法訪問。立馬拿起筆記本上網查看，發現整個機櫃的網絡都無法正常訪問。第一感覺是不是IDC網絡出問題了，給機房打電話反饋回來的信息是機房網絡正常，但是帶寬流量異常（100M帶寬的流量峰值已跑滿）

該故障的影響：直接導致數十台服務器無法連接，該機房全部業務中斷，且故障持續時間長。

 

（3）實際案例三

某月某日，接到運維朋友緊急求助，其公司的CDN源站，源站的流量沒有變動，CDN那邊的流量無故超了好幾個G，不知道怎么處理？

該故障的影響：由於是購買的CDN，雖然流量多了幾個G，但是業務未受影響，但是，這么大的異常流量，持續下去可直接導致公司無故損失數萬元。解決這個問題體現運維的價值。

 

1.2 分析問題：

 

1）IDC帶寬被占滿的原因很多，常見的有：

a，真實遭受DDOS攻擊（遇到過幾次，造成影響的不多見，其中還有黑客勒索的案例）

b，內部服務器中毒，大量外發流量

c，網站元素（如圖片）被盜鏈，在門戶頁面被推廣導致大量流量產生

d，合作公司來抓數據，如：對合作單位提供了API數據接口

e，購買了CDN業務，CDN猛抓源站

 

2）CDN帶寬異常，源站沒異常

這類問題基本都是緩存在CDN的數據被頻繁訪問引起的。解決方法見結尾案例。

 

3）CDN帶寬異常，源站也異常。

可能原因如公司做推廣，大量數據訪問，熱點數據cache里不全。或CDN問題導致數據回源。影響就是帶寬高，后端靜態服務器及圖片及存儲壓力大。

 

1.3 解決問題：

分析了問題的可能原因，就好比較排查了。

 

1）真實遭受DDOS攻擊

如何防護DDOS攻擊?

1.了解DDOS的幾種攻擊類型，攻擊原理，攻擊特征，抓包和分析日志那是必須的，只有知道這些信息，才能制定應對措施。

2.了解自己公司帶寬，服務器，防火牆，架構的承受能力，再就是制定相應的應急預案，有什么情況下起用什么樣的應對策略，讓處理問題有序進行，以保證業務正常對外提供服務為原則。

3.IDC機房的選用：這一點確實很關鍵，要尋找一些有實力，能提供更高級別防護，當面對攻擊時能快速響應並配合做各種防護策略的IDC廠商合作，當然這種機房的價格也就相對會高些，這個根據實際情況來考慮，成本和安全找到一個平衡點，不要為公司省錢，當出現問題時，公司可能就不會考慮你為公司省了多少，而是損失多少。

4.架構設計：對於整體架構的設計要基於核心單點無單點（如果要求更高些，可以整體無單點），多緩存的原則，保證高可用，跨ISP，跨機房多點分布式部署，不能在一棵樹上吊死，大量的DDOS攻擊導致整個機房跨掉的我是碰到過幾次。

5.系統優化：操作系統內核優化，程序層的代碼優化，數據庫層的結構優化，存儲層的性能優化，業務層的業務邏輯優化，整體構架的節點優化...，另外，不要動不動就配置65535，很多運維人員總覺得配置的最大連接數越大越好，其實不然，這個要根據實際情況來設置，如果把連接數設的太大，一旦攻擊來了，還沒等你去分析問題，服務器就已經掛了。

6.CDN：借助CDN來分擔壓力

7.硬件防護：對於軟件防護，我想一般在對操作系統內核做優化的時候這些都已經考慮進去了，對於硬件防護我們可以使用傲盾，黑洞等專業的防DDOS防火牆組建集群。

8.數據包及日志分析：對於那種四兩撥千斤（SYN flood，CC）或者疑似DDOS的攻擊，可以通過分析數據包，日志來按制定防護策略，如果說要報警，這些也可以為警方提供線索。

9.疑似DDOS攻擊：如果文件被盜鏈，服務器中毒，前端緩存服務器設置不合理，程序BUG，交換機（路由器）故障等要通過抓包分析，日志分析來定位問題。

10.第三方求助：對於大量的攻擊可以請求上層的IDC或者ISP協助處理，對於一些無法准確判斷的攻擊方式可以請求行業內相熟的高手來協助處理，懂得求助往往事半功倍，還能快速的處理問題。

 

2）內部服務器中毒，大量外發流量。

  • 這個問題的解決比較簡單，可能有的同學說，看看服務器流量，哪個機器帶寬高處理下就好了。其實不然，實際解決比這復雜得多，帶寬打滿，所有監控都是看不到的。

  • 比較好的思路，是聯系機房確定機房自身無問題后（機房一般沒法幫我們的），請機房斷開連接外部IP服務器的網線，如負載均衡器，僅保留VPN SERVER，然后斷掉內部服務器出網關的線路，切斷外發流量源頭。

  • 接下來查看監控流量服務，判斷外發流量的服務器，然后進行處理。

  • 其實，這個問題的發生及快速定位和很多公司的運維規范，制度關系很大，在給一些公司做運維培訓分享時發現這個問題很嚴重（表象很好，內部運維規范，制度欠缺很多），大家都討論的很深入，實際用的還是和聊的有差距。

  • 比如有的公司開發直接FTP連接隨時發布代碼，或者由開發人員負責定時多次上線。而運維人員又不知曉，結果導致問題發生定位時間長。

  • 建議的運維思路是：如果把網站機房比喻為一座房子，那首先要堵住后門（內部），其次是監控好前門（做好安全，留個小窗戶給外面人看，即80端口服務，同時安排站崗值班的）

  • 網站的無休止的隨時隨意發布代碼，對網站的穩定影響是至關重要的。對運維人員對故障的定位快慢也很關鍵。根據不完全的調查統計，約50%以上的重要運維故障都是程序代碼導致的，這也是在企業做培訓分享時，灌輸建議CTO的，多把網站穩定的責任分給開發，而不是運維。如果這個思路不扭轉，網站不穩定狀況就難以改變。

 

3）網站元素（如圖片）被盜鏈

這個屬於網站的基本優化了，apache，lighttpd，nginx都有防盜鏈的方案，必須要搞。說到這也提個案例，有個學生，到了企業工作，發現人家網站沒有防盜鏈，結果上來沒有通知老大，就直接做防盜鏈了，然后美美的當時還給我留言，說給公司搞防盜鏈了，很有成就，結果導致公司對外合作的業務，都是小叉子了，幸虧發現的及時沒有出大問題。

 

（4）合作公司來抓數據，如：對合作單位提供了API數據接口或購買了CDN業務。

  • 最常見的就是購買CDN服務，如：CDN新建一個節點（可能數十機器），直接來我們IDC源站來抓數據（有的做的好點的夜里來抓）。把源站抓的流量暴漲，嚴重的導致服務宕機。幾家CDN公司，都有過這樣的問題。

  • 當然和電信，聯通，GOOGLE，BAIDU，詞霸等公司合作，也會有流量爆高的情況，這里面包括了為合作的站搜索引擎爬蟲爬數據的問題。有時雖然帶寬流量不高，但是服務器或數據庫撐不住了，搜索引擎專門喜歡爬站內搜索，DISCUZ，CMS等早期的開源程序的搜索都是全站like%%方式去數據庫搜索的，幾個爬蟲過來，直接就掛掉了。

 

1.4 實戰解決案例

下面的例子適合於網站流量很高，但是，還沒達到全網癱瘓的嚴重地步時的解決方案，適合我們自己的IDC機房及CDN業務（如果是CDN，那么，分析處理可以交給CDN，自己下載CDN日志分析也可）。

范例：分析圖片服務日志，把日志（每個圖片訪問次數*圖片大小的總和）排行，取top10，也就是計算每個url的總訪問大小

在生產環境里的應用：這個功能可以用於IDC及CDN網站流量帶寬很高，然后通過分析服務器日志哪些元素占用流量過大，進而進行優化裁剪該圖片，壓縮js等措施。

 
  1. 本題需要輸出三個指標： 【訪問次數】 【訪問次數*單個文件大小】 【文件名（可以帶URL）】
  2. 解答：
  3. 測試數據
  4. 59.33.26.105 - - [08/Dec/2010:15:43:56 +0800] "GET /static/images/photos/2.jpg HTTP/1.1" 200 11299 "http://oldboy.blog.51cto.com/static/web/column/17/index.shtml?courseId=43" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
  5. 59.33.26.105 - - [08/Dec/2010:15:43:56 +0800] "GET /static/images/photos/2.jpg HTTP/1.1" 200 11299 "http://oldboy.blog.51cto.com/static/web/column/17/index.shtml?courseId=43" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
  6. 59.33.26.105 - - [08/Dec/2010:15:44:02 +0800] "GET /static/flex/vedioLoading.swf HTTP/1.1" 200 3583 "http://oldboy.blog.51cto.com/static/flex/AdobeVideoPlayer.swf?width=590&height=328&url=/[[DYNAMIC]]/2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
  7. 124.115.4.18 - - [08/Dec/2010:15:44:15 +0800] "GET /?= HTTP/1.1" 200 46232 "-" "-"
  8. 124.115.4.18 - - [08/Dec/2010:15:44:25 +0800] "GET /static/js/web_js.js HTTP/1.1" 200 4460 "-" "-"
  9. 124.115.4.18 - - [08/Dec/2010:15:44:25 +0800] "GET /static/js/jquery.lazyload.js HTTP/1.1" 200 1627 "-" "-"


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 Linux就業技術指導（四）：企業CDN緩存加速原理解密 CDN加速原理解析 什么是CDN及CDN加速原理 CDN和CDN加速原理 CDN是什么與CDN加速的原理 CDN的加速原理是什么？ CDN原理加速解析 CDN加速原理 CDN與緩存的歸納理解 CDN與緩存的歸納理解
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM