Веб сервер как пишется

веб-сервер

A web server is computer software and underlying hardware that accepts requests via HTTP (the network protocol created to distribute web content) or its secure variant HTTPS. A user agent, commonly a web browser or web crawler, initiates communication by making a request for a web page or other resource using HTTP, and the server responds with the content of that resource or an error message. A web server can also accept and store resources sent from the user agent if configured to do so.^[1]
[2]

The hardware used to run a web server can vary according to the volume of requests that it needs to handle. At the low end of the range are embedded systems, such as a router that runs a small web server as its configuration interface. A high-traffic Internet website might handle requests with hundreds of servers that run on racks of high-speed computers.

A resource sent from a web server can be a preexisting file (static content) available to the web server, or it can be generated at the time of the request (dynamic content) by another program that communicates with the server software. The former usually can be served faster and can be more easily cached for repeated requests, while the latter supports a broader range of applications.

Technologies such as REST and SOAP, which use HTTP as a basis for general computer-to-computer communication, as well as support for WebDAV extensions, have extended the application of web servers well beyond their original purpose of serving human-readable pages.

History[edit]

This is a very brief history of web server programs, so some information necessarily overlaps with the histories of the web browsers, the World Wide Web and the Internet; therefore, for the sake of clearness and understandability, some key historical information below reported may be similar to that found also in one or more of the above-mentioned history articles.

Initial WWW project (1989-1991)[edit]

In March 1989, Sir Tim Berners-Lee proposed a new project to his employer CERN, with the goal of easing the exchange of information between scientists by using a hypertext system. The proposal titled «HyperText and CERN», asked for comments and it was read by several people. In October 1990 the proposal was reformulated and enriched (having as co-author Robert Cailliau), and finally, it was approved.^{[3] [4] [5]}

Between late 1990 and early 1991 the project resulted in Berners-Lee and his developers writing and testing several software libraries along with three programs, which initially ran on NeXTSTEP OS installed on NeXT workstations:
^[6]
[7]
[5]

• a graphical web browser, called WorldWideWeb;
• a portable line mode web browser;
• a web server, later known as CERN httpd.

Those early browsers retrieved web pages from web server(s) using a new basic communication protocol that was named HTTP 0.9.

In August 1991 Tim Berner-Lee announced the birth of WWW technology and encouraged scientists to adopt and develop it.^[8] Soon after, those programs, along with their source code, were made available to people interested in their usage.^[6] In practice CERN informally allowed other people, including developers, etc., to play with and maybe further develop what it has been made till that moment. This was the official birth of CERN httpd. Since then Berner-Lee started promoting the adoption and the usage of those programs along with their porting to other OSs.^[5]

Fast and wild development (1991-1995)[edit]

In December 1991 the first web server outside Europe was installed at SLAC (U.S.A.).^[7] This was a very important event because it started trans-continental web communications between web browsers and web servers.

In 1991-1993 CERN web server program continued to be actively developed by the www group, meanwhile, thanks to the availability of its source code and the public specifications of the HTTP protocol, many other implementations of web servers started to be developed.

In April 1993 CERN issued a public official statement stating that the three components of Web software (the basic line-mode client, the web server and the library of common code), along with their source code, were put in the public domain.^[11] This statement freed web server developers from any possible legal issue about the development of derivative work based on that source code (a threat that in practice never existed).

At the beginning of 1994, the most notable among new web servers was NCSA httpd which ran on a variety of Unix-based OSs and could serve dynamically generated content by implementing the POST HTTP method and the CGI to communicate with external programs. These capabilities, along with the multimedia features of NCSA’s Mosaic browser (also able to manage HTML FORMs in order to send data to a web server) highlighted the potential of web technology for publishing and distributed computing applications.

In the second half of 1994, the development of NCSA httpd stalled to the point that a group of external software developers, webmasters and other professional figures interested in that server, started to write and collect patches thanks to the NCSA httpd source code being available to the public domain. At the beginning of 1995 those patches were all applied to the last release of NCSA source code and, after several tests, the Apache HTTP server project was started.^[12][13]

At the end of 1994 a new commercial web server, named Netsite, was released with specific features. It was the first one of many other similar products that were developed first by Netscape, then also by Sun Microsystems, and finally by Oracle Corporation.

In mid-1995 the first version of IIS was released, for Windows NT OS, by Microsoft. This marked the entry, in the field of World Wide Web technologies, of a very important commercial developer and vendor that has played and still is playing a key role on both sides (client and server) of the web.

In the second half of 1995 CERN and NCSA web servers started to decline (in global percentage usage) because of the widespread adoption of new web servers which had a much faster development cycle along with more features, more fixes applied, and more performances than the previous ones.

Explosive growth and competition (1996-2014)[edit]

At the end of 1996 there were already over fifty known (different) web server software programs that were available to everybody who wanted to own an Internet domain name and/or to host websites.^[15] Many of them lived only shortly and were replaced by other web servers.

The publication of RFCs about protocol versions HTTP/1.0 (1996) and HTTP/1.1 (1997, 1999), forced most web servers to comply (not always completely) with those standards. The use of TCP/IP persistent connections (HTTP/1.1) required web servers both to increase a lot the maximum number of concurrent connections allowed and to improve their level of scalability.

Between 1996 and 1999 Netscape Enterprise Server and Microsoft’s IIS emerged among the leading commercial options whereas among the freely available and open-source programs Apache HTTP Server held the lead as the preferred server (because of its reliability and its many features).

In those years there was also another commercial, highly innovative and thus notable web server called Zeus (now discontinued) that was known as one of the fastest and most scalable web servers available on market, at least till the first decade of 2000s, despite its low percentage of usage.

Apache resulted in the most used web server from mid-1996 to the end of 2015 when, after a few years of decline, it was surpassed initially by IIS and then by Nginx. Afterward IIS dropped to much lower percentages of usage than Apache (see also market share).

From 2005-2006 Apache started to improve its speed and its scalability level by introducing new performance features (e.g. event MPM and new content cache).^[16][17] As those new performance improvements initially were marked as experimental, they were not enabled by its users for a long time and so Apache suffered, even more, the competition of commercial servers and, above all, of other open-source servers which meanwhile had already achieved far superior performances (mostly when serving static content) since the beginning of their development and at the time of the Apache decline were able to offer also a long enough list of well tested advanced features.

In fact, a few years after 2000 started, not only other commercial and highly competitive web servers, e.g. LiteSpeed, but also many other open-source programs, often of excellent quality and very high performances, among which should be noted Hiawatha, Cherokee HTTP server, Lighttpd, Nginx and other derived/related products also available with commercial support, emerged.

Around 2007-2008 most popular web browsers increased their previous default limit of 2 persistent connections per host-domain (a limit recommended by RFC-2616) ^[18] to 4, 6 or 8 persistent connections per host-domain, in order to speed up the retrieval of heavy web pages with lots of images, and to mitigate the problem of the shortage of persistent connections dedicated to dynamic objects used for bi-directional notifications of events in web pages.^[19] Within a year, these changes, on average, nearly tripled the maximum number of persistent connections that web servers had to manage. This trend (of increasing the number of persistent connections) definitely gave a strong impetus to the adoption of reverse proxies in front of slower web servers and it gave also one more chance to the emerging new web servers that could show all their speed and their capability to handle very high numbers of concurrent connections without requiring too many hardware resources (expensive computers with lots of CPUs, RAM and fast disks).^[20]

New challenges (2015 and later years)[edit]

In 2015, RFCs published new protocol version [HTTP/2], and as the implementation of new specifications was not trivial at all, a dilemma arose among developers of less popular web servers (e.g. with a percentage of usage lower than 1% .. 2%), about adding or not adding support for that new protocol version.^[21][22]

In fact supporting HTTP/2 often required radical changes to their internal implementation due to many factors (practically always required encrypted connections, capability to distinguish between HTTP/1.x and HTTP/2 connections on the same TCP port, binary representation of HTTP messages, message priority, compression of HTTP headers, use of streams also known as TCP/IP sub-connections and related flow-control, etc.) and so a few developers of those web servers opted for not supporting new HTTP/2 version (at least in the near future) also because of these main reasons:^[21][22]

• protocols HTTP/1.x would have been supported anyway by browsers for a very long time (maybe forever) so that there would be no incompatibility between clients and servers in next future;
• implementing HTTP/2 was considered a task of overwhelming complexity that could open the door to a whole new class of bugs that till 2015 did not exist and so it would have required notable investments in developing and testing the implementation of the new protocol;
• adding HTTP/2 support could always be done in future in case the efforts would be justified.

Instead, developers of most popular web servers, rushed to offer the availability of new protocol, not only because they had the work force and the time to do so, but also because usually their previous implementation of SPDY protocol could be reused as a starting point and because most used web browsers implemented it very quickly for the same reason. Another reason that prompted those developers to act quickly was that webmasters felt the pressure of the ever increasing web traffic and they really wanted to install and to try — as soon as possible — something that could drastically lower the number of TCP/IP connections and speedup accesses to hosted websites.^[23]

In 2020–2021 the HTTP/2 dynamics about its implementation (by top web servers and popular web browsers) were partly replicated after the publication of advanced drafts of future RFC about HTTP/3 protocol.

Technical overview[edit]

The following technical overview should be considered only as an attempt to give a few very limited examples about some features that may be implemented in a web server and some of the tasks that it may perform in order to have a sufficiently wide scenario about the topic.

A web server program plays the role of a server in a client–server model by implementing one or more versions of HTTP protocol, often including the HTTPS secure variant and other features and extensions that are considered useful for its planned usage.

The complexity and the efficiency of a web server program may vary a lot depending on (e.g.):^[1]

• common features implemented;
• common tasks performed;
• performances and scalability level aimed as a goal;
• software model and techniques adopted to achieve wished performance and scalability level;
• target hardware and category of usage, e.g. embedded system, low-medium traffic web server, high traffic Internet web server.

Common features[edit]

Although web server programs differ in how they are implemented, most of them offer the following common features.

These are basic features that most web servers usually have.

• Static content serving: to be able to serve static content (web files) to clients via HTTP protocol.
• HTTP: support for one or more versions of HTTP protocol in order to send versions of HTTP responses compatible with versions of client HTTP requests, e.g. HTTP/1.0, HTTP/1.1 (eventually also with encrypted connections HTTPS), plus, if available, HTTP/2, HTTP/3.
• Logging: usually web servers have also the capability of logging some information, about client requests and server responses, to log files for security and statistical purposes.

A few other more advanced and popular features (only a very short selection) are the following ones.

• Dynamic content serving: to be able to serve dynamic content (generated on the fly) to clients via HTTP protocol.
• Virtual hosting: to be able to serve many websites (domain names) using only one IP address.
• Authorization: to be able to allow, to forbid or to authorize access to portions of website paths (web resources).
• Content cache: to be able to cache static and/or dynamic content in order to speed up server responses;
• 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 content responses in order to not saturate the network and to be able to serve more clients;
• Rewrite engine: to map parts of clean URLs (found in client requests) to their real names.
• Custom error pages: support for customized HTTP error messages.

Common tasks[edit]

A web server program, when it is running, usually performs several general tasks, (e.g.):^[1]

• starts, optionally reads and applies settings found in its configuration file(s) or elsewhere, optionally opens log file, starts listening to client connections / requests;
• optionally tries to adapt its general behavior according to its settings and its current operating conditions;
• manages client connection(s) (accepting new ones or closing the existing ones as required);
• receives client requests (by reading HTTP messages):
  • reads and verify each HTTP request message;
  • usually performs URL normalization;
  • usually performs URL mapping (which may default to URL path translation);
  • usually performs URL path translation along with various security checks;
• executes or refuses requested HTTP method:
  • optionally manages URL authorizations;
  • optionally manages URL redirections;
  • optionally manages requests for static resources (file contents):
    • optionally manages directory index files;
    • optionally manages regular files;
  • optionally manages requests for dynamic resources:
    • optionally manages directory listings;
    • optionally manages program or module processing, checking the availability, the start and eventually the stop of the execution of external programs used to generate dynamic content;
    • optionally manages the communications with external programs / internal modules used to generate dynamic content;
• replies to client requests sending proper HTTP responses (e.g. requested resources or error messages) eventually verifying or adding HTTP headers to those sent by dynamic programs / modules;
• optionally logs (partially or totally) client requests and/or its responses to an external user log file or to a system log file by syslog, usually using common log format;
• optionally logs process messages about detected anomalies or other notable events (e.g. in client requests or in its internal functioning) using syslog or some other system facilities; these log messages usually have a debug, warning, error, alert level which can be filtered (not logged) depending on some settings, see also severity level;
• optionally generates statistics about web traffic managed and/or its performances;
• other custom tasks.

Read request message[edit]

Web server programs are able:^{[24]
[25]
[26]}

• to read an HTTP request message;
• to interpret it;
• to verify its syntax;
• to identify known HTTP headers and to extract their values from them.

Once an HTTP request message has been decoded and verified, its values can be used to determine whether that request can be satisfied or not. This requires many other steps, including security checks.

URL normalization[edit]

Web server programs usually perform some type of URL normalization (URL found in most HTTP request messages) in order:

• to make resource path always a clean uniform path from root directory of website;
• to lower security risks (e.g. by intercepting more easily attempts to access static resources outside the root directory of the website or to access to portions of path below website root directory that are forbidden or which require authorization);
• to make path of web resources more recognizable by human beings and web log analysis programs (also known as log analyzers / statistical applications).

The term URL normalization refers to the process of modifying and standardizing a URL in a consistent manner. There are several types of normalization that may be performed, including the conversion of the scheme and host to lowercase. Among the most important normalizations are the removal of «.» and «..» path segments and adding trailing slashes to a non-empty path component.

URL mapping[edit]

«URL mapping is the process by which a URL is analyzed to figure out what resource it is referring to, so that that resource can be returned to the requesting client. This process is performed with every request that is made to a web server, with some of the requests being served with a file, such as an HTML document, or a gif image, others with the results of running a CGI program, and others by some other process, such as a built-in module handler, a PHP document, or a Java servlet.»^[27]

In practice, web server programs that implement advanced features, beyond the simple static content serving (e.g. URL rewrite engine, dynamic content serving), usually have to figure out how that URL has to be handled, e.g.:

• as a URL redirection, a redirection to another URL;
• as a static request of file content;
• as a dynamic request of:
  • directory listing of files or other sub-directories contained in that directory;
  • other types of dynamic request in order to identify the program / module processor able to handle that kind of URL path and to pass to it other URL parts, i.e. usually path-info and query string variables.

One or more configuration files of web server may specify the mapping of parts of URL path (e.g. initial parts of file path, filename extension and other path components) to a specific URL handler (file, directory, external program or internal module).^[28]

When a web server implements one or more of the above-mentioned advanced features then the path part of a valid URL may not always match an existing file system path under website directory tree (a file or a directory in file system) because it can refer to a virtual name of an internal or external module processor for dynamic requests.

URL path translation to file system[edit]

Web server programs are able to translate an URL path (all or part of it), that refers to a physical file system path, to an absolute path under the target website’s root directory.^[28]

