The Complete Flowchart of Network Communication

Introduction

#

Let’s say, you type “anishpant.com.np” and press Enter. What happens next? How does your computer know where to get to get the website from?

→ It has to perform carefully planned series of steps to fetch the website for you. Let’s break down this complex process:

Step 1: Getting an Address (DHCP)

#

Every device needs an IP address (including subnet mask and default gateway) before it can communicate to the internet. Manual IP assignment isn’t practical for most environments, especially where devices frequently join and leave the network.

That’s where DHCP (Dynamic Host Configuration Protocol) comes in. It automatically assigns the necessary network details to your device.

DHCP Process

#

DHCP works in four steps:

1. DHCP Discover

   • The client sends a broadcast message to 255.255.255.255 asking for a network address.
   • It uses source IP 0.0.0.0 because it doesn’t have an address yet.
   • It includes its MAC address for identification.

2. DHCP Offer

   • A DHCP server replies with an available IP address.
   • It also includes the subnet mask, default gateway, DNS servers, and lease time.
   • If multiple servers are available, more than one might respond.

3. DHCP Request

   • The client sends a request to accept one of the offers.
   • This is broadcast so all DHCP servers know which offer was accepted.

4. DHCP Acknowledgment (ACK)

   • The selected server confirms and finalizes the lease.
   • The client configures its network settings and starts using the IP address.

Things to Know

#

• Lease Renewal: The client tries to renew the lease halfway through its duration.
• Redundancy: Large networks may use multiple DHCP servers for failover.
• Reservations: Important devices can be assigned fixed IPs using MAC address bindings.

Step 2: Resolving the Domain (DNS)

#

We use domain names, but computers need IP addresses to communicate. The DNS is responsible for translating those domain names into IP addresses.

How DNS Resolution Works

#

When you visit a new website, your system follows this sequence:

1. Check Local Cache

#

Before going to the internet, your system looks for saved DNS information:

