What is client server architecture? Following one tap there and back

Meera Kulkarni taps Book for Saturday’s club match. The ₹299 seat goes through, but she frowns. “It took a moment. Why?”

Arjun Nair is sure the server is slow. He opens the booking code and times it. The code takes almost no time at all.

He books seat B07 himself, booking BK-10421, and times every step from tap to ticket. All 100 members book through SeatJaldi’s one ₹1,200-a-month server. So where does the time go?

Client server architecture is a design where one program, the client, asks, and another program, the server, waits and answers.

When Meera taps Book, her app is the client.

It sends a request to the server.

The server sends back a response.

That whole journey, there and back, is a round trip.

• The client asks first, always.
• The server waits, does the work and answers.
• A round trip has hops, the legs of the journey, like the waiter’s walk to the kitchen. The wait you feel is every hop added up.

A connection is the open line between the phone and the server. Like the waiter coming to Priya’s table, it has to be set up before any request can travel.

You have seen this when a food app is slow on the first tap after a long gap, then instant the next. Part of the wait was setting up a fresh connection, and the next tap reused it.

You log in on a new phone and your tickets are there. They live in the server’s database, never on the old phone.

A map app says “Server not responding” while your phone works fine. The client asked, and nothing answered.

One tap becomes a round trip: request out, server work, database answer, response back.

A booking request arrives at SeatJaldi’s one machine. That machine runs many programs, so each server program waits behind its own numbered door.

Private web traffic, the kind with a lock in the address bar, usually arrives at port 443.

Like Priya’s slip, the request uses a fixed format the kitchen can read, called HTTP.

The seat details inside the request are written as JSON.

On the server, the code asks the database a question in SQL.

You met the server in lesson 1. Here is its other half: the numbered door it waits behind.

In the restaurant, “kitchen” names a job: cooking whatever the slips ask for. The machine is the building, the port is the numbered door, and the server program is the cook. So SeatJaldi’s one machine runs two programs that wait behind ports, like a kitchen and a store room: the booking server on port 443 and the database on its own port.

Before the first request can leave, phone and server must agree a connection. On a fresh connection, each agreement usually costs one round trip.

The first agreement is called TCP.

The second is called TLS.

Say a round trip takes 50 ms, an assumed number. Then about 100 ms passes before the request can even leave the phone, like the waiter coming to Priya’s table.

The fix is to reuse the connection. HTTP keeps it open by default, so the next tap skips the setup trips, like the same waiter staying at the table. After a quiet spell either side closes it, and the next tap pays again.

Engineers watch the time to first byte: how long until the first piece of the response arrives. For loading a web page, web.dev gives a rough guide of 0.8 seconds or less as good and over 1.8 seconds as poor.

HTTP/3 swaps TCP for a newer agreement called QUIC. One lost piece of data then holds up only its own request, not the others sharing the connection. Setup also takes one round trip instead of two.

You can time one request yourself with curl, a tool you run from a terminal window. On Windows PowerShell, type curl.exe and use -o NUL instead of -o /dev/null.

What just happened? curl timed one request to example.com, a name kept for examples. Each number counts from the start. The tls number minus the connect number is the locking time. The first byte number minus the tls number is one round trip plus the server’s work. On a nearby server, it is mostly the round trip.

Try it yourself

1. 1

   Open the network tab

   In a desktop browser, press F12 (Cmd+Option+I on a Mac), pick Network, and tick the box that makes the browser fetch every file fresh.

2. 2

   Reload and count

   Reload any page and count the requests. Each is its own round trip.

3. 3

   Open the slowest

   Sort by time and open the slowest request’s timing. Look for rows for the initial connection and the locking step; a reused connection has none.

4. 4

   Check your answer

   You got it if you can name the slowest request and its largest timing row. Then say whether it paid for setup or reused an open connection.

Arjun shows Meera his timings for BK-10421. “So the server is not slow?” she asks. “The program is quick,” Arjun says. “The wait is the first connection and the database. And the server is a program, not a giant machine. Your ticket lives in its database, not on your phone.”

It is Priya’s dinner again. The store room was slow, and the waiter’s first walk took longer than Arjun guessed.

Arjun rereads his timings. The app connects to seatjaldi.in, but a connection needs a numbered address. The phone only knew seatjaldi.in. How did it find the server’s address?