Website’s root directory may be specified by a configuration file or by some internal rule of the web server by using the name of the website which is the host part of the URL found in HTTP client request.^[28]

Path translation to file system is done for the following types of web resources:

• a local, usually non-executable, file (static request for file content);
• a local directory (dynamic request: directory listing generated on the fly);
• a program name (dynamic requests that is executed using CGI or SCGI interface and whose output is read by web server and resent to client who made the HTTP request).

The web server appends the path found in requested URL (HTTP request message) and appends it to the path of the (Host) website root directory. On an Apache server, this is commonly /home/www/website (on Unix machines, usually it is: /var/www/website). See the following examples of how it may result.

URL path translation for a static file request

Example of a static request of an existing file specified by the following URL:

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

The client’s user agent connects to www.example.com and then sends the following HTTP/1.1 request:

GET /path/file.html HTTP/1.1
Host: www.example.com
Connection: keep-alive

The result is the local file system resource:

/home/www/www.example.com/path/file.html

The web server then reads the file, if it exists, and sends a response to the client’s web browser. The response will describe the content of the file and contain the file itself or an error message will return saying that the file does not exist or its access is forbidden.

URL path translation for a directory request (without a static index file)

Example of an implicit dynamic request of an existing directory specified by the following URL:

http://www.example.com/directory1/directory2/

The client’s user agent connects to www.example.com and then sends the following HTTP/1.1 request:

GET /directory1/directory2 HTTP/1.1
Host: www.example.com
Connection: keep-alive

The result is the local directory path:

/home/www/www.example.com/directory1/directory2/

The web server then verifies the existence of the directory and if it exists and it can be accessed then tries to find out an index file (which in this case does not exist) and so it passes the request to an internal module or a program dedicated to directory listings and finally reads data output and sends a response to the client’s web browser. The response will describe the content of the directory (list of contained subdirectories and files) or an error message will return saying that the directory does not exist or its access is forbidden.

URL path translation for a dynamic program request

For a dynamic request the URL path specified by the client should refer to an existing external program (usually an executable file with a CGI) used by the web server to generate dynamic content.^[29]

Example of a dynamic request using a program file to generate output:

http://www.example.com/cgi-bin/forum.php?action=view&orderby=thread&date=2021-10-15

The client’s user agent connects to www.example.com and then sends the following HTTP/1.1 request:

GET /cgi-bin/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1
Host: www.example.com
Connection: keep-alive

The result is the local file path of the program (in this example, a PHP program):

/home/www/www.example.com/cgi-bin/forum.php

The web server executes that program, passing in the path-info and the query string action=view&orderby=thread&date=2021-10-15 so that the program has the info it needs to run. (In this case, it will return an HTML document containing a view of forum entries ordered by thread from October 15th, 2021). In addition to this, the web server reads data sent from the external program and resends that data to the client that made the request.

Manage request message[edit]

Once a request has been read, interpreted, and verified, it has to be managed depending on its method, its URL, and its parameters, which may include values of HTTP headers.

In practice, the web server has to handle the request by using one of these response paths:^[28]

• if something in request was not acceptable (in status line or message headers), web server already sent an error response;
• if request has a method (e.g. OPTIONS) that can be satisfied by general code of web server then a successful response is sent;
• if URL requires authorization then an authorization error message is sent;
• if URL maps to a redirection then a redirect message is sent;
• if URL maps to a dynamic resource (a virtual path or a directory listing) then its handler (an internal module or an external program) is called and request parameters (query string and path info) are passed to it in order to allow it to reply to that request;
• if URL maps to a static resource (usually a file on file system) then the internal static handler is called to send that file;
• if request method is not known or if there is some other unacceptable condition (e.g. resource not found, internal server error, etc.) then an error response is sent.

Serve static content[edit]

If a web server program is capable of serving static content and it has been configured to do so, then it is able to send file content whenever a request message has a valid URL path matching (after URL mapping, URL translation and URL redirection) that of an existing file under the root directory of a website and file has attributes which match those required by internal rules of web server program.^[28]

That kind of content is called static because usually it is not changed by the web server when it is sent to clients and because it remains the same until it is modified (file modification) by some program.

NOTE: when serving static content only, a web server program usually does not change file contents of served websites (as they are only read and never written) and so it suffices to support only these HTTP methods:

• OPTIONS
• HEAD
• GET

Response of static file content can be sped up by a file cache.

Directory index files[edit]

If a web server program receives a client request message with an URL whose path matches one of an existing directory and that directory is accessible and serving directory index file(s) is enabled then a web server program may try to serve the first of known (or configured) static index file names (a regular file) found in that directory; if no index file is found or other conditions are not met then an error message is returned.

Most used names for static index files are: index.html, index.htm and Default.htm.

Regular files[edit]

If a web server program receives a client request message with an URL whose path matches the file name of an existing file and that file is accessible by web server program and its attributes match internal rules of web server program, then web server program can send that file to client.

Usually, for security reasons, most web server programs are pre-configured to serve only regular files or to avoid to use special file types like device files, along with symbolic links or hard links to them. The aim is to avoid undesirable side effects when serving static web resources.^[30]

Serve dynamic content[edit]

If a web server program is capable of serving dynamic content and it has been configured to do so, then it is able to communicate with the proper internal module or external program (associated with the requested URL path) in order to pass to it parameters of client request; after that, web server program reads from it its data response (that it has generated, often on the fly) and then it resends it to the client program who made the request.^{[citation needed]}

NOTE: when serving static and dynamic content, a web server program usually has to support also the following HTTP method in order to be able to safely receive data from client(s) and so to be able to host also websites with interactive form(s) that may send large data sets (e.g. lots of data entry or file uploads) to web server / external programs / modules:

• POST

In order to be able to communicate with its internal modules and/or external programs, a web server program must have implemented one or more of the many available gateway interface(s) (see also Web Server Gateway Interfaces used for dynamic content).

The three standard and historical gateway interfaces are the following ones.

CGI

An external CGI program is run by web server program for each dynamic request, then web server program reads from it the generated data response and then resends it to client.

SCGI

An external SCGI program (it usually is a process) is started once by web server program or by some other program / process and then it waits for network connections; every time there is a new request for it, web server program makes a new network connection to it in order to send request parameters and to read its data response, then network connection is closed.

FastCGI

An external FastCGI program (it usually is a process) is started once by web server program or by some other program / process and then it waits for a network connection which is established permanently by web server; through that connection are sent the request parameters and read data responses.

Directory listings[edit]

A web server program may be capable to manage the dynamic generation (on the fly) of a directory index list of files and sub-directories.^[31]

If a web server program is configured to do so and a requested URL path matches an existing directory and its access is allowed and no static index file is found under that directory then a web page (usually in HTML format), containing the list of files and/or subdirectories of above mentioned directory, is dynamically generated (on the fly). If it cannot be generated an error is returned.

Some web server programs allow the customization of directory listings by allowing the usage of a web page template (an HTML document containing placeholders, e.g. $(FILE_NAME), $(FILE_SIZE), etc., that are replaced with the field values of each file entry found in directory by web server), e.g. index.tpl or the usage of HTML and embedded source code that is interpreted and executed on the fly, e.g. index.asp, and / or by supporting the usage of dynamic index programs such as CGIs, SCGIs, FGCIs, e.g. index.cgi, index.php, index.fcgi.

Usage of dynamically generated directory listings is usually avoided or limited to a few selected directories of a website because that generation takes much more OS resources than sending a static index page.

The main usage of directory listings is to allow the download of files (usually when their names, sizes, modification date-times or file attributes may change randomly / frequently) as they are, without requiring to provide further information to requesting user.^[32]

Program or module processing[edit]

An external program or an internal module (processing unit) can execute some sort of application function that may be used to get data from or to store data to one or more data repositories, e.g.:^{[citation needed]}

• files (file system);
• databases (DBs);
• other sources located in local computer or in other computers.

A processing unit can return any kind of web content, also by using data retrieved from a data repository, e.g.:^{[citation needed]}

• a document (e.g. HTML, XML, etc.);
• an image;
• a video;
• structured data, e.g. that may be used to update one or more values displayed by a dynamic page (DHTML) of a web interface and that maybe was requested by an XMLHttpRequest API (see also: dynamic page).

In practice whenever there is content that may vary, depending on one or more parameters contained in client request or in configuration settings, then, usually, it is generated dynamically.

Send response message[edit]

Web server programs are able to send response messages as replies to client request messages.^[24]

An error response message may be sent because a request message could not be successfully read or decoded or analyzed or executed.^[25]

NOTE: the following sections are reported only as examples to help to understand what a web server, more or less, does; these sections are by any means neither exhaustive nor complete.

Error message[edit]

A web server program may reply to a client request message with many kinds of error messages, anyway these errors are divided mainly in two categories:

• HTTP client errors, due to the type of request message or to the availability of requested web resource;^[33]
• HTTP server errors, due to internal server errors.^[34]

When an error response / message is received by a client browser, then if it is related to the main user request (e.g. an URL of a web resource such as a web page) then usually that error message is shown in some browser window / message.

[edit]

A web server program may be able to verify whether the requested URL path:^[35]

• can be freely accessed by everybody;
• requires a user authentication (request of user credentials, e.g. such as user name and password);
• access is forbidden to some or all kind of users.

If the authorization / access rights feature has been implemented and enabled and access to web resource is not granted, then, depending on the required access rights, a web server program:

• can deny access by sending a specific error message (e.g. access forbidden);
• may deny access by sending a specific error message (e.g. access unauthorized) that usually forces the client browser to ask human user to provide required user credentials; if authentication credentials are provided then web server program verifies and accepts or rejects them.

URL redirection[edit]

A web server program may have the capability of doing URL redirections to new URLs (new locations) which consists in replying to a client request message with a response message containing a new URL suited to access a valid or an existing web resource (client should redo the request with the new URL).^[36]

URL redirection of location is used:^[36]

• to fix a directory name by adding a final slash ‘/’;^[31]
• to give a new URL for a no more existing URL path to a new path where that kind of web resource can be found.
• to give a new URL to another domain when current domain has too much load.

Example 1: a URL path points to a directory name but it does not have a final slash ‘/’ so web server sends a redirect to client in order to instruct it to redo the request with the fixed path name.^[31]

From:
  /directory1/directory2
To:
  /directory1/directory2/

Example 2: a whole set of documents has been moved inside website in order to reorganize their file system paths.

From:
  /directory1/directory2/2021-10-08/
To:
  /directory1/directory2/2021/10/08/

Example 3: a whole set of documents has been moved to a new website and now it is mandatory to use secure HTTPS connections to access them.

From:
  http://www.example.com/directory1/directory2/2021-10-08/
To:
  https://docs.example.com/directory1/2021-10-08/

Above examples are only a few of the possible kind of redirections.

Successful message[edit]

A web server program is able to reply to a valid client request message with a successful message, optionally containing requested web resource data.^[37]

If web resource data is sent back to client, then it can be static content or dynamic content depending on how it has been retrieved (from a file or from the output of some program / module).

Content cache[edit]

In order to speed up web server responses by lowering average HTTP response times and hardware resources used, many popular web servers implement one or more content caches, each one specialized in a content category.^[38]
[39]

Content is usually cached by its origin, e.g.:

• static content:
  • file cache;
• dynamic content:
  • dynamic cache (module / program output).

File cache[edit]

Historically, static contents found in files which had to be accessed frequently, randomly and quickly, have been stored mostly on electro-mechanical disks since mid-late 1960s / 1970s; regrettably reads from and writes to those kind of devices have always been considered very slow operations when compared to RAM speed and so, since early OSs, first disk caches and then also OS file cache sub-systems were developed to speed up I/O operations of frequently accessed data / files.

Even with the aid of an OS file cache, the relative / occasional slowness of I/O operations involving directories and files stored on disks became soon a bottleneck in the increase of performances expected from top level web servers, specially since mid-late 1990s, when web Internet traffic started to grow exponentially along with the constant increase of speed of Internet / network lines.

The problem about how to further efficiently speed-up the serving of static files, thus increasing the maximum number of requests/responses per second (RPS), started to be studied / researched since mid 1990s, with the aim to propose useful cache models that could be implemented in web server programs.^[40]

In practice, nowadays, many popular / high performance web server programs include their own userland file cache, tailored for a web server usage and using their specific implementation and parameters.^{[41]
[42]
[43]}

The wide spread adoption of RAID and/or fast solid-state drives (storage hardware with very high I/O speed) has slightly reduced but of course not eliminated the advantage of having a file cache incorporated in a web server.

Dynamic cache[edit]

Dynamic content, output by an internal module or an external program, may not always change very frequently (given a unique URL with keys / parameters) and so, maybe for a while (e.g. from 1 second to several hours or more), the resulting output can be cached in RAM or even on a fast disk.^[44]

The typical usage of a dynamic cache is when a website has dynamic web pages about news, weather, images, maps, etc. that do not change frequently (e.g. every n minutes) and that are accessed by a huge number of clients per minute / hour; in those cases it is useful to return cached content too (without calling the internal module or the external program) because clients often do not have an updated copy of the requested content in their browser caches.^[45]

Anyway, in most cases those kind of caches are implemented by external servers (e.g. reverse proxy) or by storing dynamic data output in separate computers, managed by specific applications (e.g. memcached), in order to not compete for hardware resources (CPU, RAM, disks) with web server(s).^[46]
[47]

Kernel-mode and user-mode web servers[edit]

A web server software can be either incorporated into the OS and executed in kernel space, or it can be executed in user space (like other regular applications).

Web servers that run in kernel mode (usually called kernel space web servers) can have direct access to kernel resources and so they can be, in theory, faster than those running in user mode; anyway there are disadvantages in running a web server in kernel mode, e.g.: difficulties in developing (debugging) software whereas run-time critical errors may lead to serious problems in OS kernel.

Web servers that run in user-mode have to ask the system for permission to use more memory or more CPU resources. Not only do these requests to the kernel take time, but they might not always be satisfied because the system reserves resources for its own usage and has the responsibility to share hardware resources with all the other running applications. Executing in user mode can also mean using more buffer/data copies (between user-space and kernel-space) which can lead to a decrease in the performance of a user-mode web server.

Nowadays almost all web server software is executed in user mode (because many of the aforementioned small disadvantages have been overcome by faster hardware, new OS versions, much faster OS system calls and new optimized web server software). See also comparison of web server software to discover which of them run in kernel mode or in user mode (also referred as kernel space or user space).

Performances[edit]

To improve the user experience (on client / browser side), a web server should reply quickly (as soon as possible) to client requests; unless content response is throttled (by configuration) for some type of files (e.g. big or huge files), also returned data content should be sent as fast as possible (high transfer speed).

In other words, a web server should always be very responsive, even under high load of web traffic, in order to keep total user’s wait (sum of browser time + network time + web server response time) for a response as low as possible.

Performance metrics[edit]

For web server software, main key performance metrics (measured under vary operating conditions) usually are at least the following ones (i.e.):^[48]
[49]

