网络路径跟踪

最近对网络数据的传输路径感兴趣，在Windows上用tracert命令进行了一次追踪，这个命令的工作方式是这样的：

当运行 tracert 命令时，你的电脑会发送第一个ICMP数据包到目标地址，这个数据包的 “Time to Live” （TTL）值被设置为1。TTL是一种防止数据包在网络中无限循环的机制。每当数据包经过一个路由器，ICMP数据包的TTL都会减1，如果TTL变为0，那么这个数据包就会被丢弃，同时这个路由器会发送一个ICMP消息回发送者，告诉它数据包已经被丢弃。

tracert利用ICMP的这个特性。将初始的TTL设置为1，意味着这个数据包在经过第一跳后就会被丢弃，然后第一跳的路由器会返回一个ICMP消息。接收到这个消息后，tracert就知道了第一跳的地址和经过的时间。然后，tracert再发送一个TTL为2的数据包，进而得知第二跳的信息，以此类推，直到到达目标。通过这种方法，tracert就能得知数据包经过的每一跳的信息。

就这样，tracert命令会逐步“探索”出从源到目的地的路由路径。所以，tracert展示的路由路径是在运行命令时数据包经过的路由。

但是网络是动态变化的，会不会在跟踪的时候，tracert前一次发送的ICMP数据包所走的路径和后一次完全不同呢？

这也是有可能的，不过我跟踪overleaf.com的时候这种状况并不多见，短时间内重复测试同一条tracert命令，返回结果基本相同，说明网络状况还挺稳定的。

但跟踪google.com的时候，网络状况变化复杂很多，短时间内重复执行tracert，解析出的Google服务器地址往往不同。因为Google有大量的服务器和数据中心分布在全世界各地。当你尝试访问google.com时，DNS服务器不会总是解析为同一个IP地址，而是可能会提供最佳的、基于你的地理位置和Google网络状况的IP地址。

tracert命令解析google.com得到对应的IP地址后，将在整个过程中使用这个IP。换句话说，即使在tracert命令运行期间，google.com被解析为不同的IP地址，也不会更改初始的目标，即第一次解析出的IP地址仍是tracert命令的目标。

下面是一次跟踪overleaf.com的结果：

PS C:\Users\Administrator> tracert overleaf.com

通过最多 30 个跃点跟踪
到 overleaf.com [34.120.52.64] 的路由:

  1     4 ms     2 ms     1 ms  10.100.0.1
  2     *        *        *     请求超时。
  3    24 ms     2 ms     2 ms  65.45.17.58.adsl-pool.jx.chinaunicom.com [58.17.45.65]
  4     2 ms     2 ms     1 ms  189.194.248.220.adsl-pool.jx.chinaunicom.com [220.248.194.189]
  5    16 ms    15 ms    16 ms  45.1.34.171.adsl-pool.jx.chinaunicom.com [171.34.1.45]
  6     *       23 ms    22 ms  219.158.106.169
  7    27 ms    31 ms    31 ms  219.158.18.70
  8    26 ms    31 ms    31 ms  219.158.16.82
  9   215 ms   215 ms   213 ms  219.158.117.2
 10   203 ms   202 ms   202 ms  12.246.229.121
 11     *        *        *     请求超时。
 12     *        *        *     请求超时。
 13     *        *        *     请求超时。
 14   196 ms   194 ms   196 ms  32.130.104.53
 15   280 ms   292 ms   295 ms  12.255.10.180
 16   283 ms   276 ms   298 ms  64.233.174.209
 17   291 ms   280 ms   264 ms  209.85.249.177
 18   296 ms   295 ms   282 ms  64.52.120.34.bc.googleusercontent.com [34.120.52.64]

跟踪完成。

直接看不太能提取出有用的信息，这个时候就需要交给GPT了：

我：可以针对这次跟踪结果，解读一些有用的信息吗？

GPT：当然可以，我们来逐步分析一下这个 tracert 的结果。

1. 第1跳：IP地址 10.100.0.1，延迟时间很短，这通常是你的本地网络的网关，可能是你的路由器或者modem。
2. 第2跳：请求超时，可能是由于这个节点忽略了我们的ICMP请求，或者节点过于繁忙无法及时回复。
3. 第3-5跳：看起来像是中国联通的广域网络设备（chinaunicom.com），这可能提供了将你的数据包从你的本地网络连接到更广泛的Internet的服务。
4. 第6-8跳：看起来像是互联网服务供应商（ISP）的核心网络设备，能看出数据包经过了ISP的内部网络。
5. 第9跳：延迟时间大幅增加，这可能是你的数据包离开了中国，开始进入国际网络。
6. 第10跳：IP地址变成了12开头，可能是进入了AT&T的网络（AT&T的网络IP通常以12开头），现在你的数据包在国际网络中传输。
7. 第11-13跳：请求超时，可能是选择忽略或者阻止对我们ICMP请求的设备。
8. 第14-17跳：延迟开始稳定，看起来你的数据包已经接近目标网络了。
9. 第18跳：IP地址对应的域名为bc.googleusercontent.com，这表明数据包已经到达Google的网络，最终到达IP为 34.120.52.64 的目的地服务器。
   注意，这里所有的设备和网络分析都是基于IP地址的推测，最准确的设备和网络信息由各自的网络管理员和ISP持有。
   总的来说，这个 tracert 命令展示了数据包从你的电脑到达 overleaf.com 的逐步路径，并展示了在每个阶段可能导致延迟的设备或网络细节。这些信息可以帮助你更好地理解包括网络延迟、数据路径、网络瓶颈等概念。希望这些信息能对你有所帮助！

