整理自【微學堂】第二十五期課程實錄
嘉賓介紹
白金， ChinaUnix 資深版主， 曾擔任《iptables 高級使用研討》講師， 精通iptables模組的開發和netfilter內核開發， 擅長協定識別技術及網路攻擊防禦技術。
直播實錄
上期回顧：乾貨！史上最全的CDN內容分發網路實戰技巧
咱們接著上期繼續。
CDN有很多的性能指標， 也有很多協力廠商的探測工具或者是系統。 那麼， 客戶在接入CDN後可能會擔心他們的服務品質怎麼樣， 往往就會借助協力廠商的探測工具來分析CDN的性能。
比如， 如果DNS時間慢， 就意味著可能是你的用戶端擁塞了， 或是你的用戶端設的Local DNS到你那兒的距離太遠， 或者用戶所使用的Local DNS存在問題。
如果是建連時間慢， 至少代表用戶端有可能是擁塞， 或是用戶端到你的CDN節點的距離太遠， 又或是CDN本身的調度機制有問題， 或是CDN的節點頻寬滿。
首包時間除了包含建連時間的所有的範疇外， 還加上一個伺服器的負載時間或是伺服器的回源時間。 那首包是什麼意思呢？首包是說， 從發完GET請求之後開始計時， 到接到第一個資料包為止算結束， 這期間的時間。 那這個時間除了RTT的以外， 還包含了伺服器磁片佔用過高， 導致準備資料時間過長， 又或是MISS了然後需要回源去拿。
由此， 我們可以理解為， 慢是由多種原因造成的， 無論哪一個環節慢都會造成最後的慢。
直播意味著什麼？意味著他不可緩存， 是動態的， 是從源站拿來的資料。 曲線圖和資料表就是跟競爭對手相比時的建連時間對比圖。 從時間可看出來我們的RTT是不佔據優勢的。
上圖是首包時間的圖， 可看出， 我們的首包時間競爭對手的7.8倍。 由此產生個疑問， 這是個動態的業務測試， 如果是動態必然有回源， 如果是回源必然有經過CDN的上下層，
為什麼競爭對手的首包時間和建連時間差不多呢？極有可能是由於他錯誤的設置了策略， 導致不公平的測試， 他把這個資料緩存住了。
為了驗證之前的猜測， 做了一個抓包的測試。首先，測試廠商A通過ping的方法，得知延時大概是52毫秒，然後再發起TCP建連時可看到，建連的時間大概是57毫秒，再發起GET請求後立刻收到了GET請求的回應包。這是協議棧回的，不是伺服器自己回的。因此跟回源沒關係的，是62毫秒。最後，真正的首包時間是441毫秒。這個符合真正的動態回源的時間。
再來看一下競爭對手。通過ping來測試，往返時間大概是42毫秒，TCP第三次握手建連的響應時間也是42毫秒。在發完GET請求之後，收到GET請求的確認包也是42毫秒，符合建連時間。但後面真正的首包時間只用1毫秒,顯然這是有問題的。因為客戶的源站距離Edge Server大概是18毫秒。無論如何首包時間也絕對不可能小於18毫秒。
從這個分析可看出他絕對是做錯了策略，把不應該緩存的ts片緩存到了伺服器上，因此這是個不公平的測試。所以我們就這個情況，拿到這個資料之後寫了詳細的報告跟客戶去回饋了，得到了客戶的認可。
以上的是上期沒有講完的幾頁。
通過這節，是想告訴各位：第一，CDN是個什麼東西；第二，我們在CDN 裡面經常遇到的一些問題以及分析方法；第三，想強調的一點就是所有的東西其實都是圍繞網路來進行的。
CDN - 隕坑篇
接下來講第三篇，是隕坑篇。我整理和總結了很多在CDN和網路上面遇到一些坑。這些坑有可能跟CDN有關，也可能跟CDN無關，但至少都是我們平時會遇到的。在這篇裡，共分成四個部分，DNS的坑、IP庫的坑、網路探測的坑以及關於劫持的一些東西。
第一篇講了什麼是CDN？CDN是Content Delivery Network。第二篇中引入一些我個人的觀點，就是把CDN定義成Can Do sth. on Network。
那第三篇，我把它昇華了一下，C（操）D（蛋）Network，操蛋的網路。
首先，來講一下LDNS（Local DNS）的坑。
先說一下LDNS，也就是我們所使用本地DNS伺服器。一般情況下，標準DNS的作法是緩存直接給你資料，如果沒有緩存，他會逐級去替你遞迴，最終拿到一個資料交給你。但有一些小的ISP，它的LDNS不具備遞迴的能力，只具備緩存的能力。如果你訪問的這個功能變數名稱一旦沒有命中，比如是個冷功能變數名稱，那它有可能把這個請求發送給一個真正具備遞迴能力的伺服器，而那個伺服器他的出口位址和你所在的運營商不在一個區域，就可能會導致CDN調度誤判.
舉例來說，如果你是北京電信用戶，設置的是北京電信的LDNS的伺服器。恰好假設這個北京電信的LDNS伺服器不具備遞迴能力。他把這個請求投遞給山東聯通的DNS伺服器讓它去做遞迴。根據之前講的CDN調度原理，山東聯通的伺服器發起這個請求，最終到我們的這個CDN的GLB的時，出口地址是山東聯通，那麼就會誤認用戶端也是在山東聯通，從而就會分配給山東聯通的這個DNS伺服器。山東聯通的這個LDNS伺服器拿到記錄後會回傳給北京電信的DNS伺服器，回傳給用戶端，用戶端進而就會去訪問山東聯通的CDN位址。
之前講的是LDNS的坑，本篇講PDNS（Public DNS）的坑。很多公共的DNS有很多人都在用，比如，8.8.8.8，114.114.114.114，比如阿裡的223.5.5.5，比如DNSPod的119.29.29.29，大家可能會認為，這些DNS比較靠譜。第一，是大廠商；第二，做過Anycast，地址的可用性非常好；第三，你看你們都不會設，我會設我多牛逼啊！對吧？
但你是否想到這種自認為很牛逼的做法，有可能出現嚴重問題呢？
舉個例子，看阿裡的這個DNS的伺服器地址，從北京聯通的出口，去traceroute時，發現他的入口是在山東青島BGP。言外之意是說，如果我請求的功能變數名稱是能緩存在DNS上的，意思是不用遞迴，那跟當地的LDNS相比，這個RTT一下就很大了，至少是16毫秒出去，那這個時間浪費掉了，得不償失。
大家需明確另一個概念，就是 DNS 的入口和出口位址有可能是不一樣的。比如，你的入口位址是 A 區域，但訪問 GLB 的時很可能用的是 B 區域的位址，這樣也會造成調度偏差。
以阿裡的 223.5.5.5 為例，入口之前是山東青島。出口通過工具分析，出口卻是廣東珠海電信。這就意味著，你是北京聯通的用戶，訪問到看上去可以裝逼的公共 DNS，卻可能被 CDN 認為你在廣東電信，分配給你一個廣東電信的 Edge Server，到時候你就呵呵了。
這是個活生生的測試。從測試可看出，北京聯通使用阿裡 DNS，或得到的 CDN 資源在江蘇，而且是電信，跨了省，跨了 ISP，且 ping 值達到了 43ms
再做一個測試，老老實實使用 ISP 分配的北京聯通的 DNS。
OK，這次拿到的 IP 在北京了，同 ISP，而且 ping 值不到 10ms。所以，如果你不懂，不要裝懂，老老實實可能會更好。好奇害死貓，裝逼害死人。
另外，說一下 IP 庫的坑。很多人都認為 IP 庫無所謂，其實是錯誤的。（這也沒什麼好講的，看就可以）
（這頁也是，就不講了）
這是一個推翻之前觀點的反例。用 whois 看到的是在浙江電信。
通過多個 IP 庫投票的方式，大多數也都說是浙江電信。
但實際應該怎麼樣呢？不可能是浙江電信，因為最後進入了廣東。
無論你是做CDN，還是做電商，只要跟網路有關，其實最關注的還是網路品質，那麼，你必然會有一些探測的系統。相信每個廠商自己都會有，但往往一般比較關心的是什麼？是性能和穩定性。性能指的是輸送量和往返時延，穩定性指的是丟包率。如果你的公司更牛一些，還會關注抖動、亂序，還有畸形包等等。
但你是否考慮過另外兩個特性？一個是支持特性，就是功能支持程度；另外一個是資料的真實性。所謂支持特性，就是有沒有一些特殊的機制，會把你阻斷掉不讓資料通信。而真實性更重要了，你能保證你看到的東西一定是真實的嗎？
Ping值是看往返時延的一個最通用的工具。但除了ping值以外，TCP的三次握手也是可以知道網路的往返時延的。而真正在互聯網裡邊請求HTTP協議的時，一個往返時延的計算就是在TCP這個層面來出現的。所以，在有的網路裡，不妨去嘗試用一些tcpping的工具，對比看你的網路是不是有些手腳。
上圖是個真實案例，可以看到用tcpping和用普通的ping出來的結果竟然能差出10倍，那言外之意是你的這個ping，ICMP協議，有可能是被ISP動過手腳的，也有可能給你做個QoS，你看到的只是他們想讓你看到的。
另外，在移動互聯網的情況下，你的包大小對往返時延可能會有嚴重影響。比如，尤其是在窄帶情況下，包越大，在傳輸的時由於是窄帶，擁塞程度就會很大。所以，用小包ping和用大包ping看到結果可能不同。那由於我們現在越來越多的都是互聯網的應用，所以你在真正去做網路探測網速測試的時不妨去考慮，用大包來試。比如，把大包設成像HTTP滿載那麼大，因為你在網路裡面傳輸的時，你的TCP的資料基本都是滿載MTU的，MSS大概是1460。如果是移動互聯網接入，可能會更小，那你不妨就把它設成這麼大，看看真實情況會怎麼樣？
另外，探測時間間隔的不同會導致結果不同。上圖可看到，如果每10毫秒發一個ping包和每1毫秒發一個ping包，看到的丟包率是不一樣的。那有可能有人會說了，你這麼ping的話會被運營商截掉的。憑什麼呢？這樣解釋對嗎？路由器有兩個功能，第一個是有自己的本地協議棧，另外是負責資料轉發。如果你去ping路由器自己的話，那麼由於它自己要耗費CPU去回應你的這個應答，所以你要這麼ping他肯定會有問題，有可能會出現丟包，或者被人為限速的情況。但如果你要是穿透他的話，那應該是無條件替你轉發的。因此有的人如果告訴你說你ping會被攔截，那這是錯誤的，沒有道理的。
之所以是錯誤的，是因為你要ping的目標並不是路由器，他只需替你做轉發。那種硬體路由器背板速率是非常高的，而且不去區分你的四層、三層甚至七層應用。他只瞭解這是一個乙太網幀，只需要看到他是IPv4，然後把資料包轉發出去就可以了。那如果一旦發現這種，低速ping和高速ping是不一樣的，你需要去考慮是不是你的運營商給你做了一些策略，或者是鏈路裡邊真的是有問題，只是你的頻度太低你看不出來。
另外，有人會認為，擁有很多的機房，機房有很多機器，想要探測這些機房的資料。每個機房有個代表的伺服器，直接去測，便能代表整個機房的網路品質。理論上沒錯，但需注意，由於路由的不同，導致同一機房的同一網段相鄰IP可能走的路由路徑是不一樣的。最後導致的網路品質也是不同的，這一定要注意。
對於TCP來說，如果發出去的包被丟掉，但由於後邊會有陸陸續續的包發過去。假如，在接收端他只看到了其中一個包丟掉，那後續的包收到後會馬上回給伺服器，之前的包只確認到了哪兒，伺服器也可間接知道，快速回應你之前某一個包丟掉了，然後快速給你補傳其中的某一個包。但是如果你丟的包是最後一個怎麼辦呢？伺服器之後沒有資料可發了。那麼，作為接收端無法回應，而伺服器只能傻等，等RTO這個時間就會很長。如果你的網路有輕量的丟包，且趕上尾包，那有可能會導致你探測的結果會和之前大相徑庭。
上圖是，我在幫一個朋友去排查他的路由器。他那個社區通道是Chinnel 1，802.11g。由於這個通道擠的已經一塌糊塗了。所以，儘管他的信號強度很大，但由於串擾很多，到閘道延時也依然很大。最有意思的是，我通過他的路由器去traceroute時，發現無論哪個網站，兩跳必到，第一跳到路由器，第二跳到了。這說明什麼？說明你所看到的東西是別人想讓你看到的。
之前，我也進行過投訴，但是他們解釋是網內10Mbps，出網2.5Mbps，就是這樣的，那這個沒有辦法。
現在講，網路探測指標中大家可能不會關心的第三點，新技術可以隨便用嗎？比如，TFO其實是個很好的技術。它的原理是在TCP發三次握手的時已攜帶類似GET請求。而當伺服器接收到3次握手時已開始處理GET請求了，這樣可省掉一個RTT。穀歌針對這個技術做了個測試，尤其是小檔案傳輸時會有比較大的性能提升。但這個技術需在TCP三次握手的時，同時兩邊在TCP選項裡邊支援這個選項，有點類似WScale和SACK一樣。
大家可看到截圖，
Google流覽器是支持TFO的。linux在某個版本之上，在你開發時通過setsockopt，設這個通訊端也是能支援的，所以當時我們想用這個技術做一個測試。
結果測試完後就傻眼了。因為我們通過測試資料收集，然後大資料匯總和視覺化，我們發現，真正這種握手的出網的資料包還OK，但這種TFO在入網時大概有26.09%的節點沒有辦法收到，無法接受這個資料也就是說被牆掉了。
新技術不一定可用，後面講其他，比如隧道協議。在資料傳輸時可能會被劫持，無論劫持原因是什麼，我們是希望改變這種現狀，往往會做一些隧道來規避這種問題。經資料測試發現，GRE這種協議如果隧道，有3.91%出網被攔截，入網10.43%被攔截，證明這種協議也不能通用，且很多ISP是根據你的流量的限制的。就是說你沒跑GRE協議，且跑的不大時他可能不會去限制，但如果要是出現很大流量持續一段時間後，可能會臨時做策略，這是很不靠譜的。
相對於GRE協定來說，其實他不太知名。比如PPTP的VPN，是借助GRE來真正傳輸資料的。所謂的TCP 1723埠只是用來做驗證而已，同理，除了GRE的點對點的隧道外還有一種叫IPIP協議也可做點對點隧道。但由於它的知名度不如GRE高，所以他的攔截率相對來說也比較低。
還有就是有中國特色的社會主義網路，聯通和電信。或可說跨ISP，因為它不僅限於聯通和電信，移動、鐵通、長寬、廣電都有類似這個問題。如果你要跨ISP就可能會出現這個網間結算過大或是被限制這種情況。
很早之前，有相關的文章或新聞說過，聯通和電信壟斷的相關的事情。但是他們只是說說，我也是看他們說說，把這些發出來讓大家看看。在最後一個URL大家如果感興趣可以點進去看。
還有一個更狠的坑就是IDC裡邊的NAT。你們可能經常見到小路由做NAT，公司的閘道出口作NAT。但你有見過IDC做NAT嗎？他分配給你一個ip位址，你從外網訪問這個ip位址是可以訪問到伺服器上的。但如果你從伺服器發出去資料時，別人看到ip位址卻不是這個IP而是別的，且這個IP有可能會動態的變化。
有人會講這個其實無所謂，反正別人都是去訪問你，而你回源時，去拿資料也只是拿而已，為什麼要關心你的IP呢？其實不是這樣的。如果你的很多業務，比如，傳日誌，假設你用的是FTP協議就會遇到很嚴重的問題。FTP用兩個埠傳輸，一個是命令的通道一個是資料通道，在最開始建連時用的是21埠。有很多人認為FTP只工作在21，其實是不對的。也有很多人認為FTP工作在21和20的，其實也是不對的。他其實工作在20和一個隨機埠上。
FTP有兩種工作模式，第一種叫主動工作模式——21埠收到資料後會主動Server本地的20做為源埠反連。第二種情況是被動模式——在21埠就連著後會協商出一個埠，然後用戶端回去連他的這個埠。那麼，在主動工作模式時就可能會遇到問題。如果你看到Server IP是A，嘗試去等待一個來自20埠的A位址去連的話，你永遠也等不到。被動模式其實也是一樣的。如果資料傳輸時下一個Data Channel，IP位址變了的話也會導致傳輸故障。
所以，有很多的廠商可能會鬱悶，為什麼這個日誌傳不回去，為什麼傳一半就斷了或者是為什麼傳不動？那麼我建議你不要再用FTP了。
我們對國內的節點做了一個視覺化分析，發現有2.61的概率出口存在NAT的這種情況的。
另外講一下關於劫持。在網上，我們能看到很多奇怪的現象，比如，圖裂，突然告訴你說沒有備案，但其實你是通過IP位址去訪問的。再比如，你在訪問某一個網頁時右下角會突然插入一個跟網頁一點兒關係都沒有的廣告。實際上，這是種干擾，也是劫持。因為他的目的並不是說一定要去拿到你的資料，他有可能是破壞你。
目前為止，沒有一個廠商或沒有一個組織站出來承認有這麼一種東西存在。當然，也有一些業內人士，可能是清楚這個事情的。我其實對這個東西大概研究了有五年。根據很多資訊以及一些我自己的一些分析，大概畫出一個猜測的網路拓撲圖。
首先，你必須有網路出口的設備接入許可權，其次通過鏡像或分光的方式通過旁路拿到穿過這個關鍵設備的正反向流量。第三，你有一個網線是可以連上Internet，然後去發你想定制的一些資料包的，符合這幾個條件就可以做到劫持。實際上，是通過資料的收集分析，分析時通過IP埠、DPI的七層或者DFI的一種行為分析。拿到一些資料，且這個資料是她感興趣的，就需要去對你動手腳，通過那根紅線去向兩邊發包。偽造成對端的資料，讓兩邊都認為是對端給我發的這個真實的資料，從而實現一些劫持的效果。
舉例來說，中間是防火牆，實際上就是劫持設備。不管是AFW還是BFW還是CFW，只要是某FW，就存在這種劫持的行為。當用戶端和服務端進行三次握手建連之後，用戶端會發起一個GET請求。由於某FW在中間會優先於Server看到GET請求，所以他就可以優先於 Server先搶答一個以Server作為源位址，以同樣的埠80作為源埠，並且發一個假的302資料。迫使他認為拿到了一個真正從server發過來的302跳轉，從而關閉原有連結打開新的連結到達fw，給他指定的伺服器實現劫持。
這是一個真正的劫持的資料包的例子。通過這個分析我們可以發現，第一個包和第二個包之間差是49毫秒，也就是建連時間是49毫秒，ping值是49毫秒。發完GET請求之後，在短短的6毫秒之內，也就是4號和5號包之間6毫秒之內你就收到了一個HTTP回應，顯然是有問題的。因為你的RTT已經是小50毫秒，就算是40毫秒。你發個請求之後，加上伺服器的回應時間無論如何也不可能低於五50毫秒，而他恰恰卻只有6毫米就能響應。也就是說，第一，這個資料絕對不是真正伺服器回的，第二，這個給你回的假資料的設備離你很近。
再看下這個資料包下的真實明文資訊。他是一個HTTP的302響應頭，而且他location的新座標是十網段的地址。大家注意，我這個請求是訪問國外的一個作業系統的軟體更新包。它應該訪問的是真正的公網位址，但卻給我轉向到一個內網的位址，這就是劫持。
去年開始我發現還有一種200劫持。先篡改你的資料，以真正的回應資料方式返回給你。因為有很多的這種設備去分析你的回應頭是不是302，如果是302認為這個是有問題的，因為業務是沒有302的。OK，我乾脆給你回個200。你看這個資料包，1、2包的這個RTT是24毫秒。但是發了GET請求之後，5毫秒就收到一個響應頭也是200。但真正的這個首包是在25毫秒之後發回來的。也就是第10號包，這才是真正的資料的首包。
看上圖，首先遇到的問題是被302跳轉，調整到一個特殊的位址。但是，當去連這個特殊的地址時被403了，也就是說，不做劫持我們還能訪問，做完劫持後我們訪問不了，造成大量客戶投訴。更悲催的是右面的工單系統，從最開始的16年的1月26號開始發起，一直到3月17號始終無進展，運營商那邊也不care。
劫持分成兩種類型，一種叫干擾型，一種就是投毒型。所謂的干擾型他就是利用這個報文強打的方式持續的對你的這個資料產生影響，時不時的對你有干擾的這種行為。另外一種叫投毒型，就是說我可能只有一次去觸發讓你中毒，然後不會再有這種行為了，那麼這種情況一旦發生的話就會很危險。比如，你是做CDN的，邊緣節點如果被投毒的話，有可能你會錯誤的緩存了一個被人為設置成一年才過期的錯誤的圖片，比如是一個黃色圖片，那就會導致這個區域的人訪問看到的都是這個圖片。而且客戶投訴你非常有理，因為人家理由是綁定源站就沒事，是你的問題。
更悲催的是，由於這個投毒行為是一次性的，投完毒以後就不管了，而且它可以持續的生效。第一，你很難抓到之前的現場，且後續有可能很長時間抓不到這個情況。第二，由於很難抓到這個現象，所以，也很難去規避這個問題。你不知道他是怎麼產生的，你只看到他確實東西變了，甚至有可能會誤導你去懷疑這個設備有可能被黑。
從劫持的目的來看，大概分成三種。第一種是法律法規的規避，比如，禁止讓你訪問某FW。第二種是運營商的一種減少成本的一種優化手段，比如，控制網間結算，利用302來提升用戶體驗感，這是一個雙贏的事情。還有一種就是黑產，比如，利益的驅使，讓這個機房的人做劫持，好處多等。其中會有人可能動心，就和他合作，分成是非常厲害，每個月他們XXX的收入這是很正常的。
從劫持的效果來說，有三種。第一種雙贏，當然這個是最好了。第二種的是好心辦壞事兒，類似之前遇到的投訴case，本來是想節省成本，提升用戶體驗感，結果由於你的出現，成本是節省了，但是用戶體驗感大大下降，雖然對運營商的網路非常瞭解，但是她對CDN、對內容這塊還是技術欠缺。第三個就是所謂的黑產，他的目的很簡單，損人利己。
由於前面講了，這種劫持設備的特殊性，我們很難去知道他的存在，也很難去證明它的存在。那就更難去跟運營商打招呼，那如果你想讓人家去承認就得拿出證據來，那麼接下來，我就給大家講下如何去取證？
在IPv4頭裡邊有一個很有意思的一個欄位叫TTL，他的這個全稱是Time To Live，指的是網路資料包在網路裡面所能傳播的距離的遠近，也就是跳數。跟DNS裡邊那個TTL是不一樣的，那個指的是時間。它的特點是什麼？每個作業系統預設有一個自己的發出去的資料包的TTL初始值，叫做TTL base。每跨一條路由TTL就會建議，真到什麼時候為止呢？減到零時，這時路由器就不再替你傳輸了。那不同的作業系統，它的預設值是不一樣的，比如說Windows是128，Linux是64。
如何證明他是劫持呢？通過抓包去看，如果這個資料包裡的TTL，大家都是一樣的或者說即使有不一樣的他有可能就差那麼一到兩個。但是，關鍵資料包，什麼叫關鍵資料包？比如是302的包，或者是異常的200的資料包。他的TTL如果和其他的TTL有明顯出入，那麼他肯定是劫持。
這就是剛才的例子。建連時間49毫秒，get請求的回應包只有6毫秒。這個圖當時沒有截出那個TTL值來。如果要是把那個TTL值截出來，其實一目了然就可以看到TTL是跟其他的不一樣的。
另外，還有一點這個圖裡提到的RTT。那你可以跟運營商去說我的這個伺服器的距離有多遠，ping值有多大，建連時間至少有多長。發完請求之後，看到的異常資料包距離我的時間有多少？無論你做不做TTL的演示，你的RTT一定是要比標準的RTT短，因為劫持的原理就是利用搶答來做。如果他能劫持必然要比你的時間短，否則搶答不了。所以，一旦是劫持你看到的資料包的時間差一定是比標準的要小很多。
最後雖然能夠證明是劫持，但你去跟誰投訴呢？中途有很多運營商，你去跟哪個機房的運營商去投訴呢？所以，這裡涉及到一個定位的問題也就是溯源。同時，這裡還是會用到TTL這個概念。如果大家明白traceroute的原理的話，就會知道了，TTL是可控制你資料包發送的遠近範圍的。如果你的資料包的TTL初始值是3，那你只能發出3條。到第三個路由器時就不再替你轉發了，如果你的初始值是5，那是讓你能傳播5的距離這麼遠。
說完了以後大家多少能想到一個辦法了，是什麼呢？比如，如果通過某個wget時，發一個特殊的GET請求，絕對可以百分之百觸發這個劫持，那不妨發起一次的這個wget請求，然後只把GET包的TTL設置成可以控制的範圍。比如，半徑一、半徑二、半徑三，看到哪一個半徑開始出現劫持。並且在收斂回小一個半徑時，就沒有劫持了。而半徑的距離不足以達到真正要訪問的服務端時，劫持的設備就在剛剛出現這個異常現象的這個半徑範圍之內。
最後，你知道提前的跳數之後，再通過traceroute或mtr去真正跟蹤一下，數一下剛才看的那個跳數，是在這個路徑的第幾個節點，最終就找那個節點的相關負責人了。
中國的網路真的是非常非常的複雜，因為牽扯到特別多東西，有政治因素、利益因素、經濟效益因素。這裡邊的坑也是特別多。那這裡邊比如，我們看到的好多問題，是隨時間變化而變化的隨流量變化而變化，隨政策，隨利益甚至隨心情都會隨時變化。所以說你如果想做好，真的是太不容易了！
最後這部分的是裡面需要用到的一些知識點或者是一些工具，或者是一些引用的一些文章。大家感興趣的話可以看一下。那麼整個的這個分享到這兒就結束了，謝謝大家。
提問環節
1.白老師，我聽到一半下班了，剛回來，請問有沒有各cdn伺服器之間資料同步的問題？這個佈局，也有種分散式的感腳，所以需不需要也要考慮各個節點資料出現差異的情況？
答：如果是指數據分發的話，有兩種模式，一種是樹形結構的分發。比如由邊緣、父層、超父層來實現，逐漸收斂，逐級緩存；第二種是利用 P2P 的機制在同機房甚至跨機房裡實現緩存。
2.就是說資料一致性，比如在原始伺服器改了一下某個頁面，訪問cdn的話，還是老頁面嗎？
答： 這是刷新，當客戶有要求在某個 URL 沒過期之前，強行刷掉，就會用到這個機制
3. cdn各個節點之間怎麼做的資料同步？緩存時間會是多久？
答：緩存時間有兩種設定：一種是遵循源站，也就是源站讓你緩存多久，你就緩存多久；另一種是自訂，比如你修改了緩存時間，具體要看客戶需求。
4.比如全球有多個節點，我上傳一個檔，多久之後可以完全同步到這幾個節點？
答：這是由支撐系統來完成的。一般都是全網下發指令，拿到指令的機器自動去做 preload，或者 refresh。
5.還有個防盜鏈的問題~不太懂，CDN 如何實現防盜鏈的？
答：CDN 的防盜鏈是要和客戶對接演算法的，有兩種模式，一種是 CDN 有自己的演算法，客戶支援 CDN，另一種是客戶有自己的演算法，CDN 適配客戶。
一般的防盜鏈都是和 key 和時間因數有關的，對，然後不同的客戶協商一個特殊的 key，遵循同樣的演算法即可。
6.關於tcp優化的問題，bbr算是一種了，白老師覺得這個演算法怎麼樣？
7.GLB一般都怎麼搭啊？
答：最簡單的方案，用 bind 就可以。
8.有沒有成熟的商業系統？
答：DNSPod 就可以做調度，我們也可以。我們的 DNS 和 DNSPod 都是高性能的，我們是基於 kernel 寫的，DNSPod 是用 DPDK 寫的，處理性能都可以達到 400w ~ 700w QPS。
9.有沒有確定劫持節點的工具？
答：如果感興趣的話可以等幾個月以後在論文庫裡查到我寫的《抗旁路干擾系統的分析與設計》
做了一個抓包的測試。首先，測試廠商A通過ping的方法，得知延時大概是52毫秒，然後再發起TCP建連時可看到，建連的時間大概是57毫秒，再發起GET請求後立刻收到了GET請求的回應包。這是協議棧回的，不是伺服器自己回的。因此跟回源沒關係的，是62毫秒。最後，真正的首包時間是441毫秒。這個符合真正的動態回源的時間。
再來看一下競爭對手。通過ping來測試，往返時間大概是42毫秒，TCP第三次握手建連的響應時間也是42毫秒。在發完GET請求之後，收到GET請求的確認包也是42毫秒，符合建連時間。但後面真正的首包時間只用1毫秒,顯然這是有問題的。因為客戶的源站距離Edge Server大概是18毫秒。無論如何首包時間也絕對不可能小於18毫秒。
從這個分析可看出他絕對是做錯了策略，把不應該緩存的ts片緩存到了伺服器上，因此這是個不公平的測試。所以我們就這個情況，拿到這個資料之後寫了詳細的報告跟客戶去回饋了，得到了客戶的認可。
以上的是上期沒有講完的幾頁。
通過這節，是想告訴各位：第一，CDN是個什麼東西；第二，我們在CDN 裡面經常遇到的一些問題以及分析方法；第三，想強調的一點就是所有的東西其實都是圍繞網路來進行的。
CDN - 隕坑篇
接下來講第三篇，是隕坑篇。我整理和總結了很多在CDN和網路上面遇到一些坑。這些坑有可能跟CDN有關，也可能跟CDN無關，但至少都是我們平時會遇到的。在這篇裡，共分成四個部分，DNS的坑、IP庫的坑、網路探測的坑以及關於劫持的一些東西。
第一篇講了什麼是CDN？CDN是Content Delivery Network。第二篇中引入一些我個人的觀點，就是把CDN定義成Can Do sth. on Network。
那第三篇，我把它昇華了一下，C（操）D（蛋）Network，操蛋的網路。
首先，來講一下LDNS（Local DNS）的坑。
先說一下LDNS，也就是我們所使用本地DNS伺服器。一般情況下，標準DNS的作法是緩存直接給你資料，如果沒有緩存，他會逐級去替你遞迴，最終拿到一個資料交給你。但有一些小的ISP，它的LDNS不具備遞迴的能力，只具備緩存的能力。如果你訪問的這個功能變數名稱一旦沒有命中，比如是個冷功能變數名稱，那它有可能把這個請求發送給一個真正具備遞迴能力的伺服器，而那個伺服器他的出口位址和你所在的運營商不在一個區域，就可能會導致CDN調度誤判.
舉例來說，如果你是北京電信用戶，設置的是北京電信的LDNS的伺服器。恰好假設這個北京電信的LDNS伺服器不具備遞迴能力。他把這個請求投遞給山東聯通的DNS伺服器讓它去做遞迴。根據之前講的CDN調度原理，山東聯通的伺服器發起這個請求，最終到我們的這個CDN的GLB的時，出口地址是山東聯通，那麼就會誤認用戶端也是在山東聯通，從而就會分配給山東聯通的這個DNS伺服器。山東聯通的這個LDNS伺服器拿到記錄後會回傳給北京電信的DNS伺服器，回傳給用戶端，用戶端進而就會去訪問山東聯通的CDN位址。
之前講的是LDNS的坑，本篇講PDNS（Public DNS）的坑。很多公共的DNS有很多人都在用，比如，8.8.8.8，114.114.114.114，比如阿裡的223.5.5.5，比如DNSPod的119.29.29.29，大家可能會認為，這些DNS比較靠譜。第一，是大廠商；第二，做過Anycast，地址的可用性非常好；第三，你看你們都不會設，我會設我多牛逼啊！對吧？
但你是否想到這種自認為很牛逼的做法，有可能出現嚴重問題呢？
舉個例子，看阿裡的這個DNS的伺服器地址，從北京聯通的出口，去traceroute時，發現他的入口是在山東青島BGP。言外之意是說，如果我請求的功能變數名稱是能緩存在DNS上的，意思是不用遞迴，那跟當地的LDNS相比，這個RTT一下就很大了，至少是16毫秒出去，那這個時間浪費掉了，得不償失。
大家需明確另一個概念，就是 DNS 的入口和出口位址有可能是不一樣的。比如，你的入口位址是 A 區域，但訪問 GLB 的時很可能用的是 B 區域的位址，這樣也會造成調度偏差。
以阿裡的 223.5.5.5 為例，入口之前是山東青島。出口通過工具分析，出口卻是廣東珠海電信。這就意味著，你是北京聯通的用戶，訪問到看上去可以裝逼的公共 DNS，卻可能被 CDN 認為你在廣東電信，分配給你一個廣東電信的 Edge Server，到時候你就呵呵了。
這是個活生生的測試。從測試可看出，北京聯通使用阿裡 DNS，或得到的 CDN 資源在江蘇，而且是電信，跨了省，跨了 ISP，且 ping 值達到了 43ms
再做一個測試，老老實實使用 ISP 分配的北京聯通的 DNS。
OK，這次拿到的 IP 在北京了，同 ISP，而且 ping 值不到 10ms。所以，如果你不懂，不要裝懂，老老實實可能會更好。好奇害死貓，裝逼害死人。
另外，說一下 IP 庫的坑。很多人都認為 IP 庫無所謂，其實是錯誤的。（這也沒什麼好講的，看就可以）
（這頁也是，就不講了）
這是一個推翻之前觀點的反例。用 whois 看到的是在浙江電信。
通過多個 IP 庫投票的方式，大多數也都說是浙江電信。
但實際應該怎麼樣呢？不可能是浙江電信，因為最後進入了廣東。
無論你是做CDN，還是做電商，只要跟網路有關，其實最關注的還是網路品質，那麼，你必然會有一些探測的系統。相信每個廠商自己都會有，但往往一般比較關心的是什麼？是性能和穩定性。性能指的是輸送量和往返時延，穩定性指的是丟包率。如果你的公司更牛一些，還會關注抖動、亂序，還有畸形包等等。
但你是否考慮過另外兩個特性？一個是支持特性，就是功能支持程度；另外一個是資料的真實性。所謂支持特性，就是有沒有一些特殊的機制，會把你阻斷掉不讓資料通信。而真實性更重要了，你能保證你看到的東西一定是真實的嗎？
Ping值是看往返時延的一個最通用的工具。但除了ping值以外，TCP的三次握手也是可以知道網路的往返時延的。而真正在互聯網裡邊請求HTTP協議的時，一個往返時延的計算就是在TCP這個層面來出現的。所以，在有的網路裡，不妨去嘗試用一些tcpping的工具，對比看你的網路是不是有些手腳。
上圖是個真實案例，可以看到用tcpping和用普通的ping出來的結果竟然能差出10倍，那言外之意是你的這個ping，ICMP協議，有可能是被ISP動過手腳的，也有可能給你做個QoS，你看到的只是他們想讓你看到的。
另外，在移動互聯網的情況下，你的包大小對往返時延可能會有嚴重影響。比如，尤其是在窄帶情況下，包越大，在傳輸的時由於是窄帶，擁塞程度就會很大。所以，用小包ping和用大包ping看到結果可能不同。那由於我們現在越來越多的都是互聯網的應用，所以你在真正去做網路探測網速測試的時不妨去考慮，用大包來試。比如，把大包設成像HTTP滿載那麼大，因為你在網路裡面傳輸的時，你的TCP的資料基本都是滿載MTU的，MSS大概是1460。如果是移動互聯網接入，可能會更小，那你不妨就把它設成這麼大，看看真實情況會怎麼樣？
另外，探測時間間隔的不同會導致結果不同。上圖可看到，如果每10毫秒發一個ping包和每1毫秒發一個ping包，看到的丟包率是不一樣的。那有可能有人會說了，你這麼ping的話會被運營商截掉的。憑什麼呢？這樣解釋對嗎？路由器有兩個功能，第一個是有自己的本地協議棧，另外是負責資料轉發。如果你去ping路由器自己的話，那麼由於它自己要耗費CPU去回應你的這個應答，所以你要這麼ping他肯定會有問題，有可能會出現丟包，或者被人為限速的情況。但如果你要是穿透他的話，那應該是無條件替你轉發的。因此有的人如果告訴你說你ping會被攔截，那這是錯誤的，沒有道理的。
之所以是錯誤的，是因為你要ping的目標並不是路由器，他只需替你做轉發。那種硬體路由器背板速率是非常高的，而且不去區分你的四層、三層甚至七層應用。他只瞭解這是一個乙太網幀，只需要看到他是IPv4，然後把資料包轉發出去就可以了。那如果一旦發現這種，低速ping和高速ping是不一樣的，你需要去考慮是不是你的運營商給你做了一些策略，或者是鏈路裡邊真的是有問題，只是你的頻度太低你看不出來。
另外，有人會認為，擁有很多的機房，機房有很多機器，想要探測這些機房的資料。每個機房有個代表的伺服器，直接去測，便能代表整個機房的網路品質。理論上沒錯，但需注意，由於路由的不同，導致同一機房的同一網段相鄰IP可能走的路由路徑是不一樣的。最後導致的網路品質也是不同的，這一定要注意。
對於TCP來說，如果發出去的包被丟掉，但由於後邊會有陸陸續續的包發過去。假如，在接收端他只看到了其中一個包丟掉，那後續的包收到後會馬上回給伺服器，之前的包只確認到了哪兒，伺服器也可間接知道，快速回應你之前某一個包丟掉了，然後快速給你補傳其中的某一個包。但是如果你丟的包是最後一個怎麼辦呢？伺服器之後沒有資料可發了。那麼，作為接收端無法回應，而伺服器只能傻等，等RTO這個時間就會很長。如果你的網路有輕量的丟包，且趕上尾包，那有可能會導致你探測的結果會和之前大相徑庭。
上圖是，我在幫一個朋友去排查他的路由器。他那個社區通道是Chinnel 1，802.11g。由於這個通道擠的已經一塌糊塗了。所以，儘管他的信號強度很大，但由於串擾很多，到閘道延時也依然很大。最有意思的是，我通過他的路由器去traceroute時，發現無論哪個網站，兩跳必到，第一跳到路由器，第二跳到了。這說明什麼？說明你所看到的東西是別人想讓你看到的。
之前，我也進行過投訴，但是他們解釋是網內10Mbps，出網2.5Mbps，就是這樣的，那這個沒有辦法。
現在講，網路探測指標中大家可能不會關心的第三點，新技術可以隨便用嗎？比如，TFO其實是個很好的技術。它的原理是在TCP發三次握手的時已攜帶類似GET請求。而當伺服器接收到3次握手時已開始處理GET請求了，這樣可省掉一個RTT。穀歌針對這個技術做了個測試，尤其是小檔案傳輸時會有比較大的性能提升。但這個技術需在TCP三次握手的時，同時兩邊在TCP選項裡邊支援這個選項，有點類似WScale和SACK一樣。
大家可看到截圖，
Google流覽器是支持TFO的。linux在某個版本之上，在你開發時通過setsockopt，設這個通訊端也是能支援的，所以當時我們想用這個技術做一個測試。
結果測試完後就傻眼了。因為我們通過測試資料收集，然後大資料匯總和視覺化，我們發現，真正這種握手的出網的資料包還OK，但這種TFO在入網時大概有26.09%的節點沒有辦法收到，無法接受這個資料也就是說被牆掉了。
新技術不一定可用，後面講其他，比如隧道協議。在資料傳輸時可能會被劫持，無論劫持原因是什麼，我們是希望改變這種現狀，往往會做一些隧道來規避這種問題。經資料測試發現，GRE這種協議如果隧道，有3.91%出網被攔截，入網10.43%被攔截，證明這種協議也不能通用，且很多ISP是根據你的流量的限制的。就是說你沒跑GRE協議，且跑的不大時他可能不會去限制，但如果要是出現很大流量持續一段時間後，可能會臨時做策略，這是很不靠譜的。
相對於GRE協定來說，其實他不太知名。比如PPTP的VPN，是借助GRE來真正傳輸資料的。所謂的TCP 1723埠只是用來做驗證而已，同理，除了GRE的點對點的隧道外還有一種叫IPIP協議也可做點對點隧道。但由於它的知名度不如GRE高，所以他的攔截率相對來說也比較低。
還有就是有中國特色的社會主義網路，聯通和電信。或可說跨ISP，因為它不僅限於聯通和電信，移動、鐵通、長寬、廣電都有類似這個問題。如果你要跨ISP就可能會出現這個網間結算過大或是被限制這種情況。
很早之前，有相關的文章或新聞說過，聯通和電信壟斷的相關的事情。但是他們只是說說，我也是看他們說說，把這些發出來讓大家看看。在最後一個URL大家如果感興趣可以點進去看。
還有一個更狠的坑就是IDC裡邊的NAT。你們可能經常見到小路由做NAT，公司的閘道出口作NAT。但你有見過IDC做NAT嗎？他分配給你一個ip位址，你從外網訪問這個ip位址是可以訪問到伺服器上的。但如果你從伺服器發出去資料時，別人看到ip位址卻不是這個IP而是別的，且這個IP有可能會動態的變化。
有人會講這個其實無所謂，反正別人都是去訪問你，而你回源時，去拿資料也只是拿而已，為什麼要關心你的IP呢？其實不是這樣的。如果你的很多業務，比如，傳日誌，假設你用的是FTP協議就會遇到很嚴重的問題。FTP用兩個埠傳輸，一個是命令的通道一個是資料通道，在最開始建連時用的是21埠。有很多人認為FTP只工作在21，其實是不對的。也有很多人認為FTP工作在21和20的，其實也是不對的。他其實工作在20和一個隨機埠上。
FTP有兩種工作模式，第一種叫主動工作模式——21埠收到資料後會主動Server本地的20做為源埠反連。第二種情況是被動模式——在21埠就連著後會協商出一個埠，然後用戶端回去連他的這個埠。那麼，在主動工作模式時就可能會遇到問題。如果你看到Server IP是A，嘗試去等待一個來自20埠的A位址去連的話，你永遠也等不到。被動模式其實也是一樣的。如果資料傳輸時下一個Data Channel，IP位址變了的話也會導致傳輸故障。
所以，有很多的廠商可能會鬱悶，為什麼這個日誌傳不回去，為什麼傳一半就斷了或者是為什麼傳不動？那麼我建議你不要再用FTP了。
我們對國內的節點做了一個視覺化分析，發現有2.61的概率出口存在NAT的這種情況的。
另外講一下關於劫持。在網上，我們能看到很多奇怪的現象，比如，圖裂，突然告訴你說沒有備案，但其實你是通過IP位址去訪問的。再比如，你在訪問某一個網頁時右下角會突然插入一個跟網頁一點兒關係都沒有的廣告。實際上，這是種干擾，也是劫持。因為他的目的並不是說一定要去拿到你的資料，他有可能是破壞你。
目前為止，沒有一個廠商或沒有一個組織站出來承認有這麼一種東西存在。當然，也有一些業內人士，可能是清楚這個事情的。我其實對這個東西大概研究了有五年。根據很多資訊以及一些我自己的一些分析，大概畫出一個猜測的網路拓撲圖。
首先，你必須有網路出口的設備接入許可權，其次通過鏡像或分光的方式通過旁路拿到穿過這個關鍵設備的正反向流量。第三，你有一個網線是可以連上Internet，然後去發你想定制的一些資料包的，符合這幾個條件就可以做到劫持。實際上，是通過資料的收集分析，分析時通過IP埠、DPI的七層或者DFI的一種行為分析。拿到一些資料，且這個資料是她感興趣的，就需要去對你動手腳，通過那根紅線去向兩邊發包。偽造成對端的資料，讓兩邊都認為是對端給我發的這個真實的資料，從而實現一些劫持的效果。
舉例來說，中間是防火牆，實際上就是劫持設備。不管是AFW還是BFW還是CFW，只要是某FW，就存在這種劫持的行為。當用戶端和服務端進行三次握手建連之後，用戶端會發起一個GET請求。由於某FW在中間會優先於Server看到GET請求，所以他就可以優先於 Server先搶答一個以Server作為源位址，以同樣的埠80作為源埠，並且發一個假的302資料。迫使他認為拿到了一個真正從server發過來的302跳轉，從而關閉原有連結打開新的連結到達fw，給他指定的伺服器實現劫持。
這是一個真正的劫持的資料包的例子。通過這個分析我們可以發現，第一個包和第二個包之間差是49毫秒，也就是建連時間是49毫秒，ping值是49毫秒。發完GET請求之後，在短短的6毫秒之內，也就是4號和5號包之間6毫秒之內你就收到了一個HTTP回應，顯然是有問題的。因為你的RTT已經是小50毫秒，就算是40毫秒。你發個請求之後，加上伺服器的回應時間無論如何也不可能低於五50毫秒，而他恰恰卻只有6毫米就能響應。也就是說，第一，這個資料絕對不是真正伺服器回的，第二，這個給你回的假資料的設備離你很近。
再看下這個資料包下的真實明文資訊。他是一個HTTP的302響應頭，而且他location的新座標是十網段的地址。大家注意，我這個請求是訪問國外的一個作業系統的軟體更新包。它應該訪問的是真正的公網位址，但卻給我轉向到一個內網的位址，這就是劫持。
去年開始我發現還有一種200劫持。先篡改你的資料，以真正的回應資料方式返回給你。因為有很多的這種設備去分析你的回應頭是不是302，如果是302認為這個是有問題的，因為業務是沒有302的。OK，我乾脆給你回個200。你看這個資料包，1、2包的這個RTT是24毫秒。但是發了GET請求之後，5毫秒就收到一個響應頭也是200。但真正的這個首包是在25毫秒之後發回來的。也就是第10號包，這才是真正的資料的首包。
看上圖，首先遇到的問題是被302跳轉，調整到一個特殊的位址。但是，當去連這個特殊的地址時被403了，也就是說，不做劫持我們還能訪問，做完劫持後我們訪問不了，造成大量客戶投訴。更悲催的是右面的工單系統，從最開始的16年的1月26號開始發起，一直到3月17號始終無進展，運營商那邊也不care。
劫持分成兩種類型，一種叫干擾型，一種就是投毒型。所謂的干擾型他就是利用這個報文強打的方式持續的對你的這個資料產生影響，時不時的對你有干擾的這種行為。另外一種叫投毒型，就是說我可能只有一次去觸發讓你中毒，然後不會再有這種行為了，那麼這種情況一旦發生的話就會很危險。比如，你是做CDN的，邊緣節點如果被投毒的話，有可能你會錯誤的緩存了一個被人為設置成一年才過期的錯誤的圖片，比如是一個黃色圖片，那就會導致這個區域的人訪問看到的都是這個圖片。而且客戶投訴你非常有理，因為人家理由是綁定源站就沒事，是你的問題。
更悲催的是，由於這個投毒行為是一次性的，投完毒以後就不管了，而且它可以持續的生效。第一，你很難抓到之前的現場，且後續有可能很長時間抓不到這個情況。第二，由於很難抓到這個現象，所以，也很難去規避這個問題。你不知道他是怎麼產生的，你只看到他確實東西變了，甚至有可能會誤導你去懷疑這個設備有可能被黑。
從劫持的目的來看，大概分成三種。第一種是法律法規的規避，比如，禁止讓你訪問某FW。第二種是運營商的一種減少成本的一種優化手段，比如，控制網間結算，利用302來提升用戶體驗感，這是一個雙贏的事情。還有一種就是黑產，比如，利益的驅使，讓這個機房的人做劫持，好處多等。其中會有人可能動心，就和他合作，分成是非常厲害，每個月他們XXX的收入這是很正常的。
從劫持的效果來說，有三種。第一種雙贏，當然這個是最好了。第二種的是好心辦壞事兒，類似之前遇到的投訴case，本來是想節省成本，提升用戶體驗感，結果由於你的出現，成本是節省了，但是用戶體驗感大大下降，雖然對運營商的網路非常瞭解，但是她對CDN、對內容這塊還是技術欠缺。第三個就是所謂的黑產，他的目的很簡單，損人利己。
由於前面講了，這種劫持設備的特殊性，我們很難去知道他的存在，也很難去證明它的存在。那就更難去跟運營商打招呼，那如果你想讓人家去承認就得拿出證據來，那麼接下來，我就給大家講下如何去取證？
在IPv4頭裡邊有一個很有意思的一個欄位叫TTL，他的這個全稱是Time To Live，指的是網路資料包在網路裡面所能傳播的距離的遠近，也就是跳數。跟DNS裡邊那個TTL是不一樣的，那個指的是時間。它的特點是什麼？每個作業系統預設有一個自己的發出去的資料包的TTL初始值，叫做TTL base。每跨一條路由TTL就會建議，真到什麼時候為止呢？減到零時，這時路由器就不再替你傳輸了。那不同的作業系統，它的預設值是不一樣的，比如說Windows是128，Linux是64。
如何證明他是劫持呢？通過抓包去看，如果這個資料包裡的TTL，大家都是一樣的或者說即使有不一樣的他有可能就差那麼一到兩個。但是，關鍵資料包，什麼叫關鍵資料包？比如是302的包，或者是異常的200的資料包。他的TTL如果和其他的TTL有明顯出入，那麼他肯定是劫持。
這就是剛才的例子。建連時間49毫秒，get請求的回應包只有6毫秒。這個圖當時沒有截出那個TTL值來。如果要是把那個TTL值截出來，其實一目了然就可以看到TTL是跟其他的不一樣的。
另外，還有一點這個圖裡提到的RTT。那你可以跟運營商去說我的這個伺服器的距離有多遠，ping值有多大，建連時間至少有多長。發完請求之後，看到的異常資料包距離我的時間有多少？無論你做不做TTL的演示，你的RTT一定是要比標準的RTT短，因為劫持的原理就是利用搶答來做。如果他能劫持必然要比你的時間短，否則搶答不了。所以，一旦是劫持你看到的資料包的時間差一定是比標準的要小很多。
最後雖然能夠證明是劫持，但你去跟誰投訴呢？中途有很多運營商，你去跟哪個機房的運營商去投訴呢？所以，這裡涉及到一個定位的問題也就是溯源。同時，這裡還是會用到TTL這個概念。如果大家明白traceroute的原理的話，就會知道了，TTL是可控制你資料包發送的遠近範圍的。如果你的資料包的TTL初始值是3，那你只能發出3條。到第三個路由器時就不再替你轉發了，如果你的初始值是5，那是讓你能傳播5的距離這麼遠。
說完了以後大家多少能想到一個辦法了，是什麼呢？比如，如果通過某個wget時，發一個特殊的GET請求，絕對可以百分之百觸發這個劫持，那不妨發起一次的這個wget請求，然後只把GET包的TTL設置成可以控制的範圍。比如，半徑一、半徑二、半徑三，看到哪一個半徑開始出現劫持。並且在收斂回小一個半徑時，就沒有劫持了。而半徑的距離不足以達到真正要訪問的服務端時，劫持的設備就在剛剛出現這個異常現象的這個半徑範圍之內。
最後，你知道提前的跳數之後，再通過traceroute或mtr去真正跟蹤一下，數一下剛才看的那個跳數，是在這個路徑的第幾個節點，最終就找那個節點的相關負責人了。
中國的網路真的是非常非常的複雜，因為牽扯到特別多東西，有政治因素、利益因素、經濟效益因素。這裡邊的坑也是特別多。那這裡邊比如，我們看到的好多問題，是隨時間變化而變化的隨流量變化而變化，隨政策，隨利益甚至隨心情都會隨時變化。所以說你如果想做好，真的是太不容易了！
最後這部分的是裡面需要用到的一些知識點或者是一些工具，或者是一些引用的一些文章。大家感興趣的話可以看一下。那麼整個的這個分享到這兒就結束了，謝謝大家。
提問環節
1.白老師，我聽到一半下班了，剛回來，請問有沒有各cdn伺服器之間資料同步的問題？這個佈局，也有種分散式的感腳，所以需不需要也要考慮各個節點資料出現差異的情況？
答：如果是指數據分發的話，有兩種模式，一種是樹形結構的分發。比如由邊緣、父層、超父層來實現，逐漸收斂，逐級緩存；第二種是利用 P2P 的機制在同機房甚至跨機房裡實現緩存。
2.就是說資料一致性，比如在原始伺服器改了一下某個頁面，訪問cdn的話，還是老頁面嗎？
答： 這是刷新，當客戶有要求在某個 URL 沒過期之前，強行刷掉，就會用到這個機制
3. cdn各個節點之間怎麼做的資料同步？緩存時間會是多久？
答：緩存時間有兩種設定：一種是遵循源站，也就是源站讓你緩存多久，你就緩存多久；另一種是自訂，比如你修改了緩存時間，具體要看客戶需求。
4.比如全球有多個節點，我上傳一個檔，多久之後可以完全同步到這幾個節點？
答：這是由支撐系統來完成的。一般都是全網下發指令，拿到指令的機器自動去做 preload，或者 refresh。
5.還有個防盜鏈的問題~不太懂，CDN 如何實現防盜鏈的？
答：CDN 的防盜鏈是要和客戶對接演算法的，有兩種模式，一種是 CDN 有自己的演算法，客戶支援 CDN，另一種是客戶有自己的演算法，CDN 適配客戶。
一般的防盜鏈都是和 key 和時間因數有關的，對，然後不同的客戶協商一個特殊的 key，遵循同樣的演算法即可。
6.關於tcp優化的問題，bbr算是一種了，白老師覺得這個演算法怎麼樣？
7.GLB一般都怎麼搭啊？
答：最簡單的方案，用 bind 就可以。
8.有沒有成熟的商業系統？
答：DNSPod 就可以做調度，我們也可以。我們的 DNS 和 DNSPod 都是高性能的，我們是基於 kernel 寫的，DNSPod 是用 DPDK 寫的，處理性能都可以達到 400w ~ 700w QPS。
9.有沒有確定劫持節點的工具？
答：如果感興趣的話可以等幾個月以後在論文庫裡查到我寫的《抗旁路干擾系統的分析與設計》