网络服务器

Web服务器是计算机软件，并且是通过HTTP （为分发Web内容创建的网络协议）或其安全变体HTTPS接受请求的基础硬件。用户代理通常是Web浏览器或Web爬网，通过使用HTTP提出网页或其他资源的请求来启动通信，而服务器则使用该资源的内容或错误消息响应。如果配置为此，Web服务器还可以接受并存储从用户代理发送的资源。

用于运行Web服务器的硬件可能会根据需要处理的请求量而变化。在范围的低端，是嵌入式系统，例如一个路由器，该路由器以其配置接口运行小型Web服务器。高流量的互联网网站可能会处理数百台服务器在高速计算机架上运行的请求。

从Web服务器发送的资源可以是可用于Web服务器的预先存在的文件（静态内容），也可以是在请求时通过与服务器软件通信的另一个程序在请求时生成的资源。前者通常可以更快地提供服务，并且可以更轻松地缓存以进行重复请求，而后者则支持更广泛的应用程序。

使用HTTP作为一般计算机对计算机通信的基础以及对WebDAV扩展的支持，诸如REST和SOAP之类的技术已经扩展了Web服务器的应用，远远超出了其最初提供的可读页面的目的。

历史

这是Web服务器程序的非常简短的历史记录，因此一些信息必然与Web浏览器，万维网和Internet的历史相关。因此，为了清晰和可理解，下面报告的一些关键历史信息可能与上述历史文章中的一篇或多个中也相似。

最初的www项目（1989-1991）

1989年3月，蒂姆·伯纳斯·李爵士（Tim Berners-Lee）爵士向他的雇主CERN提出了一个新项目，目的是通过使用超文本系统来放松科学家之间的信息交换。标题为“超文本和CERN”的提案要求发表评论，并由几个人阅读。 1990年10月，该提案得到了重新制定和丰富（作为罗伯特·凯里亚（Robert Cailliau ）的合著者），最后得到批准。

在1990年末至1991年初之间，该项目导致Berners-Lee及其开发人员撰写和测试了几个软件库以及三个程序，最初安装在下一步工作站上的NextStep OS上运行：

一个图形的Web浏览器，称为WorldWideWeb ；
便携式线模式Web浏览器；
Web服务器，后来称为CERN HTTPD 。

这些早期浏览器使用名为HTTP 0.9的新基本通信协议从Web服务器中检索了以HTML的简单早期形式编写的网页。

1991年8月，蒂姆·伯纳·李（Tim Berner-Lee）宣布了WWW技术的诞生，并鼓励科学家采用和开发它。不久之后，这些程序以及其源代码都可以向有兴趣使用的人提供。尽管源代码未正式许可或放置在公共领域，但CERN非正式地允许用户和开发人员在其上进行实验并进一步开发。 Berners-Lee开始促进这些程序的采用和使用以及对其他操作系统的移植。

Fast and Wild Development（1991-1995）

活动网站的数量（1991-1996）

1991年12月，欧洲以外的第一台Web服务器安装在美国SLAC（美国）。这是一个非常重要的事件，因为它启动了Web浏览器和Web服务器之间的跨大陆Web通信。

同时，由于其源代码的可用性和HTTP协议的公开规格，在1991 - 1993年，CERN Web服务器程序继续由WWW Group积极开发，因此，Web服务器的其他许多实现开始开发。

1993年4月，CERN发表了公开官员声明，指出Web软件的三个组成部分（基本线模式客户端，Web服务器和通用代码的库）以及其源代码及其源代码都放在公共领域中。该声明使Web Server开发人员从基于该源代码开发衍生作品开发的任何可能的法律问题（实践中从未存在的威胁）中释放出任何可能的法律问题。

在1994 年初，新的Web服务器中最著名POSTHTTP方法和CGI与外部程序进行通信。这些功能以及NCSA的Mosaic浏览器的多媒体功能（也能够管理HTML 表单以将数据发送到Web服务器）突出了Web技术在发布和分布式计算应用程序中的潜力。

在1994年下半年，NCSA HTTPD的开发停滞不前，以至于一组外部软件开发人员，网站管理员和对该服务器感兴趣的其他专业人物开始编写和收集补丁程序，这要归功于NCSA HTTPD httpd源代码。公共领域。在1995年初，这些补丁都应用于NCSA源代码的最后一个版本，经过多次测试，启动了Apache HTTP服务器项目。

1994年底，一家名为Netsite的新商业网络服务器已发行，具有特定功能。这是首先是由Netscape ，然后是Sun Microsystems ，最后是Oracle Corporation开发的许多其他类似产品中的第一个。

1995年中， Microsoft于1995年中期，由Microsoft发布了Windows NT OS的第一版。这标志着一位非常重要的商业开发人员和供应商在世界范围的Web技术领域中的条目，并且在网络的双方（客户端和服务器）中都发挥了关键作用。

在1995年下半年，CERN和NCSA Web服务器开始下降（在全球百分比使用中），这是因为新的Web服务器的广泛采用，这些新网络服务器具有更快的开发周期以及更多的功能，更多的修复程序，并且超过更多的固定功能，并且比其他更大的性能相比以前的。

爆炸性增长与竞争（1996- 2014年）

活动网站的数量（1996-2002）

