转自https://mp.weixin.qq.com/s/JfM8fmuyQTljI7Msi6IwDQ
咱们接着上期继续。
CDN有很多的性能指标，也有很多第三方的探测工具或者是系统。那么，客户在接入CDN后可能会担心他们的服务质量怎么样，往往就会借助第三方的探测工具来分析CDN的性能。
上图是常见的几个概念。分几个不同的阶段，比如，DNS解析时间、建连时间、首包时间、SSLL握手时间、下载时间等。每一个指标代表不同的含义，通过每个指标的长短也可以分析出问题点大概是在哪里。
比如，如果DNS时间慢，就意味着可能是你的客户端拥塞了，或是你的客户端设的Local DNS到你那儿的距离太远，或者用户所使用的Local DNS存在问题。
如果是建连时间慢，至少代表客户端有可能是拥塞，或是客户端到你的CDN节点的距离太远，又或是CDN本身的调度机制有问题，或是CDN的节点带宽满。
首包时间除了包含建连时间的所有的范畴外，还加上一个服务器的负载时间或是服务器的回源时间。那首包是什么意思呢？首包是说，从发完GET请求之后开始计时，到接到第一个数据包为止算结束，这期间的时间。那这个时间除了RTT的以外，还包含了服务器磁盘占用过高，导致准备数据时间过长，又或是MISS了然后需要回源去拿。
对于SSL握手时间，就是你在最开始交换证书密钥时开始计时，一直到SSL握手结束这个时间。而下载时间是指客户端从拿到第一个数据包开始计时，然后到所有的数据包都下载完的这个时间。
由此，我们可以理解为，慢是由多种原因造成的，无论哪一个环节慢都会造成最后的慢。
这是个性能分析的例子，我把业务大概简单介绍下，它是一个切片直播，也就是m3u8，它是通过文件下载实现直播效果的业务方式。
m3u8你可理解成是一个文件目录列表，然后你的浏览器拿到这个列表之后，它里边很多的文件你可以一个一个去下载。每一个文件都是一个小的时间段的视频，然后它拼起来播放的时候就形成了所谓的直播的这种状态。那么这是个直播的业务测试，客户希望看到ts片在纯回源时各家CDN的服务质量如何。
直播意味着什么？意味着他不可缓存，是动态的，是从源站拿来的数据。曲线图和数据表就是跟竞争对手相比时的建连时间对比图。从时间可看出来我们的RTT是不占据优势的。和竞争比较，他的RTT比我们的要小,因为建连时间代表RTT。
上图是首包时间的图，可看出，我们的首包时间竞争对手的7.8倍。由此产生个疑问，这是个动态的业务测试，如果是动态必然有回源，如果是回源必然有经过CDN的上下层，然后经过源站，再传回给CDN，最后回传给Edge Server。把这数据准备好后再吐给客户，那首包时间必然会很长。
为什么竞争对手的首包时间和建连时间差不多呢？极有可能是由于他错误的设置了策略，导致不公平的测试，他把这个数据缓存住了。
为了验证之前的猜测，做了一个抓包的测试。首先，测试厂商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可能走的路由路径是不一样的。最后导致的网络质量也是不同的，这一定要注意。
可能你想说ping这些网络的东西没有意义，因为最终关心的是业务服务质量，所以，与其这样不如直接去测业务最终的服务效果。所以，确实有人放一个小的Object在你的Web Server上或Cache Server上。那你访问时可能也就是1KB、2KB这样，很短的时间就下载完了，可通过真正的下载时间来看你真正透过HTTP这层的服务效果怎么样，但是这里边有一个坑,就是由于TCP协议的尾包丢包的问题有可能会导致你的判断会失误。
对于TCP来说，如果发出去的包被丢掉，但由于后边会有陆陆续续的包发过去。假如，在接收端他只看到了其中一个包丢掉，那后续的包收到后会马上回给服务器，之前的包只确认到了哪儿，服务器也可间接知道，快速响应你之前某一个包丢掉了，然后快速给你补传其中的某一个包。但是如果你丢的包是最后一个怎么办呢？服务器之后没有数据可发了。那么，作为接收端无法响应，而服务器只能傻等，等RTO这个时间就会很长。如果你的网络有轻量的丢包，且赶上尾包，那有可能会导致你探测的结果会和之前大相径庭。
那探测出了问题难道说不好吗？实际上，如果是一个大的文件下载，你中间某一个包丢掉了，对传输来说无所谓。因为很快就可以走到快速重传的路径，然后把这个数据快速的发给客户端。但如果你是尾包丢掉的话，得出的结论就有可能是网络非常不好，这样会造成一个误判，认为你的网络不可用，但并没这么严重。
上图是，我在帮一个朋友去排查他的路由器。他那个小区信道是Chinnel 1，802.11g。由于这个信道挤的已经一塌糊涂了。所以，尽管他的信号强度很大，但由于串扰很多，到网关延时也依然很大。最有意思的是，我通过他的路由器去traceroute时，发现无论哪个网站，两跳必到，第一跳到路由器，第二跳到了。这说明什么？说明你所看到的东西是别人想让你看到的。
上图其实和CDN一点关系都没有，我想分享的是ISP。ISP可能被很少了解,后面还会讲劫持，那其也有可能会影响我们真正的服务质量。对客户来说，在家上网，签署的协议是租了一条10MbpsMbps的小区宽带。我发现，虽然迅雷下载或者BT速度都很快，但如果我从公司的服务器去拖数据到我家只有2.5MbpsMbps的速度。我在出口通过ICMP的采集这个数据点拿出来，回了一个图，通过这个图发现这个数据很稳，也就是说这绝不是我服务器的发包有问题，肯定就是做了限速。
之前，我也进行过投诉，但是他们解释是网内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去产生跳转。而真正的做法是通过一段加粗的代码促使你的浏览器产生跳转行为。如果你要访问的这个客户端是一个wget，你会拿到一个很小的数据。有任何异常你只会认为这个下载数据的那么小，但如果要是用浏览器打开时就可能被引导到一个新的一面，或下载一个新的文件。例如，被跳转到百度的一个网站去下载APK。那么，这个APK就有可能是被篡改的，而且里面有可能有木马，有可能有广告有可能有各种乱七八糟东西。
其实，对于劫持来说，有好有坏。它有两种，第一种就是不想让你去访问比如，某FW，他不想让你访问Google、Fackbook和YouTube。另外一种就是一种双赢的做法，目的是把流量牵引到本地，除了不让产生跨网流量，而减少成本和网间结算以外，由于数据都在本地所以下载速度也比外网要快很多。而且可以腾出更多资源为更多的人去服务，这是双赢。
看上图，首先遇到的问题是被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算是一种了，白老师觉得这个算法怎么样？
答：远超现有的bic、cubic、highspeed 等拥塞控制算法，尤其对中小型文件传输来说加速效果奇佳。但是，它里面有个 RTT 避让机制，会让传输效果大打折扣，在避让机制启动时，会清空 inflight 内容，释放 RTT。来让用户有更好的“髙实时”体验感。但由于 bandwidth是固定的，throughput 会有些下降。而且争抢能力并不好，遇到 P2P 强带宽，下载速度很难上去，抢带宽，而且有一定的使用门槛，Linux Kernel 必须 >= 4.9。
7.GLB一般都怎么搭啊？
答：最简单的方案，用 bind 就可以。
8.有没有成熟的商业系统？
答：DNSPod 就可以做调度，我们也可以。我们的 DNS 和 DNSPod 都是高性能的，我们是基于 kernel 写的，DNSPod 是用 DPDK 写的，处理性能都可以达到 400w ~ 700w QPS。
9.有没有确定劫持节点的工具？
答：如果感兴趣的话可以等几个月以后在论文库里查到我写的《抗旁路干扰系统的分析与设计》
