CDN架構


  CDN架構

     CDN公司在整個互聯網中部署了數以百計的節點(Cache服務器集群)。這些Cache服務器都分布在各個網絡運營商的IDC機房中,位置盡量靠近用戶網絡。CDN系統將內容從源站復制到各個節點,在內容提供者更新內容時,CDN系統將更新后的內容重新分發到各個節點。當用戶請求內容時,CDN系統將選擇一個最優的節點向用戶提供內容。這個挑選最優節點的過程,就是負載均衡。而這個最優節點,可能最接近用戶,或者有一條與用戶之間條件最好的路徑。

一、功能架構

功能架構圖

1、分發服務系統

  • 其基本的工作單元就是各個Cache服務器。負責直接響應用戶請求,將內容快速分發到用戶;同時還負責內容更新,保證和源站內容的同步。
  • 根據內容類型和服務種類的不同,分發服務系統分為多個子服務系統,如:網頁加速服務、流媒體加速服務、應用加速服務等。每個子服務系統都是一個分布式的服務集群,由功能類似、地域接近的分布部署的Cache集群組成。
  • 在承擔內容同步、更新和響應用戶請求之外,分發服務系統還需要向上層的管理調度系統反饋各個Cache設備的健康狀況、響應情況、內容緩存狀況等,以便管理調度系統能夠根據設定的策略決定由哪個Cache設備來響應用戶的請求。

2、負載均衡系統:

  • 負載均衡系統是整個CDN系統的中樞。負責對所有的用戶請求進行調度,確定提供給用戶的最終訪問地址。
  • 使用分級實現。最基本的兩極調度體系包括全局負載均衡(GSLB)和本地負載均衡(SLB)。
  • GSLB根據用戶地址和用戶請求的內容,主要根據就近性原則,確定向用戶服務的節點。一般通過DNS解析或者應用層重定向(Http 3XX重定向)的方式實現。
  • SLB主要負責節點內部的負載均衡。當用戶請求從GSLB調度到SLB時,SLB會根據節點內各個Cache設備的工作狀況和內容分布情況等對用戶請求重定向。SLB的實現有四層調度(LVS)、七層調度(Nginx)和鏈路負載調度等。

3、管理系統:

  • 分為運營管理和網絡管理子系統。
  • 網絡管理系統實現對CDN系統的設備管理、拓撲管理、鏈路監控和故障管理,為管理員提供對全網資源的可視化的集中管理,通常用web方式實現。
  • 運營管理是對CDN系統的業務管理,負責處理業務層面的與外界系統交互所必須的一些收集、整理、交付工作。包括用戶管理、產品管理、計費管理、統計分析等。

4、小結:

  • CDN系統中,分發服務器系統、調度控制系統和運營管理系統都是分級分布式部署的。CDN系統本身就是一個具有中央控制能力的分布式服務系統。

二、部署架構

部署架構圖

1、層級划分:

  • CDN系統中,直接面向用戶,負責給用戶提供內容服務的的Cache設備都部署在整個CDN網絡的邊緣位置,所以將這一層稱為邊緣層。
  • CDN系統中,中心層負責全局的管理和控制,同時也保存了最多的內容Cache。在邊緣層設備未能命中Cache時,需要向中心層設備請求;而中心層未能命中時,則需要向源站請求。不同的CDN系統設計存在差異,中心層可能具備用戶服務的能力,也可能只會向下一層提供服務。
  • 如果CDN系統比較龐大,邊緣層向中心層請求內容太多,會造成中心層負載壓力太大。此時,需要在中心層和邊緣層之間部署一個區域層,負責一個區域的管理和控制,也可以提供一些內容Cache供邊緣層訪問。

2、邊緣節點的負載均衡:

  • 這里寫圖片描述
  • Cache設備和負載均衡設備的連接方式有如上兩種:穿越方式和旁路方式。
  • 穿越方式下,SLB一般使用L4-7層的交換機實現,SLB對外提供可訪問的公網IP,而各個Cache設備只分配私網IP。一個SLB下掛載的所有Cache設備構成一個服務集群。所有的用戶請求都要先經過SLB,再由SLB將請求向Cache設備轉發。SLB對外部用戶屏蔽了Cache地址,具有較好的安全性和可靠性;但是在節點負載較大時,SLB設備容易成為性能瓶頸。另外,可以通過軟件方式實現穿越方式:LVS(四層)和Nginx(七層)。
  • 旁路模式下,SLB和Cache設備都分配有外網IP,使用並聯方式連接。用戶請求先到達SLB,SLB再將請求重定向到Cache設備。此種方式部署靈活,擴展性好。但是SLB和Cache設備都直接面向用戶,並且需要應用層重定向,安全性較差。

 

 

這里寫圖片描述

 用戶訪問網站流程框架