在1996年底，已经有五十多个已知的（不同的）Web服务器软件程序可供每个想要拥有Internet域名和/或托管网站的人使用。他们中的许多人仅在很快就居住，并被其他Web服务器所取代。

RFC关于协议版本的发表HTTP/1.0（1996）和HTTP/1.1（1997，1999）迫使大多数Web服务器遵守这些标准（并非总是完全）。需要使用TCP/IP持续连接（HTTP/1.1）的Web服务器的使用都可以增加允许的并发连接的最大数量，并提高其可扩展性水平。

在1996年至1999年之间， Netscape Enterprise Server和Microsoft的IIS出现在领先的商业选项中，而在自由使用和开源程序中，Apache HTTP Server作为首选服务器（由于其可靠性及其许多功能）中，将其列为铅。

在那几年中，还有另一台商业广告，高度创新性，因此称为宙斯（现已停产），它被称为市场上最快，最可扩展的网络服务器之一，至少截至2000年代的前十年，使用百分比低。

Apache从1996年中到2015年底产生了最常用的Web服务器，当时，经过几年的下降，IIS最初被IIS和NGINX超过了它。之后，IIS的使用百分比比Apache低得多（另请参见市场份额）。

从2005 - 2006年开始，Apache通过引入新的性能功能（例如事件MPM和新内容缓存）开始提高其速度和可伸缩性水平。由于最初将这些新的性能改进标记为实验，因此用户很长一段时间都没有启用它们，因此Apache遭受了商业服务器的竞争，最重要的是，其他已经已经存在的其他开源服务器的竞争自从其开发开始和Apache下降时，取得的表现远远出色（主要是在服务静态内容时），还可以提供足够长的经过良好测试的高级功能。

实际上，在2000年开始几年后，不仅其他商业和竞争激烈的网络服务器，例如Litespeed ，而且还有许多其他开源计划，通常具有出色的质量和非常高的性能，其中应注意到Hiawatha， Cherokee HTTP HTTP服务器， LightTPD ， NGINX和其他派生/相关产品也可以提供商业支持。

在2007 - 2008年左右，最受欢迎的Web浏览器将其先前的默认限制增加到每个宿主域的2个持续连接（RFC-2616建议的限制）至4、6或8个宿主连接，以加快检索的速度具有大量图像的重型网页，并减轻了用于用于网页中事件的双向通知的动态对象的持续连接短缺的问题。在一年之内，这些变化平均几乎使Web服务器必须管理的最大持续连接数量几乎增加了两倍。这种趋势（增加持续连接的数量）肯定为采用较慢的Web服务器面前采用反向代理带来了强烈的动力，它还为新兴的新网络服务器提供了更多机会，可以显示他们的所有速度和功能处理大量的并发连接而不需要太多硬件资源（具有大量CPU，RAM和快速磁盘的昂贵计算机）。

新挑战（2015年和后来的几年）

在2015年，RFC发布了新的协议版本[HTTP/2]，并且由于新规格的实施根本不是微不足道的，因此在较不受欢迎的Web服务器的开发人员之间出现了困境（例如使用百分比低于1％..的使用率低于1％.. .. 2％），关于添加或不添加对该新协议版本的支持。

实际上，由于许多因素，支持HTTP/2通常需要对其内部实施进行根本性更改（实际上始终需要加密的连接，可以区分同一TCP端口上HTTP/1.X和HTTP/2连接的能力，HTTP消息的二进制表示，消息优先级，HTTP标头的压缩，使用流的使用也称为TCP/IP子连接和相关的流控制等），因此这些Web服务器的一些开发人员选择不支持新的HTTP/ 2版本（在至少在不久的将来）也是由于以下主要原因：

协议HTTP/1.X无论如何都会得到浏览器很长一段时间（也许永远）的支持，因此在下一将来，客户和服务器之间不会不兼容；
实施HTTP/2被认为是压倒性复杂性的一项任务，该任务可能为直到2015年不存在的全新错误打开了大门，因此在开发和测试新协议的实施时，它将需要明显的投资；
如果将努力证明是合理的，则添加HTTP/2的支持始终可以做到。

取而代之的是，最受欢迎的Web服务器的开发人员急于提供新协议的可用性，这不仅是因为他们有劳动力和这样做的时间，而且还因为他们以前的SPDY协议的实施通常可以作为起点重复使用而且由于大多数使用的Web浏览器出于相同的原因而很快实现了它。促使这些开发人员迅速采取行动的另一个原因是，网站管理员感受到了不断增加的网络流量的压力，他们确实想尽快安装和尝试 - 可以大大降低TCP/IP连接的数量和加速度访问托管网站。

在2020– 2021年，HTTP/2关于其实现的动态（由顶级Web服务器和流行的Web浏览器）部分被部分复制，此前在发布有关HTTP/3协议的未来RFC的高级草稿发布后。

技术概述

应将以下技术概述视为尝试提供一些非常有限的示例，以了解某些功能可能在Web服务器中实现的某些功能以及它可能执行的某些任务，以便对该主题具有足够宽的方案。

Web服务器程序通过实现一个或多个版本的HTTP协议，通常包括HTTPS安全变体以及被认为对其计划的用法有用的，通常包括HTTPS Secure变体以及其他功能和扩展名，从而在客户端– Server模型中扮演角色。

Web服务器程序的复杂性和效率可能会因（例如）而有很大差异：

