DEV Community

Cover image for Networking 101 #2. How the Internet actually works
Himanshu Bhatt
Himanshu Bhatt

Posted on

Networking 101 #2. How the Internet actually works

#devops #networking #cloud #beginners

👋 Short Intro (Why I’m Writing This)

I’m currently learning Networking for DevOps and decided to learn in public by documenting my journey.

This blog is part of my Networking 101 series, where I’m learning Networking for DevOps step by step from scratch.

This series is not written by an expert — it’s a beginner learning out loud, sharing:

  • what I understand,
  • what confuses me,
  • and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

  • How DNS works
  • TCP Connection & TCP Handshake
  • TLS Brief Overview
  • Complete Request Response Flow

📂 GitHub Repository

All my notes, diagrams, and learning resources for this series live here:

👉 GitHub Repo:

https://github.com/dmz-v-x/networking-for-devops-101

This repo is updated as I continue learning.

📚 Learning Notes

1. Consider this scenario:

Let's say i want to visit a website:

https://myapp.com
Enter fullscreen mode Exit fullscreen mode

and then i press Enter.

Let’s follow this request from start to finish.

Step 0: What does your browser actually need?

Your browser cannot talk to:

  • Domain names
  • Applications
  • Containers
  • Kubernetes

Your browser only knows how to talk to:

  • IP addresses
  • Ports
  • Using TCP

So the browser’s first question is:

“What IP address should I connect to?”

That’s where DNS comes in.

Step 1: DNS — Converting Domain name → IP

From Part 1:

DNS is the phonebook of the internet.

Your browser asks the operating system:

“Do you know the IP for myapp.com?”

Possible outcomes:

Case 1: DNS cache hit

If your system already knows the IP (cached):

  • No network request needed
  • Faster response

Case 2: DNS cache miss

Your system asks:

  • DNS resolver
  • Which asks other DNS servers
  • Until it gets an IP address

Eventually, you get something like:

myapp.com → 13.234.56.78
Enter fullscreen mode Exit fullscreen mode

If DNS fails → everything stops here

Step 2: Choosing the port (HTTP vs HTTPS)

You typed:

https://myapp.com
Enter fullscreen mode Exit fullscreen mode

That https matters.

It tells the browser:

  • Use port 443
  • Use encrypted communication

If it were:

  • http:// → port 80
  • https:// → port 443

So now the browser knows:

IP:   13.234.56.78
Port: 443
Enter fullscreen mode Exit fullscreen mode

Step 3: TCP connection (very important)

Before any data is sent, TCP does something crucial.

TCP Handshake (conceptual)

  1. Client: “Can I connect?”
  2. Server: “Yes”
  3. Client: “Okay, let’s talk”

This is why TCP is called connection-based.

If this step fails, you’ll see errors like:

  • Connection refused
  • Connection timed out

This usually means:

  • Firewall blocked it
  • Port not open
  • Service not running

Step 4: TLS (HTTPS security layer)

Because this is HTTPS, another step happens.

The browser and server:

  • Agree on encryption
  • Exchange certificates
  • Set up a secure channel

If TLS fails, you’ll see:

  • “Your connection is not private”
  • Certificate errors

DevOps engineers see this often when:

  • Certs expire
  • Domains don’t match
  • Load balancers misconfigured

Step 5: HTTP request is finally sent

Only now does the browser send the request:

GET / HTTP/1.1
Host: myapp.com
Enter fullscreen mode Exit fullscreen mode

Important:

  • HTTP is inside TCP
  • TCP is inside IP
  • IP is inside the network

Think of it like nested boxes.

Step 6: The request reaches the server

On the server side:

  1. The OS receives the packet
  2. TCP hands data to the application
  3. Web server (Nginx, Node, etc.) processes it
  4. Application logic runs
  5. A response is created

Example response:

HTTP/1.1 200 OK
Enter fullscreen mode Exit fullscreen mode

Step 7: The response travels back

The response:

  • Goes back through TCP
  • Over the network
  • To your browser

Your browser:

  • Parses HTML
  • Loads CSS/JS
  • Makes more requests (repeat steps!)

One page load = many network requests

Full flow (one glance view) 

Browser
  ↓
DNS (name → IP)
  ↓
TCP connection
  ↓
TLS handshake (HTTPS)
  ↓
HTTP request
  ↓
Server processing
  ↓
HTTP response
  ↓
Browser renders page
Enter fullscreen mode Exit fullscreen mode

This is the core internet flow.

Everything else in DevOps builds on this.

Where things usually break (DevOps view)

Step Common Failure
DNS Wrong record, cache issues
TCP Port closed, firewall
TLS Expired certificate
HTTP 500 errors
Server App crash, timeout

📌 Debug top to bottom, never randomly.

Commands mapped to each step

Step Command
DNS dig, nslookup
Reachability ping
TCP nc, telnet
HTTP curl
TLS curl -v, browser errors

You now know why these commands exist.

✅ Key takeaways

  • Browsers don’t talk to apps — they talk to IPs & ports
  • DNS happens before any network connection
  • TCP connection must succeed before HTTP
  • HTTPS adds a security layer on top
  • Every failure maps to a specific step

💬 Feedback & Discussion

💡 I’d love your feedback!

If you notice:

  • missing tool categories,
  • incorrect assumptions,
  • or better learning paths,

please comment below. I’m here to learn.

⭐ Support the Learning Journey

If you found this blog useful:

⭐ Consider giving the GitHub repo a star —

it really motivates me to keep learning and sharing publicly.

🐦 Stay Updated (Twitter / X)

I share learning updates, notes, and progress regularly.

👉 Follow me on Twitter/X:

https://x.com/_himanshubhatt1

🔜 What’s Next

In the next post, I’ll be covering:

👉 IP Addresses & Ports

I’ll also continue updating the GitHub repo as I progress.

📘 Learning in public

📂 Repo: https://github.com/dmz-v-x/networking-for-devops-101
🐦 Twitter/X: https://x.com/_himanshubhatt1
💬 Feedback welcome — please comment if anything feels off
⭐ Star the repo if you find it useful

Top comments (0)