Home About Me

Inside a Linux Web Service: HTTP Messages, Resources, and Concurrency

The World Wide Web is a distributed, cross-platform graphical information system built on hypertext and HTTP. It sits on top of the Internet and gives readers a visual, easy-to-use interface for finding and moving through information. Documents and the links between them turn separate information nodes into an interconnected web.

A web service on Linux is assembled from the same pieces: content types, HTTP message exchange, resource identifiers, server request handling, and concurrency strategy.

Static and dynamic content

Static pages are HTML files, usually with an .html extension. A small HTML document can be as simple as:

<h1>I am cehngfneg.</h1>

Dynamic sites behave more like scripts: the same endpoint can return a different page depending on the parameters it receives. Common examples include PHP (*.php), JavaServer Pages (*.jsp), and Python Django applications (*.wsgi).

HTTP versions and what changed

HTTP stands for HyperText Transfer Protocol. HTTP/0.9 carried only plain text and hyperlinks over ASCII. HTTP/1.0 introduced MIME, the Multipurpose Internet Mail Extensions mechanism: non-text data is re-encoded as text before transmission, then the receiver decodes it back to its previous format and can call the appropriate program to open it. HTTP/1.0 also brought a caching mechanism.

HTTP/1.1 improved cache management and added keepalive persistent connections, along with timeouts and a limit on how many files can be requested over each persistent connection. HTTP itself is stateless, but keepalive lets the transport connection stay open across multiple requests.

Request and response messages

HTTP messages come in two forms: requests and responses. The request syntax is:

<method> <request-URL> <version>
<headers>

<entity-body>

A concrete request can look like this:

GET /1.gif HTTP/1.1
Host:www.bj.com
Connection:keep-alive

The common methods are GET, PUT, POST, DELETE, and HEAD.

A URI, or Uniform Resource Identifier, is a globally unique name for a resource; uniform refers to a consistent path format. A URL, or Uniform Resource Locator, is written as:

protocal://Host:Port/path/to/file
http://192.168.1.1/1.jpg
http://192.168.1.1:8000/1.jpg

The response syntax is:

<version> <status> <reason-phrase>
<headers>

<entity-body>

Status codes fall into five ranges:

  • 1xx: informational
  • 2xx: success
  • 3xx: redirection — 301 permanent, 302 temporary, 304 not-modified, meaning cached content is used to answer the client
  • 4xx: client error
  • 5xx: server error

A sample response:

HTTP/1.1 200 OK
X-Powerd\=By: PHP/5.2.17
vary: Accept-Encoding, Cookie, User-Agent
Cache-Control: max-age\=3, must-revalidate
Content-Encoding: gzip
Content -Length: 6931

The first line of either message is the start line. The fields after it are header fields, each made of a name and a value. A response also usually has a body: the content sent back to the client.

What a web server does

A web server performs a repeatable sequence:

  1. Establish the connection — accept or reject a client connection.
  2. Receive the request — read the HTTP request message from the network.
  3. Process the request — parse it and decide what action to take.
  4. Access the resource — reach the resource named in the request.
  5. Build the response — generate an HTTP response with the correct headers.
  6. Send the response — return the generated response to the client.
  7. Log the transaction — record completed HTTP transactions in a log file.

Handling concurrent connections

Throughput is often measured in QPS, queries per second. A web server can respond to concurrent connections in several ways:

  • Single-process/single-thread: handle each request in turn.
  • Multi-process/multi-thread: create a child process for each request; this is a stable model.
  • One process handling multiple requests (single-process, multi-thread): use an event-driven and notification mechanism.
  • Multi-process handling multiple requests.

The choice among these models affects how a Linux web service behaves under load, but all of them sit behind the same HTTP request/response cycle.