实施的共同特征；
执行的常见任务；
以目标为目标的性能和可伸缩性水平；
采用的软件模型和技术来达到既定性能和可伸缩性水平；
目标用法的硬件和类别，例如嵌入式系统，低中等流量网络服务器，高流量Internet Web服务器。

共同特征

尽管Web服务器程序的实现方式有所不同，但其中大多数提供以下常见功能。

这些是大多数Web服务器通常具有的基本功能。

静态内容服务：能够通过HTTP协议将静态内容（Web文件）提供给客户端。
HTTP ：支持一个或多个版本的HTTP协议，以发送与客户端http请求的版本兼容的http响应版本/2 ， http/3 。
记录：通常Web服务器还具有记录有关客户端请求和服务器响应的一些信息的能力，以记录文件以进行安全性和统计目的。

以下其他一些更高级和流行的功能（只有很短的选择）。

动态内容服务：能够通过HTTP协议向客户端提供动态内容（即时生成）。
虚拟托管：只能使用一个IP地址服务许多网站（域名）。
授权：能够允许，禁止或授权访问网站路径部分（Web Resources）。
内容缓存：能够缓存静态和/或动态内容以加快服务器响应；
大型文件支持：能够服务32位OS上大于2 GB的文件。
带宽节流：限制内容响应的速度，以免使网络饱和并能够为更多的客户提供服务；
重写引擎：将清洁URL的部分（在客户端请求中找到）映射到其真实名称。
自定义错误页面：支持自定义的HTTP错误消息。

常见任务

Web服务器程序运行时，通常执行几个通用任务，例如：

启动，可选地读取并应用其配置文件或其他地方发现的设置，可选地打开日志文件，开始收听客户端连接 /请求；
可以选择根据其设置和当前的操作条件来调整其一般行为；
管理客户连接（接受新的连接或根据需要关闭现有的连接）；
接收客户端请求（通过阅读HTTP消息）：
- 读取并验证每个HTTP请求消息；
- 通常执行URL归一化；
- 通常执行URL映射（可能默认为URL路径翻译）；
- 通常执行URL路径翻译以及各种安全检查；
执行或拒绝请求的HTTP方法：
- 可选管理URL授权；
- 可选管理URL重定向；
- 可选地管理静态资源的请求（文件内容）：
  - 可选管理目录索引文件；
  - 可选地管理常规文件；
- 可选管理动态资源的请求：
  - 可选管理目录列表；
  - 可选地管理程序或模块处理，检查可用性，开始和最终停止执行用于生成动态内容的外部程序的执行；
  - 可选地管理与用于生成动态内容的外部程序 /内部模块的通信；
回复客户请求，发送适当的HTTP响应（例如请求的资源或错误消息）最终将HTTP标头验证或添加到由动态程序 /模块发送的标头中；
可选的日志（部分或全部）客户端请求和/或其对外部用户日志文件或Syslog的系统日志文件的响应，通常使用常见日志格式；
可选地记录有关检测到的异常或其他值得注意的事件（例如在客户端请求或其内部功能中）的处理消息，使用Syslog或其他某些系统设施；这些日志消息通常具有调试，警告，错误，警报级别，可以根据某些设置过滤（未记录），另请参见严重性级别；
可选地生成有关Web流量管理和/或其性能的统计信息；
其他自定义任务。

阅读请求消息

Web服务器程序能够：

阅读HTTP请求消息；
解释它；
验证其语法；
识别已知的HTTP标头并从中提取其值。

一旦将HTTP请求消息解码并进行了验证，可以使用其值来确定是否可以满足该请求。这需要许多其他步骤，包括安全检查。

URL归一化

Web服务器程序通常会按顺序执行某种类型的URL标准化（在大多数HTTP请求消息中找到的URL ）：

使资源路径始终是网站根目录的干净统一路径；
降低安全风险（例如，通过更轻松地拦截网站根目录之外的静态资源或访问禁止或需要授权的网站根目录下方的部分路径的某些部分）；
使Web资源的路径更能通过人类和Web日志分析程序（也称为日志分析仪 /统计应用程序）识别。

术语URL归一化是指以一致的方式修改和标准化URL的过程。可以执行几种类型的归一化，包括方案的转换和主机向小写。最重要的正常化是删除“”。和“ ..”路径段，并在非空路径组件中添加落后的斜线。

URL映射

“ URL映射是分析URL的过程，以弄清楚它的参考资源，以便可以将资源返回到请求客户端。此过程是使用对Web服务器的每个请求（并使用）某些请求与文件一起提供，例如HTML文档或GIF映像，而其他请求则具有运行CGI程序的结果，而另一些则是其他过程，例如内置模块处理程序，PHP文档，或Java Servlet。”

实际上，除了简单的静态内容服务（例如URL重写引擎，动态内容服务）之外，实现高级功能的Web服务器程序通常必须弄清楚如何处理该URL，例如：

作为URL重定向，重定向到另一个URL；
作为文件内容的静态请求；
作为一个动态请求：
- 该目录中包含的文件或其他子目录的目录列表；
- 其他类型的动态请求，以识别能够处理该类型的URL路径并传递到其他URL零件的程序 /模块处理器，即通常是路径INFO和查询字符串变量。

Web服务器的一个或多个配置文件可以指定到特定URL处理程序（文件，目录，外部程序或内部模块）的URL路径部分（例如，文件路径的初始部分，文件名扩展和其他路径组件）的映射。

