向xxxhub发了一个数据包，发现了···
那天，我突然想到一个问题：
当我访问那个让万千宅男程序员为之着迷的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追踪到的路径是吻合的。
想不到吧，就那么一回车，数据包竟然就跑了这么多地方，计算机网络真是一个神奇的玩意。
各位伙伴们好，詹帅本帅搭建了一个个人博客和小程序，汇集各种干货和资源，也方便大家阅读，感兴趣的小伙伴请移步小程序体验一下哦！（欢迎提建议）
推荐阅读
推荐阅读