第一步:客戶端用戶從瀏覽器輸入www.baidu.com網站網址后回車,系統會查詢本地hosts文件及DNS緩存信息,查找是否存在網址對應的IP解析記錄。

             如果有就直接獲取到IP地址,然后訪問網站,一般第一次請求時,DNS緩存是沒有解析記錄的;

第二步:如果客戶端沒有DNS緩存或hosts沒有對應www.baidu.com網站網址的域名解析記錄,那么,系統會把瀏覽器的解析請求,交給客戶端本地設置的DNS服務器地址解析(此DNS為                LDNS,即Local DNS),如果LDNS服務器的本地緩存有對應的解析記錄,就會直接返回IP地址;如果沒有,LDNS會負責繼續請求其它的DNS服務器;

第三步:LDNS會從DNS系統的“.”根開始請求www.baidu.com域名的解析,經過一系列的查找各個層次DNS服務器,最終會查找到www.baidu.com域名對應的授權DNS服務器,而這個授              權DNS服務器,正是該企業購買域名時用於管理域名解析的服務器。這個服務器有www.baidu.com對應的IP解析記錄,如果此時都沒有,就表示企業的運維人員么有給                            www.baidu.com域名做解析;

第四步:baidu.com域名對應的授權DNS服務器會把www.baidu.com對應的最終IP解析記錄發給LDNS;

第五步:LDNS把收到來自授權DNS服務器關於www.baidu.com對應的IP解析記錄發給客戶端瀏覽器,並且在LDNS本地把域名和IP的對應解析緩存起來,以便下一次更快的返回相同的解析              請求的記錄;

第六步:客戶端瀏覽器獲取到了www.baidu.com的對應IP地址,接下來瀏覽器會請求獲得的IP地址對應的Web服務器,Web服務器接收到客戶的請求並響應處理,將客戶請求的內容返回給               客戶端瀏覽器;

至此,一次訪問瀏覽網頁的完整過程就完成了。

DNS解析原理

       dns解析的流程:計算機之間只能通過ip相互通信,因為ip不好記,於是才使用dns服務器把域名解析為相應的ip,這里以解析www.baidu.com為例,當我們輸入這個網址回車的時候,瀏覽器會首先查詢瀏覽器的緩存,這個緩存存活時間可能只有1分鍾,如果沒找到,則去查詢本地的dns緩存和hosts文件,如果有www.baidu.com這個域名對應的ip,則直接通過這個ip訪問網站服務器。如果本地的dns緩存和hosts文件沒找到,這時候就會把請求發送給,網卡配置信息里的dns服務器,默認有兩個,只有當dns1不能訪問時,才會使用dns2。

       我們也稱網卡配置信息里的dns為local dns,這時候local dns會先查詢它的緩存,有沒有www.baidu.com相應的記錄,如果有,則返回給用戶,如果沒有,就會訪問根域名服務器,世界一共有13台根域名服務器,根域名服務器一看,是找.com的,於是會把.com的頂級域名服務器的ip發送給local dns,這時local dns再次訪問.com的頂級域名服務器,.com的頂級域名服務器一看,是找一級域名baidu.com的,於是再將baidu.com的ip發送給local dns,然后繼續往下找,直到找到www.baidu.com的權威dns的A記錄或者cname,這時候local dns會把找到的www.baidu.com的ip發送給客戶端,並記錄在緩存中,這樣的話,下次如果有其他的用戶訪問www.baidu.com這個域名時,local dns的緩存中就有記錄了。客戶端收到local dns發送過來的ip就會通過ip去訪問服務器,並將這個ip記錄在dns緩存中。

tcp/ip三次握手

這里寫圖片描述 
通過dns解析之后,拿到了ip,就可以通過ip向服務器發送http請求了,因為http是工作在第七層應用層,tcp是工作在第四層傳輸層,所以發生http請求之前,還會進行tcp的三次握手。 
tcp的三次握手是:客戶端首先向服務器發送一個帶有SYN標識和一個seq的隨機數,服務端收到后,需要給客戶端回應一個ack,ack的值就是剛才的seq隨機數的值+1,在回應包里,還包含一個SYN的標識和一個seq隨機數。客戶端收到服務端發過來的回應包之后,再給服務端發送一個ack,ack的值就是剛才服務端發過來的seq的值+1。上面三步完成之后,三次握手就完成了,下面就可以開始傳數據了

osi參考模型

這里寫圖片描述

TCP/IP模型處理過程

這里寫圖片描述

以太網的數據鏈路大致流程

這里寫圖片描述

路由解析:

這里寫圖片描述

靜態路由

這里寫圖片描述

 動態路由

這里寫圖片描述

路由算法

這里寫圖片描述

http協議原理(www服務請求過程)請求細節,報文細節

這里就是開始發送http請求報文了

http的請求報文,主要包括,請求行,請求頭部,空行,請求主體 
這里寫圖片描述 
而請求行又包括,請求方法,url,協議版本,請求方法主要有GET、HEAD、POST、PUT、DELETE、MOVE,url就是統一資源定位符,通過這個能在服務器上找到唯一的網頁資源,協議版本,目前主流的是http1.1,開始流行的協議版本是http1.0,相對應http1.0,http1.1主要從可擴展性、緩存處理、帶寬優化、持久連接、host頭、錯誤通知、消息傳遞、內容協商等多方面做了一些優化,以上是請求行的內容 
再來說一些,請求頭部,請求頭部主要有媒體類型,語言類型、支持壓縮、客戶端類型、主機名等,媒體類型主要有文本文件,圖片文件,視頻文件等,語言類型就是告訴服務器客戶端的接受的語言,支持壓縮的話,可以節省帶寬,客戶端類型,會顯示客戶端瀏覽器的版本信息,操作系統信息等 
空行,代表請求頭部的結束,也代表着請求主體的開始 
請求報文主體,只有使用POST提交表單的時候才有

大規模網站集群架構細節

常見的網頁資源有三種,分別是靜態網頁,動態網頁,偽靜態 
靜態網頁就是沒有后台數據庫,不含php,jsp,asp等程序,不可交互的,開發者編寫的是啥,顯示的就是啥,不會有任何改變 
動態網頁,有后台數據庫,支持更多的功能,如用戶注冊,登錄,發帖,訂單,博客等,動態網頁並不獨立存在於服務器上的網頁文件,而是當用戶請求服務器上的動態程序時,服務器解析這些程序,並調用數據庫來返回一個完整的網頁內容,它跟靜態網頁的url不同,它的url中包含?、&等特殊符號,搜索引擎收錄的時候存在一定的問題。動態網頁為了方便收錄,常常會利用rewrite技術,把動態網頁的URL偽裝成靜態網頁URL,這就是偽靜態。

不同的網頁資源,打開的流程不一樣,下面假設我們訪問的是一個靜態網站: 
客戶端會通過http協議,下載服務器上的html文件,然后去讀這個html文件,根據html頁面中的鏈接,自上而下的請求,每一個請求是一個鏈接,如果是圖片的話,會下載邊渲染,遇到js,就會加載js,當js比較內容較復雜時,瀏覽器就會等待,鼠標在轉圈,我們稱這個為js阻塞,當js下載完畢並執行完成之后,才會顯示我們看到的網頁。

當我們訪問的是一個動態網頁時,首先用戶發出一個請求,服務器收到這個請求之后,這里假設服務器使用的是nginx,nginx會把這個請求轉給php,php就會去查詢數據庫,根據數據庫返回的值,生成一個完整的網頁內容,發送給用戶,用戶收到之后,也是邊下載邊渲染,加載js,執行完畢之后,才會顯示我們看到的網頁

當服務器的訪問量達到億級PV時,這個訪問的過程就更復雜了,用戶的請求會先訪問全國的CDN節點,通過CDN擋住全國80%的請求,當CDN上沒有時,在訪問服務器集群,這個集群一般都有一個4層的代理,這個4層的代理,使用軟件來完成的話,就是LVS,使用硬件就是F5,4層的代理,后面才是7層的負載均衡,常用的是haproxy,nginx,然后才是多台web服務器,web服務器比較多的時候,就有兩個問題,一個是用戶數據的一致性,不能因為不同的web服務器提供服務,而導致數據不同步,這時候,我們就需要使用NFS共享存儲,第二個問題是session,不能因為不同的web服務器提供服務,session找不到了,這時候,我們就需要使用memcached來存放並共享session。由於用戶訪問量太大,這時候的瓶頸就是數據庫的壓力,我們一般都是使用分布式緩存memcache,redis等,另外數據庫還需要做讀寫分離等優化,后面的過程與訪問動態網頁類似

http協議原理(www服務響應過程)響應細節,報文細節

對應的,服務器收到請求報文之后,就會給出響應報文

響應報文主要包含起始行、響應頭部、空行、響應報文主體 
這里寫圖片描述 
起始行一般包含http版本號,數字狀態碼,狀態情況 
而數字狀態碼,常見有以下幾種 
200 代表ok 
301 永久跳轉 
403 沒權限 
404 沒有這個文件 
500 未知的錯誤 
502 網關錯誤 
503 服務器超載,停機維護 
504 網關超時 
響應頭部,主要包括,服務器的web軟件版本,服務器時間,長連接還是短連接,設置字符集等等 
這里的空行和請求報文空行一樣

HTTP報文結構

(1)HTTP報文大致可以分為報文首部和報文主體兩塊

 

 

 這里寫圖片描述 

(2)請求報文和響應報文的結構實例 

 

 

