# What happens after you hit enter, and why interviewers ask

Source: https://www.techinterview.org/post/3233476948/what-happens-after-you-hit-enter-networking/
Updated: 2026-07-31 · techinterview.org

The single most reliable networking question in a software loop is some version of "walk me through what happens when you type google.com into your browser and press enter." It shows up at Google, at payment companies, in SRE screens, and in most senior backend rounds, because one complete answer touches DNS, TCP, TLS, and HTTP, plus a dozen places where a real system breaks. The people who do well don't recite a memorized script. They know which layer they're standing on, and they can go one level deeper the moment the interviewer pokes.

So start with the walk-through, then look at the pieces that each earn their own follow-up.

## The path from keystroke to rendered page

Your browser first needs an IP address for the hostname. It checks its own cache, then the OS cache, then asks a DNS resolver (usually your ISP's, or 8.8.8.8, or 1.1.1.1). If nobody has the answer, the resolver walks the hierarchy: a root server points it at the .com nameservers, those point at google.com's authoritative servers, and one of those returns an A record (IPv4) or AAAA record (IPv6). Most of this rides UDP on port 53, and every answer carries a TTL that says how long to cache it. That TTL is why a DNS change can take minutes or hours to show up everywhere.

With an IP in hand, the browser opens a TCP connection to port 443. That's the three-way handshake: SYN, SYN-ACK, ACK. Then TLS negotiates encryption on top of that connection. Only after the secure channel is up does the browser send the actual HTTP request, a few hundred bytes that begin with something like GET / HTTP/1.1 or an equivalent HTTP/2 frame. The server responds, the browser parses the HTML, and it fires off more requests for CSS, JavaScript, and images, each of which may need its own lookup and connection.

A strong answer names where the latency hides. A cold DNS lookup can cost 20 to 120 ms. The TCP handshake costs a full round trip before you've sent a single byte of request. TLS adds one or two more. On a mobile link with 80 ms of round-trip time, you can burn a quarter second on setup before the server does any work, which is the whole reason connection reuse and keep-alive matter.

## TCP versus UDP, and when the "unreliable" one wins

This comparison is the second most common networking question, and interviewers ask it because the naive answer (TCP good, UDP bad) is wrong often enough to be interesting. TCP gives you an ordered, reliable byte stream with flow control and congestion control. UDP gives you a thin wrapper over IP: send a datagram, hope it arrives. The catch is that reliability costs latency, and for some workloads a late packet is worse than a lost one.

| Property | TCP | UDP |
| --- | --- | --- |
| Connection setup | Connection-oriented; three-way handshake before any data | Connectionless; just send a datagram |
| Delivery guarantee | Reliable; retransmits lost segments | Best-effort; lost packets are gone |
| Ordering | In-order byte stream | None; datagrams can arrive out of order |
| Header and state overhead | Higher (20-byte header, ACKs, per-connection state) | Lower (8-byte header, no connection state) |
| Flow and congestion control | Built in | None; the application must handle it |
| Effect of one lost packet | Can stall the whole stream until retransmit | Affects only that datagram |
| Typical uses | Web (HTTP/1.1, HTTP/2), APIs, email, file transfer | DNS, live video and audio, game state, QUIC / HTTP/3 |

Live video is the cleanest example. If a frame from 200 ms ago gets dropped, you do not want TCP to freeze the whole stream while it retransmits that stale frame. You want the next frame, now. That's why real-time media, most game netcode, and DNS itself lean on UDP, and it's why QUIC, the transport under HTTP/3, was built on UDP so it could fix TCP's shortcomings without waiting for every operating system and router in the path to change.

## What the TCP handshake actually guarantees

People memorize SYN, SYN-ACK, ACK without knowing what it buys them. The handshake exists to synchronize sequence numbers. Each side picks a random initial sequence number and tells the other, so both ends agree on where the byte stream starts and can then detect loss, duplication, and reordering. The randomness doubles as a mild defense against off-path attackers trying to guess the sequence and inject data.

Once connected, TCP does two jobs people tend to conflate. Flow control keeps a fast sender from drowning a slow receiver, using the receive window the receiver advertises in every ACK. Congestion control keeps senders from overwhelming the network in between, using algorithms like slow start and CUBIC that ramp up until they see loss, then back off. A good follow-up mentions that a connection starts slow, with a small congestion window, and speeds up over its lifetime, which is one more argument for reusing a connection instead of opening a fresh one per request.

Teardown has its own trivia. Closing is a four-way exchange of FIN and ACK, and the side that closes first sits in TIME_WAIT for a while (60 seconds on Linux) so stray late packets don't leak into a new connection that reuses the same port. If you've ever watched a busy server pile up thousands of sockets in TIME_WAIT, that's the mechanism, and it's a common production-debugging prompt.

## DNS is a distributed cache with a hierarchy

Interviewers like DNS because it's a real distributed system that most engineers use daily without thinking about it. The record types are worth knowing cold: A and AAAA map a name to an address, CNAME aliases one name to another, MX routes mail, TXT holds arbitrary text (used for domain verification and SPF), and NS delegates a zone to nameservers. Resolution is recursive from your resolver's point of view and iterative as it walks down from the root.

The parts that trip candidates up are caching and propagation. There is no push. When you change a record, the old value lives in caches until its TTL expires, so "DNS propagation" is really just caches aging out. Lowering a record's TTL before a planned migration is the standard trick. The other gotcha is that DNS-level load balancing, returning different IPs or using anycast so one advertised IP routes to the nearest datacenter, is how a lot of global traffic steering happens, which ties DNS straight back to system design.

## TLS: what the handshake proves

HTTPS is just HTTP running inside TLS, and TLS is doing three separable things a candidate should be able to name: encryption so nobody on the path can read the traffic, integrity so nobody can tamper with it undetected, and authentication so you know you're actually talking to the real server. That last one comes from the certificate, signed by a certificate authority your operating system or browser already trusts.

The version matters in 2026. TLS 1.3 cut the handshake to a single round trip and dropped a pile of old, weak ciphers, where TLS 1.2 needed two. There's also a 0-RTT resumption mode that lets a returning client send data in its first packet, at the cost of some replay risk. If someone asks how HTTPS keeps your password safe on shared wifi, the answer they want walks from the CA-signed certificate, through the key exchange that produces a shared session key, to the symmetric encryption that protects the actual bytes, since asymmetric crypto is too slow to encrypt everything.

## HTTP has three versions and they behave differently

HTTP/1.1 opens a connection and mostly sends one request at a time; browsers paper over this by opening around six connections per host. HTTP/2 multiplexes many requests over one connection using streams, which removes most of the need for those tricks, but it still rides on TCP, so a single lost packet can stall every stream at once (head-of-line blocking down at the transport layer). HTTP/3 moves onto QUIC over UDP, so loss on one stream no longer blocks the others, and it folds the TLS handshake into transport setup to shave a round trip. Knowing which problem each version solves is far more useful than memorizing frame formats.

The other HTTP details that come up are semantic. Which methods are idempotent (GET, PUT, DELETE) versus not (POST). What the status classes mean, and specifically the gap between a 401 (you're not authenticated) and a 403 (you are, but you're not allowed). How caching headers and cookies behave. These blur into API design questions fast, and the same interviewer often asks both in one sitting.

## How to prep this without drowning in RFCs

You don't need to read the specs. You need to be able to draw the full request path on a whiteboard and stop at any layer to explain what it does and how it fails. Practice the "type a URL" walk-through out loud until it's boring, then have a friend interrupt with "why is that slow" or "what if the DNS server is down" at each step, because that is exactly how the real conversation goes.

A handful of questions worth rehearsing in the phrasing interviewers actually use:

- "What happens when you type a URL and press enter?" (the anchor, with follow-ups at every layer)

- "Why would you ever use UDP if it can lose packets?"

- "What does the TCP handshake actually accomplish?"

- "How does HTTPS stop someone on the same wifi from reading your traffic?"

- "You changed a DNS record an hour ago and some users still hit the old server. Why?"

Get comfortable saying "I'd have to check the exact default" for numbers like the TIME_WAIT duration. Nobody sharp expects you to have every constant in your head. They're watching whether you know the shape of the system and can reason about where it bends under load, which is the same thing the rest of the loop is testing anyway.