• number of requests per second (RPS, similar to QPS, depending on HTTP version and configuration, type of HTTP requests and other operating conditions);
• number of connections per second (CPS), is the number of connections per second accepted by web server (useful when using HTTP/1.0 or HTTP/1.1 with a very low limit of requests / responses per connection, i.e. 1 .. 20);
• network latency + response time for each new client request; usually benchmark tool shows how many requests have been satisfied within a scale of time laps (e.g. within 1ms, 3ms, 5ms, 10ms, 20ms, 30ms, 40ms) and / or the shortest, the average and the longest response time;
• throughput of responses, in bytes per second.

Among the operating conditions, the number (1 .. n) of concurrent client connections used during a test is an important parameter because it allows to correlate the concurrency level supported by web server with results of the tested performance metrics.

Software efficiency[edit]

The specific web server software design and model adopted (e.g.):

• single process or multi-process;
• single thread (no thread) or multi-thread for each process;
• usage of coroutines or not;

… and other programming techniques, such as (e.g.):

• zero copy;
• minimization of possible CPU cache misses;
• minimization of possible CPU branch mispredictions in critical paths for speed;
• minimization of the number of system calls used to perform a certain function / task;
• other tricks;

… used to implement a web server program, can bias a lot the performances and in particular the scalability level that can be achieved under heavy load or when using high end hardware (many CPUs, disks and lots of RAM).

In practice some web server software models may require more OS resources (specially more CPUs and more RAM) than others to be able to work well and so to achieve target performances.

Operating conditions[edit]

There are many operating conditions that can affect the performances of a web server; performance values may vary depending on (i.e.):

• the settings of web server (including the fact that log file is or is not enabled, etc.);
• the HTTP version used by client requests;
• the average HTTP request type (method, length of HTTP headers and optional body);
• whether the requested content is static or dynamic;
• whether the content is cached or not cached (by server and/or by client);
• whether the content is compressed on the fly (when transferred), pre-compressed (i.e. when a file resource is stored on disk already compressed so that web server can send that file directly to the network with the only indication that its content is compressed) or not compressed at all;
• whether the connections are or are not encrypted;
• the average network speed between web server and its clients;
• the number of active TCP connections;
• the number of active processes managed by web server (including external CGI, SCGI, FCGI programs);
• the hardware and software limitations or settings of the OS of the computer(s) on which the web server runs;
• other minor conditions.

Benchmarking[edit]

Performances of a web server are typically benchmarked by using one or more of the available
automated load testing tools.

Load limits[edit]

A web server (program installation) usually has pre-defined load limits for each combination of operating conditions, also because it is limited by OS resources and because it can handle only a limited number of concurrent client connections (usually between 2 and several tens of thousands for each active web server process, see also the C10k problem and the C10M problem).

When a web server is near to or over its load limits, it gets overloaded and so it may become unresponsive.

Causes of overload[edit]

At any time web servers can be overloaded due to one or more of the following causes (e.g.).

• Excess legitimate web traffic. Thousands or even millions of clients connecting to the website in a short amount of time, e.g., Slashdot effect.
• Distributed Denial of Service attacks. A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer or network resource unavailable to its intended users.
• Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them).
• XSS worms can cause high traffic because of millions of infected browsers or web servers.
• Internet bots Traffic not filtered/limited on large websites with very few network resources (e.g. bandwidth) and/or hardware resources (CPUs, RAM, disks).
• Internet (network) slowdowns (e.g. due to packet losses) so that client requests are served more slowly and the number of connections increases so much that server limits are reached.
• Web servers, serving dynamic content, waiting for slow responses coming from back-end computer(s) (e.g. databases), maybe because of too many queries mixed with too many inserts or updates of DB data; in these cases web servers have to wait for back-end data responses before replying to HTTP clients but during these waits too many new client connections / requests arrive and so they become overloaded.
• Web servers (computers) partial unavailability. This can happen because of required or urgent maintenance or upgrade, hardware or software failures such as back-end (e.g. database) failures; in these cases the remaining web servers may get too much traffic and become overloaded.

Symptoms of overload[edit]

The symptoms of an overloaded web server are usually the following ones (e.g.).

• 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,^[50][51] 503,^[52] 504,^[53] 408, or even an intermittent 404.
• 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 behavior can be considered a bug, even if it usually arises as a symptom of overload.

Anti-overload techniques[edit]

To partially overcome above average load limits and to prevent overload, most popular websites use common techniques like the following ones (e.g.).

• Tuning OS parameters for hardware capabilities and usage.
• Tuning web server(s) parameters to improve their security and performances.
• Deploying web cache techniques (not only for static contents but, whenever possible, for dynamic contents too).
• Managing network traffic, by using:
  • Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns;
  • HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns;
  • Bandwidth management and traffic shaping, in order to smooth down peaks in network usage.
• Using different domain names, IP addresses and computers to serve different kinds (static and dynamic) of content; the aim is to separate big or huge files (download.*) (that domain might be replaced also by a CDN) from small and medium-sized files (static.*) and from main dynamic site (maybe where some contents are stored in a backend database) (www.*); the idea is to be able to efficiently serve big or huge (over 10 – 1000 MB) files (maybe throttling downloads) and to fully cache small and medium-sized files, without affecting performances of dynamic site under heavy load, by using different settings for each (group) of web server computers, e.g.:
  • https://download.example.com
  • https://static.example.com
  • https://www.example.com
• Using many web servers (computers) that are grouped together behind a load balancer so that they act or are seen as one big web server.
• Adding more hardware resources (i.e. RAM, fast disks) to each computer.
• Using more efficient computer programs for web servers (see also: software efficiency).
• Using the most efficient Web Server Gateway Interface to process dynamic requests (spawning one or more external programs every time a dynamic page is retrieved, kills performances).
• Using other programming techniques and workarounds, especially if dynamic content is involved, to speed up the HTTP responses (i.e. by avoiding dynamic calls to retrieve objects, such as style sheets, images and scripts), that never change or change very rarely, by copying that content to static files once and then keeping them synchronized with dynamic content).
• Using latest efficient versions of HTTP (e.g. beyond using common HTTP/1.1 also by enabling HTTP/2 and maybe HTTP/3 too, whenever available web server software has reliable support for the latter two protocols) in order to reduce a lot the number of TCP/IP connections started by each client and the size of data exchanged (because of more compact HTTP headers representation and maybe data compression).

Caveats about using HTTP/2 and HTTP/3 protocols

Even if newer HTTP (2 and 3) protocols usually generate less network traffic for each request / response data, they may require more OS resources (i.e. RAM and CPU) used by web server software (because of encrypted data, lots of stream buffers and other implementation details); besides this, HTTP/2 and maybe HTTP/3 too, depending also on settings of web server and client program, may not be the best options for data upload of big or huge files at very high speed because their data streams are optimized for concurrency of requests and so, in many cases, using HTTP/1.1 TCP/IP connections may lead to better results / higher upload speeds (your mileage may vary).^[54][55]

[edit]

Below are the latest statistics of the market share of all sites of the top web servers on the Internet by Netcraft.

NOTE: (*) percentage rounded to integer number, because its decimal values are not publicly reported by source page (only its rounded value is reported in graph).

See also[edit]

• Server (computing)
• Application server
• Comparison of web server software
• HTTP server (core part of a web server program that serves HTTP requests)
• HTTP compression
• Web application
• Open source web application
• List of AMP packages
• Variant object
• Virtual hosting
• Web hosting service
• Web container
• Web proxy
• Web service

Standard Web Server Gateway Interfaces used for dynamic contents:

• CGI Common Gateway Interface
• SCGI Simple Common Gateway Interface
• FastCGI Fast Common Gateway Interface

A few other Web Server Interfaces (server or programming language specific) used for dynamic contents:

• SSI Server Side Includes, rarely used, static HTML documents containing SSI directives are interpreted by server software to include small dynamic data on the fly when pages are served, e.g. date and time, other static file contents, etc.
• SAPI Server Application Programming Interface:
  • ISAPI Internet Server Application Programming Interface
  • NSAPI Netscape Server Application Programming Interface
• PSGI Perl Web Server Gateway Interface
• WSGI Python Web Server Gateway Interface
• Rack Rack Web Server Gateway Interface
• JSGI JavaScript Web Server Gateway Interface
• Java Servlet, JavaServer Pages
• Active Server Pages, ASP.NET

References[edit]

External links[edit]

• Mozilla: what is a web server?
• Netcraft: news about web server survey

A web server is computer software and underlying hardware that accepts requests via HTTP (the network protocol created to distribute web content) or its secure variant HTTPS. A user agent, commonly a web browser or web crawler, initiates communication by making a request for a web page or other resource using HTTP, and the server responds with the content of that resource or an error message. A web server can also accept and store resources sent from the user agent if configured to do so.^[1]
[2]

The hardware used to run a web server can vary according to the volume of requests that it needs to handle. At the low end of the range are embedded systems, such as a router that runs a small web server as its configuration interface. A high-traffic Internet website might handle requests with hundreds of servers that run on racks of high-speed computers.

A resource sent from a web server can be a preexisting file (static content) available to the web server, or it can be generated at the time of the request (dynamic content) by another program that communicates with the server software. The former usually can be served faster and can be more easily cached for repeated requests, while the latter supports a broader range of applications.

Technologies such as REST and SOAP, which use HTTP as a basis for general computer-to-computer communication, as well as support for WebDAV extensions, have extended the application of web servers well beyond their original purpose of serving human-readable pages.

History[edit]

This is a very brief history of web server programs, so some information necessarily overlaps with the histories of the web browsers, the World Wide Web and the Internet; therefore, for the sake of clearness and understandability, some key historical information below reported may be similar to that found also in one or more of the above-mentioned history articles.

Initial WWW project (1989-1991)[edit]

In March 1989, Sir Tim Berners-Lee proposed a new project to his employer CERN, with the goal of easing the exchange of information between scientists by using a hypertext system. The proposal titled «HyperText and CERN», asked for comments and it was read by several people. In October 1990 the proposal was reformulated and enriched (having as co-author Robert Cailliau), and finally, it was approved.^{[3] [4] [5]}

Between late 1990 and early 1991 the project resulted in Berners-Lee and his developers writing and testing several software libraries along with three programs, which initially ran on NeXTSTEP OS installed on NeXT workstations:
^[6]
[7]
[5]

• a graphical web browser, called WorldWideWeb;
• a portable line mode web browser;
• a web server, later known as CERN httpd.

Those early browsers retrieved web pages from web server(s) using a new basic communication protocol that was named HTTP 0.9.

In August 1991 Tim Berner-Lee announced the birth of WWW technology and encouraged scientists to adopt and develop it.^[8] Soon after, those programs, along with their source code, were made available to people interested in their usage.^[6] In practice CERN informally allowed other people, including developers, etc., to play with and maybe further develop what it has been made till that moment. This was the official birth of CERN httpd. Since then Berner-Lee started promoting the adoption and the usage of those programs along with their porting to other OSs.^[5]

Fast and wild development (1991-1995)[edit]

In December 1991 the first web server outside Europe was installed at SLAC (U.S.A.).^[7] This was a very important event because it started trans-continental web communications between web browsers and web servers.

In 1991-1993 CERN web server program continued to be actively developed by the www group, meanwhile, thanks to the availability of its source code and the public specifications of the HTTP protocol, many other implementations of web servers started to be developed.

In April 1993 CERN issued a public official statement stating that the three components of Web software (the basic line-mode client, the web server and the library of common code), along with their source code, were put in the public domain.^[11] This statement freed web server developers from any possible legal issue about the development of derivative work based on that source code (a threat that in practice never existed).

At the beginning of 1994, the most notable among new web servers was NCSA httpd which ran on a variety of Unix-based OSs and could serve dynamically generated content by implementing the POST HTTP method and the CGI to communicate with external programs. These capabilities, along with the multimedia features of NCSA’s Mosaic browser (also able to manage HTML FORMs in order to send data to a web server) highlighted the potential of web technology for publishing and distributed computing applications.

In the second half of 1994, the development of NCSA httpd stalled to the point that a group of external software developers, webmasters and other professional figures interested in that server, started to write and collect patches thanks to the NCSA httpd source code being available to the public domain. At the beginning of 1995 those patches were all applied to the last release of NCSA source code and, after several tests, the Apache HTTP server project was started.^[12][13]

At the end of 1994 a new commercial web server, named Netsite, was released with specific features. It was the first one of many other similar products that were developed first by Netscape, then also by Sun Microsystems, and finally by Oracle Corporation.

In mid-1995 the first version of IIS was released, for Windows NT OS, by Microsoft. This marked the entry, in the field of World Wide Web technologies, of a very important commercial developer and vendor that has played and still is playing a key role on both sides (client and server) of the web.

In the second half of 1995 CERN and NCSA web servers started to decline (in global percentage usage) because of the widespread adoption of new web servers which had a much faster development cycle along with more features, more fixes applied, and more performances than the previous ones.

Explosive growth and competition (1996-2014)[edit]

At the end of 1996 there were already over fifty known (different) web server software programs that were available to everybody who wanted to own an Internet domain name and/or to host websites.^[15] Many of them lived only shortly and were replaced by other web servers.

The publication of RFCs about protocol versions HTTP/1.0 (1996) and HTTP/1.1 (1997, 1999), forced most web servers to comply (not always completely) with those standards. The use of TCP/IP persistent connections (HTTP/1.1) required web servers both to increase a lot the maximum number of concurrent connections allowed and to improve their level of scalability.

Between 1996 and 1999 Netscape Enterprise Server and Microsoft’s IIS emerged among the leading commercial options whereas among the freely available and open-source programs Apache HTTP Server held the lead as the preferred server (because of its reliability and its many features).

In those years there was also another commercial, highly innovative and thus notable web server called Zeus (now discontinued) that was known as one of the fastest and most scalable web servers available on market, at least till the first decade of 2000s, despite its low percentage of usage.

Apache resulted in the most used web server from mid-1996 to the end of 2015 when, after a few years of decline, it was surpassed initially by IIS and then by Nginx. Afterward IIS dropped to much lower percentages of usage than Apache (see also market share).

From 2005-2006 Apache started to improve its speed and its scalability level by introducing new performance features (e.g. event MPM and new content cache).^[16][17] As those new performance improvements initially were marked as experimental, they were not enabled by its users for a long time and so Apache suffered, even more, the competition of commercial servers and, above all, of other open-source servers which meanwhile had already achieved far superior performances (mostly when serving static content) since the beginning of their development and at the time of the Apache decline were able to offer also a long enough list of well tested advanced features.

In fact, a few years after 2000 started, not only other commercial and highly competitive web servers, e.g. LiteSpeed, but also many other open-source programs, often of excellent quality and very high performances, among which should be noted Hiawatha, Cherokee HTTP server, Lighttpd, Nginx and other derived/related products also available with commercial support, emerged.

Around 2007-2008 most popular web browsers increased their previous default limit of 2 persistent connections per host-domain (a limit recommended by RFC-2616) ^[18] to 4, 6 or 8 persistent connections per host-domain, in order to speed up the retrieval of heavy web pages with lots of images, and to mitigate the problem of the shortage of persistent connections dedicated to dynamic objects used for bi-directional notifications of events in web pages.^[19] Within a year, these changes, on average, nearly tripled the maximum number of persistent connections that web servers had to manage. This trend (of increasing the number of persistent connections) definitely gave a strong impetus to the adoption of reverse proxies in front of slower web servers and it gave also one more chance to the emerging new web servers that could show all their speed and their capability to handle very high numbers of concurrent connections without requiring too many hardware resources (expensive computers with lots of CPUs, RAM and fast disks).^[20]

