網際網路的流量劫持大致分兩種，第一種是dns劫持，第二種是鏈路劫持。對於這兩種劫持的原因有很多，比如使用者電腦中毒了，dns被篡改了，比如家用路由器被攻破了等等。但這種個人極端原因畢竟是少數，真正的幕後大佬（此處應該有廣東話配音）其實是運x商（此處配有bb音），這其實已經是網際網路行業公開的秘密，各大網際網路公司早已經和各大運營商展開了一場曠日持久的撕胯大戰，po主公司由於是金融行業，剛涉足網際網路不久，還處於摸石頭過河階段，卻也是感受到了我國網際網路環境的水深。對此po主只有一句話，大家都是要被顛覆的行業，難兄難弟何必相愛相殺呢？ 好了，廢話不多說了，這是乙個嚴肅的技術文件！！！
首先我們要搞明白運營商為什麼要劫持使用者dns呢？ 使用者跟你什麼仇什麼怨？
劫持原因基本分兩類，第一類是為了跳轉廣告，第二類是本地快取，總結一下就是為了——錢！
跳轉廣告比較好理解，我明明訪問的是**，怎麼跳轉成了乙個不知名小網購**，還和**長的挺像。本來po是要以身試法，截個被劫持的圖下來展示下的，結果訪問各大**1個小時，也沒有一次被劫持，真心為電信點讚！ 跳轉廣告這種方式由於過於芳草天，使用者也不是傻子，運營商用起來也是比較謹慎，所以第二類本地快取才是罪惡之源。
由於各運營商頻寬資源、網間結算費用、idc機房資源分布等存在較大差異，因此為了保證網內使用者的訪問質量，同時減少跨網結算，運營商在網內搭建了內容快取伺服器，通過把網域名稱強行指向內容快取伺服器的ip位址，就實現了把本地本網流量完全留在了本地的目的。但是由於運營商對這些內容快取伺服器的使用的技術手段參差不齊，運維管理也不是很及時。通常會引起兩個問題，一是當這些運營商的內容快取伺服器出現故障後，使用者將無法訪問到需要的資源，二是當源站已經有內容更新了，而這些運營商的內容快取伺服器並未及時更新，導致使用者訪問到舊資源，或者無法訪問到資源。
鏈路劫持的原理就是運營商（也可能是黑客）在使用者訪問**的時候進行竊聽，獲取使用者訪問的目的ip後，然後以這個ip為source-ip冒充**給使用者響應，通常響應中會插入一段js**，這段**可能會讓使用者去get一些非真實**資源，最終可能造成真實頁面被插入廣告，被蒙層，甚至整頁面被替換，嚴重影響使用者體驗以及企業形象。由於鏈路劫持可能通常發生在last-mile，而last-mile被運營商牢牢控住，所以這對監測以及解決問題帶來了巨大的挑戰。
針對於dns劫持和鏈路劫持，業界有比較多的解決方案，各有利弊，適合不同的場景，總體上來說可以分兩大類，一是被動監測型，二是主動防禦型，下面就分別介紹一下。
1）真機模擬型
由第三方監測廠商提供全國範圍內的監測服務，通過真實的pc或手機模擬使用者的真實訪問來收集相關 的效能引數，然後由廠商對資料進行分析，最終為客戶呈現效能指標或者提供告警服務。
優點：1、落地容易、實現簡單；
缺點：1、手機真機的模擬，由於手機成本以及移動流量的原因，數量比較有限，取樣資料的覆蓋度較低。
2）插入sdk型
優點：1、資料來自真實使用者，具體更高的真實性和完整性。
缺點：1、saas解決方案安全問題
2、私有雲解決方案成本高，部署複雜
目前被動監測的方式多為購買第三方廠商的監測服務，在發現某一地區的劫持率超過閥值後會向企業告警，企業依據廠商提供的證據向運營商投訴，但是往往運營商的處理效率非常低，因此要從根本上解決問題，需要採取一些主動防禦的解決方案。
主動防禦型就是主動出擊從根本上杜絕劫持的可能，對於dns劫持的解決思路目前po主了解的主要有兩種，第一種是繞過運營商的local dns，使用公共的dns，另一種是直接通過ip來訪問，拋棄了網域名稱訪問的模式。而對於鏈路劫持，業內目前還沒有什麼太好的主動防禦模式，https應該算一種，但是https也會帶來諸多其他問題。下面分別介紹下幾種思路。
1）繞過運營商localdns，使用公共的dns
2）拋棄網域名稱訪問方式，直接進行通過ip訪問
httpdns的原理大致就是在移動客戶端中加入乙個網域名稱解析的模組，客戶端通過http的方式向企業的流量排程伺服器請求ip，此時流量排程伺服器會回根據使用者所在位置給使用者乙個最優的ip。客戶端在獲取ip後直接用此ip來訪問所需站點資源。
這種方式看著確實很完美，但是對於一般的企業來說想要實現是一件極具挑戰的事情。
1、客戶端需要進行一定的開發來滿足客戶端的httpdns的請求；
2、針對這個流量排程伺服器需要自己開發一套所有節點的ip位址庫以及測速系統，才可以保證將使用者引導的訪問最快的idc節點上，並且對於使用了cdn加速的網域名稱來說，這個ip位址庫是不可控的。
所以說httpdns是乙個好的解決方案，但是用起來並不容易，而其投入產出比也只有在一些巨型的網際網路公司身上才能體現出來。
再來說說網宿的maa的解決方案，po主覺得和httpdns比較類似，前提是這個網域名稱要使用網宿的cdn加速。網宿的maa方案其實就是幫一般企業來解決上面httpdns的三點難點。
1、客戶端插入網宿研發的sdk，向其鑑權伺服器請求ip；
2、網宿的鑑權伺服器類似於httpdns中的流量排程伺服器，因為cdn廠商本來就要負責排程cdn節點的資源，所以這點對他們來說很容易；
3、如何保證高可用性以及不同運營商的使用者訪問到鑑權的伺服器，使用者的訪問延遲？這點網宿的資料裡面沒有提到，po主個人猜測問題應該不大，因為對於乙個cdn加速的網域名稱來說，使用者本來就是要去網宿的鑑權的伺服器的，而對於乙個提供cdn服務的廠商來說，鑑權的伺服器的高可用肯定是要做好的。
（以上絕對非軟文，po主覺得是個很好的解決思路，表示要向網宿徵收廣告費啊！！！）
但是網宿的這個解決方案同樣存在問題：
1、插入sdk的方式很多大企業可能無法接受
2、只能用於網宿加速的網域名稱，其他廠商的cdn節點的ip資訊網宿不可控，這樣可能會被乙個廠商綁架。
注意https是解決鏈路劫持的方案，並無法解決dns劫持的問題。https的優點太多了，什麼保密性、完整性、可用性，我就不多說了，去網上一搜一大堆，我這裡就只談談如何防禦鏈路劫持。
1、https是加密協議，我們隨便抓個http包，發現http包裡面的所有東西都是明文的，這樣就會被監聽，而https協議是加密的。
（以下僅代表個人觀點）
1、主動防禦型的解決方案總體上看雖然可以從根本上解決劫持問題，但是成本高，研發周期長，適合超大的網際網路公司，但未必適合所有企業。
2、被動監測型中，真機監測顯然不是未來主流發展方向，並且覆蓋範圍小是硬傷，但是安全無***。
saas方式的插sdk具有一定的安全風險，在傳統行業尤其是金融行業中很難被接受。
私有雲方式的插sdk成本比較高，部署相對複雜。
那麼問題來了，又便宜又安全又好用的東西，你告訴我乙個我去批發來賣。
3、能否自研製sdk。這個問題要問開發，我個人理解應該是可以。但是抓取了海量的資料要自己去分析並不是一件容易的事情，需要花費很多的人力物力，畢竟這種第三方監測廠商百來號人就是靠這個吃飯。廠商賣的不是乙個簡單的sdk，賣的是服務。說到底還是乙個投入產出比的問題，是自己花精力去搞但未必成功，還是買乙個現成的商業解決方案。
4、被動監測型除了監測劫持問題外，還有很多其他功能。比如cdn的服務質量評估，比如使用者訪問的網路效能分析，甚至可以追蹤到移動應用的崩潰原因以及**級別的執行時間開銷。這對於提高使用者體驗，減輕運維壓力都是及其重要的。
觸目驚心的網際網路流量劫持
這篇文章發出去的時候，我還是有點戰戰兢兢的，我怕萬一是自己 搞錯了，被騰訊的人懟回來，有點禁不住。以前在微博 某雲服務客戶批評某巨頭雲的文章時被人家技術專家懟過，這事我一直還都記著呢。結果沒想到，騰訊多個部門的技術人來跟我核實，尋求反饋，還說要送禮物給我。而且他們還主動跟我提及了一些更多的資訊，比如...
作為網際網路流量入口，CDN日誌大資料你該怎麼玩？
通過對cdn訪問日誌的分析，可以挖掘出大量有用的資訊作為監控 報警 渠道分析 運營分析的資料 而對於技術或者運維人員來說，cdn的線上問題其實是不好排查的，因為節點遍布全球各地，我們沒辦獲知各個節點的狀態。當前cdn廠商通常會提供離線日誌的功能，會在幾十分鐘甚至幾個小時之後提供訪問日誌給客戶，存在兩...
作為網際網路流量入口，CDN日誌大資料你該怎麼玩？
通過對cdn訪問日誌的分析，可以挖掘出大量有用的資訊作為監控 報警 渠道分析 運營分析的資料 而對於技術或者運維人員來說，cdn的線上問題其實是不好排查的，因為節點遍布全球各地，我們沒辦獲知各個節點的狀態。當前cdn廠商通常會提供離線日誌的功能，會在幾十分鐘甚至幾個小時之後提供訪問日誌給客戶，存在兩...