那天，我突然想到一個問題：

當我訪問那個讓萬千宅男程序員為之著迷的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.??.??.12????<1?毫秒???<1?毫秒???<1?毫秒?10.??.??.??3?????2?ms?????1?ms?????1?ms??182.150.63.14 ????*????????*????????*?????請求超時。5?????1?ms?????*????????2?ms??171.208.199.816?????*???????25?ms?????*?????202.97.29.457 ????*????????*????????*?????請求超時。8????36?ms????37?ms????36?ms??202.97.91.1909???184?ms???191?ms???185?ms??202.97.27.24210???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.3124 ????*????????*????????*?????請求超時。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追蹤到的路徑是吻合的。

想不到吧，就那么一回車，數據包竟然就跑了這么多地方，計算機網絡真是一個神奇的玩意。

各位伙伴們好，詹帥本帥搭建了一個個人博客和小程序，匯集各種干貨和資源，也方便大家閱讀，感興趣的小伙伴請移步小程序體驗一下哦！（歡迎提建議）

推薦閱讀

牛逼！Python常用數據類型的基本操作（長文系列第①篇）

牛逼！Python的判斷、循環和各種表達式（長文系列第②篇）

牛逼！Python函數和文件操作（長文系列第③篇）

牛逼！Python錯誤、異常和模塊（長文系列第④篇）

總結

以上是生活随笔為你收集整理的向xxxhub发了一个数据包，发现了···的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。