New challenges (2015 and later years)[edit]

In 2015, RFCs published new protocol version [HTTP/2], and as the implementation of new specifications was not trivial at all, a dilemma arose among developers of less popular web servers (e.g. with a percentage of usage lower than 1% .. 2%), about adding or not adding support for that new protocol version.^[21][22]

In fact supporting HTTP/2 often required radical changes to their internal implementation due to many factors (practically always required encrypted connections, capability to distinguish between HTTP/1.x and HTTP/2 connections on the same TCP port, binary representation of HTTP messages, message priority, compression of HTTP headers, use of streams also known as TCP/IP sub-connections and related flow-control, etc.) and so a few developers of those web servers opted for not supporting new HTTP/2 version (at least in the near future) also because of these main reasons:^[21][22]

• protocols HTTP/1.x would have been supported anyway by browsers for a very long time (maybe forever) so that there would be no incompatibility between clients and servers in next future;
• implementing HTTP/2 was considered a task of overwhelming complexity that could open the door to a whole new class of bugs that till 2015 did not exist and so it would have required notable investments in developing and testing the implementation of the new protocol;
• adding HTTP/2 support could always be done in future in case the efforts would be justified.

Instead, developers of most popular web servers, rushed to offer the availability of new protocol, not only because they had the work force and the time to do so, but also because usually their previous implementation of SPDY protocol could be reused as a starting point and because most used web browsers implemented it very quickly for the same reason. Another reason that prompted those developers to act quickly was that webmasters felt the pressure of the ever increasing web traffic and they really wanted to install and to try — as soon as possible — something that could drastically lower the number of TCP/IP connections and speedup accesses to hosted websites.^[23]

In 2020–2021 the HTTP/2 dynamics about its implementation (by top web servers and popular web browsers) were partly replicated after the publication of advanced drafts of future RFC about HTTP/3 protocol.

Technical overview[edit]

The following technical overview should be considered only as an attempt to give a few very limited examples about some features that may be implemented in a web server and some of the tasks that it may perform in order to have a sufficiently wide scenario about the topic.

A web server program plays the role of a server in a client–server model by implementing one or more versions of HTTP protocol, often including the HTTPS secure variant and other features and extensions that are considered useful for its planned usage.

The complexity and the efficiency of a web server program may vary a lot depending on (e.g.):^[1]

• common features implemented;
• common tasks performed;
• performances and scalability level aimed as a goal;
• software model and techniques adopted to achieve wished performance and scalability level;
• target hardware and category of usage, e.g. embedded system, low-medium traffic web server, high traffic Internet web server.

Common features[edit]

Although web server programs differ in how they are implemented, most of them offer the following common features.

These are basic features that most web servers usually have.

• Static content serving: to be able to serve static content (web files) to clients via HTTP protocol.
• HTTP: support for one or more versions of HTTP protocol in order to send versions of HTTP responses compatible with versions of client HTTP requests, e.g. HTTP/1.0, HTTP/1.1 (eventually also with encrypted connections HTTPS), plus, if available, HTTP/2, HTTP/3.
• Logging: usually web servers have also the capability of logging some information, about client requests and server responses, to log files for security and statistical purposes.

A few other more advanced and popular features (only a very short selection) are the following ones.

• Dynamic content serving: to be able to serve dynamic content (generated on the fly) to clients via HTTP protocol.
• Virtual hosting: to be able to serve many websites (domain names) using only one IP address.
• Authorization: to be able to allow, to forbid or to authorize access to portions of website paths (web resources).
• Content cache: to be able to cache static and/or dynamic content in order to speed up server responses;
• 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 content responses in order to not saturate the network and to be able to serve more clients;
• Rewrite engine: to map parts of clean URLs (found in client requests) to their real names.
• Custom error pages: support for customized HTTP error messages.

Common tasks[edit]

A web server program, when it is running, usually performs several general tasks, (e.g.):^[1]

• starts, optionally reads and applies settings found in its configuration file(s) or elsewhere, optionally opens log file, starts listening to client connections / requests;
• optionally tries to adapt its general behavior according to its settings and its current operating conditions;
• manages client connection(s) (accepting new ones or closing the existing ones as required);
• receives client requests (by reading HTTP messages):
  • reads and verify each HTTP request message;
  • usually performs URL normalization;
  • usually performs URL mapping (which may default to URL path translation);
  • usually performs URL path translation along with various security checks;
• executes or refuses requested HTTP method:
  • optionally manages URL authorizations;
  • optionally manages URL redirections;
  • optionally manages requests for static resources (file contents):
    • optionally manages directory index files;
    • optionally manages regular files;
  • optionally manages requests for dynamic resources:
    • optionally manages directory listings;
    • optionally manages program or module processing, checking the availability, the start and eventually the stop of the execution of external programs used to generate dynamic content;
    • optionally manages the communications with external programs / internal modules used to generate dynamic content;
• replies to client requests sending proper HTTP responses (e.g. requested resources or error messages) eventually verifying or adding HTTP headers to those sent by dynamic programs / modules;
• optionally logs (partially or totally) client requests and/or its responses to an external user log file or to a system log file by syslog, usually using common log format;
• optionally logs process messages about detected anomalies or other notable events (e.g. in client requests or in its internal functioning) using syslog or some other system facilities; these log messages usually have a debug, warning, error, alert level which can be filtered (not logged) depending on some settings, see also severity level;
• optionally generates statistics about web traffic managed and/or its performances;
• other custom tasks.

Read request message[edit]

Web server programs are able:^{[24]
[25]
[26]}

• to read an HTTP request message;
• to interpret it;
• to verify its syntax;
• to identify known HTTP headers and to extract their values from them.

Once an HTTP request message has been decoded and verified, its values can be used to determine whether that request can be satisfied or not. This requires many other steps, including security checks.

URL normalization[edit]

Web server programs usually perform some type of URL normalization (URL found in most HTTP request messages) in order:

• to make resource path always a clean uniform path from root directory of website;
• to lower security risks (e.g. by intercepting more easily attempts to access static resources outside the root directory of the website or to access to portions of path below website root directory that are forbidden or which require authorization);
• to make path of web resources more recognizable by human beings and web log analysis programs (also known as log analyzers / statistical applications).

The term URL normalization refers to the process of modifying and standardizing a URL in a consistent manner. There are several types of normalization that may be performed, including the conversion of the scheme and host to lowercase. Among the most important normalizations are the removal of «.» and «..» path segments and adding trailing slashes to a non-empty path component.

URL mapping[edit]

«URL mapping is the process by which a URL is analyzed to figure out what resource it is referring to, so that that resource can be returned to the requesting client. This process is performed with every request that is made to a web server, with some of the requests being served with a file, such as an HTML document, or a gif image, others with the results of running a CGI program, and others by some other process, such as a built-in module handler, a PHP document, or a Java servlet.»^[27]

In practice, web server programs that implement advanced features, beyond the simple static content serving (e.g. URL rewrite engine, dynamic content serving), usually have to figure out how that URL has to be handled, e.g.:

• as a URL redirection, a redirection to another URL;
• as a static request of file content;
• as a dynamic request of:
  • directory listing of files or other sub-directories contained in that directory;
  • other types of dynamic request in order to identify the program / module processor able to handle that kind of URL path and to pass to it other URL parts, i.e. usually path-info and query string variables.

One or more configuration files of web server may specify the mapping of parts of URL path (e.g. initial parts of file path, filename extension and other path components) to a specific URL handler (file, directory, external program or internal module).^[28]

When a web server implements one or more of the above-mentioned advanced features then the path part of a valid URL may not always match an existing file system path under website directory tree (a file or a directory in file system) because it can refer to a virtual name of an internal or external module processor for dynamic requests.

URL path translation to file system[edit]

Web server programs are able to translate an URL path (all or part of it), that refers to a physical file system path, to an absolute path under the target website’s root directory.^[28]

Website’s root directory may be specified by a configuration file or by some internal rule of the web server by using the name of the website which is the host part of the URL found in HTTP client request.^[28]

Path translation to file system is done for the following types of web resources:

• a local, usually non-executable, file (static request for file content);
• a local directory (dynamic request: directory listing generated on the fly);
• a program name (dynamic requests that is executed using CGI or SCGI interface and whose output is read by web server and resent to client who made the HTTP request).

The web server appends the path found in requested URL (HTTP request message) and appends it to the path of the (Host) website root directory. On an Apache server, this is commonly /home/www/website (on Unix machines, usually it is: /var/www/website). See the following examples of how it may result.

URL path translation for a static file request

Example of a static request of an existing file specified by the following URL:

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

The client’s user agent connects to www.example.com and then sends the following HTTP/1.1 request:

GET /path/file.html HTTP/1.1
Host: www.example.com
Connection: keep-alive

The result is the local file system resource:

/home/www/www.example.com/path/file.html

The web server then reads the file, if it exists, and sends a response to the client’s web browser. The response will describe the content of the file and contain the file itself or an error message will return saying that the file does not exist or its access is forbidden.

URL path translation for a directory request (without a static index file)

Example of an implicit dynamic request of an existing directory specified by the following URL:

http://www.example.com/directory1/directory2/

The client’s user agent connects to www.example.com and then sends the following HTTP/1.1 request:

GET /directory1/directory2 HTTP/1.1
Host: www.example.com
Connection: keep-alive

The result is the local directory path:

/home/www/www.example.com/directory1/directory2/

The web server then verifies the existence of the directory and if it exists and it can be accessed then tries to find out an index file (which in this case does not exist) and so it passes the request to an internal module or a program dedicated to directory listings and finally reads data output and sends a response to the client’s web browser. The response will describe the content of the directory (list of contained subdirectories and files) or an error message will return saying that the directory does not exist or its access is forbidden.

URL path translation for a dynamic program request

For a dynamic request the URL path specified by the client should refer to an existing external program (usually an executable file with a CGI) used by the web server to generate dynamic content.^[29]

Example of a dynamic request using a program file to generate output:

http://www.example.com/cgi-bin/forum.php?action=view&orderby=thread&date=2021-10-15

The client’s user agent connects to www.example.com and then sends the following HTTP/1.1 request:

GET /cgi-bin/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1
Host: www.example.com
Connection: keep-alive

The result is the local file path of the program (in this example, a PHP program):

/home/www/www.example.com/cgi-bin/forum.php

The web server executes that program, passing in the path-info and the query string action=view&orderby=thread&date=2021-10-15 so that the program has the info it needs to run. (In this case, it will return an HTML document containing a view of forum entries ordered by thread from October 15th, 2021). In addition to this, the web server reads data sent from the external program and resends that data to the client that made the request.

Manage request message[edit]

Once a request has been read, interpreted, and verified, it has to be managed depending on its method, its URL, and its parameters, which may include values of HTTP headers.

In practice, the web server has to handle the request by using one of these response paths:^[28]

• if something in request was not acceptable (in status line or message headers), web server already sent an error response;
• if request has a method (e.g. OPTIONS) that can be satisfied by general code of web server then a successful response is sent;
• if URL requires authorization then an authorization error message is sent;
• if URL maps to a redirection then a redirect message is sent;
• if URL maps to a dynamic resource (a virtual path or a directory listing) then its handler (an internal module or an external program) is called and request parameters (query string and path info) are passed to it in order to allow it to reply to that request;
• if URL maps to a static resource (usually a file on file system) then the internal static handler is called to send that file;
• if request method is not known or if there is some other unacceptable condition (e.g. resource not found, internal server error, etc.) then an error response is sent.

Serve static content[edit]

If a web server program is capable of serving static content and it has been configured to do so, then it is able to send file content whenever a request message has a valid URL path matching (after URL mapping, URL translation and URL redirection) that of an existing file under the root directory of a website and file has attributes which match those required by internal rules of web server program.^[28]

That kind of content is called static because usually it is not changed by the web server when it is sent to clients and because it remains the same until it is modified (file modification) by some program.

NOTE: when serving static content only, a web server program usually does not change file contents of served websites (as they are only read and never written) and so it suffices to support only these HTTP methods:

• OPTIONS
• HEAD
• GET

Response of static file content can be sped up by a file cache.

Directory index files[edit]

If a web server program receives a client request message with an URL whose path matches one of an existing directory and that directory is accessible and serving directory index file(s) is enabled then a web server program may try to serve the first of known (or configured) static index file names (a regular file) found in that directory; if no index file is found or other conditions are not met then an error message is returned.

Most used names for static index files are: index.html, index.htm and Default.htm.

Regular files[edit]

If a web server program receives a client request message with an URL whose path matches the file name of an existing file and that file is accessible by web server program and its attributes match internal rules of web server program, then web server program can send that file to client.

Usually, for security reasons, most web server programs are pre-configured to serve only regular files or to avoid to use special file types like device files, along with symbolic links or hard links to them. The aim is to avoid undesirable side effects when serving static web resources.^[30]

Serve dynamic content[edit]

If a web server program is capable of serving dynamic content and it has been configured to do so, then it is able to communicate with the proper internal module or external program (associated with the requested URL path) in order to pass to it parameters of client request; after that, web server program reads from it its data response (that it has generated, often on the fly) and then it resends it to the client program who made the request.^{[citation needed]}

NOTE: when serving static and dynamic content, a web server program usually has to support also the following HTTP method in order to be able to safely receive data from client(s) and so to be able to host also websites with interactive form(s) that may send large data sets (e.g. lots of data entry or file uploads) to web server / external programs / modules:

• POST

In order to be able to communicate with its internal modules and/or external programs, a web server program must have implemented one or more of the many available gateway interface(s) (see also Web Server Gateway Interfaces used for dynamic content).

The three standard and historical gateway interfaces are the following ones.

CGI

An external CGI program is run by web server program for each dynamic request, then web server program reads from it the generated data response and then resends it to client.

SCGI

An external SCGI program (it usually is a process) is started once by web server program or by some other program / process and then it waits for network connections; every time there is a new request for it, web server program makes a new network connection to it in order to send request parameters and to read its data response, then network connection is closed.

FastCGI

An external FastCGI program (it usually is a process) is started once by web server program or by some other program / process and then it waits for a network connection which is established permanently by web server; through that connection are sent the request parameters and read data responses.

Directory listings[edit]

A web server program may be capable to manage the dynamic generation (on the fly) of a directory index list of files and sub-directories.^[31]

If a web server program is configured to do so and a requested URL path matches an existing directory and its access is allowed and no static index file is found under that directory then a web page (usually in HTML format), containing the list of files and/or subdirectories of above mentioned directory, is dynamically generated (on the fly). If it cannot be generated an error is returned.

