Computer Networks for Interviews: From HTTP to TCP/IP, Explained the Right Way
Networking questions appear in every system design interview and most backend rounds. This guide explains DNS, HTTP, TCP, the OSI model, and WebSockets with the depth interviewers expect — and the conciseness you need.
"What happens when you type google.com in a browser?" is one of the most common interview openers at product companies. It looks simple. But a complete answer touches DNS resolution, TCP handshake, HTTP request-response, TLS, CDNs, and browser rendering — everything in computer networks, in one question.
This guide teaches networking with that question as the skeleton, then goes deeper into every concept interviewers actually probe.
The One Question That Covers Everything
"What happens when you type https://www.google.com and press Enter?"
Here's the complete answer, layer by layer:
Step 1: DNS Resolution
The browser needs to convert www.google.com to an IP address.
- Check browser cache (recent DNS lookups)
- Check OS cache (
/etc/hostsfile, system DNS cache) - Query the configured DNS resolver (usually your ISP's or 8.8.8.8)
- Resolver queries Root Name Server → learns
.comTLD server address - Resolver queries TLD Name Server → learns Google's authoritative name server
- Resolver queries Google's Name Server → gets
142.250.x.x - Resolver caches and returns the IP
TTL (Time to Live): Each DNS record has a TTL. When it expires, the cache is invalidated and a fresh lookup is needed.
Step 2: TCP Connection (Three-Way Handshake)
Before any data is sent, a reliable connection must be established.
Client → Server: SYN (synchronise)
Server → Client: SYN-ACK (synchronise + acknowledge)
Client → Server: ACK (acknowledge)
Connection established.
Why three steps? Each side needs to confirm the other can both send and receive. Two-way isn't enough — the server needs confirmation the client got the SYN-ACK.
Step 3: TLS Handshake (for HTTPS)
After TCP, HTTPS adds an encryption negotiation:
- Client sends supported TLS version and cipher suites
- Server responds with its certificate (containing its public key) and chosen cipher
- Client verifies the certificate with a Certificate Authority
- Client and server derive a shared session key using asymmetric encryption
- All further communication is encrypted with symmetric encryption (faster)
Why symmetric for data transfer? Asymmetric encryption (RSA) is 100x slower than symmetric (AES). Use asymmetric once to securely exchange the symmetric key, then use symmetric for everything else.
Step 4: HTTP Request and Response
GET / HTTP/1.1
Host: www.google.com
Accept: text/html
Connection: keep-alive
Server responds with HTML (200 OK), browser parses it, fetches referenced CSS/JS/images (more DNS + TCP + HTTP per resource), and renders the page.
HTTP Deep Dive
HTTP/1.1 vs HTTP/2 vs HTTP/3
| Version | Key Feature | Problem It Solved | |---|---|---| | HTTP/1.0 | New TCP connection per request | Slow (connection overhead) | | HTTP/1.1 | Keep-alive connections, pipelining | Head-of-line blocking | | HTTP/2 | Multiplexing — many requests on one TCP | HTTP head-of-line blocking | | HTTP/3 | Uses QUIC (UDP-based) instead of TCP | TCP head-of-line blocking at transport layer |
Multiplexing (HTTP/2): Multiple requests and responses interleaved on one connection. No need to wait for each response before sending the next request.
Status Codes to Know Cold
| Code | Meaning | When | |---|---|---| | 200 | OK | Success | | 201 | Created | POST that created a resource | | 204 | No Content | DELETE that succeeded | | 301 | Moved Permanently | URL has permanently changed | | 302 | Found (Temporary Redirect) | Temporary redirect | | 304 | Not Modified | Cached version is still valid | | 400 | Bad Request | Client sent invalid data | | 401 | Unauthorized | Not authenticated | | 403 | Forbidden | Authenticated but not allowed | | 404 | Not Found | Resource doesn't exist | | 429 | Too Many Requests | Rate limited | | 500 | Internal Server Error | Server bug | | 502 | Bad Gateway | Upstream server failed | | 503 | Service Unavailable | Server overloaded or down |
Cookies vs Sessions vs JWT
Cookie: Key-value pair stored in the browser, sent with every request to the domain. Used for session management, preferences, tracking.
Session: The server stores session state (user ID, cart contents) and gives the client a session ID (stored in a cookie). Server is stateful.
JWT (JSON Web Token): Server encodes user data into a signed token, sends it to the client. Client sends it back with every request. Server verifies the signature — no database lookup needed. Server is stateless.
Which to use:
- Sessions: when you need to invalidate tokens immediately (logout, account ban)
- JWT: when you want stateless servers (easy horizontal scaling)
TCP vs UDP
| Property | TCP | UDP | |---|---|---| | Connection | Handshake required | No connection setup | | Reliability | Guaranteed delivery, in order | No guarantee | | Speed | Slower (overhead) | Faster (no overhead) | | Use cases | HTTP, file transfer, email | DNS, video streaming, gaming, VoIP |
TCP guarantees order and delivery using:
- Sequence numbers (detect missing/reordered packets)
- Acknowledgements (sender knows packet was received)
- Retransmission (resend if no ACK within timeout)
- Flow control (receiver tells sender how much it can handle)
- Congestion control (slow down if network is congested)
Why UDP for video? A 100ms-old video frame is useless — you'd rather skip it than wait. UDP drops packets rather than stalling to retransmit. The video codec handles occasional loss gracefully.
The OSI Model — Interview-Ready Version
Interview truth: Nobody remembers the exact function of every layer in production. But interviewers ask to test whether you think in layers.
| Layer | Name | Protocols | What it does | |---|---|---|---| | 7 | Application | HTTP, FTP, SMTP, DNS | User-facing protocols | | 6 | Presentation | SSL/TLS | Encryption, encoding | | 5 | Session | — | Connection management | | 4 | Transport | TCP, UDP | End-to-end delivery, ports | | 3 | Network | IP, ICMP | Routing between networks | | 2 | Data Link | Ethernet, WiFi | Node-to-node on local network | | 1 | Physical | Cables, radio waves | Bits over physical medium |
The mnemonic: "All People Seem To Need Data Processing" (Application → Physical).
Interview answer:
"The OSI model is a conceptual framework for how data moves from application to physical medium. In practice, TCP/IP (which combines layers 5-7 into one Application layer) is what actually gets implemented. The value of the model is that each layer can change independently — you can swap WiFi for ethernet without changing how HTTP works."
DNS Record Types
| Record | Purpose | Example | |---|---|---| | A | Domain to IPv4 address | google.com → 142.250.x.x | | AAAA | Domain to IPv6 address | — | | CNAME | Domain alias | www.google.com → google.com | | MX | Mail server for domain | — | | TXT | Text data (used for verification) | — | | NS | Name servers for domain | — |
WebSockets vs Long Polling vs SSE
When you need real-time updates from server to client:
Short polling: Client asks "any updates?" every N seconds. Simple, wasteful — most responses are empty.
Long polling: Client asks, server holds the connection open until data is available, then responds. Client immediately makes another request. Better than short polling but still HTTP overhead per message.
WebSockets: Full-duplex persistent connection. After HTTP upgrade handshake, both sides can send at any time. Used in chat, live collaboration, stock tickers.
Client: GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Server: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
// Now both sides can send frames at any time
SSE (Server-Sent Events): One-way persistent stream from server to client over HTTP. Simpler than WebSockets when you only need server → client push (notifications, live feeds).
Networking in System Design
These networking concepts come up constantly in system design interviews:
Load balancer: Distributes requests across servers. At Layer 4 (TCP) — routes by IP/port. At Layer 7 (HTTP) — routes by URL, headers, cookies.
Reverse proxy: Server-side proxy that client doesn't know about. Handles SSL termination, caching, load balancing. Nginx is the most common.
CDN: Caches static content at edge nodes geographically close to users. Reduces latency and origin server load.
Rate limiting: Limit requests per IP/user per time window. Implemented with a counter in Redis with TTL expiry.
Circuit breaker: If a downstream service fails repeatedly, stop calling it temporarily. Prevents cascade failures.
The Quick-Answer Cheat Sheet
"What is NAT?" — Network Address Translation. Your router has one public IP; all devices on your home network share it. NAT translates between private IPs (192.168.x.x) and the public IP.
"What is a subnet?" — A subdivision of a network. 192.168.1.0/24 means the first 24 bits are the network address, last 8 bits identify hosts — up to 254 usable addresses.
"What is CORS?" — Cross-Origin Resource Sharing. Browser security policy that blocks requests from one domain to another unless the server explicitly allows it via response headers.
"What is a VPN?" — Encrypts traffic between your device and a VPN server, making it appear you're connecting from the VPN server's location. Prevents ISP monitoring; used by companies to secure remote access.
"What port does HTTP use? HTTPS? SSH? DNS?" — HTTP: 80. HTTPS: 443. SSH: 22. DNS: 53. MySQL: 3306. PostgreSQL: 5432.
Prepare with the AI Tutor: Ask AI Tutor to simulate a system design interview starting with "what happens when you type a URL." Practice explaining each step until it flows naturally.
Ready to practice what you just learned?
Apply these concepts with AI-powered tools built for CS students.