Sent a data packet to xxxhub and found some ulterior secrets

Hello everyone, this is Jay Chou.

That day, I suddenly thought of a question:

When I visited the GitHub that fascinated thousands of otaku programmers, how did the data packets sent by my computer reach the GitHub server on the other side of the ocean, and what nodes did it pass through?

Let us explore this problem together, please pay attention to fasten your seat belts, the computer network express is about to start...

IP message

The Internet connects countless mobile phones, computers, servers, routers, switches and other devices together. If these devices communicate through the network, a set of communication protocols is naturally needed. TCP/IP is such a set of protocols.

The data sent by these applications, including browsers, are encapsulated by HTTP, TCP, and IP protocol layers, and finally form individual IP packets, which are sent to the underlying network card.

The IP packets are continuously routed and forwarded by nodes in the network, and finally arrive at the target server.

So how do you know which network nodes have passed during the routing and forwarding process?

tracert program on Windows and the traceroute program on Linux can do it.

How do they do it?

IP packets can't be forwarded indefinitely. What if you do a loop forwarding, wouldn't it be endless? The IP message in the network has a concept of time to live, which is located in the header field of the IP message——

TTL：time to live。

After each forwarding, the value of TTL will be reduced by 1. If a certain node finds that the TTL has become 0, it will discard the IP packet and send a timeout notification message to the sender of the data packet.

Tracert and traceroute take advantage of this feature in the IP protocol. The TTL value is incremented from 1. Observing who sent this notification back to yourself can determine which nodes have been experienced during the routing process.

The difference between these two programs is that tracert sends ICMP packets, while traceroute sends UDP packets.

Trace route

Well, the basic knowledge is explained, let's try it quickly and visit the situation of GitHub.

First I pinged and got the IP address of GitHub: 140.80.121.3. Note that this address may be different for people in different regions.

Next, let's trace the route:

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]

It can be seen that after the forwarding of 26 nodes, it finally reached the GitHub server. In other words, the TTL of the IP message sent by your computer must be at least 26 to reach GitHub, otherwise it will fall apart.

[Supporting technical documents]

Next, let's take a look, where did all the way go?

1-2

After the data packet is sent from my computer, the first forwarding node encountered is my local LAN gateway: 10.??.??.1. For security, I desensitized the IP address and replaced the middle two paragraphs with ?.

After this, the second node is still the address of the local area network. It can be seen that the network structure where I am is only connected to the public network after two levels of local area network routing and forwarding.

3

The third forwarding node is a public network address: 182.150.63.1. I checked it and found that it is located in the Wuhou District of Chengdu, which is consistent with my actual situation.

4

The next fourth routing node is a bit fascinating, all three time points are *, and tracert shows that the request has timed out. The appearance of this means that the tracert program did not receive a notification after setting the TTL to 4, or it waited too long. Some nodes in the network may not send timeout notifications for security reasons.

In this way, tracert cannot know who the fourth node is.

5

The fifth node is: 171.208.199.81, still in Chengdu.

6

At the sixth node: 202.97.29.45, we have arrived in Beijing.

[Supporting technical documents]

7

The seventh node is the same as the fourth, and can't be seen.

8

The eighth node: 202.97.91.190, came to Shanghai.

9

The ninth node: 202.97.27.242, still in Shanghai.

10

The tenth node: I went abroad, California, USA.

Let’s not look at the rest, which is the forwarding of each node in the United States.

Let's take a look next, what kind of path is this?

ChinaNet

After the network data packet leaves our local local area network, it will finally be connected to the larger backbone network through the metropolitan area network provided by the telecom operator.

There are four main civil backbone networks in mainland China:

    ChinaNet：中国电信163骨干网
    CN2：中国电信下一代承载网
    CHINA169：中国联通169骨干网
    CMNET：中国移动骨干网

Among them, China Telecom's 163 backbone network and China Unicom's 169 backbone network are the two most important backbone networks, which carry most of China's Internet traffic.

The network I was in was finally connected to the 163 backbone network of China Telecom. The following is a rough network topology diagram of the 163 backbone network.

The 163 backbone network has a total of 9 core nodes in the country:

    超级核心：北京、上海、广州
    普通核心：天津、西安、南京、杭州、武汉、成都

Each of the 9 core nodes is responsible for a part of mainland China.

Under the three super cores of Beijing, Shanghai, and Guangzhou, there are also international interconnection equipment (X routers). ChinaNet uses X routers to interconnect and communicate with other operators in the world.

Therefore, going abroad through the 163 network must pass through one of the three core nodes of Beijing, Shanghai, and Guangzhou.

GitHub's server is located in the United States. For a data package going abroad, its approximate journey before going abroad is as follows:

Local Area Network -> Municipal Network -> Provincial Network -> Core Node -> International Export -> Overseas Access Point

This process is consistent with the path traced by tracert above.

Unexpectedly, as soon as you enter the car, the data packets go to so many places. The computer network is really a magical thing.

[Supporting technical documents]