You tap a recipe in Sprig, a recipe-sharing app, and a moment later the page appears. Before a single line of Sprig's own code runs, four decisions have already been made for you by four different layers: a hostname has become an address, a connection has opened with a fixed set of delivery guarantees, a server nobody on this network has met has been verified and a key agreed with it, and only then does an HTTP request travel.

Those layers are the protocols every request crosses before your code runs: DNS turns the name into an address, TCP (or QUIC) delivers bytes in order, TLS encrypts them and proves who the server is, and HTTP carries the request itself. Each layer that has to set something up spends at least one round trip to the server, so a cold first request pays for several of them before any of Sprig's code runs. Network essentials is the study of that path, of which layer owns each decision, and of what each one costs in round trips.

This is rarely the main prompt in a system design interview and often appears as a follow-up: "Why is the first request slow?" A useful answer traces the path, assigns each symptom to a layer, explains why each default was chosen, and states its tradeoff. For latency questions, decompose the total into round trips instead of treating the network as one undifferentiated delay.

Reach for this when the symptom lives on the path: a slow first request, users far from the servers, phones on lossy networks, a failover that waits on DNS caches, or a choice between HTTP/2, HTTP/3, and a long-lived connection. Skip it when the time is spent inside your own servers. A 900ms database query is an indexing problem, and tracing handshakes will not fix it.

A real request passes through the layers in a fixed order, so their costs add up to the total request time.