這里寫圖片描述

 HTTP/1.1規范定義了如下47種首部字段

(1)通用首部字段

 

 這里寫圖片描述 

(2)請求首部字段 

 

 
這里寫圖片描述   

(3)響應首部字段 


這里寫圖片描述 這里寫圖片描述   

 

(4)實體首部字段 

 


這里寫圖片描述

tcp/ip四次揮手過程

當瀏覽器加載一個完整的頁面時,還需要與服務器斷開連接,這個過程就是tcp的四次揮手 
首先客戶端會發送一個帶有FIN標識和一個seq隨機數,服務端收到之后,會回應一個ack,ack的值等於剛才的seq的值+1,發送之后,服務器會再發一個包,

這個包里面也帶有FIN標識和一個seq隨機數,客戶端收到之后,回應一個ack,ack的值等於剛才的seq值+1,以上完成之后,服務器和客戶端的4次揮手就完成了!

持久連接

  在HTTP協議的初始版本中,每進行一次HTTP通信就要斷開一次TCP連接。因此,每次的請求都會造成無謂的TCP連接建立與斷開,增加通信量的開銷。

為了解決這個問題,HTTP/1.1想出了持久連接(也稱為HTTP keep-alive),

其特點是:只要任意一端沒有明確提出斷開連接,則保持TCP連接狀態。 
  這里寫圖片描述

針對Web應用的攻擊模式

(1)主動攻擊:

攻擊者通過直接訪問Web應用,把攻擊代碼傳入的攻擊模式。最具典型的攻擊就是 SQL注入攻擊和OS命令注入攻擊。 
這里寫圖片描述   

(2)被動攻擊:

利用圈套策略執行攻擊代碼地攻擊模式,在被動攻擊過程中,攻擊者不直接對目標Web應用訪問發起攻擊。 
這里寫圖片描述

跨站腳本攻擊(XSS)

  跨站腳本攻擊(Cross-Site Scripting,XSS)是指通過存在安全漏洞的Web網站注冊用戶的瀏覽器內運行非法的HTML標簽或者JavaScript腳本進行攻擊的一種攻擊。 
  跨站腳本攻擊可以造成以下影響: 
  (1)利用虛假輸入表單騙取用戶個人信息。 
  (2)利用腳本竊取用戶的Cookie值,被害者在不知情的情況下,幫助攻擊者發送惡意請求。 
  (3)顯示偽造的文章或者圖片。 
  

SQL注入攻擊

  SQL注入(SQL Injection)是指針對Web應用使用的數據庫,通過運行非法的SQL而產生的攻擊。該安全隱患有可能引起極大地威脅,有時會直接導致個人信息及機密信息的泄露。 
  SQL注入攻擊有可能造成以下影響: 
 (1)非法查看或篡改數據庫內的數據。 
(2)規避認證。 
 (3)執行和數據庫服務器業務關聯的程序等。

OS命令注入攻擊

  OS命令注入攻擊是指通過Web應用,執行非法的操作系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險。

HTTP首部注入攻擊

  HTTP首部注入攻擊是指攻擊者通過在響應首部字段內插入換行,添加任意響應首部或主題的一種攻擊。屬於被動攻擊模式。

因會話管理疏忽引發的安全漏洞

  (1)會話劫持:攻擊者通過某種手段拿到了用戶的會話ID,並非法使用此會話ID偽裝成用戶,達到攻擊的目的。 
  (2)會話固定攻擊:強制用戶使用攻擊者指定的會話ID,屬於被動攻擊。 
  (3)跨站點請求偽造(Cross-Site Request Forgeries,CSRF):攻擊者通過設置好的陷阱,強制對已完成認證的用戶進行非預期的個人信息或設定信息等某些狀態更新,屬於被動攻擊。 
  CSRF有可能造成以下影響: 
1、利用已通過認證的用戶權限更新設定信息等; 
2、利用已通過認證的用戶權限購買商品; 
3、利用已通過認證的用戶權限在留言板上發表言論等;

DoS攻擊

  DoS攻擊(Denial of Service attack)是一種讓運行中的服務呈停止狀態的攻擊。有時也叫作服務停止或拒絕服務攻擊。主要有以下兩種DoS攻擊方式: 
  (1)集中利用訪問請求造成資源過載,資源用盡的同時,實際上也就呈停止狀態。 
  單純來講,就是發送大量的合法請求,服務器很難分辨何為正常請求,何為攻擊請求,因此很難防止DoS攻擊。多台計算機發起的DoS攻擊成為DDoS攻擊(Distributed Denial of Service attack),DDoS攻擊通常利用那些感染病毒的計算機作為攻擊者的攻擊跳板。 
  (2)通過攻擊安全漏洞使服務停止。

 

 

 

 

 


免責聲明!

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



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM