上节中，我们了解了自治系统AS和BGP协议。这次我们将使用MyTraceroute工具，亲手追踪我们发出数据包的路径。并介绍了一篇文献，如果我们要“感知全球的网络拓扑信息”，建设一个动态的分布式全球网络链路监测系统，可以做哪些操作。
近期正好对《互联网连接拓扑》做了初步的探索。直到认真探究之前，我对许多原理的认知都是模糊的。系列文章是探究留下的笔记。如有谬误，请不吝赐教。
- 全球互联网拓扑探索 (1) : 互联网是怎样工作的
- 全球互联网拓扑探索 (2) : 自治系统(AS)与BGP协议
- 全球互联网拓扑探索 (3) : 使用Traceroute，如何建立全球网络链路监测
- 全球互联网拓扑探索 (4) : 国家和大洲级别连接拓扑探究与可视化
Table of Contents
1 回顾和问题引入
今天，我们了解了自治系统AS和BGP协议。它们组成了我们的网络，并让网络是如何找到较优的线路进行连接。
在本文中，我们将介绍Traceroute和相关的一些概念，亲手追踪我们发出数据包是如何一步一步发送并返回的。并介绍一篇文献，看看如果我们建设一个动态的分布式全球网络链路监测系统，可以做哪些操作。
2 网络追踪实用工具
2.1 基本概念和实用工具
RTT 往返时间
Round-trip time (RTT) 是指“往返时间”，为网络请求从起点到达目的地并返回起点所用的是时间，一般使用毫秒ms计。RTT是影响我们感受网络延时的重要指标。而我们平时用到的CDN技术，目的之一也是尽量减少用户终端请求到源站服务器的RTT时间。
用来探测RTT的重要工具是Ping。RTT也是我们在网络游戏中关注的“Ping值”。
TTL 生存时间
Time To Live (TTL) 是指“生存时间”。我们一般会在IP包层面和DNS中看到这个值。今天我们的文章重点为IP包层面。数据包经过一个路由器，存活次数减1。当存活次数为0时，路由器会停止转发数据包，丢弃时一般会返回发送ICMP信息。生存时间设计的目的是为了防止无限循环耗尽网络资源。
我们可以在发送数据包时，设置不同TTL，根据丢弃数据包时返回的ICMP消息，探测网络链接上的每一跳。
这也是我们之后介绍的Traceroute的工作基础。
ICMP 消息
Internet Control Message Protocol (ICMP) 是互联网控制消息协议。工作在IP层。提供通信环境中各种问题的反馈。
Ping
Ping用来测试数据包能否透过IP协议到达特定主机。ping的运作原理是向目标主机传出一个ICMP的请求回显数据包，并等待接收回显回应数据包。程序会按时间和成功响应的次数估算丢失数据包率（丢包率）和数据包往返时间RTT。
Traceroute
Traceroute工具用来追踪网络链路上的每一跳。Traceroute通过设置不同TTL，根据丢弃数据包时该跳路由器返回的ICMP消息，从而探测网络链接上的每一跳信息。
图 Traceroute原理(by Cloudflare)
2.2 mytraceroute(MTR)
Mytraceroute(MTR)是结合了Ping和traceroute的实用工具，我们在排查网络问题和检测链路质量时使用得较为广泛。
还记得我们在之前文章追踪过的跨ISP连接吗？我们立刻就可以找个目标动手试试连通性。
笔者选取了从深圳市电信家庭宽带到DigitalOcean 新加坡1机房测速点的链路。
mtr --aslookup -4 speedtest-sgp1.digitalocean.com
MTR可以不断地循环探测。在结果中，我们可以获得三类信息。
Host
Host的信息主要是网络链路上每一跳的ip地址。
另外是根据ip地址反查得到的AS number。（我们上篇文章讲到了AS和BGP，不熟悉的读者可以翻看。）
还有根据ip地址反查得到的DNS记录。这条记录可以让我们很方便地追踪到一些路由器信息。比如本例子中，可以马上看出，数据包经过日本东京，然后到达了新加坡。海外出口的线路运营商大概是ntt.net。最终到达了DigitalOcean的新加坡机房。
Packets
主要显示了丢包情况。细心的读者可能已经发现，在第5跳和第6条的丢包率非常高。这一定表示该跳丢包率很高吗？其实不一定，因为该点路由器可能限制了ICMP包的回复速率。
一般我们再往后看丢包情况，如果接下来丢包很低，那么大概率这一跳是没有问题的。
也存在没有收到ICMP返回包的情况，比如13跳-16跳，这也是运营商对ICMP数据包的限制导致的。实际上我们的数据包到达了最终的目的地。
Ping
提供了RTT时间，包括统计上的均值，极值和标准差。
Tips
值得注意的是，这种MTR探测，只显示了从源头到目的地的链路。要看到数据包从目标地址返回我们的路径，还需要反向的MTR探测。有时高延迟和不合理的路由会发生在返回过程中。即数据包并不一定是沿着原本的路径返回的。
2.3 小结
有了MTR工具，我们可以方便地探测数据包链路的运营商、AS、地理位置和延迟等信息。
MTR既可以当做我们平时排查网络问题的工具，也可以作为大规模网络探测的基础。
接下来，笔者介绍一篇文章，讲述了通过MTR搭建动态的分布式全球网络链路监测系统的过程，并得到了一些有趣的结论。
3 网络链路动态检测(分布式网络探测初步)
笔者之前曾突发奇想，如果想要构建一个分布在全球的终端，不停地Ping和TraceRoute一些关键的节点，就能建立起一套动态的检测系统，是一件很酷的事情。其实这种构想，就是我们构建面向很多地区的服务时，需要配套的“拨测”。
引用腾讯云对拨测的定义：利用分布于全球的服务质量监测点，对域名、后台接口等进行周期性监控，可通过查看可用率和延时随时间区间变化来帮助分析站点质量情况。
笔者也找到了一篇2021年的文章，Surrounded by the Clouds: A Comprehensive Cloud Reachability Study。
文章对全球主要云厂商的网络质量进行了大量的横向测试和对比。用到的基础工具就是我们讲到的traceroute和ping。这篇文章可以作为建立拨测的参考，笔者在此分享给大家。
文章主要是先在大型云服务商处购买相当数量的云主机作为靶机，然后使用一种分布式的探针平台RIPE Atlas，在全世界范围内对各个数据中心进行广泛探测，并总结数据和横向对比。最后结合人类的感知阈值，给出实际使用场景的适用程度。
3.1 全球范围靶机建立
这一步比较好理解，就是从各家云服务提供商的各个位置数据中心购买虚拟机作为被探测对象。
图 全球靶机的分布
这里有个小知识我们可以了解下。在表中Backbone的意思，是指云服务提供商内部各个地区的机房之间，是否提供了直连的连接。其中Private代表机房间存在专线直连。而Public是指两机房间只有公共的互联网连接。这个往往和云服务商的实力有关，因为国际专线非常的昂贵。
3.2 全球范围探测点建立
这一步文章直接使用了 RIPE Atlas Platform分布在全球的探测点。使用的工具就是我们上述的Ping和Traceroute。
图 全球探测点的分布
值得指出的是，除了地理分布，探测点也需要具备多种终端环境的模拟。
比如分别在
- 骨干机房
- 家庭和办公环境的宽带
- 各类移动网络
都需要有监测点探针来模拟。
3.3 考察和收集指标
文章中提到的评价指标主要有以下几点。
用户到数据中心的延迟 Latency Estimation
本部分考虑并统计终端用户到数据中心IP的RTT时间，用于展现延迟指标。
路径长度 Path Length Estimation
本部分根据Traceroute结果，分析链路长度和质量。
网络构成 Network composition
跟踪traceroute中每一跳的IP和组织的名称、位置和网络类型，用于透视网络的构成情况。
3.4 结论
文章中根据探测数据得到了一些结论，这里笔者调有趣的结论来一起看看。
3.4.1 大洲级别云厂商普及程度
根据探测得到的信息，文章评价了各个云厂商在不同大洲的普及程度。
图：云提供商在不同大洲的普及程度
通过Traceroute和Ping的统计信息，文章得出，Google和Microsoft在全球的普及相对较好一些。
3.4.2 美洲数据中心的RTT分布
文章中也通过统计的RTT信息，画出同地区和跨地区访问的RTT分布。可以为对延时敏感的应用作网络环境的指导。
图 RTT分布
有了这些分布，我们也可以大概了解，每个国家跨国或者本国互联网访问的延迟分布。
这也意味着，每个国家的互联网基建和连接情况都是不同的。这样的监测数据，能够指导我们在全球化应用时，对本地互联网基建的认识。
4 小结
今天，我们介绍了Traceroute和Ping相关的一些概念，并亲手追踪我们发出数据包是如何一步一步发送的。
另外，通过一篇文献，设想了如何建设一个动态的分布式全球网络链路监测系统，和需要收集的指标。也印证了traceroute和ping对于互联网网络的重要性。
参考资料
[1] 网络排查工具MTR介绍-腾讯云 https://cloud.tencent.com/developer/article/1491610
[2] What is RTT - Cloudflare https://www.cloudflare.com/zh-cn/learning/cdn/glossary/round-trip-time-rtt/
[3] Corneo L, Eder M, Mohan N, et al. Surrounded by the Clouds: A Comprehensive Cloud Reachability Study[C]//Proceedings of the Web Conference 2021. 2021: 295-304. https://dl.acm.org/doi/10.1145/3442381.3449854