当Web服务器实现上述高级功能的一个或多个，那么有效URL的路径部分可能并不总是匹配网站目录树下的现有文件系统路径（文件或文件系统中的目录），因为它可以参考用于动态请求的内部或外部模块处理器的虚拟名称。

URL路径转换为文件系统

Web服务器程序能够将URL路径（全部或一部分）转换为引用物理文件系统路径的URL路径，并将其转换为目标网站根目录下的绝对路径。

网站的根目录可以通过配置文件或Web服务器的某些内部规则来指定网站的名称，该名称是HTTP客户端请求中发现的URL的主机部分。

路径转换为文件系统是针对以下类型的Web资源完成的：

一个本地，通常不执行的文件（文件内容的静态请求）；
本地目录（动态请求：即时生成的目录列表）；
一个程序名称（使用CGI或SCGI接口执行的动态请求，并且Web服务器读取其输出，并对制作HTTP请求的客户端读取）。

Web服务器附加了请求的URL（HTTP请求消息）中找到的路径，并将其附加到（主机）网站root目录的路径上。在Apache服务器上，这通常是/home/www/website（在Unix机器上，通常是：/var/www/website）。请参阅以下示例有关它如何产生的示例。

静态文件请求的URL路径翻译

以下URL指定的现有文件的静态请求的示例：

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

客户端的用户代理连接到www.example.com然后发送以下HTTP /1.1请求：

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

结果是本地文件系统资源：

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

然后，Web服务器读取文件（如果存在），并对客户端的Web浏览器发送响应。响应将描述文件的内容并包含文件本身，或者将返回错误消息，说该文件不存在或禁止其访问权限。

目录请求的URL路径翻译（没有静态索引文件）

以下URL指定的现有目录的隐式动态请求的示例：

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

客户端的用户代理连接到www.example.com然后发送以下HTTP /1.1请求：

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

结果是本地目录路径：

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

然后，Web服务器验证目录的存在，如果存在并且可以访问该目录，则尝试找出索引文件（在这种情况下不存在），因此它将请求传递给内部模块或程序专用到目录列表并最终读取数据输出并向客户端的Web浏览器发送响应。响应将描述目录的内容（包含的子目录和文件列表），否则错误消息将返回，说明目录不存在或禁止其访问权限。

动态程序请求的URL路径翻译

对于动态请求，客户端指定的URL路径应参考Web服务器使用的现有外部程序（通常是带有CGI的可执行文件）来生成动态内容。

使用程序文件生成输出的动态请求的示例：

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

客户端的用户代理连接到www.example.com然后发送以下HTTP /1.1请求：

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

结果是该程序的本地文件路径（在此示例中是PHP程序）：

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

Web服务器执行该程序，传递Path-Info和查询字符串action=view&orderby=thread&date=2021-10-15因此该程序具有需要运行的信息。（在这种情况下，它将返回一个HTML文档，其中包含2021年10月15日线程订购的论坛条目的视图）。除此之外，Web服务器还读取从外部程序发送的数据，并将数据重新发送给提出请求的客户端。

管理请求消息

一旦读取，解释和验证了请求，就必须根据其方法，URL和参数进行管理，其中可能包括HTTP标头的值。

实际上，Web服务器必须使用以下响应路径之一来处理该请求：

如果请求中的某些内容是不可接受的（在状态行或消息标头中），Web服务器已经发送了错误响应。
如果请求有一种方法（例如OPTIONS）可以通过Web服务器的一般代码来满足，然后发送成功的响应；
如果URL需要授权，则发送授权错误消息；
如果URL映射到重定向，则发送重定向消息；
如果URL映射到动态资源（虚拟路径或目录列表），则调用其处理程序（内部模块或外部程序），并将请求参数（查询字符串和路径信息）传递给它，以便允许其进入回复该请求；
如果URL映射到静态资源（通常是文件系统上的文件），则调用内部静态处理程序发送该文件；
如果尚不清楚请求方法，或者是否还有其他一些不可接受的条件（例如找不到资源，内部服务器错误等），则发送错误响应。

提供静态内容

如果Web服务器程序能够提供静态内容，并且已配置为这样做，那么每当请求消息具有有效的URL路径匹配（URL映射，URL Translation和URL重定向）时，它就可以发送文件内容。网站和文件的根目录下的现有文件的属性与Web服务器程序的内部规则所要求的属性相匹配。

这种内容称为静态，因为当它发送到客户端时，通常不会被Web服务器更改，并且由于某些程序对其进行修改（文件修改），因此它保持不变。

注意：仅服务静态内容时，Web服务器程序通常不会更改已服务网站的文件内容（因为它们仅读取而从未编写），因此仅支持这些HTTP方法是足够的：

OPTIONS
HEAD
GET

静态文件内容的响应可以通过文件缓存加速。

目录索引文件

如果Web服务器程序接收了带有URL的客户端请求消息，其路径匹配现有目录之一，并且该目录可访问，并且启用了服务目录索引文件，则Web服务器程序可以尝试使用已知的第一个（或已配置的）该目录中找到的静态索引文件名（常规文件）；如果找不到索引文件或未满足其他条件，则返回错误消息。

静态索引文件的大多数使用名称是：index.html,index.htm和Default.htm.

常规文件