Some web server programs allow the customization of directory listings by allowing the usage of a web page template (an HTML document containing placeholders, e.g. $(FILE_NAME), $(FILE_SIZE), etc., that are replaced with the field values of each file entry found in directory by web server), e.g. index.tpl or the usage of HTML and embedded source code that is interpreted and executed on the fly, e.g. index.asp, and / or by supporting the usage of dynamic index programs such as CGIs, SCGIs, FGCIs, e.g. index.cgi, index.php, index.fcgi.

Usage of dynamically generated directory listings is usually avoided or limited to a few selected directories of a website because that generation takes much more OS resources than sending a static index page.

The main usage of directory listings is to allow the download of files (usually when their names, sizes, modification date-times or file attributes may change randomly / frequently) as they are, without requiring to provide further information to requesting user.^[32]

Program or module processing[edit]

An external program or an internal module (processing unit) can execute some sort of application function that may be used to get data from or to store data to one or more data repositories, e.g.:^{[citation needed]}

• files (file system);
• databases (DBs);
• other sources located in local computer or in other computers.

A processing unit can return any kind of web content, also by using data retrieved from a data repository, e.g.:^{[citation needed]}

• a document (e.g. HTML, XML, etc.);
• an image;
• a video;
• structured data, e.g. that may be used to update one or more values displayed by a dynamic page (DHTML) of a web interface and that maybe was requested by an XMLHttpRequest API (see also: dynamic page).

In practice whenever there is content that may vary, depending on one or more parameters contained in client request or in configuration settings, then, usually, it is generated dynamically.

Send response message[edit]

Web server programs are able to send response messages as replies to client request messages.^[24]

An error response message may be sent because a request message could not be successfully read or decoded or analyzed or executed.^[25]

NOTE: the following sections are reported only as examples to help to understand what a web server, more or less, does; these sections are by any means neither exhaustive nor complete.

Error message[edit]

A web server program may reply to a client request message with many kinds of error messages, anyway these errors are divided mainly in two categories:

• HTTP client errors, due to the type of request message or to the availability of requested web resource;^[33]
• HTTP server errors, due to internal server errors.^[34]

When an error response / message is received by a client browser, then if it is related to the main user request (e.g. an URL of a web resource such as a web page) then usually that error message is shown in some browser window / message.

[edit]

A web server program may be able to verify whether the requested URL path:^[35]

• can be freely accessed by everybody;
• requires a user authentication (request of user credentials, e.g. such as user name and password);
• access is forbidden to some or all kind of users.

If the authorization / access rights feature has been implemented and enabled and access to web resource is not granted, then, depending on the required access rights, a web server program:

• can deny access by sending a specific error message (e.g. access forbidden);
• may deny access by sending a specific error message (e.g. access unauthorized) that usually forces the client browser to ask human user to provide required user credentials; if authentication credentials are provided then web server program verifies and accepts or rejects them.

URL redirection[edit]

A web server program may have the capability of doing URL redirections to new URLs (new locations) which consists in replying to a client request message with a response message containing a new URL suited to access a valid or an existing web resource (client should redo the request with the new URL).^[36]

URL redirection of location is used:^[36]

• to fix a directory name by adding a final slash ‘/’;^[31]
• to give a new URL for a no more existing URL path to a new path where that kind of web resource can be found.
• to give a new URL to another domain when current domain has too much load.

Example 1: a URL path points to a directory name but it does not have a final slash ‘/’ so web server sends a redirect to client in order to instruct it to redo the request with the fixed path name.^[31]

From:
  /directory1/directory2
To:
  /directory1/directory2/

Example 2: a whole set of documents has been moved inside website in order to reorganize their file system paths.

From:
  /directory1/directory2/2021-10-08/
To:
  /directory1/directory2/2021/10/08/

Example 3: a whole set of documents has been moved to a new website and now it is mandatory to use secure HTTPS connections to access them.

From:
  http://www.example.com/directory1/directory2/2021-10-08/
To:
  https://docs.example.com/directory1/2021-10-08/

Above examples are only a few of the possible kind of redirections.

Successful message[edit]

A web server program is able to reply to a valid client request message with a successful message, optionally containing requested web resource data.^[37]

If web resource data is sent back to client, then it can be static content or dynamic content depending on how it has been retrieved (from a file or from the output of some program / module).

Content cache[edit]

In order to speed up web server responses by lowering average HTTP response times and hardware resources used, many popular web servers implement one or more content caches, each one specialized in a content category.^[38]
[39]

Content is usually cached by its origin, e.g.:

• static content:
  • file cache;
• dynamic content:
  • dynamic cache (module / program output).

File cache[edit]

Historically, static contents found in files which had to be accessed frequently, randomly and quickly, have been stored mostly on electro-mechanical disks since mid-late 1960s / 1970s; regrettably reads from and writes to those kind of devices have always been considered very slow operations when compared to RAM speed and so, since early OSs, first disk caches and then also OS file cache sub-systems were developed to speed up I/O operations of frequently accessed data / files.

Even with the aid of an OS file cache, the relative / occasional slowness of I/O operations involving directories and files stored on disks became soon a bottleneck in the increase of performances expected from top level web servers, specially since mid-late 1990s, when web Internet traffic started to grow exponentially along with the constant increase of speed of Internet / network lines.

The problem about how to further efficiently speed-up the serving of static files, thus increasing the maximum number of requests/responses per second (RPS), started to be studied / researched since mid 1990s, with the aim to propose useful cache models that could be implemented in web server programs.^[40]

In practice, nowadays, many popular / high performance web server programs include their own userland file cache, tailored for a web server usage and using their specific implementation and parameters.^{[41]
[42]
[43]}

The wide spread adoption of RAID and/or fast solid-state drives (storage hardware with very high I/O speed) has slightly reduced but of course not eliminated the advantage of having a file cache incorporated in a web server.

Dynamic cache[edit]

Dynamic content, output by an internal module or an external program, may not always change very frequently (given a unique URL with keys / parameters) and so, maybe for a while (e.g. from 1 second to several hours or more), the resulting output can be cached in RAM or even on a fast disk.^[44]

The typical usage of a dynamic cache is when a website has dynamic web pages about news, weather, images, maps, etc. that do not change frequently (e.g. every n minutes) and that are accessed by a huge number of clients per minute / hour; in those cases it is useful to return cached content too (without calling the internal module or the external program) because clients often do not have an updated copy of the requested content in their browser caches.^[45]

Anyway, in most cases those kind of caches are implemented by external servers (e.g. reverse proxy) or by storing dynamic data output in separate computers, managed by specific applications (e.g. memcached), in order to not compete for hardware resources (CPU, RAM, disks) with web server(s).^[46]
[47]

Kernel-mode and user-mode web servers[edit]

A web server software can be either incorporated into the OS and executed in kernel space, or it can be executed in user space (like other regular applications).

Web servers that run in kernel mode (usually called kernel space web servers) can have direct access to kernel resources and so they can be, in theory, faster than those running in user mode; anyway there are disadvantages in running a web server in kernel mode, e.g.: difficulties in developing (debugging) software whereas run-time critical errors may lead to serious problems in OS kernel.

Web servers that run in user-mode have to ask the system for permission to use more memory or more CPU resources. Not only do these requests to the kernel take time, but they might not always be satisfied because the system reserves resources for its own usage and has the responsibility to share hardware resources with all the other running applications. Executing in user mode can also mean using more buffer/data copies (between user-space and kernel-space) which can lead to a decrease in the performance of a user-mode web server.

Nowadays almost all web server software is executed in user mode (because many of the aforementioned small disadvantages have been overcome by faster hardware, new OS versions, much faster OS system calls and new optimized web server software). See also comparison of web server software to discover which of them run in kernel mode or in user mode (also referred as kernel space or user space).

Performances[edit]

To improve the user experience (on client / browser side), a web server should reply quickly (as soon as possible) to client requests; unless content response is throttled (by configuration) for some type of files (e.g. big or huge files), also returned data content should be sent as fast as possible (high transfer speed).

In other words, a web server should always be very responsive, even under high load of web traffic, in order to keep total user’s wait (sum of browser time + network time + web server response time) for a response as low as possible.

Performance metrics[edit]

For web server software, main key performance metrics (measured under vary operating conditions) usually are at least the following ones (i.e.):^[48]
[49]

• number of requests per second (RPS, similar to QPS, depending on HTTP version and configuration, type of HTTP requests and other operating conditions);
• number of connections per second (CPS), is the number of connections per second accepted by web server (useful when using HTTP/1.0 or HTTP/1.1 with a very low limit of requests / responses per connection, i.e. 1 .. 20);
• network latency + response time for each new client request; usually benchmark tool shows how many requests have been satisfied within a scale of time laps (e.g. within 1ms, 3ms, 5ms, 10ms, 20ms, 30ms, 40ms) and / or the shortest, the average and the longest response time;
• throughput of responses, in bytes per second.

Among the operating conditions, the number (1 .. n) of concurrent client connections used during a test is an important parameter because it allows to correlate the concurrency level supported by web server with results of the tested performance metrics.

Software efficiency[edit]

The specific web server software design and model adopted (e.g.):

• single process or multi-process;
• single thread (no thread) or multi-thread for each process;
• usage of coroutines or not;

… and other programming techniques, such as (e.g.):

• zero copy;
• minimization of possible CPU cache misses;
• minimization of possible CPU branch mispredictions in critical paths for speed;
• minimization of the number of system calls used to perform a certain function / task;
• other tricks;

… used to implement a web server program, can bias a lot the performances and in particular the scalability level that can be achieved under heavy load or when using high end hardware (many CPUs, disks and lots of RAM).

In practice some web server software models may require more OS resources (specially more CPUs and more RAM) than others to be able to work well and so to achieve target performances.

Operating conditions[edit]

There are many operating conditions that can affect the performances of a web server; performance values may vary depending on (i.e.):

• the settings of web server (including the fact that log file is or is not enabled, etc.);
• the HTTP version used by client requests;
• the average HTTP request type (method, length of HTTP headers and optional body);
• whether the requested content is static or dynamic;
• whether the content is cached or not cached (by server and/or by client);
• whether the content is compressed on the fly (when transferred), pre-compressed (i.e. when a file resource is stored on disk already compressed so that web server can send that file directly to the network with the only indication that its content is compressed) or not compressed at all;
• whether the connections are or are not encrypted;
• the average network speed between web server and its clients;
• the number of active TCP connections;
• the number of active processes managed by web server (including external CGI, SCGI, FCGI programs);
• the hardware and software limitations or settings of the OS of the computer(s) on which the web server runs;
• other minor conditions.

Benchmarking[edit]

Performances of a web server are typically benchmarked by using one or more of the available
automated load testing tools.

Load limits[edit]

A web server (program installation) usually has pre-defined load limits for each combination of operating conditions, also because it is limited by OS resources and because it can handle only a limited number of concurrent client connections (usually between 2 and several tens of thousands for each active web server process, see also the C10k problem and the C10M problem).

When a web server is near to or over its load limits, it gets overloaded and so it may become unresponsive.

Causes of overload[edit]

At any time web servers can be overloaded due to one or more of the following causes (e.g.).

• Excess legitimate web traffic. Thousands or even millions of clients connecting to the website in a short amount of time, e.g., Slashdot effect.
• Distributed Denial of Service attacks. A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer or network resource unavailable to its intended users.
• Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them).
• XSS worms can cause high traffic because of millions of infected browsers or web servers.
• Internet bots Traffic not filtered/limited on large websites with very few network resources (e.g. bandwidth) and/or hardware resources (CPUs, RAM, disks).
• Internet (network) slowdowns (e.g. due to packet losses) so that client requests are served more slowly and the number of connections increases so much that server limits are reached.
• Web servers, serving dynamic content, waiting for slow responses coming from back-end computer(s) (e.g. databases), maybe because of too many queries mixed with too many inserts or updates of DB data; in these cases web servers have to wait for back-end data responses before replying to HTTP clients but during these waits too many new client connections / requests arrive and so they become overloaded.
• Web servers (computers) partial unavailability. This can happen because of required or urgent maintenance or upgrade, hardware or software failures such as back-end (e.g. database) failures; in these cases the remaining web servers may get too much traffic and become overloaded.

Symptoms of overload[edit]

The symptoms of an overloaded web server are usually the following ones (e.g.).

• 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,^[50][51] 503,^[52] 504,^[53] 408, or even an intermittent 404.
• 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 behavior can be considered a bug, even if it usually arises as a symptom of overload.

Anti-overload techniques[edit]

To partially overcome above average load limits and to prevent overload, most popular websites use common techniques like the following ones (e.g.).

• Tuning OS parameters for hardware capabilities and usage.
• Tuning web server(s) parameters to improve their security and performances.
• Deploying web cache techniques (not only for static contents but, whenever possible, for dynamic contents too).
• Managing network traffic, by using:
  • Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns;
  • HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns;
  • Bandwidth management and traffic shaping, in order to smooth down peaks in network usage.
• Using different domain names, IP addresses and computers to serve different kinds (static and dynamic) of content; the aim is to separate big or huge files (download.*) (that domain might be replaced also by a CDN) from small and medium-sized files (static.*) and from main dynamic site (maybe where some contents are stored in a backend database) (www.*); the idea is to be able to efficiently serve big or huge (over 10 – 1000 MB) files (maybe throttling downloads) and to fully cache small and medium-sized files, without affecting performances of dynamic site under heavy load, by using different settings for each (group) of web server computers, e.g.:
  • https://download.example.com
  • https://static.example.com
  • https://www.example.com
• Using many web servers (computers) that are grouped together behind a load balancer so that they act or are seen as one big web server.
• Adding more hardware resources (i.e. RAM, fast disks) to each computer.
• Using more efficient computer programs for web servers (see also: software efficiency).
• Using the most efficient Web Server Gateway Interface to process dynamic requests (spawning one or more external programs every time a dynamic page is retrieved, kills performances).
• Using other programming techniques and workarounds, especially if dynamic content is involved, to speed up the HTTP responses (i.e. by avoiding dynamic calls to retrieve objects, such as style sheets, images and scripts), that never change or change very rarely, by copying that content to static files once and then keeping them synchronized with dynamic content).
• Using latest efficient versions of HTTP (e.g. beyond using common HTTP/1.1 also by enabling HTTP/2 and maybe HTTP/3 too, whenever available web server software has reliable support for the latter two protocols) in order to reduce a lot the number of TCP/IP connections started by each client and the size of data exchanged (because of more compact HTTP headers representation and maybe data compression).

Caveats about using HTTP/2 and HTTP/3 protocols

Even if newer HTTP (2 and 3) protocols usually generate less network traffic for each request / response data, they may require more OS resources (i.e. RAM and CPU) used by web server software (because of encrypted data, lots of stream buffers and other implementation details); besides this, HTTP/2 and maybe HTTP/3 too, depending also on settings of web server and client program, may not be the best options for data upload of big or huge files at very high speed because their data streams are optimized for concurrency of requests and so, in many cases, using HTTP/1.1 TCP/IP connections may lead to better results / higher upload speeds (your mileage may vary).^[54][55]

[edit]

Below are the latest statistics of the market share of all sites of the top web servers on the Internet by Netcraft.

NOTE: (*) percentage rounded to integer number, because its decimal values are not publicly reported by source page (only its rounded value is reported in graph).

See also[edit]

