Web server
The term
Web server can mean one of two things:# A
computer that is responsible for accepting
HTTP requests from clients, which are known as
Web browsers, and serving them Web pages, which are usually
HTML documents and linked objects (images, etc.).# A
computer program that provides the functionality described in the first sense of the term.
Although Web server programs differ in detail, they all share some
basic common features.#
HTTP responses to HTTP requests: every Web server program operates by accepting
HTTP requests from the network, and providing an HTTP response to the requester. The HTTP response typically consists of an
HTML document, but can also be a raw text file, an image, or some other type of document; if something bad is found in client request or while trying to serve the request, a Web server has to send an error response which may include some custom HTML or text messages to better explain the problem to end users.#
Logging: usually Web servers have also the capability of
logging some detailed information, about client requests and server responses, to
log files; this allows the
Webmaster to collect statistics by running
log analyzers on log files.
In practice many Web servers implement the following
features too.
#
Configurability of available features by configuration files or even by an external
user interface.#
Authentication, optional
authorization request (request of
user name and
password) before allowing access to some or all kind of resources.# Handling of not only
static content (file content recorded in server's filesystem(s)) but of
dynamic content too by supporting one or more related interfaces (
SSI,
CGI,
SCGI,
FastCGI,
PHP,
ASP,
ASP .NET,
Server API such as
NSAPI,
ISAPI, etc.). #
Module support, in order to allow the extension of server capabilities by adding or modifying software modules which are linked to the server software or that are dynamically loaded (on demand) by the core server.#
HTTPS support (by
SSL or
TLS) in order to allow secure (encrypted) connections to the server on the standard port 443 instead of usual port 80.#
Content compression (i.e. by
gzip encoding) to reduce the size of the responses (to lower bandwidth usage, etc.).#
Virtual Host to serve many web sites using one
IP address.#
Large file support to be able to serve files whose size is greater than 2 GB on 32 bit
OS.#
Bandwidth throttling to limit the speed of responses in order to not saturate the network and to be able to serve more clients.
The
origin of the
content sent by server is called:
*
static if it comes from an existing
file lying on a
filesystem;
*
dynamic if it is dynamically generated by some other program or
script or
API called by the Web server.
Serving
static content is usually much faster (from 2 to 100 times) than serving
dynamic content, especially if the latter involves data pulled from a
database.
Web servers usually translate the path component of a
Uniform Resource Locator (URL) into a local
file system resource. The URL path specified by the client is relative to the Web server's root directory.
Consider the following URL as it would be requested by a client:
http://www.example.com/path/file.htmlThe client's Web browser 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.comThe Web server on
www.example.com will append the given path to the path of its root directory. On
Unix machines, this is commonly
/var/www/htdocs. The result is the local file system resource:
/var/www/htdocs
/path/file.htmlThe Web server will then read the file, if it exists, and send a response to the client's Web browser. The response will describe the content of the file and contain the file itself.
Web servers (programs) often use
concurrent programming techniques, sometime even in combination with
finite state machines and
non-blocking I/O, to increase the responsiveness and the
scalability of the
server when providing pages to multiple clients simultaneously.
These techniques are useful not only to reduce response latencies in the common cases (i.e. disk I/O waits, non cached accesses, etc.) but also to fully deploy some
hardware capabilities, such as:
*
multi-microprocessors (multi-CPUs);
*
multi-core microprocessors;
* multi-disks (many disk I/O subsystems, see
Disk storage);
* etc.
Server Models
A webserver program, as any other server, can be implemented by using one of these server models:
* single process, finite state machine and non blocking or even asynchronous I/O;
* multi process, finite state machine and non blocking or even asynchronous I/O;
* single process, forking a new process for each request;
* multi process, with adaptive pre-forking of processes;
* single process, multithreaded;
* multi process, multithreaded.
The following sub-chapters summarize pros and contras of the main various models.
Finite state machine servers
To minimize the
context switches and to maximize the scalability, many small Web servers are implemented as a single process (or at most as a process per
CPU) and a
finite state machine.Every task is split into two or more small steps that are executed as needed (typically
on demand); by keeping the internal state of each connection and by using
non-blocking I/O or
asynchronous I/O, it is possible to implement ultra fast Web servers, at least for serving static content.
Threaded-based servers
Many Web servers are
multithreaded. This means that inside each server's process, there are two or more threads, each one able to execute its own task independently from the others.
When a user visits a Web site, a Web server will use a thread to serve the page to that user.If another user visits the site while the previous user is still being served, the Web server can serve the second visitor by using a different thread. Thus, the second user does not have to wait for the first visitor to be served.This is very important because not all users have the same speed Internet connection. A slow user should not delay all other visitors from downloading a Web page.
Threads are often used to serve dynamic content.
For better performance, threads used by Web servers and other Internet services are typically pooled and reused to eliminate even the small overhead associated with creating a thread.
Process-based servers
For reliability and security reasons, some Web servers using multiple
processes (rather than multiple threads within a single process) still remain in production use, such as Apache 1.3.
A pool of processes are used, and reused, until a certain threshold of requests have been served by a process before it is replaced by a new one.
Because threads share a main process context, a crashing thread may more easily crash the whole application, and a
buffer overflow can have more disastrous consequences.
Moreover, a
memory leak in system libraries which are out of the control of the application programmer cannot be dealt with using threads, but are appropriately dealt with using a pool of processes with a limited life time (because
OS automatically frees all the allocated memory, requested by a process, when the process dies).
Another problem relates to the wide variety of third party libraries which might be used by an application (a
PHP extension library for instance) which might not be
thread safe.
Using multiple processes also allows to deal with situations which can benefit from
privilege separation techniques to achieve better security and to work around some
OS limits which very often are per-process.
Mixed model servers
To leverage the advantages of finite state machines, threads and processes, many webservers implement a mixture of all these programming techniques, trying to use the best model for each task (i.e. for serving static or dynamic content, etc.).
A web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 60,000, by default between 500 and 1,000) per
IP address (and IP port) and it can serve only a certain maximum number of requests per second depending on:
* its own settings;
* the
HTTP request type;
* content origin (static or dynamic);
* the fact that the served content is or is not
cached;
* the
hardware and
software limits of the
OS where it is working.
When a web server is near to or over its limits, it becomes
overloaded and thus
unresponsive.
Overload Causes
At any time Web servers can be overloaded because of:
*
too much legal Web traffic (i.e. thousands or even millions of clients hitting the Web site in a short interval of time);
*
illegal DDoS (Distributed Denial of Service) attacks;
*
Internet slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
*
Web servers (computers) partial unavailability, this can happen because of required / urgent maintenance or upgrade,
HW or
SW failures,
back-end (i.e.
DB) failures, etc.; in these cases the remaining web servers get too much traffic and of course they become overloaded.
Overload Symptoms
The
symptoms of an
overloaded Web server are:
* requests are served with noticeably (long) delays (from 1 second to a few hundreds of seconds);
*
500, 503 HTTP errors are returned to clients (sometimes also unrelated
404 error may be returned);
*
TCP connections are refused or reset before any content is sent to clients.
Anti Overload Techniques
To partially overcome above load limits and to prevent the
overload scenario,most popular Web sites use common techniques like:
* deploying
Web cache techniques;
* using different
domain names to serve different (static and dynamic) content by separate Web servers, i.e.:
**
http://images.example.com
**
http://www.example.com
* using many Web servers (programs) per
computer, each one bound to its own
network card and
IP address;
* using many Web servers (computers) that are grouped together so that they act or are seen as one big Web server, see also:
Load balancer;
* adding more
HW resources (i.e.
RAM,
disks) to each
computer;
* tuning
OS parameters for
HW capabilities and usage;
* using more efficient
computer programs for Web servers, etc.;
* using other
workarounds, specially if dynamic content is involved.
In
1989 Tim Berners-Lee proposed to his employer
CERN (European center for nuclear research) a new project, which had the goal of easing the exchange of information between scientists by using a hypertext system. As a result of the implementation of this project, Berners-Lee wrote two programs: a
browser called
WorldWideWeb and the world's first Web server, which ran on
NeXTSTEP.Today, this machine is on exhibition at
CERN's public museum,
Microcosm.
The four top most common Web or HTTP server programs are:
*
Apache HTTP Server from the
Apache Software Foundation.
*
Internet Information Services (IIS) from
Microsoft.
*
Sun Java System Web Server from
Sun Microsystems, formerly
Sun ONE Web Server,
iPlanet Web Server, and
Netscape Enterprise Server.
*
Zeus Web Server from
Zeus Technology.
There are thousands of different Web server programs available, many of them are specialized for some uses and can be tailored to satisfy specific needs.
See
:Category:Web server software for a longer list of HTTP server programs.
The most popular Web servers, used for public Web sites,are tracked by
Netcraft Web Server Survey, with details given by
Netcraft Web Server Reports.
The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards.
Apache has been the most popular Web server on the Internet since April of 1996. The November 2005 Netcraft Web Server Survey found that more than 70% of the Web sites on the Internet are using Apache, thus making it more widely used than all other Web servers combined.The Apache HTTP Server is a project of the Apache Software Foundation
Another site provide statistics is SecuritySpace:[
1]and they also provide a detail break down for each version of Web server:[
2]
*
HTTP,
HTTPS*
comparison of web servers*
tiny web servers*
SSI,
CGI,
SCGI,
FastCGI,
PHP,
Java Servlet,
JavaServer Pages,
ASP,
ASP .NET,
Server API,
*
Virtual hosting*
LAMP (software bundle)*
Web browser*
Web log analysis software*
Web hosting service*RFC 2616, the
Request for Comments document that defines the
HTTP 1.1 protocol.