Client-Server Model and HTTP

Client-server model

The client-server model (Fig. 1) is a distributed model where clients communicate with servers through a computer network such as the internet. Clients ask for services or resources from a server, which then responds to requests. The client-server model allows applications where resources (and computing power) are located on centralized servers that are used by many clients, which allows updating resources on demand (when e.g. compared to local software installations).

The client-server model is at the core of all web applications. The server is responsible for hosting and providing resources and services to one or more clients, whereby the client is dependent on the server. The model is also visible n-tier architectures such as the three-tier architecture (Fig. 2).

In three-tier architecture, the client-server model is present in two locations: (1) the client and the web server, and (2) the web server and the database server. In the latter location, the web server acts as a client to the database server.

HTTP protocol

The HTTP protocol (and its newer variants HTTP/2 and HTTP/3) that web applications predominantly rely on is based on the client-server model. An HTTP request is sent to a server, which processes the request and then provides a response. The request could ask for a resource such as a static image or a page, or, the request could ask for dynamically generated content that the server should create based on the request.

The HTTP-protocol is text-based. Each message consists of rows that form the request header and a set of optional rows that form the request body.

Structure of a HTTP request

An HTTP request contains the request method, the path of the resource, and the version number of the used protocol. The subsequent rows contain headers, where each row corresponds to one header, represented as a key-value -pair separated by a colon. After headers, there exists an empty line, which is followed by an optional request body.

request-method /path/to/resource HTTP/version
header1: value1
header2: value2
header3: value3

optional body with content

The request method indicates the method in the HTTP-protocol that is used (e.g. GET or POST). The path to resource contains the path to the resource on the server, containing parts of the URI path, query parameters, and anchor (e.g. /news/index.html?limit=10#newest). The HTTP-version outlines the used version of the HTTP-protocol (e.g. HTTP/1.1).

Structure of a HTTP response

An HTTP response contains the HTTP-protocol version, a HTTP-status code corresponding to the response, and a clarification of the status code. This is followed by a set of headers each on its own line, similar to the HTTP-request. The headers are followed by an empty line and a body of the response, which again similar to the HTTP-request, is not mandatory.

HTTP/version status-code status-code-clarification
header1: value
header2: value

optional body with content

A simple response could be as follows, which essentially states that the request was received and all is well.

HTTP/1.1 200 OK

Retrieving a web page

Web pages (and web applications) are typically composed of multiple parts. These parts include the main content (e.g. a HTML-document), images, style files, script files, music, video, and so on. When retrieving a web page with a browser, the browser first retrieves an HTML-document, which links necessary parts, which are then requested one by one.

For example, retrieving the Aalto University website leads to the browser making more than 170 requests (Fig 4.), and retrieving the Amazon website leads to the browser making nearly 300 requests (Fig 5.). Note that the number of requests is also in part exacerbated by dynamic content; when a website uses JavaScript, the JavaScript code is often used for dynamically loading content (we discuss this more in the chapter on Web Rendering Approaches).

The used HTTP protocol version relates to the requests. With HTTP/1.0, a new TCP connection is needed for each request, requiring a TCP handshake for every request. With HTTP/1.1, there is the possibility to maintain the underlying TCP connection, leading to new requests being sent potentially over an existing connection. In addition, browsers can open up multiple connections per server, leading to parallel requests; resources can also be stored on separate servers (discussed more in e.g. the chapter on Content-Delivery Networks).

HTTP/2 and HTTP/3

The HTTP/2, which is outlined in RFC 7540, attempts to address this issue. One of the improvements is to provide the server the opportunity for sending multiple resources as a part of the response to a request. This reduces the time spent in opening and closing the connections, and also potentially reduces the time that loading a site takes. The HTTP/2 protocol includes also other improvements, most of the improvements are implemented on the servers that run web applications, not web applications per se.

The third version of the HTTP-protocol, HTTP/3 (Proposed Standard), attempts to improve the functionality of dynamic web sites. For example, while HTTP/1 and HTTP/2 use the TCP-protocol, which tries to ensure that messages are received, HTTP/3 will work over UDP-protocol. As the UDP protocol, which is often used e.g. in video games, does not try to ensure that messages will be received, a protocol called QUIC is used on top of it to handle data loss.