• Server (computing)
• Application server
• Comparison of web server software
• HTTP server (core part of a web server program that serves HTTP requests)
• HTTP compression
• Web application
• Open source web application
• List of AMP packages
• Variant object
• Virtual hosting
• Web hosting service
• Web container
• Web proxy
• Web service

Standard Web Server Gateway Interfaces used for dynamic contents:

• CGI Common Gateway Interface
• SCGI Simple Common Gateway Interface
• FastCGI Fast Common Gateway Interface

A few other Web Server Interfaces (server or programming language specific) used for dynamic contents:

• SSI Server Side Includes, rarely used, static HTML documents containing SSI directives are interpreted by server software to include small dynamic data on the fly when pages are served, e.g. date and time, other static file contents, etc.
• SAPI Server Application Programming Interface:
  • ISAPI Internet Server Application Programming Interface
  • NSAPI Netscape Server Application Programming Interface
• PSGI Perl Web Server Gateway Interface
• WSGI Python Web Server Gateway Interface
• Rack Rack Web Server Gateway Interface
• JSGI JavaScript Web Server Gateway Interface
• Java Servlet, JavaServer Pages
• Active Server Pages, ASP.NET

References[edit]

External links[edit]

• Mozilla: what is a web server?
• Netcraft: news about web server survey

Русский[править]

Морфологические и синтаксические свойства[править]

веб-се́рвер

Существительное, неодушевлённое, мужской род, 2-е склонение (тип склонения 1a по классификации А. А. Зализняка).

Корень: -веб-; корень: -сервер-.

Произношение[править]

• МФА: [ˌvɛp ˈsʲervʲɪr]

Семантические свойства[править]

Значение[править]

1. информ. мощный компьютер, оснащённый специальным программным обеспечением для хранения и обработки файлов одного или многих сайтов ◆ Если в предыдущей главе речь шла только об установке CMS на хостинг (сервер хостингпровайдера), то в этой главе мы также поговорим о создании собственного веб-сервера для Joomla!. Колисниченко Денис Николаевич, «Самоучитель Joomla!», 2014 г.
2. информ. программное обеспечение, обеспечивающее работу веб-сервера [1] ◆ Веб-сервер Apache — наиболее широко используемый веб-сервер в мире. Тейт Б., Ниббс К., «Быстрая веб-разработка», 2008 г.

Синонимы[править]

1. интернет-сервер

Антонимы[править]

Гиперонимы[править]

1. сервер

Гипонимы[править]

Родственные слова[править]

Этимология[править]

Происходит от англ. web server.

Фразеологизмы и устойчивые сочетания[править]

Перевод[править]

Библиография[править]

• Новые слова и значения. Словарь-справочник по материалам прессы и литературы 90-х годов XX века. — СПб. : Дмитрий Буланин, 2014. — ISBN 978-5-86007-637-2.

Веб-сервер — сервер, принимающий HTTP-запросы от клиентов, обычно веб-браузеров, и выдающий им HTTP-ответы, как правило, вместе с HTML-страницей, изображением, файлом, медиа-потоком или другими данными^[1].

Краткая характеристика

Понятие «Веб-сервер» может относится как к к самому серверу, как физическому хранилищу, так и к программному обеспечению.

С точки зрения железа, веб-сервер — это компьютер который хранит ресурсы сайта (HTML документы, CSS стили, JavaScript файлы и другое) и доставляет их на устройство конечного пользователя (веб-браузер и т.д.). Обычно подключен к сети Интернет и может быть доступен через доменное имя, например mozilla.org.

С точки зрения ПО, веб-сервер включает в себя некоторые вещи, которые контролируют доступ пользователей к размещенным на сервере файлам, это минимум HTTP сервера. HTTP сервер это часть ПО которая расшифровывает URL (веб-адрес) и HTTP (протокол который использует браузер для просмотра веб-станиц).
Простыми словами, когда браузеру нужен файл размещенный на веб-сервере, браузер запрашивает его через HTTP. Когда запрос достигает нужного веб-сервера (железо), сервер HTTP (ПО) передает запрашиваемый документ обратно, также через HTTP.

Чтобы опубликовать веб-сайт, нужно либо статический, либо динамический веб-сервер.

Статический веб-сервер, или стек, состоит из компьютера (железо) с сервером HTTP (ПО). На слэнге это называется “статикой”, потому что сервер посылает размещенные на нем файлы в браузер “как есть”.

Динамический веб-сервер состоит из статического веб-сервера плюс дополнительного программного обеспечения, наиболее часто сервером приложений и базы данных. Мы называем его “динамический”, потому что сервер приложений изменяет исходные файлы перед отправкой в браузер по HTTP.

Например, для получения итоговой страницы, которую вы видите в браузере, сервер приложений может заполнить HTML шаблон данными из базы данных. Такие сайты, как MDN (Mozilla Developer Network) или Википедия состоят из тысяч веб-страниц, но они не являются реальными HTML документами, лишь несколько HTML шаблонов и гигантские базы данных. Эта структура упрощает и ускоряет сопровождение веб-приложений и доставку контента.

Цель и функции веб-сервера

Цель веб-сервера проста — обслуживать одновременно большое количество клиентов, максимально эффективно используя hardware.

Главная задача веб сервера принимать HTTP-запросы от пользователей, обрабатывать их, переводить в цифровой компьютерный код. Затем выдавать HTTP-ответы, преобразуя их из миллионов нолей и единичек в изображения, медиа-потоки, буквы, HTML страницы.

Любой веб сервер, для удобства его использования пользователями, должен иметь удобный веб-браузер. Он передает веб серверу запросы, преобразованные в URL-адреса интернет — ресурсов.

Наряду со стандартными функциями, некоторые веб серверы имеют дополнительные. Так, к примеру, соответствующее программное обеспечение может фиксировать число обращений пользователей к тому или иному ресурсу, записывать их в отдельный журнал. А еще они могут поддерживать HTTPS, что не маловажно для защищенного соединения между сайтами и пользователями. Зачастую веб-сервер устанавливается вместе с мейл-сервером. Это позволяет пользователям быстро переходить на страничку почты прямо с сайта, нажав всего лишь на одну гиперссылку.

Хостинг файлов

Во-первых, веб-сервер хранит файлы веб-сайта, а именно все HTML документы и связанные с ними ресурсы, включая изображения, CSS стили, JavaScript файлы, шрифты и видео.

Технически, вы можете разместить все эти файлы на своем компьютере, но гораздо удобнее хранить их на выделенном веб-сервере, который^[2]:

• всегда запущен и работает
• постоянно в сети Интернет
• имеет тот же IP адрес все время (не все провайдеры предоставляют статический IP адрес для домашнего подключения)
• обслуживается на стороне

По всем этим причинам, поиск хорошего хостинг-провайдера является ключевой частью создания вашего сайта. Рассмотрите различные предложения компаний и выберите то, что соответствует вашим потребностям и бюджету (предложения варьируются от бесплатных до тысяч долларов в месяц).

HTTP

Во-вторых, веб-сервер обеспечивает поддержку HTTP (hypertext transfer protocol). Как следует из названия, HTTP указывает, как передавать гипертекст (т.е. связанные веб-документы) между двумя компьютерами.

Протокол представляет собой набор правил для связи между двумя компьютерами. HTTP является текстовым протоколом без сохранения состояния и обладает следующими свойствами:

• Текстовый (Все команды представлены в текстовом виде и пригодны для восприятия человеком) .
• Не сохраняет состояние(ни клиент, ни сервер, не помнят о предыдущих соединениях. Например, опираясь только на HTTP, сервер не сможет вспомнить введенный вами пароль или на каком шаге транзакции вы находитесь. Для таких задач, вам потребуется сервер приложений.)

HTTP задает строгие правила, как клиент и сервер должны общаться. Мы рассмотрим непосредственно HTTP далее в техническом разделе. Вот некоторые из них:

1. Только клиенты могут отправлять HTTP запросы, и только на сервера. Сервера отвечают только на HTTP запросы клиента.
2. Когда запрашивается физический файл, клиент должен сформировать URL для сервера.
3. Веб-сервер должен ответить на каждый HTTP запрос, по крайней мере с сообщением об ошибке.

На веб-сервере, HTTP сервер отвечает за обработку входящих запросов и ответ на них:

• При получении запроса, HTTP сервер сначала проверяет существует ли ресурс по данному URL.
• Если это так, веб-сервер отправляет содержимое файла обратно в браузер. Если нет, сервер приложений создает необходимый ресурс.
• Если это не возможно, веб-сервер возвращает сообщение об ошибке в браузер, чаще всего “404 Not Found”. (Это ошибка настолько распространена, что многие веб-дизайнеры тратят большое количество времени на разработку 404 страниц об ошибках.)

Популярные веб-сервера

Apache HTTP Server

Apache HTTP Server является проектом, развиваемый The Apache Software Foundation, в рамках которого разрабатывается кроссплатформенный HTTP сервер с открытым исходным кодом. Входит в состав LAMP (комплект из Linux, Apache, MySQL, PHP) и WAMP (комплект из Windows, Apache, MySQL, PHP). Другими словами, это полнофункциональный, расширяемый веб-сервер, полностью поддерживающий протокол HTTP/1.1 и распространяющийся с открытым исходным кодом^[3].

Состав архитектуры Apache HTTP Server:

Ядро, написанное на языке программирования C, в чьи функциональные возможности входит:

• обработка конфигурационных файлов
• протокол HTTP
• система загрузки модулей

Система текстовой конфигурации, состоящая из трех уровней:

• Конфигурация сервера (httpd.conf).
• Конфигурация виртуального хоста (httpd.conf c версии 2.2, extra/httpd-vhosts.conf).
• Конфигурация уровня директории (.htaccess).

Мультипроцессорные модели (MPM), которые используются для работы с различными серверными операционными системами.(worker, pre-fork и др.)
Система модулей для обеспечения:

• Поддержки языков программирования.
• Добавления функций.
• Исправление ошибок или модификация основных функций.
• Усиления безопасности.

Механизм виртуальных хостов, он позволяет полноценно обслуживать на одном IP-адресе множество сайтов (доменных имён), отображая для каждого из них собственное
содержимое.

Веб-сервер Apache разрабатывается и поддерживается открытым сообществом разработчиков под эгидой Apache Software Foundation и включён во многие программные продукты, среди которых СУБД Oracle и IBM WebSphere. С апреля 1996 и до настоящего времени является самым популярным HTTP-сервером в Интернете.

Apache Tomcat

Apache Tomcat — это контейнер, который позволяет вам использовать интернет приложения такие, как Java сервлеты и JSP (серверные страницы Java).
Пакеты Apache Tomcat 6.0 в Ubuntu поддерживают два варианта запуска Tomcat^[4]:

1. Использовать Tomcat как классический одиночный экземпляр на всю систему, который будет запускаться при загрузке системы от имени непривилегированного пользователя tomcat6.
2. Развернуть частные экземпляры, которые будут запускаться с правами вашего собственного пользователя, и вам придется запускать и останавливать их самостоятельно.

Tomcat используется в качестве самостоятельного веб-сервера, в качестве сервера контента в сочетании с веб-сервером Apache HTTP Server, а также в качестве контейнера сервлетов в серверах приложений JBoss и GlassFish.
Компоненты Tomcat:

1. Catalina — контейнер сервлетов Tomcat’а, который реализует спецификацию сервлетов Servlet API. Servlet API является основой для всех остальных технологий Java, касающихся Web и дает возможность динамически генерировать любой web-контент, используя любые библиотеки, доступные для java. Архитектором Catalina являлся Craig McClanahan.
2. Coyote — компонент стека HTTP Tomcat’а, который поддерживает протокол HTTP 1.1 для веб-серверов или контейнера приложений. Coyote прослушивает входящие соединения на определённом TCP порту сервера, пересылает запросы в механизм Tomcat для обработки запросов и отправляет ответ назад запрашивающему клиенту.
3. Jasper — механизм JSP Tomcat’а. Tomcat 5.x использует Jasper 2, который является реализацией спецификации JavaServer Pages 2.0 Sun Microsystems. Jasper анализирует JSP-файлы, чтобы компилировать их в Java код, как сервлеты (которые могут быть обработаны с помощью Catalina). Во время выполнения, Jasper может автоматически обнаруживать изменения JSP-файла и перекомпилировать его. В Jasper 2, были добавлены важные особенности:

• JSP библиотеки тегов объединения — Каждый тег разметки в файле JSP обрабатывается классом обработчика тегов. Объекты класса обработчика тега может быть объединены и использованы повторно в целом JSP сервлете.
• Фоновая JSP компиляция — в то время как происходит перекомпиляция измененного JSP Java-кода, старая версия все еще доступна для серверных запросов. Старый JSP сервлет удаляется только когда новый JSP сервлет закончил перекомпиляцию.
• Компилятор Java JDT — Jasper 2 может использовать Eclipse, JDT (Средства разработки Java) компилятор Java вместо Apache Ant Ant и JAVAC.

Некоторые из свободных ресурсов и объединений Apache Tomcat включают Tomcatexpert.com (а SpringSource спонсорское сообщество разработчиков и операторов, которые работают с Apache Tomcat в крупномасштабных производственных средах) и Apache Tomcat MuleSoft (который имеет учебные руководства по установке, обновлению, Настройка, мониторинг, устранение неполадок и крепления различные версии Tomcat).

nginx

Основная статья: nginx

nginx (engine x) является HTTP-сервером изначально написанным Игорем Сысоевым. nginx также может использоваться как почтовый прокси-сервер, а также TCP/UDP прокси-сервер общего назначения^[5]. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 27.80% самых нагруженных сайтов в октябре 2016 года. Рабочие процессы в Nginx одновременно обслуживают множество соединений, обеспечивая их вызовами ОС (операционной системы) epoll (Linux), select и kqueue (FreeBSD).

Данные, полученные от клиента, разбираются посредством конечного автомата. Обработку разобранного запроса осуществляет цепочка модулей, задаваемая конфигурацией. Формирование ответа клиенту происходит в буферах, которые могут указывать на отрезок файла или хранить данные в памяти. Последовательность передачи данных клиенту определяется цепочками, в которые группируются буферы. В структурном отношении HTTP-сервер Nginx разделён на виртуальные серверы, которые в свою очередь делятся на location. Виртуальному серверу или директиве можно задать порты и адреса для приёма соединений. Для location можно задать точный URI, часть URI, или регулярное выражение.Для оперативного управления памятью служат пулы, являющиеся последовательностью заранее выбранных блоков памяти. Один блок, выделяемый изначально под пул, имеет длину от 1 до 16 килобайт. Он разделён на области – занятую и незанятую. По мере заполнения последней выделение нового объекта обеспечивается образованием нового блока.

