向xxxhub发了一个数据包，发现了一些不可告人的秘密
source link: https://segmentfault.com/a/1190000041243687
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
向xxxhub发了一个数据包，发现了一些不可告人的秘密
大家好，我是周杰伦。
那天，我突然想到一个问题：
当我访问那个让万千宅男程序员为之着迷的GitHub时，我电脑发出的数据包是如何抵达大洋彼岸的GitHub服务器的呢，这中间又要经过哪些节点呢？
让我们一起来探究下这个问题，请注意系好安全带，计算机网络快车要发车了···
互联网把无数的手机、电脑、服务器、路由器、交换机等各种设备连接在一块儿，那这些设备之间要通过网络通信，自然就需要一套通信协议，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，否则就会中道崩殂。
接下来，咱们来看一下，这一路都去了哪里？
数据包从我的计算机发出后，遇到的第一个转发节点就是我的本地局域网网关：10.??.??.1。为了安全性，我把IP地址进行了脱敏，中间两段用?代替。
这之后第二个节点还是局域网的地址，由此可见，我所在的网络格局，经过了两级局域网路由转发才上了公网。
第三个转发节点是一个公网地址：182.150.63.1，查了一下发现位于成都市武侯区，这和我的实际情况相符。
接下来的第四个路由节点就有点迷了，三个时间点都是*，tracert显示请求超时。出现这个意味着tracert程序在将TTL设置为4后，没有收到通知，或者等待的时间太久。网络中的有一些节点出于安全考虑可能并不会发送超时通知。
如此一来，tracert便无法知道这第四个节点到底是谁。
第五个节点是：171.208.199.81，仍然还在成都。
第六个节点时：202.97.29.45，到了北京了。
第七个节点和第四个一样，也看不到。
第八个节点：202.97.91.190，来到上海了。
第九个节点：202.97.27.242，还在上海。
第十个节点：出国了，美国加利福尼亚州。
后面的咱就不看了，就是在美国境内各个节点的转发了。
接下来看一下，这是一条什么样的路径呢？
ChinaNet
网络数据包出了咱们本地的局域网后，就会通过电信运营商提供的城域网最终接入到更大的骨干网。
中国大陆地区的民用骨干网主要有四个：
ChinaNet：中国电信163骨干网
CN2：中国电信下一代承载网
CHINA169：中国联通169骨干网
CMNET：中国移动骨干网
其中中国电信的163骨干网和中国联通的169骨干网是最主要的两个骨干网，承载了中国互联网绝大多数的流量。
我所在的网络，最后接入的就是中国电信的163骨干网，下面是163骨干网的一个大致网络拓扑图。
163骨干网在全国总共有9个核心节点：
超级核心：北京、上海、广州
普通核心：天津、西安、南京、杭州、武汉、成都
9个核心节点各自负责中国大陆的一部分区域。
在北京、上海、广州三个超级核心下还挂有国际网间互联设备（X路由器） ，ChinaNet通过X路由器与世界上其他运营商互联和流量互访。
因此，通过163网络出国，必然经过北上广三个核心节点之一。
GitHub的服务器位于美国，对于一个要出国的数据包，它在出国前的大致旅程是这样的：
本地局域网 -> 市级网络 -> 省级网络 -> 核心节点 -> 国际出口 -> 境外接入点
这个过程跟我们上面tracert追踪到的路径是吻合的。
想不到吧，就那么一回车，数据包竟然就跑了这么多地方，计算机网络真是一个神奇的玩意。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK