向xxxhub發了一個資料包,發現了一些不可告人的祕密

程式碼熬夜敲發表於2022-01-08

大家好,我是周杰倫。

那天,我突然想到一個問題:

當我訪問那個讓萬千宅男程式設計師為之著迷的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追蹤到的路徑是吻合的。

想不到吧,就那麼一回車,資料包竟然就跑了這麼多地方,計算機網路真是一個神奇的玩意。

【配套技術文件】

相關文章