Перейти до вмісту
Networking 101 #2. How the Internet actually works
Source: Dev.to | Jan 13, 2026 (UTC)
👋 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:
- Why DevOps engineers should care about networking
- The core networking mental model
- DNS, IP addresses, and ports
- TCP vs UDP
- ICMP vs TCP vs HTTP
- A practical debugging flow
- Hands-on commands to make networking real
📂 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)
- Client: “Can I connect?”
- Server: “Yes”
- Client: “Okay, let’s talk”
This is why TCP is called connection-based.
If this step fails, you’ll see errors like:
Connection refusedConnection 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:
- The OS receives the packet
- TCP hands data to the application
- Web server (Nginx, Node, etc.) processes it
- Application logic runs
- 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
For further actions, you may consider blocking this person and/or reporting abuse
Залишити відповідь