What is the Internet?
Internet is a large hierarchical network of devices talking to each other. The devices that reside at the edge of the Internet are called hosts. The devices at the center are a bunch of interconnected packet switches, including switches and routers. Those devices rely on protocols to talk to each other.
Together, those devices form groups of networks. And those networks are interconnected to create a larger network. The links between them can be either wired or wireless. They form a very complex infrastructure for daily applications to operate. They facilitate the development of modern and convenient services such as instant messaging, video streaming, social media, etc.
How do devices communicate on Internet?
When two processes on the same host communicate, they rely on inter-process communication mechanisms provided by the OS. However, the communication between two processes on two different hosts is different. They need to use messages to talk to each other. And those messages need to be passed around the Internet.
A typical way to model the networking system is to use the five layers TCP/IP model. From the top to the bottom, we have the application layer, transport layer, network layer, link layer, and physical layers. Each layer has a separate consideration, with a different set of protocols, and is often stacked together to make protocol stacks.
Those stacks are the things that empower the Internet. If an application on one machine needs to send the message to another application that resides on a different machine, that message should travel from the application layer, transport layer, network layer, link layer, and physical layer. From that layer, it will be bit by bit transmitted to the other host's physical layer and then travels back to the application layer in the reverse manner.
What happened behind the scene when we browse for somesite.com?
Notes: somesite.com is just an arbitrary domain name. I assume that there is a web server running behind that domain name.
When you enter somesite.com in your browser, you'll get a homepage of that website. The server of that website has done an amazing job to serves our request in just a second. But there are lots of things that happened behind the scene.
The very first thing is DNS lookup. We can imagine that somesite.com is like a person's name. If we know a name of a person, we cannot send them letters. We need to know their address. Similarly, on the Internet, we also have what is called an IP address. The IP address of somesite.com is kept in some DNS servers, and we need to send the query to those servers to get the address.
There are a lot of DNS servers around the world. And they form a hierarchical structure. On the top, we have root DNS servers. Then at the lower level is top-level domain servers, authoritative servers, and local DNS servers.
Our local machine might keep a cache of the recent DNS queries. But in case there is a cache miss, we might send the query to the local DNS server to get the IP address. Wait! How do we know the IP address of the local DNS server? Don't worry, it is often configured on our machines when we first set up the Internet.
At that time, the local DNS might or might not have that address. If it doesn't, it will act on our behalf to send the query to some root server. Then, that root server might return the address of somesite.com, or it will return the address of another server who might know that address (usually the .com top-level domain servers). And the local DNS server needs to send queries back and forth until it reaches the server that contains the IP address of somesite.com.
And we've done so many things just to know the destination that we are going to send. At this time, our browser will open a TCP connection to the destination IP address on port 443 (this article gives a interesting discussion on what does it mean to listen on a port). Notice that we assume somesite.com supports HTTPS. The details of this connection are far more complicated since a couple of packets will be sent back and forth to make sure both parties acknowledge each other.
After the TCP handshake (sending packets to open the connection), we still have the TLS handshake to make. TLS is a protocol used to secure the data being transmitted. At the end of this handshake, your browser and web server have the same session key that is used to encrypt and decrypt the message.
After TLS, the browser can officially send the GET HTTP request, which is then encrypted by TLS before passing to the TCP socket. HTTP is an application layer protocol, and TCP is a transport layer protocol. Once the message goes to the hand of the TCP socket, it will be the job of TCP to make sure that data will reach the TCP socket on the somesite.com server-side. Then, the somesite.com server will return the HTTP response, which contains the HTML page to be rendered.
Then the communication keeps going on. The browser may also request CSS files, JS files, or a couple of other requests, and the server replies to them with different responses. After they think that they have talked enough, there is also a ritual they need to follow to terminate the TCP connection.
Anything else?
We have just finished probably the simplest journey over the network. There are lots of things that I haven't covered yet. What happened if the transmission message is lost? What happened when the traffic is too busy? How messages from one computer can find their way to another computer that is thousands of miles away? How data can be transmitted in a wireless environment?
There are a lot of interesting problems along the way when people try to make computers talk together. They rely on some fundamentals (say, TCP/IP layer model), and offer enough flexibility for further improvement (the way they replace TCP by UDP in HTTP/3 stack). It's the reason why learning about the Internet is so much fun. But there is one thing for sure, people always try to make things better, and I believe the Internet is getting far better than it used to be.
Top comments (0)