如果Web服务器程序接收了带有URL的客户端请求消息，其路径与现有文件的文件名匹配，并且该文件可通过Web Server程序访问，其属性可以匹配Web服务器程序的内部规则，则Web Server程序可以发送该文件向客户端文件。

通常，出于安全原因，大多数Web服务器程序都是预先配置的，以仅使用常规文件或避免使用诸如设备文件之类的特殊文件类型，以及符号链接或与之的硬链接。目的是在提供静态Web资源时避免不良的副作用。

提供动态内容

如果Web服务器程序能够提供动态内容，并且已配置为这样做，则它能够与适当的内部模块或外部程序（与请求的URL路径关联）进行通信，以传递给IT参数客户要求；之后，Web服务器程序从其数据响应中读取（经常生成，通常是在即时生成的），然后将其重新发送给提出该请求的客户端程序。

注意：服务静态和动态内容时，Web服务器程序通常还必须支持以下HTTP方法，以便能够从客户端安全接收数据，以便能够托管具有交互式表单的网站（S ）可能将大型数据集（例如大量数据输入或文件上传）发送到Web服务器 /外部程序 /模块：

POST

为了能够与其内部模块和/或外部程序进行通信，Web服务器程序必须实现了许多可用网关接口中的一个或多个（另请参见用于动态内容的Web服务器网关接口）。

三个标准和历史网关接口是以下。

CGI: 对于每个动态请求，Web服务器程序运行了一个外部CGI程序，然后Web服务器程序从中读取生成的数据响应，然后将其重新将其重新定位给客户端。

SCGI: Web Server程序或其他某些程序 /进程启动了一次外部SCGI程序（通常是一个过程），然后等待网络连接；每次有新的请求时，Web服务器程序都会建立一个新的网络连接，以发送请求参数并读取其数据响应，然后关闭网络连接。

fastcgi: Web Server程序或其他某些程序 /进程启动了一次外部FastCGI程序（通常是一个过程），然后等待由Web服务器永久建立的网络连接；通过该连接发送请求参数并读取数据响应。

目录列表

Web服务器程序可能能够管理文件和子目录目录索引列表的动态生成。

如果将Web服务器程序配置为这样做，并且请求的URL路径匹配现有目录且允许其访问权限，并且在该目录下没有找到静态索引文件，则在网页（通常以HTML格式为html格式）中找到了文件，其中包含文件列表和/或上述目录的子目录是动态生成的（拍摄的）。如果无法生成，则返回错误。

一些Web服务器程序允许使用网页模板来自定义目录列表（HTML文档，包含占位符，例如$(FILE_NAME), $(FILE_SIZE)等等，被Web服务器目录中的每个文件条目的字段值替换），例如index.tpl或使用即时解释和执行的HTML和嵌入式源代码的使用，例如index.asp，和 /或通过支持CGIS，SCGIS，FCGIS等动态索引程序的使用index.cgi,index.php,index.fcgi.

动态生成的目录列表的使用通常可以避免或限于网站的几个选定目录，因为该一代比发送静态索引页面要多得多。

目录列表的主要用法是允许下载文件（通常是在其名称，大小，修改日期或文件属性可能随机 /频繁更改时），而无需向请求用户提供更多信息。

程序或模块处理

外部程序或内部模块（处理单元）可以执行某种应用程序功能，该功能可用于将数据从或将数据存储到一个或多个数据存储库中，例如：

文件（文件系统）;
数据库（DB）;
位于本地计算机或其他计算机中的其他来源。

处理单元可以返回任何类型的Web内容，也可以使用从数据存储库中检索的数据，例如：

文档（例如HTML ， XML等）；
一个图像;
一段录像;
结构化数据，例如，可用于更新Web接口的动态页面（ DHTML ）显示的一个或多个值，并且可能是由XMLHTTPRequest API请求的（另请参见： Dynamic Page ）。

实际上，只要有可能会有所不同的内容，具体取决于客户端请求中包含的一个或多个参数，则通常会动态生成。

发送响应消息

Web服务器程序能够将响应消息作为回复发送给客户端请求消息。

可能会发送错误响应消息，因为无法成功读取，解码，分析或执行请求消息。

注意：仅报告以下各节作为示例，以帮助理解Web服务器或多或少的作用；这些部分既不详尽又完整。

错误讯息

Web服务器程序可以回复带有多种错误消息的客户端请求消息，无论如何这些错误主要分为两个类别：

由于请求消息的类型或请求的Web资源的可用性， HTTP客户端错误；
由于内部服务器错误， HTTP服务器错误。

客户浏览器收到错误响应 /消息时，如果它与主要用户请求有关（例如Web资源（例如网页）的URL），则通常在某些浏览器窗口 /消息中显示错误消息。

URL授权

Web服务器程序可能能够验证是否请求的URL路径：

每个人都可以自由访问；
需要用户身份验证（用户凭据的请求，例如用户名和密码）；
某些或各种用户禁止访问。

如果已实施并启用了授权 /访问权限功能，并且未授予对Web资源的访问，则根据所需的访问权限，Web服务器程序：

可以通过发送特定错误消息（例如禁止访问）来拒绝访问；
可以通过发送特定错误消息（例如未经授权）来拒绝访问，该消息通常迫使客户浏览器要求人类用户提供所需的用户凭据；如果提供了身份验证凭据，则Web服务器程序将验证并接受或拒绝它们。

