The HTTP Server Explained

What is a server: a few notions

In computing, a server is a computer program or a device that provides functionality for other programs or devices, called clients.

The functionalities, or services, that a server can provide are multiple and go from sharing data or resources among multiple clients to performing computation for a client.

A single server can provide, or in computing jargon can serve, multiple clients, and a single client can use multiple servers.

The request/response model

The request/response model is mostly used to implement client/server systems:

a client sends a request to the server, which performs some action and sends a response back to the client, which could be a result or an acknowledgement (like an error message etc.)

As we will see further below, this is the same model that the HTTP server relies on.

Definition of the web or HTTP server

The web server or HTTP server is a server software (or hardware dedicated to running a server software) that implements the request/response model using the World Wide Web and the HTTP (protocol.)

The HTTP server processes incoming network requests from the clients over the HTTP protocol and serves contents over the internet.

What’s the HTTP and how does it work

The HTTP or Hypertext Transfer Protocol is an application layer protocol that is used to virtually transmit files and other data on the World Wide Web, whether they’re HTML files, image files, query results, or anything else.

In simpler words,

the HTTP is a universally-spoken language with a simple grammar that “translates” the communication between the client and the server by specifying how the information must be requested and how the responses are formed.

Usually, HTTP is based on the TCP/IP protocols so it takes place through TCP/IP sockets.

What does the HTTP server do

The primary function of the HTTP server is to store, process and deliver web pages to clients using the Hypertext Transfer Protocol.

A client, or better said a user agent which is a software acting on behalf of a user (commonly represented by a web browser), initiates communication by making a request for a specific resource using HTTP to the server, an application running on a computer hosting a website.

The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client.

The response served by the server contains completion status information about the request and may also contain requested content in its message body, or an error message if it is unable to serve the content.

While the primary function of the HTTP server is to serve content, its implementation can also include ways of receiving content from clients. This feature is used for example for submitting web forms, including uploading of files.

The HTTP server can generate HTML documents dynamically (“on-the-fly”) as opposed to returning documents statically. Or it could merge and serve both. These decisions are made based on configuration options and programs written in languages like PHP.

Dynamically documents are generated when retrieving or modifying information from databases for example. Statically documents are more easily cached and are generally faster to serve.

Interpreting the URL

HTTP servers are able to map the path component of a URL or Uniform Resource Locator into:

• a local file system resource (for static requests)
• an internal or external program name (for dynamic requests).

For a static request the URL path specified by the client is relative to the web server’s root directory.

Example of an HTTP (static) request (shamelessly copied from Wikipedia)

Consider the following URL as it would be requested by a client:

http://www.example.com/path/file.html

The client’s user agent will translate it into a connection to www.example.com with the following HTTP 1.1 request:

GET /path/file.html HTTP/1.1
Host: www.example.com

HTTP/1.1 tells the server which version of HTTP the request is going to use.

The web server on www.example.com will append the given path to the path of its root directory. On an Apache server (aka a free and open-source cross-platform web server serving more than 100 million websites,) this is commonly /home/www. The result is the local file system resource:

/home/www/path/file.html

If the file exists, the web server reads it and sends a response to the client’s web browser. The response will describe the content of the file and contain the file itself. It will also contain a status code for successful response:

HTTP/1.1 200 OK

If the file does not exit, the response will contain an error message and the status code for error:

HTTP/1.1 404 Not Found

The first part of the reply is the version of HTTP being used, the second part is the error code number, and the last part of the reply is the message in human-readable text.

Load limits of the HTTP server

An HTTP server has load limits as it can only handle a limited number of concurrent client connections per IP address (and TCP port) — usually between 2 and 80,000, by default between 500 and 1,000 — and it can only serve a limited number of requests per second (RPS, AKA queries per second or QPS) depending on:

• its own settings
• the HTTP request type
• whether the content is static or dynamic
• whether the content is cached
• the hardware and software limitations of the OS of the computer on which the web server runs.

When a web server is near to or over its limit, it becomes unresponsive.

Symptoms of overload (also bluntly copied from Wikipedia)

The symptoms of an overloaded web server are:

• requests are served with (possibly long) delays (from 1 second to a few hundred seconds);
• the web server returns an HTTP error code, such as 500, 502, 503, 504, 408;
• the web server refuses or resets (interrupts) TCP connections before it returns any content;
• in very rare cases, the web server returns only a part of the requested content. This behaviour can be considered a bug, even if it usually arises as a symptom of overload.

In conclusion

There is a reason why I am writing an overviewing blog post about HTTP servers, the reason being: I’m about to implement one in the next days or so!

Reading — and getting more — about HTTP servers definitely acted as a huge boost in view of the big event (writing the HTTP server is a feared moment shared by all apprentices at some point here at 8th Light.)

I’ve already implemented an EchoServer so I hope this will make the implementation of the HTTP server easier (big times.)

Stay tuned!