nginx считается очень быстрым HTTP сервером. Вместо Apache или совместно с ним Nginx используют, чтобы ускорить обработку запросов и уменьшить нагрузку на сервер. Дело в том, что огромные возможности, заложенные модульной архитектурой Apache, большинству пользователей не требуются. Платить же за эту невостребованную функциональность приходится значительным расходом системных ресурсов. Для обычных сайтов, как правило, характерно явное «засилье» статичных файлов (изображений, файлов стилей, JavaScript), а не скриптов. Никакого специального функционала для передачи этих файлов посетителю ресурса не требуется, так как задача весьма проста. А, значит, и веб-сервер для обработки таких запросов должен быть простым и легковесным, как Nginx. Географическая классификация клиентов по их IP-адресу производится в nginx посредством специального модуля. Система Radix tree позволяет оперативно работать с IP-адресами, занимая минимум памяти.

Примечания

Всего найдено: 15

Здравствуйте! Уточните, пожалуйста, нужнали запятая в этом объявлении? : Приглашаем к сотрудничеству владельцев Web-камер ? для трансляции в эфире нашего чата. Спасибо.

Ответ справочной службы русского языка

Запятая не ставится. Корректно: веб-камер.

Добрый день, подскажите, пожалуйста, допустимо ли написание web-проект? Или все же правильно веб-проект? Спасибо.

Ответ справочной службы русского языка

Первая часть сложных слов веб- уже зафиксирована словарями русского языка. Поэтому следует писать кириллицей: веб-проект.

Как правильно написать, web-страница или веб-страница? Спасибо

Ответ справочной службы русского языка

Корректно: веб-страница.

Web сайт или Web-сайт?

Ответ справочной службы русского языка

Правильно: веб-сайт.

Пожалуйста, ответьте на вопрос:
Демо-Web-интерфейс — как правильно? Верно ли расставлены дефисы?
спасибо

Ответ справочной службы русского языка

Орфографически верно: демо-веб-интерфейс.

Здравствуйте! Подскажите, пожалуйста, можно ли писать web-сайт или обе части это слова должны быть написаны по-русски: веб-сайт? Спасибо!

Ответ справочной службы русского языка

Предпочтительно писать слово веб-сайт.

Здравствуйте! Я всегда задумывался над тем, как правильно писать: веб-сайт, вебсайт или web-сайт? Также возникают вопросы с такими словами как «вебмастер» и «веб-дизайнер», «веб-программист» (мне действительно кажется что первое пишется слитно, а второе и третье — через дефис). Допустимо ли употребление слова «веб» в значении «сеть, интернет»?

Ответ справочной службы русского языка

Правильное написание: веб-сайт (именно такое написание рекомендует «Русский орфографический словарь» РАН). В значении «Интернет» существительное Веб пишется с большой буквы. Слова с первой частью веб… (веб-программист, веб-дизайнер, веб-мастер) пишутся через дефис, со строчной буквы.

Здравствуйте! Скажите пожалуйста, правильно ли написание слова «интернет» в середине предложения с большой буквы, и склоняется ли это слово?
«Размещение электронной версии каталога в Интернете на web-странице выставочной компании.»

Ответ справочной службы русского языка

Да, слово _Интернет_ пишется с большой буквы и склоняется. Вы написали верно.

Добрый день!
У меня к Вам оргомная прсьба. Знакомые открывают новое направление и попросили написать для них коммерческое предложение, что я и сделала. Но я не уверена, что здесь нет орфографических ошибок. Пожалуйста, проверьте текст. С благодарностью приму все замечания и исправления.

Уважаемые дамы и господа!
Не для кого не секрет, что в последнее время все большей популярностью пользуется всемирная сеть Интернет. В связи с этим наша компания запускает новый проект — _______________
___________________ – это информационно-справочный Интернет-сайт, посвященный развлечениям и досугу. Поскольку, наш город растет и развивается с неумолимой скоростью и почти каждый день открываются новые торговый центры, кафе, клубы и прочие заведения, мы считаем, что столица давно нуждается в таком проекте. На сайте будет размещаться информация рекламного характера, позволяющая жителям и гостям нашей столицы легко ориентироваться и выбирать для себя нужное из огромного количества предложений.
Одним из неоспоримых преимуществ Интернет сайта является то, что Ваша информация работает на Вас 24 часа в сутки, 7 дней в неделю, при необходимости она обновляется.
Наша цель – собрать информацию обо всех организациях, деятельность которых, так или иначе, соприкасается с досугом и развлечениями.
Мы отлично понимаем, что у нас огромная целевая аудитория и для Вашего удобства мы сформировали 3 варианта размещения информации. Вы можете выбрать тот пакет, который оптимально подходит для Вас.
У многих фирм существуют собственные web-сайты, но зачастую их посещаемость оставляет желать лучшего, ведь тратить огромные средства на продвижение в сети иногда бывает не целесообразно.
_________________ – это идеальный вариант рекламы не только Вашей фирмы, но и Вашего персонального электронного представительства.
Мы постоянно работаем над продвижением сайта и стремимся занять лидирующие позиции.
Помимо прочего на сайте так же будут размещаться новостная лента, интересные фотографии о нашем городе, рубрика «Халява», в которой Вы можете размещать информацию о предстоящих мероприятиях, о скидках, распродажах, акциях и т.д. совершенно бесплатно, прогноз погоды, курсы валют и многое другое.
P.S.: Поскольку наш проект пока только набирает обороты нам хочется знать Ваше мнение. Будем рады принять Ваши пожелания, предложения и замечания по e-mail.

Ответ справочной службы русского языка

«Справочное бюро» не занимается проверкой текстов.

Добрый день!

Скажите, пожалуйста, нужна ли запятая после «однако» в следующем предложении:
Однако когда запрашивается динамическая страница, действия web-сервера не столь однозначны.

Спасибо.

Ответ справочной службы русского языка

Запятая перед _когда_ нужна.

Как правильно писать «Web-страницы»?

Ответ справочной службы русского языка

Правильно: _web-страницы_.

Здравствуйте, скажите пожалуйста, как следует писать Web-страница или web-страница? Спасибо, Ирина

Ответ справочной службы русского языка

В русском языке есть слово _веб-страница_.

Запятая ставится в обоих случаях или нигде? Спасибо.
Каталоги самых известных поисковых машин содержат ссылки на более, чем миллионы web-ресурсов.

Каталог содержит более, чем 150 наименований продукции.

Ответ справочной службы русского языка

Запятые не ставятся в обоих случаях.

Web-сайт[,] как эффективный инструмент pr-кампании.

Ответ справочной службы русского языка

Запятая не нужна.

Подскажите, пожалуйста, как правильно: «закончить дела по окончанИЮ рабочего дня» или «закончить дела по окончанИИ рабочего дня»?
И еще одни вопрос:
Во фразе «Если Вы разбираетесь в компьютерных технологих и знаете, чем отличается браузер от web-обозревателя Вы наш главный кандидат» правильно ли расставлены знаки препинания?

Ответ справочной службы русского языка

Правильно: _по окончании рабочего дня_.
Правильно: _Если Вы разбираетесь в компьютерных технологиях и знаете, чем отличается браузер от web-обозревателя, Вы наш главный кандидат_.

А веб сервер является серверное программное обеспечение, или же аппаратное обеспечение посвященный запуску этого программного обеспечения, которое может удовлетворить клиент просьбы о Всемирная паутина. Веб-сервер, как правило, может содержать один или несколько веб-сайты. Веб-сервер обрабатывает входящие сеть запросы более HTTP и несколько других связанных протоколы.

Основная функция веб-сервера — хранить, обрабатывать и доставлять веб-страница клиентам.^[1] Связь между клиентом и сервером осуществляется с помощью Протокол передачи гипертекста (HTTP). Доставляемые страницы чаще всего HTML документы, который может включать изображений, таблицы стилей и скрипты в дополнение к текстовому содержанию.

А пользовательский агент, обычно веб-браузер или же поисковый робот, инициирует обмен данными, отправляя запрос на конкретный ресурс с помощью HTTP, и сервер отвечает содержимым этого ресурса или сообщение об ошибке если не может этого сделать. Ресурс обычно представляет собой реальный файл на сервере вторичное хранилище, но это не обязательно так и зависит от того, как веб-сервер реализовано.

Хотя основная функция заключается в обслуживании контента, полная реализация HTTP также включает способы получения контента от клиентов. Эта функция используется для отправки веб-формы, включая загрузка файлов.

Многие общие веб-серверы также поддерживают серверные сценарии с помощью Активные серверные страницы (ASP), PHP (Препроцессор гипертекста) или другой языки сценариев. Это означает, что поведение веб-сервера может быть записано в отдельных файлах, в то время как фактическое программное обеспечение сервера остается неизменным. Обычно эта функция используется для создания HTML-документов. динамично («на лету») вместо возврата статические документы. Первый в основном используется для извлечения или изменения информации из базы данных. Последнее, как правило, намного быстрее и проще. кешированный но не может доставить динамический контент.

Веб-серверы можно найти часто встроенный в таких устройствах, как принтеры, маршрутизаторы, веб-камеры и обслуживает только локальная сеть. Затем веб-сервер может использоваться как часть системы для мониторинга или администрирования рассматриваемого устройства. Обычно это означает, что на клиентском компьютере не нужно устанавливать дополнительное программное обеспечение, поскольку требуется только веб-браузер (который сейчас включен в большинство операционные системы ).

История

В марте 1989 г. Сэр Тим Бернерс-Ли предложил новый проект своему работодателю ЦЕРН, с целью облегчения обмена информацией между учеными с помощью гипертекст система.^[2][3] В результате проекта Бернерс-Ли в 1990 году написал две программы:

• А веб-браузер называется Всемирная паутина^[4]
• Первый в мире веб-сервер, позже известный как ЦЕРН httpd, который работал на Следующий шаг

Между 1991 и 1994 годами простота и эффективность ранних технологий, используемых для просмотра и обмена данными через всемирную паутину, помогла перенести их на множество различных операционных систем и распространить их использование среди научных организаций и университетов, а затем и в отрасли.

В 1994 году Бернерс-Ли решил создать Консорциум World Wide Web (W3C) для регулирования дальнейшего развития многих задействованных технологий (HTTP, HTML и т. д.) в процессе стандартизации.

Перевод пути

Веб-серверы могут отображать компонент пути Единый указатель ресурсов (URL) в:

• Местный файловая система ресурс (для статических запросов)
• Внутреннее или внешнее имя программы (для динамических запросов)

Для статический запрос URL-путь, указанный клиентом, относительно корневого каталога веб-сервера.

Рассмотрим следующий URL в том виде, в каком он будет запрошен клиентом по HTTP:

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

Клиентский пользовательский агент переведет это в соединение с www.example.com со следующими HTTP / 2 запрос:

ПОЛУЧИТЬ /path/file.html HTTP / 2Host: www.example.com

Веб-сервер на www.example.com добавит указанный путь к пути своего корневого каталога. На Сервер Apache, это обычно / главная / www (на Unix машины, обычно / var / www). Результатом является ресурс локальной файловой системы:

/home/www/path/file.html

Затем веб-сервер читает файл, если он существует, и отправляет ответ в веб-браузер клиента. Ответ будет описывать содержимое файла и содержать сам файл, либо будет возвращено сообщение об ошибке о том, что файл не существует или недоступен.

Веб-серверы в режиме ядра и в пользовательском режиме

Веб-сервер может быть включен в Операционные системы ядро, или в пространство пользователя (как и другие обычные приложения).

Веб-серверы, которые работают в пользовательский режим необходимо запросить у системы разрешение на использование большего объема памяти или ресурсов ЦП. Эти запросы к ядру не только требуют времени, но и не всегда удовлетворяются, потому что система резервирует ресурсы для собственного использования и несет ответственность за совместное использование аппаратных ресурсов со всеми другими запущенными приложениями. Выполнение в пользовательском режиме также может означать бесполезные буферные копии, что является еще одним ограничением для веб-серверов пользовательского режима.

Пределы нагрузки

Веб-сервер (программа) имеет определенные пределы нагрузки, потому что он может обрабатывать только ограниченное количество одновременных клиентских подключений (обычно от 2 до 80 000, по умолчанию от 500 до 1000) на айпи адрес (и порт TCP), и он может обслуживать только определенное максимальное количество запросов в секунду (RPS, также известный как запросов в секунду или QPS) в зависимости от:

• собственные настройки,
• тип HTTP-запроса,
• является ли контент статическим или динамическим,
• является ли контент кешированный, или же сжатый, и
• в аппаратное обеспечение и программного обеспечения ограничения ОС компьютера, на котором работает веб-сервер.

Когда веб-сервер приближается к своему пределу или превышает его, он перестает отвечать.

Причины перегрузки

В любой момент веб-серверы могут быть перегружены из-за:

• Избыточный законный веб-трафик. Тысячи или даже миллионы клиентов подключаются к веб-сайту за короткий промежуток времени, например, Эффект слэшдота;
• Распределенный отказ в обслуживании атаки. Атака отказа в обслуживании (DoS-атака) или распределенная атака типа «отказ в обслуживании» (DDoS-атака) — это попытка сделать компьютер или сетевой ресурс недоступным для предполагаемых пользователей;
• Компьютерные черви которые иногда вызывают аномальный трафик из-за миллионов зараженных компьютеров (не координированных между ними)
• XSS-черви может вызвать высокий трафик из-за миллионов зараженных браузеров или веб-серверов;
• Интернет-боты Трафик не фильтруется / не ограничивается на больших веб-сайтах с очень небольшими ресурсами (пропускной способностью и т. Д.);
• Интернет (сеть) замедляется, так что клиентские запросы обслуживаются медленнее, а количество подключений увеличивается настолько, что достигаются ограничения сервера;
• Веб-серверы (компьютеры ) частичная недоступность. Это может произойти из-за необходимого или срочного обслуживания или обновления, сбоев оборудования или программного обеспечения, бэкэнд (например., база данных ) отказы и т.д .; в этих случаях оставшиеся веб-серверы получают слишком много трафика и становятся перегруженными.

Симптомы перегрузки

Симптомы перегруженного веб-сервера:

• Запросы обслуживаются с (возможно, длительными) задержками (от 1 секунды до нескольких сотен секунд).
• Веб-сервер возвращает Код ошибки HTTP, например 500, 502,^[5] 503,^[6] 504,^[7] 408 или даже 404, что не подходит для условий перегрузки.^[8]
• Веб-сервер отказывается или перезагружается (прерывает) TCP соединения, прежде чем он вернет какой-либо контент.
• В очень редких случаях веб-сервер возвращает только часть запрошенного контента. Такое поведение можно считать ошибка, даже если обычно возникает как симптом перегрузки.

Методы защиты от перегрузки

Чтобы частично преодолеть ограничения нагрузки выше среднего и предотвратить перегрузку, большинство популярных веб-сайтов используют общие методы, такие как:

• Управление сетевым трафиком с помощью:
  • Межсетевые экраны для блокировки нежелательного трафика, исходящего из плохих IP-источников или имеющего плохие шаблоны
  • Менеджеры HTTP-трафика для отбрасывания, перенаправления или перезаписи запросов с плохими HTTP узоры
  • Управление пропускной способностью и формирование трафика, чтобы сгладить пики использования сети
• Развертывание веб-кеш техники
• Используя разные доменные имена или IP-адреса для обслуживания различного (статического и динамического) контента отдельными веб-серверами, например:
  • http://images.example.com
  • http://example.com