URL重定向

Web服务器程序可能具有将URL重定向到新URL（新位置）的能力，该新位置包括回复端请求消息，其中包含适合访问有效或现有Web资源的新URL的响应消息（客户端应重做带有新URL的请求）。

使用位置的URL重定向：

通过添加最终斜杠'/'来修复目录名称；
为新的网址提供新的URL，通往可以找到这种Web资源的新路径。
当当前域的负载太多时，要给另一个域提供新的URL。

示例1：URL路径指向目录名称，但没有最终的斜杠'/'，因此Web服务器将重定向发送到客户端，以指示其用固定路径名重做请求。

从：
/directory1/directory2
到：
/directory1/directory2/

示例2：一组文档已在网站内部移动，以重组其文件系统路径。

从：
/directory1/directory2/2021-10-08/
到：
/directory1/directory2/2021/10/08/

示例3：一组文档已移至新网站，现在必须使用安全的HTTPS连接来访问它们。

从：
http://www.example.com/directory1/directory2/2021-10-08/
到：
https://docs.example.com/directory1/2021-10-08/

上面的示例只是一些可能的重定向。

成功的消息

Web服务器程序能够使用成功的消息回复有效的客户端请求消息，该消息包含所请求的Web资源数据。

如果Web资源数据被发送回客户端，则可以根据其检索方式（来自文件或某些程序 /模块的输出），它可以是静态内容或动态内容。

内容缓存

为了通过降低平均HTTP响应时间和所使用的硬件资源来加快Web服务器响应的速度，许多流行的Web服务器实现了一个或多个内容缓存，每个速度都专门用于内容类别。

内容通常由其起源缓存，例如：

静态内容：
- 文件缓存;
动态内容：
- 动态缓存（模块 /程序输出）。

文件缓存

从历史上看，自1960年代中期 / 1970年代中期以来，必须经常，随机和快速访问的文件中发现的静态内容。遗憾的是，与RAM Speed相比，从读取并写入此类设备的操作一直被认为是非常缓慢的操作，因此，由于早期OSS ，第一个磁盘缓存，然后开发了OS文件缓存子系统来加快I/O操作经常访问的数据 /文件。

即使借助OS文件缓存，涉及目录和存储在磁盘上的目录和文件的I / O操作的相对 /偶尔也很快就成为了最高网络服务器预期的性能的瓶颈，特别是自1990年代中期以来，当Web Internet流量开始成倍增长，以及互联网/网络线路的速度不断提高时。

自1990年代中期以来，如何进一步有效地加速静态文件的服务，从而增加每秒的最大请求 /响应数量（ RPS ），目的是提出有用的缓存模型可以在Web服务器程序中实现。

实际上，如今，许多流行 /高性能的Web服务器程序包括其自己的Userland文件缓存，该文件为Web服务器使用量以及使用其特定的实现和参数。

RAID和/或快速固态驱动器（具有很高I/O速度的存储硬件）的广泛利用采用略有降低，但当然没有消除将文件缓存纳入Web服务器中的优势。

动态缓存

动态内容（由内部模块或外部程序输出）可能总是很频繁（给定键 /参数的唯一URL），因此，也许持续一段时间（例如，1秒至几个小时或更长时间），结果输出可以在RAM甚至快速磁盘上缓存。

动态缓存的典型用法是，网站上有有关新闻，天气，图像，地图等的动态网页，这些网页不会经常变化（例如每n分钟），并且每分钟大量客户访问这些网页小时;在这种情况下，返回缓存的内容也很有用（不调用内部模块或外部程序），因为客户端通常没有更新的浏览器caches中请求内容的副本。

无论如何，在大多数情况下，这种缓存是由外部服务器（例如反向代理）或通过特定应用程序管理（例如Memcached ）管理的单独计算机中的动态数据输出来实现的，以便不竞争硬件资源（CPU，RAM，RAM，RAM，RAM ，带Web服务器的磁盘）。

内核模式和用户模式Web服务器

可以将Web服务器软件合并到OS中并在内核空间中执行，也可以在用户空间（与其他常规应用程序）中执行。

以内核模式运行的Web服务器（通常称为内核空间Web服务器）可以直接访问内核资源，因此，从理论上讲，它们可以比以用户模式运行的速度更快。无论如何，在内核模式下运行Web服务器的缺点，例如：开发（调试）软件的困难，而运行时关键错误可能会导致OS内核中的严重问题。

在用户模式中运行的Web服务器必须要求系统使用更多内存或更多CPU资源。这些请求不仅需要花费时间，而且可能并不总是满足它们，因为系统保留资源以供自己使用，并有责任与所有其他运行的应用程序共享硬件资源。在用户模式下执行还意味着使用更多的缓冲区/数据副本（在用户空间和内核空间之间），这可能会导致用户模式Web服务器的性能下降。

如今，几乎所有Web服务器软件都是在用户模式下执行的（因为上述许多小缺点已通过更快的硬件，新的OS版本，更快的OS系统调用和新的优化Web服务器软件克服了）。另请参阅Web服务器软件的比较，以发现其中哪些以内核模式或用户模式运行（也称为内核空间或用户空间）。

表演

为了改善用户体验（在客户端 /浏览器方面），Web服务器应尽快（尽快）回复客户请求；除非为某些类型的文件（例如大或巨大的文件）限制内容响应（通过配置），否则还应尽快发送返回的数据内容（高传输速度）。

