The round trip between client and server

An exchange between client and server always comes two at a time. What the client sends is the request; what the server sends back is the response. On the web, HTTP is what settles how both are written.

A request says which one you want (the URL) and what you want to do with it (the method). Just fetching something is GET; sending what somebody typed in is POST.

A response starts with a number saying whether it worked. 200 is success, 404 is not found, 500 is something failing on the server side, and so on.

When somebody tells you "the page will not come up", just looking at which number came back narrows down where to search enormously.

What a single round trip usually carries is only the HTML text. The CSS that decides how it looks, the photos, and the JavaScript that makes it move are all still elsewhere.

The browser reads the HTML it received and fires off another request every time it notices something missing. Ten images means ten more round trips on their own. So showing one page is a pile of dozens of round trips.

When a page is slow, it is not unusual for the culprit to be not "each exchange is slow" but "there are far too many round trips".

Read the tricks coming up with that in mind: almost all of them are about cutting the number of round trips, or cutting how much each one carries.

HTTP has a property that comes as a surprise. Once a round trip ends, the server forgets who you were. This is called being stateless.

There are times when that will not do. What you put in a shopping basket, and the fact that you are logged in, really ought to survive into the next request.

So we use a cookie. The server attaches a small note to its response, and the browser sends that note along from the next request onward. What gets handed over is usually only a session ID — "you are visitor number such-and-such" — with the actual data kept on the server.

On top of a mechanism that forgets, we lay a mechanism that appears to remember. That two-storey arrangement is how the web is built.

What a server returns comes in two kinds.

• Static content … a file sitting there, handed back as it is. Images, and pages that never change
• Dynamic content … content built by a program once it has been asked for. Search results, or your own account page

To make something dynamic, the web server has to call an outside program. The agreement for that handover is CGI. The program that gets called puts the HTML together, and the web server carries it back in the response.

The two cost wildly different amounts of effort. Against static, which only reads a file, dynamic runs a program and usually goes as far as a database. Which is where the idea of handing the heavier one to a different machine comes from.

There are two places a program can run: inside the server, or on the client after being sent there.

• Runs on the server … programs called through CGI, and servlets. Only the resulting HTML comes back
• Runs on the client … applets and JavaScript. The program itself is sent over and runs at your end

An applet is a small compiled program kept on the server which, when asked for, is transferred to the client and only then run. The similarly named servlet is the one that runs inside the server.

The way to tell them apart is right there in the names: the one with "serv" in it is the server side. The exam lines these two up with their roles swapped.

Inside a server that returns dynamic pages, the work is divided further still. Three tiers is the common shape.

• Web server … the front door that takes requests and returns responses
• AP server … runs the programs that do the business processing
• DB server … looks after the data

Let us follow one request through that line. Having read what came in, it connects to the DB, builds the SQL, fetches the data, assembles the HTML, sends it to the browser, and finally disconnects from the DB.

Two spots trip people up. Building the SQL comes before the access, and assembling the HTML comes after fetching the data. You cannot build HTML with nothing to put in it.

The gain from three tiers is that work of different kinds can be sent to the machine that suits it.

A light request that only returns a file sitting there gets dealt with by the web server itself, while a heavy one that runs a program and goes out to a database is passed to the AP server. Being able to divide the work by the kind of request is where splitting machines really earns its keep.

The other gain is that business processing gathers on the server side. All that is left on the client is showing the screen, so when you want to change the processing you change the server and it takes effect for everybody. Nothing has to be handed round to every device.

Put the other way: any choice saying the business processing happens on the client is describing the shape from before the split.

If round trips are expensive, bundle them up. The version of this used with databases is the stored procedure.

A useful lump of SQL is registered in advance with the DBMS on the server, and the client calls it by name: "run that one". Dozens of lines of SQL no longer have to be sent, so the traffic between client and server drops.

Worth being careful about: traffic is the only thing that drops. How much the server reads from the database files, how much memory it uses, and how much room the storage takes are all unchanged. The work has only moved location; it has not disappeared.

When a question says "the load from a great many SQL statements", this is the answer.

The old web redrew the entire page every time you pressed a button. Only a fraction was changing, and yet the whole lot was carried over afresh each time.

Ajax changed that. JavaScript talks to the server in the background and uses what comes back to redraw only part of the screen. The reason a map does not go blank while you drag it is this.

The key word is asynchronous. The screen does not lock up while a reply is outstanding, and you can carry on. It did away with "once you ask, you can do nothing until the answer arrives".

Since only a fraction is carried, each round trip is smaller too. It works on both the count and the volume.

Sometimes another machine sits between client and server. The classic case is a proxy server.

The browser asks the proxy, and the proxy goes and asks the real server on its behalf. The round trip splits into two, and so do the destination port numbers. The request from browser to proxy goes to the proxy port (say 8080), and the request from proxy to web server goes to 80.

Responses flow the opposite way, so their destination is whoever did the asking. If you are asked which packets are "always addressed to 8080", the answer is only the requests aimed at the proxy.

That 80 is the number agreed worldwide as the door for the web. A firewall will have it open before anything else, which is why some unpleasant programs choose it as their route.

So far this has been a person asking through a browser. The same round trip can happen between programs, and that is a web service.

The difficulty here is that the program at the other end is written in a different language from yours. So you convert to a form both can read before carrying it. The one used for a long time is XML.

What marks XML out is that you decide the tags yourself. HTML has a fixed set, but in XML you may define <price> or <author> as you like. That is what makes it suited to exchanging data between systems.

The agreement for passing those XML messages between the sending and receiving programs is SOAP. And joining several web services into a new one is called mashup.