• Browser Cache

  • Some browsers save recently used DNS entries.
  • (In Chrome: chrome://net-internals/#dns)

• OS Cache

  • Your operating system also stores DNS entries temporarily.
  • (In Windows, you can check this using ipconfig /displaydns)

• Hosts File

  • A manual file that maps hostnames to IPs.
  • Located at C:\Windows\System32\drivers\etc\hosts.

2. Ask a DNS Server

#

If nothing is found locally, your system asks a recursive DNS resolver—usually from your ISP or a public provider like:

• Google DNS → 8.8.8.8
• Cloudflare DNS → 1.1.1.1

These queries usually use UDP port 53, unless the response is too large (then it switches to TCP).

The resolver follows a process like this:

graph LR
A[Recursive Resolver] --> B[Root Server]
B --> C[TLD Server (.com)]
C --> D[Authoritative Server]
D --> A

This process is iterative, meaning the resolver contacts each server level one by one.

3. Get the Answer

#

After getting a response, the DNS resolver returns the correct IP address for the website, and your device can now reach the web server.

Common DNS Record Types

#

• A → IPv4 address
• AAAA → IPv6 address
• CNAME → Alias to another domain
• MX → Mail server info
• TXT → Miscellaneous info (e.g., domain verification)

Step 3: Finding the Gateway’s MAC (ARP)

#

Once your computer knows the IP address of the destination website (e.g., 142.250.190.46 for google.com), it still can’t send the packet right away. That’s because at the link layer (Ethernet or Wi-Fi), communication happens using MAC addresses, not IPs.

But here’s the catch: that IP address belongs to a remote server on the internet. Your device can’t reach it directly—it has to go through your default gateway (usually your router).

To send the packet to the gateway, your device needs the gateway’s MAC address.

How ARP Works

#

The protocol responsible for mapping IP addresses to MAC addresses is called ARP (Address Resolution Protocol).

1. Your device checks its ARP cache to see if it already knows the MAC address of the gateway IP (e.g., 192.168.1.1).

2. If not, it sends a broadcast on the local network:

   Who has 192.168.1.1? Tell 192.168.1.100
   

3. The router replies:

   192.168.1.1 is at AA:BB:CC:DD:EE:FF
   

4. Now your device knows where to send the packet on the local network.

ARP works only within a local network. Beyond the gateway, MAC addresses are no longer relevant.

Step 4: Leaving the LAN – Routing & NAT

#

Now that your device knows the MAC address of the gateway, it sends the packet to the router. From there, the packet is prepared to leave your local network and travel across the internet.

But there’s one more important step before that: NAT.

What is NAT?

#

Most home and office networks use private IP addresses (e.g., 192.168.x.x, 10.x.x.x). These addresses aren’t routable on the internet.

The router uses Network Address Translation (NAT) to convert your internal (private) IP into a public IP—the one assigned by your ISP.

For example:

Your PC:     192.168.1.100:54321  
Router NAT: 203.0.113.42:49100  

The router keeps a mapping of these connections so it knows how to forward the response back to the correct device.

Next Hop: ISP and Beyond

#

Once NAT is done, your router sends the packet out through your WAN interface, forwarding it to your ISP’s network, and from there it travels through various routers on the internet until it reaches the destination server.

The destination server doesn’t see your local IP (192.168.1.100). It sees your router’s public IP (203.0.113.42).

Step 5: Establishing a Connection (TCP Handshake)

#

By this point, your packet has traveled through your router, crossed your ISP, and reached the destination server’s network.

But before any actual data (like a webpage) can be exchanged, your computer needs to set up a reliable connection with the server.

This is where TCP (Transmission Control Protocol) comes in.

Why TCP?

#

TCP ensures that:

• Data is delivered in the correct order
• Lost packets are retransmitted
• Both ends agree on when communication starts and ends

This reliability makes TCP ideal for things like web browsing, where missing or jumbled data would break the page.

The 3-Way Handshake

#

To start the connection, TCP uses a three-step process:

1. SYN – Your computer sends a synchronize (SYN) message to the server, asking to start a conversation.

2. SYN-ACK – The server replies with a SYN-ACK, acknowledging the request and offering to connect.

3. ACK – Your computer sends a final ACK to confirm.

Client → SYN → Server  
Server → SYN-ACK → Client  
Client → ACK → Server

Once this handshake is done, the connection is open and ready to send or receive data.

Port Numbers: Web traffic usually uses port 80 for HTTP and port 443 for HTTPS.

Step 6: Securing the Connection (TLS Handshake)

#

Today, most websites use HTTPS, not plain HTTP. The extra “S” stands for Secure—and that security is provided by TLS (Transport Layer Security).

Before any sensitive information is sent (like login credentials or cookies), your browser and the server must agree on how to encrypt the communication.

This happens through the TLS handshake, right after the TCP handshake.

What Happens During the TLS Handshake?

#

Here’s a simplified version of the process:

1. ClientHello – Your browser sends a list of supported encryption algorithms (ciphers) and some random data used for encryption.

2. ServerHello – The server responds with:

   • Its digital certificate (proving its identity)
   • A chosen cipher
   • Its own random data

3. Key Exchange – Both sides securely agree on a shared encryption key, often using Diffie-Hellman or a similar method.

4. Secure Session Begins – From this point on, all communication is encrypted.

Client → ClientHello  
Server → ServerHello + Certificate  
→ Key Exchange →  
Encrypted Session Starts

Certificate Validation: Your browser checks if the server’s certificate is valid and trusted. If not, you’ll see a warning like “Your connection is not private.”

Read more about certificates in this post: What exactly is a Digital Certificate?.

Step 7: Sending the Request (HTTP/HTTPS)

#

Now that the connection is secure, your browser finally sends the actual HTTP request—this is where it asks for the webpage you typed.

Your browser typically sends a request like this:

GET / HTTP/1.1  
Host: google.com  
User-Agent: Mozilla/5.0 (...)  
Accept: text/html  

This tells the server:

• Which page you want (/)
• Which domain you’re referring to (google.com)
• What kind of content your browser can handle

Because we’re using HTTPS, this request is encrypted, so no one in between (like your ISP) can read it.

Read: HTTP and HTTPS: Understanding the Key Differences.

What Comes Back?

#

The server responds with:

• A status code (e.g., 200 OK, 404 Not Found)
• The HTML, CSS, JavaScript, and images needed to render the webpage
• Optional headers like caching rules or cookies

The browser then parses this response and starts rendering the page, possibly repeating the request process for additional resources like fonts, images, or APIs.

Note: All of this → request, response, rendering — happens in milliseconds.

Summary: From Browser to Internet in 7 Steps

#

Here’s the breakdown of each steps:

Conclusion

#

The next time you hit Enter after typing a URL, remember: it’s not a single step—it’s a finely tuned chain reaction.

Your device negotiates an IP, asks DNS where to go, uses ARP to find a way out, relies on routers to navigate the internet, and finally sets up secure, structured communication just to get a simple webpage.