换句话说，即使在高负载Web流量的情况下， Web服务器也应始终非常响应，以便保持总用户的等待（浏览器时间 +网络时间 + Web服务器响应时间），以便尽可能低。

性能指标

对于Web服务器软件，主要密钥性能指标（在不同的操作条件下测量）通常至少为以下（即）：

数量每秒请求（ RPS ，类似于QPS ，具体取决于HTTP版本和配置，HTTP请求类型和其他操作条件）；
每秒连接数（ CPS ）是Web服务器接受的每秒连接数（使用HTTP/1.0或HTTP/1.1时，每个连接的请求/响应极限，即1 .. 20）;
每个新客户端请求的网络延迟+响应时间；通常，基准工具显示在时间单板中满足了多少请求（例如1ms，3ms，5ms，10ms，20ms，20ms，30ms，40ms）和 /或最短，平均值和最长响应时间；
响应的吞吐量，以每秒字节为单位。

在操作条件中，测试期间使用的并发客户端连接的数字（1 .. n ）是一个重要参数，因为它允许将Web服务器支持的并发级别与测试性能指标的结果相关联。

软件效率

采用特定的Web服务器软件设计和模型（例如）：

单个过程或多过程；
每个过程的单线程（无线程）或多线程；
是否使用Coroutines ；

...以及其他编程技术，例如（例如）：

最小化可能的CPU缓存失误；
最小化可能的CPU分支错误预测在关键速度的速度中；
最小化用于执行特定功能 /任务的系统调用数量；
其他技巧；

...用于实现Web服务器程序，可能会偏向很多性能，尤其是在重载下或使用高端硬件（许多CPU，磁盘和大量RAM）时可以达到的可伸缩性级别。

实际上，某些Web服务器软件模型可能需要更多的操作系统资源（特别是更多的CPU和更多的RAM），而其他人则能够正常工作，从而实现目标性能。

运行条件

有许多操作条件会影响Web服务器的性能；性能值可能会因（IE）而异：

Web服务器的设置（包括日志文件是或未启用的事实等）；
客户端请求使用的HTTP版本；
平均HTTP请求类型（方法，HTTP标头的长度和可选主体）；
所请求的内容是静态的还是动态的；
是否已缓存内容（由服务器和/或客户端缓存）；
内容是否被即时压缩（转移时），请预压缩（即，当将文件资源存储在磁盘上已压缩时，以便Web服务器可以直接将该文件发送到网络，并以唯一的指示表明其内容已被压缩））或根本不压缩；
连接是否是加密的；
Web服务器与其客户端之间的平均网络速度；
活动性TCP连接的数量；
Web服务器管理的活动流程数量（包括外部CGI，SCGI，FCGI程序）；
Web服务器运行的计算机OS的硬件和软件限制或设置；
其他次要条件。

基准测试

通常，使用一种或多种可用的自动加载测试工具来对Web服务器的性能进行基准测试。

负载限制

Web服务器（程序安装）通常针对每种操作条件组合都具有预定义的负载限制，这也是因为它受OS资源的限制，并且因为它只能处理有限数量的并发客户连接（通常在2到几十次之间对于每个活动的Web服务器过程，数千个，另请参见C10K问题和C10M问题）。

当Web服务器靠近或超过其负载限制时，它会被超载，因此可能会变得无反应。

过载的原因

在任何时候，由于以下一个或多个原因（例如），Web服务器可以过载。

过多的合法网络流量。在短时间内连接到网站的数千甚至数百万个客户，例如， slashdot效果。
分布式拒绝服务攻击。拒绝服务攻击（DOS攻击）或分布式拒绝服务攻击（DDOS攻击）是试图使计算机或网络资源无法为其预期用户提供。
由于数百万受感染的计算机（其中未协调），有时会导致流量异常的计算机蠕虫。
由于数百万受感染的浏览器或Web服务器， XSS蠕虫可能会引起高流量。
Internet机器人流量未过滤/限制在很少的网络资源（例如带宽）和/或硬件资源（CPU，RAM，磁盘）上进行过滤/有限。
Internet （网络）放缓（例如，由于数据包丢失而引起的），以使客户请求更慢，并且连接数量增加了，以至于达到了服务器限制。
Web服务器，提供动态内容，等待来自后端计算机（例如数据库）的缓慢响应，也许是因为查询过多与太多插入或DB数据的更新混合在一起；在这些情况下，Web服务器必须等待后端数据响应，然后再回复HTTP客户端，但是在此期间等待太多新的客户端连接 /请求到达，因此它们变得过载。
Web服务器（计算机）部分不可用。这可能是由于所需或紧急维护或升级，硬件或软件故障（例如数据库）故障而发生的；在这些情况下，其余的Web服务器可能会获得过多的流量并过载。

超负荷的症状

超载Web服务器的症状通常是以下（例如）。

请求包括（可能很长的）延迟（从1秒到几百秒）。
Web服务器返回HTTP错误代码，例如500、502、503、504、408，甚至间歇性404 。
Web服务器在返回任何内容之前拒绝或重置（中断） TCP连接。
在极少数情况下，Web服务器仅返回所请求的内容的一部分。即使通常是作为超负荷的症状，这种行为也可以视为一个错误。

