In the first part of this three part series on networking layers, I showed you everything you need to know about the Physical, Data Link, and Network layers. You also learned the the differences between hubs and switches. We closed out the article with the inside scoop on IP addresses.
Today I’m going to show you one thing:
- How it all fits together!
Let’s jump in!
Bringing everything together
So how does network communication really work?
I’ve showed you bits and pieces but now we need to zoom out and look at the big picture.
When two computers live on the same street they are said to be on the same LAN (Local Area Network). Hosts can communicate with other hosts on the same LAN by sending frames directly to each other. There’s no need to get a router involved; the switch simply does a super fast table lookup, finds which port the device lives on and shoots the frame along at lightning speed.
In the example below you can see hosts with the MAC addresses A, B, and C live on a street (network) called 10.0.2.0.
The real magic happens when two hosts live on two different networks.
Pulling back the curtain
When you type in fixedbyvonnie.com it probably says “Error connecting to Database”
haha, okay let me stop bashing my own website.
Normally, when you enter fixedbyvonnie.com, the page displays in a few seconds but here’s the questions:
What’s really happening behind the scenes?
First, your computer tries to figure out the layer 3 IP address of fixedbyvonnie.com. fixedbyvonnie.com is a webserver with an IP address so your computer needs to know the IP address of my website before it can send the homepage request.
Let’s assume your computer has the following IP information:
- Host IP: 10.0.2.15
- Subnet Mask: 255.255.255.0 (I’ll explain masks in a future tutorial)
- Default Gateway: 10.0.2.1
- DNS: 184.108.40.206
And let’s say fixedbyvonnie.com is really 220.127.116.11.
Resolve the hostname to an IP address
Your PC says:
My DNS is 18.104.22.168 but my host IP is 10.0.2.15 so we don’t live on the same network. Hmm… I’ll ask everyone on the LAN for the MAC address of my default gateway. I don’t know how to get to 22.214.171.124 but my default gateway probably knows a router that does.
So your computer sends out what’s known as an ARP broadcast so that it can find the default gateway. ARP stands for the Address Resolution Protocol and it’s a layer 2 protocol that resolves IP Addresses to MAC addresses.
For example, when you enter fixedbyvonnie.com in Google Chrome, your NIC sends an ARP frame with your computers physical address as the source MAC but with a destination MAC address of all F’s (which are all ones in binary but we’ll talk about that later):
This just means: Send the frame to every host on the LAN
So every host on the LAN gets the frame but only the default gateway router responds with his MAC address.
Next, your computer makes a DNS request to 126.96.36.199 and your computer forwards the request to the default router which sends it along through the internet (using a process I’m about to describe)
The DNS server replies with what’s known as Type A record which returns the IP address assigned to the fixedbyvonnie.com domain name. In our case, the DNS reply contains an A record for 188.8.131.52.
Next your host completes what’s known as a TCP three-way handshake with the server. I won’t get into the details yet but just know that the three-way handshake is how TCP/IP ensures the reliable delivery of information.
It all starts at the Application Layer
Alright, so now we know the IP address of the webserver thanks to DNS.
Here’s the setup:
The moment you popped open Chrome and typed http://www.fixedbyvonnie.com/, the HTTP service took over the web request in the Application Layer. DNS resolved the hostname to an IP address and then HTTP passed the protocol data unit (PDU) down to the Transport layer.
At the Transport Layer your computer says:
I see this is a HTTP request so I’ll use TCP to guarantee delivery. Also I know that most webservers listen on TCP port 80 so I’ll put that port in the destination field of my TCP header.
The segment moves down the TCP/IP stack on your computer and gets swallowed up by the Network layer header. The Network layer looks at the segment and says:
The source IP will be 10.0.2.15 which is the IP address of the sending computer and the destination address will be 184.108.40.206, which is the IP address I got from DNS.
The Network layer mashes this header on the TCP segment and passes the packet down to the Data Link layer.
At Layer 2 the computer says:
I’m on 10.0.2.0 street but the webserver is on 220.127.116.11 street. We’re in two different streets so I know the webserver is not in my LAN. I need to forward this request to my default gateway so I can get off the local network and into the interwebs.
The default gateway receives the frame, de-encapsulates it and checks out the physical address.
Ahh, the frame is destined to me! Cool, but what’s the IP address? That tells me the ultimate destination.
Next, the default gateway looks at the layer 3 IP address:
The destination IP address is 18.104.22.168 which doesn’t belong to me but I know the best path to the network where that host lives. I’ll forward it to the MAC address of the next hop router.
Router 2 gets the bits, reassembles the frames, checks out the source MAC address and instantly realizes:
Hey! This frame is for me. Where is the final destination?
After chopping off the Ethernet header and trailer it peals back the layer 3 destination IP address.
Ah ha! So this packet is going to the web server that’s directly connected to my gi1/0 interface
Router 2 encapsulates the packet, slaps on the layer 2 destination address of the webserver 00:00:dd and forwards the packet to the switch.
When the switch gets it it says:
I know which layer 2 addresses live off all my switchports. You want to send it out the port that’s connected to MAC address 00:00:dd? Alright, hang on tight! I can do that!
So the bits race along port 2 and enter the NIC of the fixedbyvonnie.com webserver. When the bits arrive, the NIC sees the destination MAC address matches his MAC address. Then it passes the frame up to layer 3 and sees the layer 3 IP address also matches his IP address.
The server passes the packet up to layer 4 and notices the destination port is for port 80 which it just happens to be listening for incoming connections on! Different applications listen on different ports so when data enters the computer, it knows which application to send it to. Port 80 is a well-known port for webservers so there is no guessing here.
Next, the TCP/IP request is received by the HTTP protocol running at the Application Layer – and BAM!
That’s how network communication works.
When the webserver sends the reply with the requested webpage; the entire process repeats itself in reverse.
The server encapsulates the reply down through the TCP/IP layers and forwards it to the switch. The switch makes a forwarding decision based on the layer 2 information and sends the frame to Router 2.
Router 2 de-encapsulates the frame, checks out the layer 3 information and forwards the packet to Router 1.
Router 1 does the same thing and sends it to our computer which de-encapsulates it up the TCP/IP stack until it arrives back in the Application Layer in your browser.
The Bottom Line
Network communication isn’t so difficult when you take the time to break down the process.
In the last part of our series I’ll show you real packet captures from a HTTP request to fixedbyvonnie.com. We’re going to dive into the nitty details of the headers and see exactly what’s happening under the hood.
I can’t wait to see you here tomorrow.