• Использование разных доменных имен или компьютеров для отделения больших файлов от файлов малого и среднего размера; идея состоит в том, чтобы иметь возможность полностью тайник файлы малого и среднего размера, а также для эффективного обслуживания больших или больших (более 10 — 1000 МБ) файлов с использованием различных настроек
• Использование множества интернет-серверов (программ) на компьютере, каждый из которых привязан к своему собственному сетевая карта и айпи адрес
• Использование множества интернет-серверов (компьютеров), сгруппированных вместе за балансировщик нагрузки чтобы они действовали или рассматривались как один большой веб-сервер
• Добавление дополнительных аппаратных ресурсов (т.е. баран, диски ) на каждый компьютер
• Настройка параметров ОС для аппаратных возможностей и использования
• Использование более эффективных компьютерные программы для веб-серверов и т. д.
• Используя другие обходные пути, особенно если задействован динамический контент

Дополнительная информация о программах HTTP-сервера: Категория: Программное обеспечение для веб-серверов

Февраль 2019 г.

Ниже представлена ​​последняя статистика рыночная доля всех сайтов лучших веб-серверов в Интернете по версии W3TechsИспользование веб-серверов для веб-сайтов.

Все остальные веб-серверы используются менее чем 1% веб-сайтов.

Июль 2018 г.

Ниже представлена ​​последняя статистика рыночная доля всех сайтов лучших веб-серверов в Интернете по версии W3TechsИспользование веб-серверов для веб-сайтов.

Все остальные веб-серверы используются менее чем 1% веб-сайтов.

Февраль 2017 г.

Ниже представлена ​​последняя статистика рыночная доля всех сайтов лучших веб-серверов в Интернете по NetcraftОбзор веб-серверов, февраль 2017 г..

Февраль 2016 г.

Ниже представлена ​​последняя статистика рыночная доля всех сайтов лучших веб-серверов в Интернете по NetcraftОбзор веб-серверов, февраль 2016 г..

Apache, IIS и Nginx — наиболее часто используемые веб-серверы во всемирной паутине.^[9][10]

Смотрите также

• Сервер (вычисления)
• Сервер приложений
• Сравнение программного обеспечения веб-сервера
• HTTP-сжатие
• Веб-приложение с открытым исходным кодом
• Серверная сторона включает, Общий интерфейс шлюза, Простой общий интерфейс шлюза, FastCGI, PHP, Сервлет Java, JavaServer Pages, Активные серверные страницы, ASP.NET, и Интерфейс программирования серверных приложений
• Вариант объекта
• Виртуальный хостинг
• Услуги веб-хостинга
• Веб-контейнер
• Веб-прокси
• веб-сервис

Рекомендации

внешняя ссылка

• RFC 2616, то Запрос комментариев документ, определяющий HTTP 1.1 протокол

Внутри и спереди сервера Dell PowerEdge, компьютера, предназначенного для установки в Среда для монтажа в стойку.

A веб-сервер — это серверное программное обеспечение или аппаратное обеспечение, предназначенное для запуска этого программного обеспечения, которое может удовлетворить запросы клиента в World Wide Web. Веб-сервер, как правило, может содержать один или несколько веб-сайтов. Веб-сервер обрабатывает входящие сетевые запросы через HTTP и несколько других связанных протоколов.

. Основная функция веб-сервера — хранить, обрабатывать и доставлять веб- страницы клиентам. Связь между клиентом и сервером осуществляется с использованием протокола передачи гипертекста (HTTP). Доставляемые страницы — это чаще всего HTML-документы, которые могут включать изображения, таблицы стилей и скрипты в дополнение к текстовому содержимому.

Для веб-сайта с высокой посещаемостью может использоваться несколько веб-серверов; здесь серверы Dell устанавливаются вместе и используются для Wikimedia Foundation.

A пользовательского агента, обычно веб-браузера или поискового робота, инициирует обмен данными, отправляя запрос на конкретный ресурс по протоколу HTTP, и сервер отвечает содержимым этого ресурса или сообщением об ошибке , если это невозможно. Ресурс обычно представляет собой реальный файл на вторичном хранилище сервера, но это не всегда так и зависит от того, как реализован.

веб-сервер. Хотя основная функция заключается в обслуживании контента, полная реализация HTTP также включает способы получения контента от клиентов. Эта функция используется для отправки веб-форм, включая загрузку файлов.

Многие общие веб-серверы также поддерживают сценарии на стороне сервера с использованием Active Server Pages (ASP), PHP (препроцессор гипертекста) или других языки сценариев. Это означает, что поведение веб-сервера может быть записано в отдельных файлах, в то время как фактическое программное обеспечение сервера остается неизменным. Обычно эта функция используется для генерации HTML-документов динамически («на лету»), а не для возврата статических документов. Первый в основном используется для получения или изменения информации из баз данных. Последние обычно намного быстрее и проще кэшировать, но не могут доставлять динамический контент.

Веб-серверы часто можно найти встроенными в такие устройства, как принтеры, маршрутизаторы, веб-камеры и обслуживающие только локальную сеть. Затем веб-сервер может использоваться как часть системы для мониторинга или администрирования рассматриваемого устройства. Обычно это означает, что на клиентском компьютере не нужно устанавливать дополнительное программное обеспечение, поскольку требуется только веб-браузер (который сейчас входит в состав большинства операционных систем ).

Содержание

• 1 История
• 2 Трансляция пути
• 3 Веб-серверы в режиме ядра и в режиме пользователя
• 4 Ограничения нагрузки
  • 4.1 Причины перегрузки
  • 4.2 Симптомы перегрузки
  • 4.3 Методы защиты от перегрузки
• 5 Доля рынка
  • 5.1 Февраль 2019
  • 5.2 Июль 2018
  • 5,3 Февраль 2017
  • 5.4 Февраль 2016
• 6 См. Также
• 7 Ссылки
• 8 Внешние ссылки

История

Первый в мире веб-сервер, рабочая станция NeXT Computer с Ethernet, 1990 год. На этикетке на корпусе написано: «Эта машина является сервером. НЕ ОТКЛЮЧАЙТЕ ЕГО !! « Sun Cobalt Qube 3 — компьютер серверное устройство (2002, снято с производства)

В марте 1989 года сэр Тим Бернерс-Ли предложил новый проект для своего работодателя CERN с целью облегчения обмена информацией между учеными с помощью системы гипертекста. В результате проекта Бернерс-Ли написал две программы в 1990 году:

• A Веб-браузер под названием WorldWideWeb
• Первый в мире веб-сервер, позже известный как CERN httpd, который работал на NeXTSTEP

Между 1991 и 1994 годами простота и эффективность ранних технологий, используемых для просмотра и обмена данными через всемирную паутину, помогла перенести их на множество различных операционных систем и распространить их использование среди научных организаций и университетов, а также впоследствии в промышленность.

В 1994 году Бернерс-Ли решил создать Консорциум Всемирной паутины (W3C) для регулирования дальнейшего развития множества задействованных технологий (HTTP, HTML и т. Д.) В процессе стандартизации.

Преобразование пути

Веб-серверы могут отображать компонент пути в унифицированном указателе ресурсов (URL) в:

• локальную файловую систему ресурс (для статических запросов)
• Внутреннее или внешнее имя программы (для динамических запросов)

Для статического запроса путь URL, указанный клиентом, определяется относительно корневого каталога веб-сервера.

Рассмотрим следующий URL в том виде, в каком он будет запрошен клиентом по HTTP:

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

Клиентский пользовательский агент преобразует его в соединение с www.example.comс помощью следующего запроса HTTP / 2 :

GET / path / file.html Хост HTTP / 2: www.example.com

Веб-сервер на www.example.comдобавит указанный путь к пути своего корневого каталога. На сервере Apache это обычно / home / www(на машинах Unix обычно / var / www). Результатом является ресурс локальной файловой системы:

/home/www/path/file.html

Затем веб-сервер считывает файл, если он существует, и отправляет ответ в веб-браузер клиента. Ответ будет описывать содержимое файла и содержать сам файл, либо будет возвращено сообщение об ошибке о том, что файл не существует или недоступен.

Веб-серверы в режиме ядра и пользователя

Веб-сервер может быть либо включен в OS ядро ​​, либо в пользовательское пространство (например, другие обычные приложения).

Веб-серверы, работающие в пользовательском режиме, должны запрашивать у системы разрешение на использование большего объема памяти или ресурсов ЦП. Эти запросы к ядру не только требуют времени, но и не всегда удовлетворяются, потому что система резервирует ресурсы для собственного использования и несет ответственность за совместное использование аппаратных ресурсов со всеми другими запущенными приложениями. Выполнение в пользовательском режиме также может означать бесполезные буферные копии, что является еще одним ограничением для веб-серверов пользовательского режима.

Пределы нагрузки

Веб-сервер (программа) имеет определенные ограничения нагрузки, поскольку он может обрабатывать только ограниченное количество одновременных клиентских подключений (обычно от 2 до 80 000, по умолчанию от 500 до 1000) на IP-адрес (и порт TCP), и он может обслуживать только определенное максимальное количество запросов в секунду (RPS, также известное как запросов в секунду или QPS) в зависимости от:

• собственные настройки,
• тип HTTP-запроса,
• независимо от того, является ли контент статическим или динамическим,
• независимо от того, является ли контент кешированным или сжатый и
• аппаратные и программные ограничения ОС компьютера, на котором работает веб-сервер.

Когда веб-сервер приближается к своему пределу или превышает его, он перестает отвечать.

Причины перегрузки

В любой момент веб-серверы могут быть перегружены из-за:

• Избыточного законного веб-трафика. Тысячи или даже миллионы клиентов подключаются к веб-сайту за короткий промежуток времени, например, эффект Slashdot ;
• Распределенный отказ в обслуживании атаки. Атака отказа в обслуживании (DoS-атака) или распределенная атака отказа в обслуживании (DDoS-атака) — это попытка сделать компьютер или сетевой ресурс недоступным для предполагаемых пользователей;
• Компьютерные черви, которые иногда вызывают аномальный трафик из-за миллионов зараженных компьютеров (не координированных между ними)
• XSS-черви могут вызывать высокий трафик из-за миллионов зараженных браузеров или веб-серверов;
• Интернет-боты Трафик не фильтруется / не ограничивается большие веб-сайты с очень небольшим количеством ресурсов (пропускная способность и т. д.);
• Интернет (сеть) замедляется, поэтому запросы клиентов обслуживаются медленнее, а количество подключений увеличивается настолько, что достигаются ограничения сервера;
• Веб-серверы (компьютеры ) частичная недоступность. Это может произойти из-за необходимого или срочного обслуживания или обновления, сбоев оборудования или программного обеспечения, сбоев внутренней части (например, базы данных ) и т. Д.; в этих случаях оставшиеся веб-серверы получают слишком много трафика и становятся перегруженными.

Симптомы перегрузки

Симптомы перегруженного веб-сервера:

• Запросы обслуживаются с (возможно, долгими) задержками (от От 1 секунды до нескольких сотен секунд).
• Веб-сервер возвращает код ошибки HTTP, например 500, 502, 503, 504, 408 или даже 404, что неприемлемо для состояния перегрузки.
• Веб-сервер отклоняет или сбрасывает (прерывает) TCP соединения, прежде чем он вернет какое-либо содержимое.
• В очень редких случаях, веб-сервер возвращает только часть запрошенного контента. Такое поведение можно рассматривать как ошибку, даже если она обычно возникает как симптом перегрузки.

Методы защиты от перегрузки

Чтобы частично преодолеть пределы нагрузки выше среднего и предотвратить перегрузку, большинство популярных веб-сайтов используют общие методы, такие как:

• Управление сетевым трафиком с помощью:
  • межсетевых экранов для блокировки нежелательного трафика, исходящего от плохих IP-источников или имеющего плохие шаблоны
  • HTTP-менеджеров трафика, которые нужно отбросить, перенаправляйте или перезаписывайте запросы с плохими шаблонами HTTP
  • Управление полосой пропускания и формирование трафика, чтобы сгладить пики использования сети
• Развертывание сети методы кеширования
• Использование разных доменных имен или IP-адресов для обслуживания различного (статического и динамического) контента отдельными веб-серверами, например:
  • http: //images.example.com
  • http://example.com
• Использование разных доменных имен или компьютеров для отделения больших файлов от файлов малого и среднего размера; идея состоит в том, чтобы иметь возможность полностью кэшировать файлы малого и среднего размера и эффективно обслуживать большие или огромные (более 10 — 1000 МБ) файлы с помощью различных настроек
• Использование множества интернет-серверов (программ) на компьютер, каждый из которых привязан к своей собственной сетевой карте и IP-адресу
• Использование множества интернет-серверов (компьютеров), сгруппированных вместе за балансировщиком нагрузки чтобы они действовали или рассматривались как один большой веб-сервер
• Добавление дополнительных аппаратных ресурсов (т.е. RAM, дисков ) на каждый компьютер
• Настройка Параметры ОС для аппаратных возможностей и использования
• Использование более эффективных компьютерных программ для веб-серверов и т. Д.
• Использование других обходных путей, особенно если динамический контент участвует

доля рынка

LAMP (пакет программного обеспечения) (здесь дополнительно с Squid ), полностью состоящий из бесплатного программного обеспечения с открытым исходным кодом, является высокопроизводительным и надежным решением для тяжелых условий эксплуатации vironment Диаграмма:. Доля рынка всех сайтов основных веб-серверов 2005–2018 гг.

Февраль 2019 г.

Ниже представлены последние статистические данные о рыночной доле всех сайтов ведущих веб-серверов на Интернет компанией W3Techs Использование веб-серверов для веб-сайтов.

Все остальные веб-серверы используются менее чем 1% веб-сайтов.

Июль 2018 г.

Ниже приведены последние статистические данные о рыночной доле всех сайтов ведущих веб-серверов в Интернете по данным W3Techs Использование веб-серверов для веб-сайтов.

Все остальные веб-серверы используются менее чем на 1% веб-сайтов.

Февраль 2017 г.

Ниже приведены последние статистические данные о рыночной доле всех сайтов ведущих веб-серверов в Интернете по Netcraft Обзор веб-серверов за февраль 2017 г..

февраль 2016

Ниже приведены последние статистические данные о рыночной доле всех сайтов ведущих веб-серверов в Интернете по Netcraft февраль Обзор веб-серверов 2016.

Apache, IIS и Nginx — наиболее часто используемые веб-серверы во всемирной паутине.

См. Также

• Сервер (вычисления)
• Сервер приложений
• Сравнение программного обеспечения веб-сервера
• HTTP-сжатие
• Веб-приложение с открытым исходным кодом
• Серверная сторона включает, Общий интерфейс шлюза, Простой общий интерфейс шлюза, FastCGI, PHP, Java S ervlet, JavaServer Pages, Active Server Pages, ASP.NET и Интерфейс программирования серверных приложений
• Вариант объекта
• Виртуальный хостинг
• Служба веб-хостинга
• Веб-контейнер
• Веб-прокси
• Веб-служба

Ссылки

Внешние ссылки

• RFC 2616, запрос Комментарии документ, определяющий протокол HTTP 1.1