How a request travels

A student taps "Inter-college Battle of Bands" in the Gatepass app and, a moment later, the event page appears. In that moment the phone has asked for directions, shaken hands twice, agreed on secret keys, sent a request, and waited for a server and a database to answer. Knowing these steps tells you where time goes, and where you can win it back.

Finding the server: DNS

The app knows a name, api.gatepass.app. The internet routes by numbers, IP addresses like 203.0.113.7. DNS (the Domain Name System) turns the first into the second.

The phone asks a resolver, usually run by the mobile network or a service like 1.1.1.1. If the resolver doesn't already know the answer, it asks a chain of servers: the root, then the servers for .app, then the servers for gatepass.app. Each answer comes with a TTL (time to live), saying how long it may be cached.

A cold lookup can take 20–100 ms. A cached one, on the phone or at the resolver, takes about nothing. That's why DNS barely shows up for an app you use daily, and why the first request after installing feels slower.

Opening a connection: TCP

Now the phone knows where to go. Before sending anything, it opens a TCP connection, which guarantees bytes arrive complete and in order. Opening one takes a three-step handshake:

The phone says "let's talk" (SYN), the server says "sure" (SYN-ACK), and the phone confirms (ACK). The phone can send right after its ACK, so the handshake costs one round trip time (RTT): the time for a message to reach the server and a reply to come back.

RTT is set mostly by distance. Light in fibre covers about 200 km per millisecond, and real routes zigzag. Same city: 5–20 ms. Mumbai to Frankfurt: around 120 ms. Mumbai to California: 200–250 ms. You can't optimise the speed of light; you can only do fewer round trips or move closer.

Making it private: TLS

Next, TLS encrypts the connection so nobody on the café Wi-Fi can read the student's session token. The phone and server agree on keys, and the server proves it really is api.gatepass.app with a certificate.

With TLS 1.3 this takes one more round trip (older TLS 1.2 took two). So before the app has sent a single byte of its actual request, a fresh connection has spent two round trips on handshakes. Same city, that's ~25 ms. Across an ocean, ~400 ms, before the server even knows what you want.

The HTTP request itself

Finally the app sends its request:

GET /events/42 HTTP/1.1
Host: api.gatepass.app
Authorization: Bearer eyJhbGciOi…
Accept: application/json

That's another half round trip to get there, the server's own time to answer, and half a round trip back. The server's part is usually the smallest: routing the request, checking the token, running one database query, turning rows into JSON. For a simple page, 5–20 ms.

Inside the data centre

The server and database usually sit in the same data centre, often the same rack. A round trip between them is around half a millisecond, so a query that hits an index might take 1–5 ms in total. That changes once you have many queries per request: twenty queries in a row is twenty round trips, and suddenly the database hop matters. Keep that in mind; it's the reason "N+1 queries" is a famous performance bug.

Watch it end to end

Here's the whole journey as a timeline. Start with the server in the same city, then move it to another continent and watch the handshakes balloon. Then turn on the two toggles and see what reuse saves.

Interactive

One tap, seven steps

Server in the same cityServer on another continent

DNS answer cachedthe phone looked it up recentlyReuse the connectionkeep-alive skips TCP and TLS

Tap to response

85 ms

Waiting on the network

86%

1. DNS lookup

   Ask a resolver for gatepass.app's IP address

   35 ms

2. TCP handshake

   SYN → SYN-ACK → ACK: one round trip

   12 ms

3. TLS handshake

   Agree on keys (TLS 1.3): one more round trip

   12 ms

4. Request travels

   GET /events/42 goes out: half a round trip

   6 ms

5. Server code

   Route, check auth, build the response

   8 ms

6. Database query

   SELECT … FROM events WHERE id = 42

   4 ms

7. Response travels

   ~6 KB of JSON comes back: half a round trip

   8 ms

Play the request network your servers

Three lessons hide in this visual:

1. Distance multiplies. Every round trip pays the distance again. A request that needs four round trips is four times as sensitive to where your server is.
2. Connection reuse is huge. HTTP keep-alive (and HTTP/2, which runs many requests over one connection) lets every request after the first skip TCP and TLS. Apps that open a fresh connection per request throw away hundreds of milliseconds.
3. Your code is the small bar. Optimising server code from 8 ms to 4 ms is invisible next to a 190 ms round trip. Moving closer to users, or caching at the edge, is where big wins live.

Check yourself

Gatepass expands to students abroad, 200 ms round trip from the server. A first request on a fresh connection needs DNS (cached), TCP, TLS 1.3 and the HTTP exchange. Roughly how long before the response arrives, ignoring server time?

AAbout 200 msBAbout 400 msCAbout 600 msDAbout 1 second

Key takeaways

• A fresh HTTPS request costs DNS, a TCP handshake (1 RTT), a TLS handshake (1 RTT with TLS 1.3), then the request itself (1 RTT).
• Round trip time is set by distance; same city is ~10 ms, across an ocean ~150–250 ms.
• Keep-alive and HTTP/2 reuse connections so later requests skip both handshakes.
• Server and database time is often the smallest part; fewer round trips usually beat faster code.
• DNS answers are cached for their TTL, which makes them fast and also slow to change.