共计 2953 个字符，预计需要花费 8 分钟才能阅读完成。
大家好，我是周杰伦。
那天，我忽然想到一个问题：
当我拜访那个让万千宅男程序员为之着迷的 GitHub 时，我电脑收回的数据包是如何到达大洋彼岸的 GitHub 服务器的呢，这两头又要通过哪些节点呢？
让咱们一起来探索下这个问题，请留神系好安全带，计算机网络慢车要发车了···
IP 报文
互联网把有数的手机、电脑、服务器、路由器、交换机等各种设施连贯在一块儿，那这些设施之间要通过网络通信，天然就须要一套通信协议，TCP/IP 就是这样一套协定。
包含浏览器在内的这些应用程序收回的数据，被 HTTP、TCP、IP 协定层层封装，最终造成一个个的 IP 报文，交给底层网卡收回去。
IP 报文通过网络中节点的一直路由转发，最终来到了指标服务器。
那如何晓得路由转发过程中，都通过了哪些网络节点呢？
Windows 上的 tracert 程序和 Linux 上的 traceroute 程序就可能做到。
它们是如何做到的呢？
IP 报文总不能无限度转发吧，万一搞了个循环转发，那不就没完没了了？网络中的 IP 报文有一个生存工夫的概念，位于 IP 报文头部字段中——
TTL：time to live。
每通过一次转发，TTL 的值就会减 1。如果某一个节点发现 TTL 变成了 0，就会丢掉这个 IP 报文，并给这个数据报文的发送者发一个超时的告诉音讯过来。
tracert 和 traceroute 正是利用了 IP 协定中的这个特点，将 TTL 的值从 1 开始递增，察看都是谁给本人发回了这个告诉，就能判断路由过程中经验了哪些节点了。
这两个程序的区别在于，tracert 发送的是 ICMP 报文，traceroute 发送的则是 UDP 报文。
路由跟踪
好了，基础知识交代结束，连忙来试一下，拜访 GitHub 的状况。
首先 ping 了一下，拿到了 GitHub 的 IP 地址：140.80.121.3。留神，这个地址，不同地区的人拿到的可能不一样。
接下来路由跟踪一下吧：
F:\work>tracert 140.82.121.3
通过最多 30 个跃点跟踪
到 lb-140-82-121-3-fra.github.com [140.82.121.3] 的路由:
1 <1 毫秒 <1 毫秒 <1 毫秒 10.??.??.1
2 <1 毫秒 <1 毫秒 <1 毫秒 10.??.??.??
3 2 ms 1 ms 1 ms 182.150.63.1
4 * * * 申请超时。5 1 ms * 2 ms 171.208.199.81
6 * 25 ms * 202.97.29.45
7 * * * 申请超时。8 36 ms 37 ms 36 ms 202.97.91.190
9 184 ms 191 ms 185 ms 202.97.27.242
10 195 ms 194 ms 194 ms xe-10-0-0.mpr4.sjc7.us.zip.zayo.com [64.125.14.45]
11 190 ms 190 ms 190 ms ae16.cr2.sjc2.us.zip.zayo.com [64.125.31.14]
12 324 ms 325 ms 324 ms ae27.cs2.sjc2.us.eth.zayo.com [64.125.30.232]
13 * * 333 ms ae16.cs2.den5.us.zip.zayo.com [64.125.28.215]
14 334 ms * * ae5.cs4.ord2.us.eth.zayo.com [64.125.29.217]
15 * 327 ms 325 ms ae3.cs2.lga5.us.eth.zayo.com [64.125.29.212]
16 * * * 申请超时。17 * * * 申请超时。18 332 ms 332 ms 340 ms ae0.cs1.lhr15.uk.eth.zayo.com [64.125.29.119]
19 * * * 申请超时。20 343 ms 338 ms * ae4.cs1.ams17.nl.eth.zayo.com [64.125.28.36]
21 355 ms 353 ms 353 ms ae2.cs1.fra6.de.eth.zayo.com [64.125.29.58]
22 335 ms 334 ms 338 ms ae1.mcs1.fra6.de.eth.zayo.com [64.125.29.57]
23 340 ms 341 ms 341 ms 82.98.193.31
24 * * * 申请超时。25 * * * 申请超时。26 335 ms 343 ms 343 ms lb-140-82-121-3-fra.github.com [140.82.121.3]能够看到，通过了 26 个节点的转发后，最终达到了 GitHub 服务器。也就是说，你电脑收回的 IP 报文的 TTL 至多要大于等于 26 能力到达 GitHub，否则就会中道崩殂。
【配套技术文档】
接下来，咱们来看一下，这一路都去了哪里？
1-2
数据包从我的计算机收回后，遇到的第一个转发节点就是我的本地局域网网关：10.??.??.1。为了安全性，我把 IP 地址进行了脱敏，两头两段用? 代替。
这之后第二个节点还是局域网的地址，由此可见，我所在的网络格局，通过了两级局域网路由转发才上了公网。
3
第三个转发节点是一个公网地址：182.150.63.1，查了一下发现位于成都市武侯区，这和我的理论状况相符。
4
接下来的第四个路由节点就有点迷了，三个工夫点都是 *，tracert 显示申请超时。呈现这个意味着 tracert 程序在将 TTL 设置为 4 后，没有收到告诉，或者期待的工夫太久。网络中的有一些节点出于平安思考可能并不会发送超时告诉。
如此一来，tracert 便无奈晓得这第四个节点到底是谁。
5
第五个节点是：171.208.199.81，依然还在成都。
6
第六个节点时：202.97.29.45，到了北京了。
【配套技术文档】
7
第七个节点和第四个一样，也看不到。
8
第八个节点：202.97.91.190，来到上海了。
9
第九个节点：202.97.27.242，还在上海。
10
第十个节点：出国了，美国加利福尼亚州。
前面的咱就不看了，就是在美国境内各个节点的转发了。
接下来看一下，这是一条什么样的门路呢？
ChinaNet
网络数据包出了咱们本地的局域网后，就会通过电信运营商提供的城域网最终接入到更大的骨干网。
中国大陆地区的民用骨干网次要有四个：
ChinaNet：中国电信 163 骨干网
CN2：中国电信下一代承载网
CHINA169：中国联通 169 骨干网
CMNET：中国移动骨干网
其中中国电信的 163 骨干网和中国联通的 169 骨干网是最次要的两个骨干网，承载了中国互联网绝大多数的流量。
我所在的网络，最初接入的就是中国电信的 163 骨干网，上面是 163 骨干网的一个大抵网络拓扑图。
163 骨干网在全国总共有 9 个外围节点：
超级外围：北京、上海、广州
一般外围：天津、西安、南京、杭州、武汉、成都
9 个外围节点各自负责中国大陆的一部分区域。
在北京、上海、广州三个超级外围下还挂有国内网间互联设施（X 路由器），ChinaNet 通过 X 路由器与世界上其余运营商互联和流量互访。
因而，通过 163 网络出国，必然通过北上广三个外围节点之一。
GitHub 的服务器位于美国，对于一个要出国的数据包，它在出国前的大抵旅程是这样的：
本地局域网 -> 市级网络 -> 省级网络 -> 外围节点 -> 国内进口 -> 境外接入点
这个过程跟咱们下面 tracert 追踪到的门路是吻合的。
想不到吧，就那么一回车，数据包居然就跑了这么多中央，计算机网络真是一个神奇的玩意。
【配套技术文档】