反载荷技术

要部分克服高于平均负载限制并防止超载，大多数流行的网站都使用以下技术（例如）（例如）。

调整硬件功能和用法的操作系统参数。
调整Web服务器参数以提高其安全性和性能。
部署Web缓存技术（不仅适用于静态内容，而且在可能的情况下也适用于动态内容）。
通过使用：管理网络流量：
防火墙可以阻止来自不良IP源或模式不良的不必要的流量；
http流量管理人员将删除，重定向或重写HTTP模式不良的请求；
带宽管理和交通构成，以平滑网络使用中的峰值。
使用不同的域名， IP地址和计算机来提供内容的不同种类（静态和动态）；目的是分开大或大文件（download.*（该域也可以用CDN替换）来自中小型文件（static.*）和从主要动态站点（也许将某些内容存储在后端数据库中）（www.*）；这个想法是能够有效地提供大型或巨大的（超过10 - 1000 MB）文件（也许是节流下载），并完全缓存中小型文件，而不会使用不同的设置在重载下不影响动态站点的性能对于Web服务器计算机的每个（组），例如：
https://download.example.com
https://static.example.com
https://www.example.com
使用许多Web服务器（计算机），这些服务器（计算机）在负载平衡器后面组合在一起，以使其作用或被视为一台大型Web服务器。
在每个计算机中添加更多硬件资源（即RAM ，快速磁盘）。
使用更有效的计算机程序用于Web服务器（另请参见：软件效率）。
使用最有效的Web服务器网关接口来处理动态请求（每次检索动态页面时都会产生一个或多个外部程序，杀死表演）。
使用其他编程技术和解决方法，尤其是在涉及动态内容的情况下，以加快HTTP响应（即避免动态调用以检索对象，例如样式表，图像和脚本），这些响应永远不会通过复制而稀少地变化或更改该内容一次用于静态文件，然后将其与动态内容同步）。
使用最新有效的HTTP版本（例如，除了使用常见的HTTP/1.1之外，还可以通过启用HTTP/2以及也许是HTTP/3 ，只要可用的Web Server软件对后两个协议有可靠的支持），以减少很多数量TCP/IP连接由每个客户端启动以及交换数据的大小（由于更紧凑的HTTP标头表示以及可能的数据压缩）。

有关使用HTTP/2和HTTP/3协议的警告

即使较新的HTTP（2和3）协议通常为每个请求 /响应数据生成更少的网络流量，它们可能需要Web服务器软件使用的更多OS资源（即RAM和CPU）（由于加密数据，大量流缓冲区和其他实施细节）；除此之外，http/2，也许还有http/3，也取决于Web服务器和客户端程序的设置，可能不是数据以非常高速的大型或巨大文件的最佳选择，因为它们的数据流已优化以供并发进行优化在许多情况下，使用HTTP/1.1 TCP/IP连接可能会导致更好的结果/更高的上传速度（您的里程可能会有所不同）。

市场占有率

以下是Netcraft在Internet上所有顶级网络服务器的所有站点市场份额的最新统计数据。

网络服务器：所有网站的市场份额
日期	nginx （Nginx，Inc。）	apache （ ASF ）	开放式（Openresty Software Foundation）	Cloudflare服务器（ Cloudflare，Inc 。）	IIS （ Microsoft ）	GWS （ Google ）	其他的
2021年10月	34.95%	24.63%	6.45%	4.87%	4.00% (*)	4.00% (*)	小于22％
2021年2月	34.54%	26.32%	6.36%	5.0%	6.5%	3.90%	小于18％
2020年2月	36.48%	24.5%	4.00%	3.0%	14.21%	3.18%	小于15％
2019年2月	25.34%	26.16%	N/A。	N/A。	28.42%	1.66%	小于19％
2018年2月	24.32%	27.45%	N/A。	N/A。	34.50%	1.20%	小于13％
2017年2月	19.42%	20.89%	N/A。	N/A。	43.16%	1.03%	小于15％
2016年2月	16.61%	32.80%	N/A。	N/A。	29.83%	2.21%	小于19％

注意：（*）舍入到整数数字的百分比，因为其小数值未通过源页面公开报告（仅在图中报告其圆形值）。

也可以看看

服务器（计算）
应用服务器
Web服务器软件的比较
HTTP服务器（服务HTTP请求的Web服务器程序的核心部分）
HTTP压缩
Web应用程序
开源Web应用程序
放大器套件列表
变体对象
虚拟托管
网络托管服务
Web容器
Web代理
网络服务

用于动态内容的标准Web服务器网关接口：

CGI公共网关接口
SCGI简单的公共网关接口
FastCGI快速公共网关界面

用于动态内容的其他一些Web服务器接口（服务器或编程语言特定）：

SSI服务器端包括，很少使用的，静态的HTML文档包含SSI指令的静态HTML文档由服务器软件解释，以在提供页面时即时包含小型动态数据，例如日期和时间，其他静态文件内容等。
SAPI服务器应用程序编程接口：
ISAPI Internet服务器应用程序编程接口
NSAPI NETSCAPE服务器应用程序编程接口
PSGI PERL WEB服务器网关接口
WSGI Python Web服务器网关接口
机架机架网络服务器网关接口
JSGI JavaScript Web服务器网关接口
Java Servlet ， Javaserver页面
活动服务器页面 ASP.NET