再贴一个google.com的跟踪结果和分析结果：

PS C:\Users\Administrator> tracert google.com

通过最多 30 个跃点跟踪
到 google.com [2404:6800:4012:2::200e] 的路由:

  1     4 ms     2 ms     3 ms  2001:250:6c04::2
  2     3 ms     3 ms     3 ms  2001:250:6c04::1
  3     2 ms     2 ms     1 ms  2001:250:6c01:fff2::1
  4    10 ms    10 ms    10 ms  2001:250:6c01:ffff::2e
  5    14 ms    13 ms    13 ms  2001:250:6c01:ffff::51
  6     *        *        *     请求超时。
  7    17 ms    16 ms    16 ms  2001:250:6c01:ffff::86
  8    16 ms    17 ms    17 ms  2001:250:6c01:ffff::2
  9    16 ms    16 ms    16 ms  cernet2.net [2001:da8:cb:11::1]
 10    18 ms    18 ms    18 ms  2001:da8:2:135::1
 11    28 ms    24 ms    30 ms  2001:da8:2:56::1
 12    31 ms    29 ms    29 ms  2001:da8:2:f::1
 13    38 ms    37 ms    37 ms  2001:da8:2:d::2
 14    47 ms    47 ms    47 ms  2001:da8:2:1::1
 15    48 ms    47 ms    47 ms  cernet2.net [2001:252:0:2::101]
 16    48 ms    47 ms    47 ms  cernet2.net [2001:252:0:10a::2]
 17    81 ms    82 ms    83 ms  google2-lacp-100g.hkix.net [2001:7fa:0:1::ca28:a10a]
 18    87 ms    81 ms    82 ms  2001:4860:0:e05::e
 19   104 ms   103 ms   103 ms  2001:4860::c:4001:2282
 20   103 ms   103 ms   214 ms  2001:4860::c:4003:2e3c
 21   104 ms   108 ms   103 ms  2001:4860::1:0:c726
 22   104 ms   103 ms   103 ms  2001:4860:0:1011::1
 23   102 ms   103 ms   104 ms  2001:4860:0:1::34c5
 24     *        *        *     请求超时。
 25     *        *        *     请求超时。
 26     *        *        *     请求超时。
 27     *        *        *     请求超时。
 28     *        *        *     请求超时。
 29     *        *        *     请求超时。
 30     *        *        *     请求超时。

跟踪完成。

GPT：这次我们进行的是IPv6地址的跟踪，原理与IPv4的跟踪是一致的，只是地址格式不同。以下是逐步分析：

1. 第1-3跳：你正在使用的地方网络和路由器，这可从延迟的低度来看，几乎没有。
2. 第4-5跳：看起来像是国内网络对你的数据包的处理，在这个过程中延迟有所增加，这可能是因为数据包正在经过更复杂的网络和设备。
3. 第6跳：请求超时，原因可能多样，可能是对这种ICMP请求不回应，或者节点过于繁忙未能及时回应。
4. 第7-9跳：数据包继续在国内网络中传输，可以看到跳数（路由器/设备数）增多，但延迟相对稳定。
5. 第10-16跳：数据包仍在国内网络中，但延迟有所增加，可能是数据包在向境外移动的过程中。
6. 第17-23跳：这是一个有趣的部分，数据包离开国内网络，进入了Google的网络环境，可以从IP地址的巨大变化中看出，也从延迟的显著增加中得出，此时数据包可能已经进入了海底光缆网络，方向可能是香港的数据中心。
7. 第24-30跳：这些请求超时，可能是因为Google的内部网络设备选择不回应这些ICMP请求，或者数据包已经到达目标，traceroute 在尝试寻找不存在的下一跳。

总之，这次traceroute过程显示了你的数据包是如何从你的本地计算机一直到达google.com服务器的每一步，包括国内网络环境，海底光缆，以及Google的内部网络。值得注意的是，由于网络状况的动态性，结果可能在任何时间改变，以反映当前的网络状况。

如果你的网络开了TUN模式，那就是这样的了：

PS C:\Users\Administrator> tracert google.com

通过最多 30 个跃点跟踪
到 google.com [198.18.0.5] 的路由:

  1    <1 毫秒   <1 毫秒   <1 毫秒 198.18.0.5

跟踪完成。

无论你跟踪的是什么网站，都是类似的结果，仅用一跳。在TUN模式下，数据包被封装起来，并通过一个虚拟的网络隧道发送到目标服务器，而忽略了数据包原本会经过的所有网络节点。可以看到google.com的地址被解析成198.18.0.5，这是局域网的一个地址，它和我们的主机在同一个网络里。ICMP包并不会发送到google服务器，而是发送到198.18.0.5，所以一跳就完成了。其他所有域名的地址都会被解析为这类局域网地址，所以都仅需一跳。