Prerequisite:

Overview

Every network request your code makes travels through a stack of layered abstractions. IP delivers packets between machines (unreliably); TCP turns that into a reliable ordered byte stream; HTTP defines the request-response semantics that applications use. Understanding this stack lets you diagnose latency, debug failures, and make informed decisions about protocols and architecture.

  • Problem it solves: Physical networks drop, reorder, and corrupt packets; TCP hides this unreliability; HTTP provides a standard application-layer contract so any client can talk to any server.
  • Alternatives: UDP for latency-sensitive applications (gaming, live video); gRPC (HTTP/2 + Protobuf) for efficient RPC; WebSockets for bidirectional streaming; QUIC for better performance on lossy mobile networks.
  • Pros: Universal support; TCP guarantees ordered delivery; HTTP/1.1 is human-readable for debugging; TLS provides encryption and server authentication.
  • Cons: TCP head-of-line blocking hurts HTTP/2 multiplexing; TLS handshake adds 1–2 round-trip times of latency; NAT and firewalls complicate peer-to-peer networking.

The Layered Model

Application    HTTP, DNS, TLS, SMTP
Transport      TCP, UDP
Network        IP, ICMP
Link           Ethernet, Wi-Fi

Each layer adds a header and passes data down; each layer on the receiving end strips its header and passes data up. This separation of concerns means an HTTP client does not need to know whether it is running over Wi-Fi or fibre.

IP: Internet Protocol

IP addresses identify hosts. IPv4 uses dotted-decimal notation: 192.168.1.45. CIDR notation adds a prefix length: 192.168.1.0/24 means the first 24 bits are the network address, leaving 8 bits (256 addresses) for hosts on that subnet.

Key IP concepts:

  • Routing: routers forward packets hop-by-hop toward the destination IP using routing tables.
  • TTL (Time To Live): an integer decremented at each hop; when it reaches 0 the packet is dropped. This prevents loops from circulating packets forever. traceroute exploits TTL to map the path.

TCP: Reliability Over IP

TCP is connection-oriented. Before any data flows, the three-way handshake establishes a connection:

Client                Server
  |--- SYN ---------->|   "I want to connect, starting at seq=1000"
  |<-- SYN-ACK -------|   "OK, my seq=5000, I acknowledge your 1001"
  |--- ACK ---------->|   "Acknowledged 5001, connection open"

TCP provides:

  • Sequence numbers - every byte is numbered so the receiver can reorder out-of-order segments and detect gaps.
  • Acknowledgements - the receiver confirms which bytes have arrived; unacknowledged segments are retransmitted.
  • Flow control - the receiver advertises a window size (how many bytes it can buffer); the sender respects it to avoid overwhelming the receiver.
  • Congestion control - slow start begins with a small congestion window and doubles it each round-trip until a packet is lost (AIMD: additive increase, multiplicative decrease). This prevents any single connection from saturating the network.

UDP: When You Don’t Need Reliability

UDP is connectionless - no handshake, no acknowledgement, no ordering. It is just a thin wrapper over IP. Use it when:

  • Latency matters more than reliability (online games, live video calls)
  • The application handles its own retransmission logic
  • You are sending small, self-contained queries where a retry is cheaper than a connection (DNS)

DNS: The Internet’s Phone Book

DNS maps hostnames to IP addresses. When you look up api.example.com:

  1. Your OS checks its local cache and /etc/hosts.
  2. Queries your recursive resolver (usually your ISP’s or 8.8.8.8).
  3. The resolver queries a root nameserver → returns the .com TLD nameserver.
  4. Queries the .com TLD nameserver → returns example.com’s authoritative nameserver.
  5. Queries the authoritative nameserver → returns the A record (IPv4 address).

Each answer has a TTL; the resolver caches it and skips the chain on future lookups until the TTL expires.

Common record types: A (IPv4), AAAA (IPv6), CNAME (alias to another hostname), MX (mail exchange), TXT (arbitrary text, used for SPF/DKIM).

HTTP Versions

HTTP/1.1 (1997): text-based, one request per TCP connection per round-trip (with keep-alive, one at a time per connection). Browsers open 6 connections per origin to work around this.

HTTP/2 (2015): binary framing, multiplexes multiple requests over one TCP connection, header compression (HPACK), server push. Eliminates the need for domain sharding.

HTTP/3 (2022): runs over QUIC instead of TCP. QUIC is built on UDP and implements its own reliability and congestion control, but multiplexed streams are independent - a lost packet on one stream does not block others (no head-of-line blocking).

HTTPS and TLS

HTTPS is HTTP over TLS. The TLS handshake (1.3, simplified):

  1. Client sends ClientHello with supported cipher suites.
  2. Server responds with its certificate (public key + identity signed by a CA).
  3. Client verifies the certificate against trusted root CAs.
  4. Both sides derive shared symmetric keys (via ECDHE) and begin encrypted communication.

The certificate chain: your server cert is signed by an intermediate CA, which is signed by a root CA stored in your OS/browser trust store. If any link in the chain is untrusted or expired, the handshake fails.

Well-Known Ports

Port Protocol
22 SSH
80 HTTP
443 HTTPS
5432 PostgreSQL
6379 Redis

Tools

# test HTTP responses
curl -I https://example.com           # headers only
curl -v https://example.com           # verbose: show TLS + headers + body
curl -X POST -H "Content-Type: application/json" \
     -d '{"name":"test"}' https://api.example.com/items

# DNS lookups
dig api.example.com A                 # A record
dig api.example.com +trace            # full resolution chain
nslookup api.example.com

# network diagnostics
ping api.example.com                  # ICMP round-trip time
traceroute api.example.com            # hop-by-hop path
ss -tlnp                              # show listening TCP sockets
netstat -an | grep ESTABLISHED        # established connections
tcpdump -i eth0 port 443              # capture TLS traffic (encrypted, but useful for metadata)

Examples

Trace a web request end-to-end:

# 1. DNS resolution
dig +short api.example.com
# 93.184.216.34

# 2. TCP + TLS handshake + HTTP round-trip time
curl -w "\n\nDNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" \
     -o /dev/null -s https://api.example.com/health

# 3. Inspect response headers
curl -I https://api.example.com/health

DNS lookup chain with dig +trace:

dig api.example.com +trace
# . -> com. -> example.com. -> api.example.com
# Shows each nameserver queried and the TTL at each step

Check what is listening on a port:

ss -tlnp | grep 8080
# LISTEN 0 128 0.0.0.0:8080 ... users:(("python",pid=12345,...))

Knowing the network stack - IP routing, TCP’s guarantees, DNS caching, HTTP versions, TLS trust - is the foundation for diagnosing anything that involves a network call. Most production bugs touch at least one of these layers.

Read Next: