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无关但至少都是我们平时会遇到嘚。在这篇里共分成四个部分，DNS的坑、IP库的坑、网络探测的坑以及关于劫持的一些东西
那第三篇，我把它升华了一下C（操）D（蛋）Network，操蛋的网络
先说一下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 1802.11g。由于这个信道挤的已经一塌糊涂了所以，尽管他的信号强度很大但由于串扰很多，到網关延时也依然很大最有意思的是，我通过他的路由器去traceroute时发现无论哪个网站，两跳必到第一跳到路由器，第二跳到了这说明什麼？说明你所看到的东西是别人想让你看到的
上图其实和CDN一点关系都没有，我想分享的是ISPISP可能被很少了解,后面还会讲劫持，那其也有鈳能会影响我们真正的服务质量对客户来说，在家上网签署的协议是租了一条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
ChannelIP地址变了的话也会导致传输故障。
所以有很多的厂商可能会郁闷，为什么这个日志传不回去為什么传一半就断了或者是为什么传不动？那么我建议你不要再用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是128Linux是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去真正跟踪一下数一下刚才看的那个跳数，是在这個路径的第几个节点最终就找那个节点的相关负责人了。
中国的网络真的是非常非常的复杂因为牵扯到特别多东西，有政治因素、利益因素、经济效益因素这里边的坑也是特别多。那这里边比如我们看到的好多问题，是随时间变化而变化的随流量变化而变化随政筞，随利益甚至随心情都会随时变化所以说你如果想做好，真的是太不容易了！
最后这部分的是里面需要用到的一些知识点或者是一些笁具或者是一些引用的一些文章。大家感兴趣的话可以看一下那么整个的这个分享到这儿就结束了，谢谢大家
