做爲前端er,辛辛苦苦搬完磚,好不容易上線以後,正準備告一聲萬事大吉,回家吃雞。突然qa/pm/老闆問,爲何我這裏仍是沒有更新?只能是弱弱的回一聲,清個緩存看看?或者還有那麼一天,發現大部分區域都是好的,只有某些區域是舊的,這就要討論一個叫CDN的東西了。html
說個最經典的結論,不管什麼東西,傳輸都須要時間。這個應該都不會有疑問。
咱們的網絡而言,有兩個用戶,一個在海角天邊,一個就用內網坐在你跟前,你說他們的體驗會不會有差異。這裏就不說結論了,應該比較清晰。 關鍵在於如何解決這個問題,最理想化的,海角天邊的跟前要是也有個相同服務器不就完了。 就是這麼樸素的道理,這樣就引出了CDN。前端
CDN的全稱是Content Delivery Network,即內容分發網絡。
可以實時地根據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上。
已達到一下三點:segmentfault
從技術上全面解決因爲網絡帶寬小、用戶訪問量大、網點分佈不均等緣由,解決用戶訪問網站的響應速度慢的根本緣由。瀏覽器
在看CDN如何解決以前,先回頭看下經典的問題,用戶輸入url回車以後會發生什麼。 對於未使用CDN以前,以下圖所示: 注:本圖來源見水印,比較經典的圖就不本身瞎畫了 大概有這麼幾個步驟:緩存
這樣來看,有這麼幾個地方須要考慮: 請求直接到達服務器上,存在傳輸距離的問題。 每次直接請求服務器,響應速度能夠優化。 流量直接打到服務器上,存在超負荷的可能。安全
引入cdn以後整個流程以下: 服務器
提供內容的原始站點,也就是咱們的服務器網絡
包括CDN網管中心和全局負載均衡DNS重定向解析系統,負責整個CDN網絡的分發及管理。
主要做爲內容分發和邊緣未命中時的服務點負載均衡
主要指異地分發節點,由負載均衡設備、高速緩存服務器兩部分組成。 簡單歸納就是離用戶最近的節點。主要做爲直接向用戶提供服務的節點。運維
CDN邊緣節點緩存策略因服務商不一樣而不一樣,但通常都會遵循http標準協議,經過http響應頭中的 Cache-control: max-age的字段來設置CDN邊緣節點數據緩存時間。
當用戶向CDN發出請求時,CDN階段會判斷資源是否過時,未過時直接使用緩存(這也就提高了響應速度)。若是認爲資源過時,那麼就會向實際服務器去請求新的資源,即發生回源。
CDN從源站獲取最新資源的過程即爲回源,該過程會同時更新本地緩存資源,並將新的資源返回給用戶。 固然對於回源咱們是要不推薦的,搭建CDN除了必要狀況下,固然但願都走節點緩存。若是回源率太高能夠參考這裏看看CDN 命中率、回源率常見問題
對於新資源上線,爲了確保全部節點都能訪問最新資源,須要主動失效CDN緩存。CDN運營商都會暴露主動刷新的接口,通常公司運維也會暴露出刷新CDN的接口的,已解決CDN緩存不主動更新問題。
什麼叫流量劫持,比較籠統的說只要是對請求及數據進行篡改、轉發的均可以認爲是流量劫持。
其實CDN也是一種流量劫持,其經過DNS解析將域名匹配到最近的服務器上。
不過這是一種主動已知的劫持,目的爲更好的用戶體驗。 惡意的劫持通常分爲兩類:
又稱域名劫持,是指在劫持的網絡範圍內攔截域名解析的請求,分析請求的域名,把審查範圍之外的請求放行,不然返回假的IP地址或者什麼都不作使請求失去響應,其效果就是對特定的網絡不能反應或訪問的是假網址。
常見實現也是經過污染路由器等中間鏈路,將解析請求進行篡改。
數據劫持是指針對明文傳輸的內容發生。
用戶發起HTTP請求,服務器返回頁面內容時,通過中間的運營商網絡,頁面內容被篡改或加塞內容,強行插入彈窗或者廣告。 如何預防?
行業內解決的辦法便是對內容進行HTTPS加密,實現密文傳輸,完全避免劫持問題。
理想狀況下,CDN 的安全性應該和咱們的服務器一致,但若是,CDN 和用戶之間、CDN服務器之間,走明文的htttp協議也是會出現數據劫持的現象。
book.51cto.com/art/201205/…
www.zhihu.com/question/36…
hpoenixf.com/DNS%E4%B8%8…
segmentfault.com/a/119000001… zhuanlan.zhihu.com/p/40682772 本着學習的態度,從上面各類大神的文章中受益不淺,再次感謝上述文章做者。彙總一下做爲本身的解惑筆記,但願也能對其餘人有所幫助。