大家好，我是周杰倫。
那天，我突然想到一個問題：
當我訪問那個讓萬千宅男程式設計師為之著迷的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追蹤到的路徑是吻合的。
想不到吧，就那麼一回車，資料包竟然就跑了這麼多地方，計算機網路真是一個神奇的玩意。