Networking 101 #2. How the Internet actually works

Source: Dev.to

Short intro (why I’m writing this)

I’m learning networking for DevOps and documenting the journey publicly. This post is part of the Networking 101 series, written from a beginner’s perspective. I’ll share what I understand, what confuses me, and what I learn along the way.

Why DevOps engineers should care about networking

• Network reliability directly impacts deployment pipelines, service discovery, and observability.
• Mis‑configured DNS, firewalls, or TLS certificates are common causes of production incidents.
• Understanding the end‑to‑end request flow helps you troubleshoot faster and design more resilient architectures.

Core networking mental model

From a browser request to a server response

1. User types a URL – e.g. https://myapp.com and presses Enter.

2. DNS resolution – the browser asks the OS for the IP address of myapp.com.

   • If cached, the OS returns the IP immediately.
   • Otherwise the OS queries a DNS resolver, which walks the DNS hierarchy until it receives an address (e.g. 13.234.56.78).
   • If DNS fails, the request stops here.

3. Port selection – the scheme determines the port:

   • http:// → port 80
   • https:// → port 443 (encrypted)

4. TCP handshake – the client initiates a connection:

   SYN → Server
   SYN‑ACK ← Server
   ACK → Server

   If this step fails you’ll see errors such as Connection refused or Connection timed out (often caused by firewalls, closed ports, or stopped services).

5. TLS handshake (only for HTTPS) – the client and server negotiate encryption, exchange certificates, and establish a secure channel. Failure results in messages like “Your connection is not private” or certificate errors.

6. HTTP request – now the browser sends the actual request, e.g.:

   GET / HTTP/1.1
   Host: myapp.com

   HTTP lives inside TCP, which lives inside IP, which lives inside the underlying network.

7. Server processing – the OS receives the packet, TCP hands the payload to the web server (Nginx, Node, etc.), which runs application logic and generates a response, e.g.:

   HTTP/1.1 200 OK

8. Response travel – the response traverses TCP → IP → network back to the browser, which parses HTML, loads CSS/JS, and may issue additional requests (a single page load typically involves many network round‑trips).

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

Common failure points

Debug top‑to‑bottom, never randomly.

Hands‑on commands

These commands map directly to the steps above: DNS must resolve before a TCP connection can be attempted; the TCP connection must succeed before an HTTP request is sent; TLS adds a security layer on top of TCP.

Resources

• GitHub repository – all notes, diagrams, and learning resources for this series:

Feedback is welcome—please comment if you notice missing tool categories, incorrect assumptions, or better learning paths.