Servidor web

Este artículo necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Servidor web» – noticias  · periódicos  · libros  · académico  · JSTOR ( marzo de 2009 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Un servidor web es un software informático y hardware subyacente que acepta solicitudes a través de HTTP (el protocolo de red creado para distribuir contenido web ) o su variante segura HTTPS . Un agente de usuario, comúnmente un navegador web o un rastreador web , inicia la comunicación al realizar una solicitud de una página web u otro recurso mediante HTTP, y el servidor responde con el contenido de ese recurso o un mensaje de error . Un servidor web también puede aceptar y almacenar recursos enviados desde el agente de usuario si está configurado para hacerlo. ^{[1] [2]}

El hardware utilizado para ejecutar un servidor web puede variar según el volumen de solicitudes que necesita manejar. En el extremo inferior de la gama se encuentran los sistemas integrados , como un enrutador que ejecuta un pequeño servidor web como su interfaz de configuración. Un sitio web de Internet con mucho tráfico puede manejar solicitudes con cientos de servidores que se ejecutan en bastidores de computadoras de alta velocidad.

Un recurso enviado desde un servidor web puede ser un archivo preexistente ( contenido estático ) disponible para el servidor web, o puede ser generado en el momento de la solicitud ( contenido dinámico ) por otro programa que se comunica con el software del servidor. El primero suele poder servirse más rápido y puede almacenarse en caché más fácilmente para solicitudes repetidas, mientras que el segundo admite una gama más amplia de aplicaciones.

Tecnologías como REST y SOAP , que utilizan HTTP como base para la comunicación general de computadora a computadora, así como el soporte para extensiones WebDAV , han extendido la aplicación de los servidores web mucho más allá de su propósito original de servir páginas legibles para humanos.

Esta es una historia muy breve de los programas de servidores web , por lo que cierta información necesariamente se superpone con las historias de los navegadores web , la World Wide Web e Internet ; por lo tanto, en aras de la claridad y la comprensión, alguna información histórica clave que se informa a continuación puede ser similar a la que se encuentra también en uno o más de los artículos históricos mencionados anteriormente. ^{[ cita requerida ]}

En marzo de 1989, Sir Tim Berners-Lee propuso un nuevo proyecto a su empleador , el CERN , con el objetivo de facilitar el intercambio de información entre científicos mediante un sistema de hipertexto . La propuesta, titulada "Hipertexto y CERN" , pidió comentarios y fue leída por varias personas. En octubre de 1990 la propuesta fue reformulada y enriquecida (teniendo como coautor a Robert Cailliau ), y finalmente, fue aprobada. ^{[3] [4] [5]}

Entre finales de 1990 y principios de 1991, el proyecto dio como resultado que Berners-Lee y sus desarrolladores escribieran y probaran varias bibliotecas de software junto con tres programas, que inicialmente se ejecutaban en el sistema operativo NeXTSTEP instalado en estaciones de trabajo NeXT : ^{[6] [7] [5]}

• un navegador web gráfico , llamado WorldWideWeb ;
• un navegador web de modo de línea portátil ;
• un servidor web, más tarde conocido como CERN httpd .

Los primeros navegadores recuperaban páginas web escritas en una forma temprana y simple de HTML , desde servidores web utilizando un nuevo protocolo de comunicación básico que se denominó HTTP 0.9 .

En agosto de 1991, Tim Berners-Lee anunció el nacimiento de la tecnología WWW y animó a los científicos a adoptarla y desarrollarla. ^[8] Poco después, esos programas, junto con su código fuente , se pusieron a disposición de las personas interesadas en su uso. ^[6] Aunque el código fuente no estaba formalmente autorizado ni se puso en el dominio público, el CERN permitió informalmente a los usuarios y desarrolladores experimentar y seguir desarrollando a partir de ellos. Berners-Lee comenzó a promover la adopción y el uso de esos programas junto con su adaptación a otros sistemas operativos . ^[5]

Los gráficos no están disponibles debido a problemas técnicos. Hay más información en Phabricator y en MediaWiki.org.

Número de sitios web activos (1991–1996) ^{[9] [10]}

En diciembre de 1991 se instaló en SLAC (EE.UU.) el primer servidor web fuera de Europa . ^[7] Este fue un acontecimiento muy importante porque dio inicio a las comunicaciones web transcontinentales entre navegadores y servidores web.

Entre 1991 y 1993, el programa de servidor web del CERN siguió siendo desarrollado activamente por el grupo www, mientras tanto, gracias a la disponibilidad de su código fuente y a las especificaciones públicas del protocolo HTTP, se empezaron a desarrollar muchas otras implementaciones de servidores web.

En abril de 1993, el CERN emitió una declaración oficial pública indicando que los tres componentes del software web (el cliente básico en modo de línea, el servidor web y la biblioteca de código común), junto con su código fuente , se ponían en el dominio público . ^[11] Esta declaración liberaba a los desarrolladores de servidores web de cualquier posible problema legal sobre el desarrollo de trabajos derivados basados ​​en ese código fuente (una amenaza que en la práctica nunca existió).

A principios de 1994, el más destacado entre los nuevos servidores web era NCSA httpd , que funcionaba en una variedad de sistemas operativos basados ​​en Unix y podía ofrecer contenido generado dinámicamente implementando el POSTmétodo HTTP y CGI para comunicarse con programas externos. Estas capacidades, junto con las características multimedia del navegador Mosaic de NCSA (que también podía gestionar formularios HTML para enviar datos a un servidor web), pusieron de relieve el potencial de la tecnología web para la publicación y las aplicaciones informáticas distribuidas .

En la segunda mitad de 1994, el desarrollo de NCSA httpd se estancó hasta el punto de que un grupo de desarrolladores de software externos, webmasters y otras figuras profesionales interesadas en ese servidor, comenzaron a escribir y recopilar parches gracias a que el código fuente de NCSA httpd estaba disponible para el dominio público. A principios de 1995, todos esos parches se aplicaron a la última versión del código fuente de NCSA y, después de varias pruebas, se inició el proyecto del servidor HTTP Apache . ^{[12] [13]}

A finales de 1994 se lanzó al mercado un nuevo servidor web comercial, llamado Netsite , con características específicas. Fue el primero de muchos otros productos similares que fueron desarrollados primero por Netscape , luego también por Sun Microsystems y finalmente por Oracle Corporation .

A mediados de 1995, Microsoft lanzó la primera versión de IIS para el sistema operativo Windows NT . Esto marcó la entrada en el campo de las tecnologías de la World Wide Web de un desarrollador y proveedor comercial muy importante que ha desempeñado y sigue desempeñando un papel clave en ambos lados (cliente y servidor) de la web.

En la segunda mitad de 1995, los servidores web del CERN y del NCSA empezaron a declinar (en porcentaje de uso global) debido a la adopción generalizada de nuevos servidores web que tenían un ciclo de desarrollo mucho más rápido junto con más funciones, más correcciones aplicadas y más rendimiento que los anteriores.

Los gráficos no están disponibles debido a problemas técnicos. Hay más información en Phabricator y en MediaWiki.org.

Número de sitios web activos (1996-2002) ^{[10] [14]}

A finales de 1996 ya existían más de cincuenta programas de software de servidores web conocidos (diferentes), que estaban disponibles para todo aquel que quisiera poseer un nombre de dominio en Internet y/o alojar sitios web. ^[15] Muchos de ellos duraron poco tiempo y fueron reemplazados por otros servidores web.

La publicación de RFCs sobre las versiones de protocolo HTTP/1.0 (1996) y HTTP/1.1 (1997, 1999) obligó a la mayoría de los servidores web a cumplir (no siempre de forma completa) con dichos estándares. El uso de conexiones persistentes TCP/IP (HTTP/1.1) obligó a los servidores web a aumentar el número máximo de conexiones simultáneas permitidas y a mejorar su nivel de escalabilidad.

Entre 1996 y 1999, Netscape Enterprise Server y el IIS de Microsoft surgieron entre las principales opciones comerciales, mientras que entre los programas de código abierto y de libre acceso , Apache HTTP Server ocupó el primer lugar como servidor preferido (debido a su fiabilidad y sus numerosas características).

En aquellos años también había otro servidor web comercial, muy innovador y por ello notable, llamado Zeus ( ahora descontinuado ), que era conocido como uno de los servidores web más rápidos y escalables disponibles en el mercado, al menos hasta la primera década de los 2000, a pesar de su bajo porcentaje de uso.

Apache resultó ser el servidor web más utilizado desde mediados de 1996 hasta finales de 2015, cuando, tras unos años de declive, fue superado inicialmente por IIS y luego por Nginx. Posteriormente, IIS cayó a porcentajes de uso mucho más bajos que Apache (véase también cuota de mercado).

A partir de 2005-2006, Apache comenzó a mejorar su velocidad y su nivel de escalabilidad mediante la introducción de nuevas características de rendimiento (por ejemplo, MPM de eventos y nuevo caché de contenido). ^{[16] [17]} Como esas nuevas mejoras de rendimiento inicialmente fueron marcadas como experimentales, sus usuarios no las habilitaron durante mucho tiempo y, por lo tanto, Apache sufrió, aún más, la competencia de servidores comerciales y, sobre todo, de otros servidores de código abierto que, mientras tanto, ya habían logrado rendimientos muy superiores (principalmente al servir contenido estático) desde el comienzo de su desarrollo y en el momento del declive de Apache podían ofrecer también una lista suficientemente larga de características avanzadas bien probadas.

De hecho, pocos años después de iniciado el 2000, surgieron no sólo otros servidores web comerciales y altamente competitivos, como por ejemplo LiteSpeed , sino también muchos otros programas de código abierto, a menudo de excelente calidad y altísimas prestaciones, entre los que cabe destacar Hiawatha , Cherokee HTTP server , Lighttpd , Nginx y otros productos derivados/relacionados también disponibles con soporte comercial.

Entre 2007 y 2008, los navegadores web más populares aumentaron su límite predeterminado anterior de 2 conexiones persistentes por host-dominio (un límite recomendado por RFC-2616) ^[18] a 4, 6 u 8 conexiones persistentes por host-dominio, con el fin de acelerar la recuperación de páginas web pesadas con muchas imágenes y mitigar el problema de la escasez de conexiones persistentes dedicadas a objetos dinámicos utilizados para notificaciones bidireccionales de eventos en páginas web. ^[19] En un año, estos cambios, en promedio, casi triplicaron el número máximo de conexiones persistentes que los servidores web tenían que gestionar. Esta tendencia (de aumentar el número de conexiones persistentes) definitivamente dio un fuerte impulso a la adopción de proxies inversos frente a servidores web más lentos y también dio una oportunidad más a los nuevos servidores web emergentes que podían mostrar toda su velocidad y su capacidad para manejar cantidades muy altas de conexiones concurrentes sin requerir demasiados recursos de hardware (computadoras costosas con muchas CPU, RAM y discos rápidos). ^[20]

En 2015, los RFC publicaron una nueva versión del protocolo [HTTP/2], y como la implementación de nuevas especificaciones no era nada trivial, surgió un dilema entre los desarrolladores de servidores web menos populares (por ejemplo, con un porcentaje de uso inferior al 1%... 2%), sobre agregar o no soporte para esa nueva versión del protocolo. ^{[21] [22]}

De hecho, soportar HTTP/2 a menudo requería cambios radicales en su implementación interna debido a muchos factores (prácticamente siempre se requerían conexiones cifradas, capacidad de distinguir entre conexiones HTTP/1.x y HTTP/2 en el mismo puerto TCP, representación binaria de mensajes HTTP, prioridad de mensajes, compresión de encabezados HTTP, uso de flujos también conocidos como subconexiones TCP/IP y control de flujo relacionado, etc.) y por eso algunos desarrolladores de esos servidores web optaron por no soportar la nueva versión de HTTP/2 (al menos en el futuro cercano) también por estas razones principales: ^{[21] [22]}

• Los protocolos HTTP/1.x habrían sido soportados de todas formas por los navegadores durante mucho tiempo (quizás para siempre) de modo que no habría incompatibilidad entre clientes y servidores en el futuro próximo;
• Implementar HTTP/2 se consideraba una tarea de enorme complejidad que podría abrir la puerta a toda una nueva clase de errores que hasta 2015 no existían y por lo tanto habría requerido inversiones notables en el desarrollo y prueba de la implementación del nuevo protocolo;
• Agregar soporte para HTTP/2 siempre podría hacerse en el futuro en caso de que los esfuerzos estuvieran justificados.

En cambio, los desarrolladores de los servidores web más populares se apresuraron a ofrecer la disponibilidad del nuevo protocolo , no sólo porque tenían la fuerza de trabajo y el tiempo para hacerlo, sino también porque normalmente su implementación anterior del protocolo SPDY podía reutilizarse como punto de partida y porque la mayoría de los navegadores web más utilizados lo implementaron muy rápidamente por la misma razón. Otra razón que impulsó a esos desarrolladores a actuar rápidamente fue que los webmasters sintieron la presión del tráfico web cada vez mayor y realmente querían instalar y probar, lo antes posible, algo que pudiera reducir drásticamente el número de conexiones TCP/IP y acelerar los accesos a los sitios web alojados. ^[23]

En 2020-2021, la dinámica de HTTP/2 sobre su implementación (por parte de los principales servidores web y navegadores web populares) se replicó parcialmente después de la publicación de borradores avanzados del futuro RFC sobre el protocolo HTTP/3 .

La siguiente descripción técnica debe considerarse solo como un intento de dar algunos ejemplos muy limitados sobre algunas características que se pueden implementar en un servidor web y algunas de las tareas que puede realizar para tener un escenario suficientemente amplio sobre el tema.

Un programa de servidor web desempeña el papel de un servidor en un modelo cliente-servidor al implementar una o más versiones del protocolo HTTP, que a menudo incluye la variante segura HTTPS y otras características y extensiones que se consideran útiles para su uso planificado.

La complejidad y la eficiencia de un programa de servidor web pueden variar mucho dependiendo de (por ejemplo): ^[1]

• características comunes implementadas;
• Tareas comunes realizadas;
• rendimiento y nivel de escalabilidad como objetivo;
• modelo de software y técnicas adoptadas para lograr el nivel de rendimiento y escalabilidad deseados;
• hardware de destino y categoría de uso, por ejemplo, sistema integrado, servidor web de tráfico bajo a medio, servidor web de Internet de tráfico alto .

Aunque los programas de servidor web difieren en cómo se implementan, la mayoría de ellos ofrecen las siguientes características comunes.

Estas son características básicas que suelen tener la mayoría de servidores web.

• Servicio de contenido estático : poder servir contenido estático (archivos web) a los clientes a través del protocolo HTTP.
• HTTP : soporte para una o más versiones del protocolo HTTP para enviar versiones de respuestas HTTP compatibles con versiones de solicitudes HTTP de cliente, por ejemplo, HTTP/1.0, HTTP/1.1 (eventualmente también con conexiones cifradas HTTPS ), además, si está disponible, HTTP/2 , HTTP/3 .
• Registro : normalmente los servidores web también tienen la capacidad de registrar cierta información, sobre las solicitudes de los clientes y las respuestas del servidor, en archivos de registro con fines de seguridad y estadísticos.

Algunas otras características más avanzadas y populares ( sólo una selección muy corta ) son las siguientes.

• Entrega de contenido dinámico : poder entregar contenido dinámico (generado sobre la marcha) a los clientes a través del protocolo HTTP.
• Hospedaje virtual : poder servir muchos sitios web ( nombres de dominio ) utilizando una sola dirección IP .
• Autorización: poder permitir, prohibir o autorizar el acceso a porciones de rutas de sitios web (recursos web).
• Caché de contenido: poder almacenar en caché contenido estático y/o dinámico para acelerar las respuestas del servidor;
• Compatibilidad con archivos grandes : para poder servir archivos cuyo tamaño sea mayor a 2 GB en sistemas operativos de 32 bits .
• Limitación de ancho de banda : para limitar la velocidad de respuesta de los contenidos para no saturar la red y poder atender a más clientes;
• Motor de reescritura : para asignar partes de URL limpias (que se encuentran en las solicitudes del cliente) a sus nombres reales.
• Páginas de error personalizadas : compatibilidad con mensajes de error HTTP personalizados.

Un programa de servidor web, cuando se está ejecutando, generalmente realiza varias tareas generales , (por ejemplo): ^[1]

• inicia, opcionalmente lee y aplica las configuraciones que se encuentran en sus archivos de configuración o en otro lugar, opcionalmente abre el archivo de registro, comienza a escuchar las conexiones/solicitudes del cliente;
• intenta opcionalmente adaptar su comportamiento general de acuerdo a su configuración y sus condiciones de funcionamiento actuales;
• administra las conexiones del cliente (aceptando las nuevas o cerrando las existentes según sea necesario);
• recibe solicitudes de clientes (leyendo mensajes HTTP):
  • lee y verifica cada mensaje de solicitud HTTP;
  • Generalmente realiza la normalización de URL;
  • Generalmente realiza el mapeo de URL (que puede tener como valor predeterminado la traducción de la ruta URL);
  • Generalmente realiza la traducción de la ruta URL junto con varias comprobaciones de seguridad;
• ejecuta o rechaza el método HTTP solicitado:
  • gestiona opcionalmente las autorizaciones de URL;
  • gestiona opcionalmente las redirecciones de URL;
  • Gestiona opcionalmente solicitudes de recursos estáticos (contenido de archivos):
    • administra opcionalmente archivos de índice de directorio;
    • administra opcionalmente archivos regulares;
  • Gestiona opcionalmente solicitudes de recursos dinámicos :
    • administra opcionalmente listados de directorios;
    • gestiona opcionalmente el procesamiento de programas o módulos, comprobando la disponibilidad, el inicio y eventualmente la detención de la ejecución de programas externos utilizados para generar contenidos dinámicos;
    • gestiona opcionalmente las comunicaciones con programas externos / módulos internos utilizados para generar contenido dinámico;
• responde a las solicitudes del cliente enviando respuestas HTTP adecuadas (por ejemplo, recursos solicitados o mensajes de error) y eventualmente verificando o agregando encabezados HTTP a los enviados por programas/módulos dinámicos;
• registra opcionalmente (parcial o totalmente) las solicitudes del cliente y/o sus respuestas en un archivo de registro de usuario externo o en un archivo de registro del sistema mediante syslog , generalmente utilizando un formato de registro común ;
• opcionalmente registra mensajes de proceso sobre anomalías detectadas u otros eventos notables (por ejemplo, en solicitudes de clientes o en su funcionamiento interno) utilizando syslog o algunas otras funciones del sistema; estos mensajes de registro generalmente tienen un nivel de depuración, advertencia, error y alerta que se puede filtrar (no registrar) dependiendo de algunas configuraciones, consulte también el nivel de gravedad ;
• genera opcionalmente estadísticas sobre el tráfico web gestionado y/o su rendimiento;
• Otras tareas personalizadas.

Los programas de servidor web pueden: ^{[24] [25] [26]}

• para leer un mensaje de solicitud HTTP;
• para interpretarlo;
• para verificar su sintaxis;
• para identificar encabezados HTTP conocidos y extraer sus valores de ellos.

Una vez que se ha decodificado y verificado un mensaje de solicitud HTTP, sus valores se pueden utilizar para determinar si se puede satisfacer esa solicitud o no. Esto requiere muchos otros pasos, incluidas las comprobaciones de seguridad .

Los programas de servidor web generalmente realizan algún tipo de normalización de URL ( URL que se encuentra en la mayoría de los mensajes de solicitud HTTP) para:

• hacer que la ruta de recursos sea siempre una ruta limpia y uniforme desde el directorio raíz del sitio web;
• menores riesgos de seguridad (por ejemplo, interceptando más fácilmente los intentos de acceder a recursos estáticos fuera del directorio raíz del sitio web o de acceder a partes de la ruta por debajo del directorio raíz del sitio web que están prohibidas o que requieren autorización);
• hacer que la ruta de los recursos web sea más reconocible para los seres humanos y los programas de análisis de registros web (también conocidos como analizadores de registros/aplicaciones estadísticas).

El término normalización de URL se refiere al proceso de modificar y estandarizar una URL de manera consistente. Existen varios tipos de normalización que se pueden realizar, incluida la conversión del esquema y el host a minúsculas. Entre las normalizaciones más importantes se encuentran la eliminación de los segmentos de ruta "." y ".." y la adición de barras diagonales finales a un componente de ruta que no esté vacío.

Esta sección necesita ser actualizada . Por favor, ayude a actualizar este artículo para reflejar eventos recientes o nueva información disponible. ( Junio ​​de 2023 )

"El mapeo de URL es el proceso por el cual se analiza una URL para determinar a qué recurso se refiere, de modo que se pueda devolver ese recurso al cliente solicitante. Este proceso se realiza con cada solicitud que se realiza a un servidor web; algunas de las solicitudes se atienden con un archivo, como un documento HTML o una imagen gif, otras con los resultados de la ejecución de un programa CGI y otras mediante algún otro proceso, como un controlador de módulo integrado, un documento PHP o un servlet Java". ^{[27] [ necesita actualización ]}

En la práctica, los programas de servidor web que implementan funciones avanzadas, más allá del simple servicio de contenido estático (por ejemplo, motor de reescritura de URL, servicio de contenido dinámico), generalmente tienen que descubrir cómo se debe manejar esa URL, por ejemplo, como:

• Redirección de URL, una redirección a otra URL;
• solicitud estática del contenido del archivo ;
• Solicitud dinámica de:
  • listado de directorios de archivos u otros subdirectorios contenidos en ese directorio;
  • otros tipos de solicitud dinámica para identificar el procesador del programa/módulo capaz de manejar ese tipo de ruta URL y pasarle otras partes de URL , es decir, generalmente variables de información de ruta y de cadena de consulta .

Uno o más archivos de configuración del servidor web pueden especificar la asignación de partes de la ruta URL (por ejemplo, partes iniciales de la ruta del archivo , extensión del nombre del archivo y otros componentes de la ruta) a un controlador de URL específico (archivo, directorio, programa externo o módulo interno). ^[28]

Cuando un servidor web implementa una o más de las características avanzadas mencionadas anteriormente, la parte de ruta de una URL válida puede no siempre coincidir con una ruta del sistema de archivos existente en el árbol de directorios del sitio web (un archivo o un directorio en el sistema de archivos ) porque puede hacer referencia a un nombre virtual de un procesador de módulo interno o externo para solicitudes dinámicas.

Los programas de servidor web pueden traducir una ruta URL (total o parcialmente), que hace referencia a una ruta del sistema de archivos físico, a una ruta absoluta bajo el directorio raíz del sitio web de destino. ^[28]

El directorio raíz del sitio web puede especificarse mediante un archivo de configuración o mediante alguna regla interna del servidor web utilizando el nombre del sitio web, que es la parte del host de la URL que se encuentra en la solicitud del cliente HTTP. ^[28]

La traducción de ruta al sistema de archivos se realiza para los siguientes tipos de recursos web:

• un archivo local, normalmente no ejecutable (solicitud estática de contenido de archivo);
• un directorio local (solicitud dinámica: listado de directorios generado sobre la marcha);
• un nombre de programa (solicitudes dinámicas que se ejecutan utilizando la interfaz CGI o SCGI y cuya salida es leída por el servidor web y reenviada al cliente que realizó la solicitud HTTP).

El servidor web agrega la ruta encontrada en la URL solicitada (mensaje de solicitud HTTP) y la agrega a la ruta del directorio raíz del sitio web (Host). En un servidor Apache , esto es común /home/www/website(en máquinas Unix , generalmente es: /var/www/website). Vea los siguientes ejemplos de cómo puede resultar.

Traducción de la ruta URL para una solicitud de archivo estático

Ejemplo de una solicitud estática de un archivo existente especificado por la siguiente URL:

http://www.ejemplo.com/ruta/archivo.html

El agente de usuario del cliente se conecta www.example.comy luego envía la siguiente solicitud HTTP /1.1:

GET /ruta/archivo.html HTTP/1.1Anfitrión: www.example.comConexión: mantener viva

El resultado es el recurso del sistema de archivos local:

/home/www/www.example.com/ruta/archivo.html

A continuación, el servidor web lee el archivo , si existe, y envía una respuesta al navegador web del cliente. La respuesta describirá el contenido del archivo y contendrá el archivo en sí o devolverá un mensaje de error que indicará que el archivo no existe o que su acceso está prohibido.

Traducción de la ruta URL para una solicitud de directorio (sin un archivo de índice estático)

Ejemplo de una solicitud dinámica implícita de un directorio existente especificado por la siguiente URL:

http://www.ejemplo.com/directorio1/directorio2/

El agente de usuario del cliente se conecta www.example.comy luego envía la siguiente solicitud HTTP /1.1:

GET /directorio1/directorio2 HTTP/1.1Anfitrión: www.example.comConexión: mantener viva

El resultado es la ruta del directorio local:

/home/www/www.example.com/directorio1/directorio2/

El servidor web verifica entonces la existencia del directorio y si existe y se puede acceder a él intenta encontrar un archivo de índice (que en este caso no existe) y pasa la petición a un módulo interno o a un programa dedicado a listados de directorios y finalmente lee los datos de salida y envía una respuesta al navegador web del cliente. La respuesta describirá el contenido del directorio (lista de subdirectorios y archivos contenidos) o devolverá un mensaje de error diciendo que el directorio no existe o que su acceso está prohibido.

Traducción de la ruta URL para una solicitud de programa dinámico

Para una solicitud dinámica, la ruta URL especificada por el cliente debe hacer referencia a un programa externo existente (normalmente un archivo ejecutable con un CGI) utilizado por el servidor web para generar contenido dinámico. ^[29]

Ejemplo de una solicitud dinámica que utiliza un archivo de programa para generar salida:

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

El agente de usuario del cliente se conecta www.example.comy luego envía la siguiente solicitud HTTP /1.1:

OBTENER /cgi-bin/forum.php?action=view&ordeby=thread&date=2021-10-15 HTTP/1.1Anfitrión: www.example.comConexión: mantener viva

El resultado es la ruta del archivo local del programa (en este ejemplo, un programa PHP ):

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

El servidor web ejecuta ese programa, pasando la información de la ruta y la cadena de consulta action=view&orderby=thread&date=2021-10-15 para que el programa tenga la información que necesita para ejecutarse. (En este caso, devolverá un documento HTML que contiene una vista de las entradas del foro ordenadas por hilo a partir del 15 de octubre de 2021). Además de esto, el servidor web lee los datos enviados desde el programa externo y reenvía esos datos al cliente que realizó la solicitud.

Una vez leída, interpretada y verificada una solicitud, debe gestionarse en función de su método, su URL y sus parámetros, que pueden incluir valores de encabezados HTTP.

En la práctica, el servidor web tiene que gestionar la solicitud utilizando una de estas rutas de respuesta: ^[28]

• Si algo en la solicitud no era aceptable (en la línea de estado o en los encabezados de los mensajes), el servidor web ya envió una respuesta de error;
• Si la solicitud tiene un método (por ejemplo OPTIONS) que puede satisfacerse mediante el código general del servidor web, se envía una respuesta exitosa;
• Si la URL requiere autorización, se envía un mensaje de error de autorización;
• Si la URL corresponde a una redirección, se envía un mensaje de redirección;
• si la URL se asigna a un recurso dinámico (una ruta virtual o un listado de directorios), entonces se llama a su controlador (un módulo interno o un programa externo) y se le pasan parámetros de solicitud (cadena de consulta e información de ruta) para permitirle responder a esa solicitud;
• Si la URL se asigna a un recurso estático (normalmente un archivo en el sistema de archivos), se llama al controlador estático interno para enviar ese archivo;
• Si no se conoce el método de solicitud o si hay alguna otra condición inaceptable (por ejemplo, recurso no encontrado, error interno del servidor, etc.), se envía una respuesta de error.

Si un programa de servidor web es capaz de servir contenido estático y ha sido configurado para hacerlo, entonces puede enviar contenido de archivo siempre que un mensaje de solicitud tenga una ruta URL válida que coincida (después del mapeo de URL, la traducción de URL y la redirección de URL) con la de un archivo existente bajo el directorio raíz de un sitio web y el archivo tenga atributos que coincidan con los requeridos por las reglas internas del programa de servidor web. ^[28]

Ese tipo de contenido se llama estático porque normalmente no lo modifica el servidor web cuando lo envía a los clientes y porque permanece igual hasta que lo modifica (modificación del archivo) algún programa.

NOTA: cuando se sirve únicamente contenido estático , un programa de servidor web generalmente no modifica el contenido de los archivos de los sitios web servidos (ya que solo se leen y nunca se escriben) y, por lo tanto, es suficiente admitir solo estos métodos HTTP :

• OPTIONS
• HEAD
• GET

La respuesta del contenido de un archivo estático se puede acelerar mediante un caché de archivos .

Si un programa de servidor web recibe un mensaje de solicitud de cliente con una URL cuya ruta coincide con la de un directorio existente y ese directorio es accesible y la función de servir archivos de índice de directorio está habilitada, entonces un programa de servidor web puede intentar servir el primero de los nombres de archivo de índice estático conocidos (o configurados) (un archivo normal) que se encuentre en ese directorio; si no se encuentra ningún archivo de índice o no se cumplen otras condiciones, se devuelve un mensaje de error.

Los nombres más utilizados para archivos de índice estático son: index.html, index.htmy Default.htm.

Si un programa de servidor web recibe un mensaje de solicitud de cliente con una URL cuya ruta coincide con el nombre de archivo de un archivo existente y ese archivo es accesible por el programa de servidor web y sus atributos coinciden con las reglas internas del programa de servidor web, entonces el programa de servidor web puede enviar ese archivo al cliente.

Por lo general, por razones de seguridad, la mayoría de los programas de servidores web están preconfigurados para servir solo archivos normales o para evitar el uso de tipos de archivos especiales como archivos de dispositivo , junto con enlaces simbólicos o enlaces duros a ellos. El objetivo es evitar efectos secundarios indeseables al servir recursos web estáticos. ^[30]

Si un programa de servidor web es capaz de servir contenido dinámico y ha sido configurado para ello, entonces es capaz de comunicarse con el módulo interno o programa externo adecuado (asociado con la ruta URL solicitada) para pasarle los parámetros de la solicitud del cliente. Después de eso, el programa de servidor web lee de él su respuesta de datos (que ha generado, a menudo sobre la marcha) y luego la reenvía al programa cliente que realizó la solicitud. ^{[ cita requerida ]}

NOTA: al servir contenido estático y dinámico , un programa de servidor web generalmente también debe soportar el siguiente método HTTP para poder recibir datos de forma segura de los clientes y así poder alojar también sitios web con formularios interactivos que puedan enviar grandes conjuntos de datos (por ejemplo, muchas entradas de datos o cargas de archivos ) al servidor web/programas externos/módulos:

• POST

Para poder comunicarse con sus módulos internos y/o programas externos, un programa de servidor web debe tener implementada una o más de las muchas interfaces de puerta de enlace disponibles (consulte también Interfaces de puerta de enlace de servidor web utilizadas para contenido dinámico).

Las tres interfaces de puerta de enlace estándar e históricas son las siguientes.

CGI

El programa del servidor web ejecuta un programa CGI externo para cada solicitud dinámica; luego, el programa del servidor web lee la respuesta de datos generada y la reenvía al cliente.

sggi

Un programa SCGI externo (generalmente es un proceso) es iniciado una vez por un programa de servidor web o por algún otro programa/proceso y luego espera conexiones de red; cada vez que hay una nueva solicitud, el programa de servidor web realiza una nueva conexión de red para enviar parámetros de solicitud y leer su respuesta de datos, luego se cierra la conexión de red.

CGI rápido

Un programa FastCGI externo (normalmente es un proceso) es iniciado una vez por un programa de servidor web o por algún otro programa/proceso y luego espera una conexión de red que es establecida permanentemente por el servidor web; a través de esa conexión se envían los parámetros de solicitud y se leen las respuestas de datos.

Un programa de servidor web puede ser capaz de gestionar la generación dinámica (sobre la marcha) de una lista de índice de directorio de archivos y subdirectorios. ^[31]

Si un programa de servidor web está configurado para hacerlo y la ruta URL solicitada coincide con un directorio existente y se permite el acceso, pero no se encuentra ningún archivo de índice estático en ese directorio, se genera dinámicamente (sobre la marcha) una página web (normalmente en formato HTML) que contiene la lista de archivos y/o subdirectorios del directorio mencionado anteriormente. Si no se puede generar, se devuelve un error.

Algunos programas de servidor web permiten la personalización de listados de directorios al permitir el uso de una plantilla de página web (un documento HTML que contiene marcadores de posición, por ejemplo $(FILE_NAME), $(FILE_SIZE), , etc., que se reemplazan con los valores de campo de cada entrada de archivo que el servidor web encuentra en el directorio), por ejemplo, index.tplo el uso de HTML y código fuente integrado que se interpreta y ejecuta sobre la marcha, por ejemplo index.asp, y/o al admitir el uso de programas de índice dinámico como CGI, SCGI, FCGI, por ejemplo index.cgi, index.php, index.fcgi.

El uso de listados de directorios generados dinámicamente generalmente se evita o se limita a unos pocos directorios seleccionados de un sitio web porque dicha generación requiere muchos más recursos del sistema operativo que el envío de una página de índice estática.

El uso principal de los listados de directorios es permitir la descarga de archivos (generalmente cuando sus nombres, tamaños, fechas y horas de modificación o atributos de archivo pueden cambiar aleatoriamente/con frecuencia) tal como están, sin necesidad de proporcionar información adicional al usuario solicitante . ^[32]

Un programa externo o un módulo interno ( unidad de procesamiento ) puede ejecutar algún tipo de función de aplicación que puede usarse para obtener datos de uno o más repositorios de datos o para almacenar datos en uno o más repositorios de datos , por ejemplo: ^{[ cita requerida ]}

• archivos (sistema de archivos);
• bases de datos (BD);
• otras fuentes ubicadas en la computadora local o en otras computadoras.

Una unidad de procesamiento puede devolver cualquier tipo de contenido web, también utilizando datos recuperados de un repositorio de datos, por ejemplo: ^{[ cita requerida ]}

• un documento (por ejemplo, HTML , XML , etc.);
• una imagen;
• un video;
• datos estructurados, por ejemplo, que pueden usarse para actualizar uno o más valores mostrados por una página dinámica ( DHTML ) de una interfaz web y que pueden haber sido solicitados por una API XMLHttpRequest (véase también: página dinámica ).

En la práctica, siempre que hay contenido que puede variar dependiendo de uno o más parámetros contenidos en la solicitud del cliente o en la configuración, generalmente se genera de forma dinámica.

Los programas de servidor web pueden enviar mensajes de respuesta como respuestas a los mensajes de solicitud del cliente. ^[24]

Se puede enviar un mensaje de respuesta de error porque no se pudo leer, decodificar, analizar o ejecutar correctamente un mensaje de solicitud. ^[25]

NOTA: las siguientes secciones se presentan sólo como ejemplos para ayudar a comprender lo que hace, más o menos, un servidor web; estas secciones no son de ninguna manera exhaustivas ni completas.

Un programa de servidor web puede responder a un mensaje de solicitud de cliente con muchos tipos de mensajes de error, de todos modos estos errores se dividen principalmente en dos categorías:

• Errores del cliente HTTP , debido al tipo de mensaje de solicitud o a la disponibilidad del recurso web solicitado; ^[33]
• Errores del servidor HTTP , debido a errores internos del servidor. ^[34]

Cuando un navegador de un cliente recibe una respuesta/mensaje de error, si está relacionado con la solicitud principal del usuario (por ejemplo, una URL de un recurso web como una página web), generalmente ese mensaje de error se muestra en alguna ventana/mensaje del navegador.

Un programa de servidor web puede verificar si la ruta URL solicitada: ^[35]

• puede ser accedido libremente por todos;
• requiere una autenticación de usuario (solicitud de credenciales de usuario, por ejemplo, nombre de usuario y contraseña );
• El acceso está prohibido a algunos o todo tipo de usuarios.

Si se ha implementado y habilitado la función de autorización/derechos de acceso y no se concede acceso al recurso web, entonces, dependiendo de los derechos de acceso requeridos, un programa de servidor web:

• puede denegar el acceso enviando un mensaje de error específico (por ejemplo, acceso prohibido );
• puede denegar el acceso enviando un mensaje de error específico (por ejemplo, acceso no autorizado ) que generalmente obliga al navegador del cliente a solicitar al usuario humano que proporcione las credenciales de usuario requeridas; si se proporcionan las credenciales de autenticación, el programa del servidor web las verifica y las acepta o las rechaza.

Un programa de servidor web puede tener la capacidad de hacer redirecciones de URL a nuevas URL (nuevas ubicaciones), lo que consiste en responder a un mensaje de solicitud de cliente con un mensaje de respuesta que contiene una nueva URL adecuada para acceder a un recurso web válido o existente (el cliente debe rehacer la solicitud con la nueva URL). ^[36]

Se utiliza la redirección de ubicación mediante URL: ^[36]

• para fijar un nombre de directorio agregando una barra final '/'; ^[31]
• para dar una nueva URL a una ruta URL que ya no existe y una nueva ruta donde se pueda encontrar ese tipo de recurso web.
• dar una nueva URL a otro dominio cuando el dominio actual tiene demasiada carga.

Ejemplo 1: una ruta URL apunta a un nombre de directorio pero no tiene una barra final '/', por lo que el servidor web envía una redirección al cliente para indicarle que rehaga la solicitud con el nombre de ruta fijo. ^[31]

Desde:
  /directory1/directory2
Hasta:
  /directory1/directory2/

Ejemplo 2: se ha movido un conjunto completo de documentos dentro del sitio web para reorganizar las rutas de su sistema de archivos.

Desde:
  /directory1/directory2/2021-10-08/
Hasta:
  /directory1/directory2/2021/10/08/

Ejemplo 3: un conjunto completo de documentos se ha trasladado a un nuevo sitio web y ahora es obligatorio utilizar conexiones HTTPS seguras para acceder a ellos.

Desde:
  http://www.example.com/directory1/directory2/2021-10-08/
Hasta:
  https://docs.example.com/directory1/2021-10-08/

Los ejemplos anteriores son sólo algunos de los posibles tipos de redirecciones.

Un programa de servidor web puede responder a un mensaje de solicitud de cliente válido con un mensaje exitoso, que opcionalmente contiene los datos del recurso web solicitado . ^[37]

Si los datos de recursos web se envían de vuelta al cliente, pueden ser contenido estático o dinámico dependiendo de cómo se hayan recuperado (de un archivo o de la salida de algún programa/módulo).

Para acelerar las respuestas del servidor web reduciendo los tiempos de respuesta HTTP promedio y los recursos de hardware utilizados, muchos servidores web populares implementan uno o más cachés de contenido , cada uno especializado en una categoría de contenido. ^{[38] [39]}

El contenido generalmente se almacena en caché según su origen, por ejemplo:

• contenido estático:
  • caché de archivos;
• Contenido dinámico:
  • caché dinámica (salida del módulo/programa).

Históricamente, los contenidos estáticos que se encuentran en archivos a los que se debe acceder con frecuencia, de forma aleatoria y rápida, se han almacenado principalmente en discos electromecánicos desde mediados de los años 1960/1970; lamentablemente, las lecturas y escrituras en ese tipo de dispositivos siempre se han considerado operaciones muy lentas en comparación con la velocidad de la RAM y, por eso, desde los primeros sistemas operativos , primero se desarrollaron cachés de disco y luego también subsistemas de caché de archivos del sistema operativo para acelerar las operaciones de E/S de datos/archivos a los que se accede con frecuencia.

Incluso con la ayuda de un caché de archivos del sistema operativo, la lentitud relativa/ocasional de las operaciones de E/S que involucraban directorios y archivos almacenados en discos pronto se convirtió en un cuello de botella en el aumento del rendimiento esperado de los servidores web de nivel superior, especialmente desde mediados de los años 1990, cuando el tráfico de Internet comenzó a crecer exponencialmente junto con el aumento constante de la velocidad de las líneas de Internet/red.

El problema de cómo acelerar aún más eficientemente el servicio de archivos estáticos, aumentando así el número máximo de solicitudes/respuestas por segundo (RPS), comenzó a estudiarse/investigarse desde mediados de la década de 1990, con el objetivo de proponer modelos de caché útiles que pudieran implementarse en programas de servidor web. ^[40]

En la práctica, hoy en día, muchos programas de servidores web populares y de alto rendimiento incluyen su propio caché de archivos de usuario , adaptado para el uso del servidor web y que utiliza su implementación y parámetros específicos. ^{[41] [42] [43]}

La adopción generalizada de RAID y/o unidades de estado sólido rápidas (hardware de almacenamiento con una velocidad de E/S muy alta) ha reducido ligeramente, pero por supuesto no eliminado, la ventaja de tener un caché de archivos incorporado en un servidor web.

El contenido dinámico, generado por un módulo interno o un programa externo, puede no cambiar siempre con mucha frecuencia (dada una URL única con claves/parámetros) y por lo tanto, tal vez por un tiempo (por ejemplo, desde 1 segundo hasta varias horas o más), la salida resultante puede almacenarse en caché en la RAM o incluso en un disco rápido . ^[44]

El uso típico de un caché dinámico es cuando un sitio web tiene páginas web dinámicas sobre noticias, clima, imágenes, mapas, etc. que no cambian con frecuencia (por ejemplo, cada n minutos) y que son accedidas por una gran cantidad de clientes por minuto/hora; en esos casos es útil devolver también contenido en caché (sin llamar al módulo interno o al programa externo) porque los clientes a menudo no tienen una copia actualizada del contenido solicitado en los cachés de sus navegadores. ^[45]

De todos modos, en la mayoría de los casos, este tipo de cachés se implementan mediante servidores externos (por ejemplo, proxy inverso ) o almacenando la salida de datos dinámicos en computadoras separadas, administradas por aplicaciones específicas (por ejemplo, memcached ), para no competir por los recursos de hardware (CPU, RAM, discos) con el servidor o servidores web. ^{[46] [47]}

Un software de servidor web puede incorporarse al sistema operativo y ejecutarse en el espacio del kernel , o puede ejecutarse en el espacio del usuario (como otras aplicaciones normales).

Los servidores web que se ejecutan en modo kernel (generalmente llamados servidores web de espacio kernel ) pueden tener acceso directo a los recursos del kernel y, por lo tanto, pueden ser, en teoría, más rápidos que los que se ejecutan en modo usuario; de todos modos, existen desventajas en ejecutar un servidor web en modo kernel, por ejemplo: dificultades en el desarrollo ( depuración ) de software, mientras que los errores críticos en tiempo de ejecución pueden provocar problemas graves en el kernel del sistema operativo.

Los servidores web que se ejecutan en modo de usuario deben pedirle permiso al sistema para usar más memoria o más recursos de CPU . Estas solicitudes al núcleo no solo llevan tiempo, sino que también pueden no ser siempre satisfechas porque el sistema reserva recursos para su propio uso y tiene la responsabilidad de compartir los recursos de hardware con todas las demás aplicaciones que se ejecutan. La ejecución en modo de usuario también puede implicar el uso de más copias de búfer/datos (entre el espacio de usuario y el espacio del núcleo), lo que puede provocar una disminución del rendimiento de un servidor web en modo de usuario.

Hoy en día, casi todo el software de servidor web se ejecuta en modo de usuario (porque muchas de las pequeñas desventajas mencionadas anteriormente se han superado gracias a un hardware más rápido, nuevas versiones del sistema operativo, llamadas al sistema operativo mucho más rápidas y un nuevo software de servidor web optimizado). Consulte también la comparación del software de servidor web para descubrir cuál de ellos se ejecuta en modo kernel o en modo de usuario (también conocido como espacio kernel o espacio de usuario).

Para mejorar la experiencia del usuario (en el lado del cliente/navegador), un servidor web debe responder rápidamente (lo antes posible) a las solicitudes del cliente; a menos que la respuesta del contenido esté limitada (por configuración) para algún tipo de archivos (por ejemplo, archivos grandes o enormes), también el contenido de datos devuelto debe enviarse lo más rápido posible (alta velocidad de transferencia).

En otras palabras, un servidor web siempre debe ser muy receptivo , incluso bajo una gran carga de tráfico web, para mantener el tiempo total de espera del usuario (suma del tiempo del navegador + tiempo de red + tiempo de respuesta del servidor web ) para una respuesta lo más bajo posible .

Para el software de servidor web, las principales métricas de rendimiento clave (medidas en diferentes condiciones de funcionamiento) suelen ser al menos las siguientes (es decir): ^[48]

• Número desolicitudes por segundo (RPS, similar aQPS, dependiendo de la versión y configuración de HTTP, el tipo de solicitudes HTTP y otras condiciones operativas);
• número de conexiones por segundo ( CPS ), es el número de conexiones por segundo aceptadas por el servidor web (útil cuando se utiliza HTTP/1.0 o HTTP/1.1 con un límite muy bajo de solicitudes/respuestas por conexión, es decir, 1... 20);
• latencia de red + tiempo de respuesta para cada nueva solicitud de cliente; normalmente la herramienta de evaluación comparativa muestra cuántas solicitudes se han satisfecho dentro de una escala de lapsos de tiempo (por ejemplo, dentro de 1 ms, 3 ms, 5 ms, 10 ms, 20 ms, 30 ms, 40 ms) y/o el tiempo de respuesta más corto, promedio y más largo;
• rendimiento de respuestas , en bytes por segundo.

Entre las condiciones de operación, el número (1 .. n ) de conexiones de cliente simultáneas utilizadas durante una prueba es un parámetro importante porque permite correlacionar el nivel de concurrencia soportado por el servidor web con los resultados de las métricas de rendimiento probadas.

El diseño y modelo de software de servidor web específico adoptado (por ejemplo):

• proceso único o multiproceso;
• un solo hilo (sin hilo) o múltiples hilos para cada proceso;
• uso de corrutinas o no;

...y otras técnicas de programación , como (por ejemplo):

• minimización de posibles fallos de caché de CPU ;
• minimización de posibles predicciones erróneas de ramas de CPU en rutas críticas para la velocidad;
• minimización del número de llamadas al sistema utilizadas para realizar una determinada función/tarea;
• otros trucos;

... utilizado para implementar un programa de servidor web, puede sesgar mucho el rendimiento y, en particular, el nivel de escalabilidad que se puede lograr bajo una carga pesada o cuando se utiliza hardware de alta gama (muchas CPU, discos y mucha RAM).

En la práctica, algunos modelos de software de servidor web pueden requerir más recursos del sistema operativo (especialmente más CPU y más RAM) que otros para poder funcionar bien y así lograr el rendimiento objetivo.

Existen muchas condiciones operativas que pueden afectar el rendimiento de un servidor web; los valores de rendimiento pueden variar dependiendo de (por ejemplo):

• la configuración del servidor web (incluido el hecho de si el archivo de registro está o no habilitado, etc.);
• la versión HTTP utilizada por las solicitudes del cliente;
• el tipo de solicitud HTTP promedio (método, longitud de los encabezados HTTP y cuerpo opcional);
• si el contenido solicitado es estático o dinámico;
• si el contenido está almacenado en caché o no (por el servidor y/o por el cliente);
• si el contenido se comprime sobre la marcha (cuando se transfiere), se comprime previamente (es decir, cuando un recurso de archivo se almacena en el disco ya comprimido para que el servidor web pueda enviar ese archivo directamente a la red con la única indicación de que su contenido está comprimido) o no se comprime en absoluto;
• si las conexiones están o no cifradas;
• la velocidad media de la red entre el servidor web y sus clientes;
• el número de conexiones TCP activas ;
• el número de procesos activos administrados por el servidor web (incluidos programas externos CGI, SCGI y FCGI);
• las limitaciones de hardware y software o la configuración del sistema operativo de la(s) computadora(s) en la que se ejecuta el servidor web;
• otras condiciones menores.

El rendimiento de un servidor web normalmente se evalúa mediante una o más de las herramientas de prueba de carga automatizadas disponibles .

Un servidor web (instalación de programa) normalmente tiene límites de carga predefinidos para cada combinación de condiciones de funcionamiento, también porque está limitado por los recursos del sistema operativo y porque sólo puede manejar un número limitado de conexiones de cliente simultáneas (normalmente entre 2 y varias decenas de miles para cada proceso de servidor web activo, véase también el problema C10k y el problema C10M ).

Cuando un servidor web está cerca o por encima de sus límites de carga, se sobrecarga y puede dejar de responder .

En cualquier momento los servidores web pueden sobrecargarse debido a una o más de las siguientes causas (por ejemplo).

• Exceso de tráfico web legítimo . Miles o incluso millones de clientes que se conectan al sitio web en un corto período de tiempo, por ejemplo, el efecto Slashdot .
• Ataques de denegación de servicio distribuido . Un ataque de denegación de servicio (ataque DoS) o un ataque de denegación de servicio distribuido (ataque DDoS) es un intento de hacer que un equipo o un recurso de red no esté disponible para sus usuarios previstos.
• Gusanos informáticos que a veces provocan tráfico anormal debido a millones de computadoras infectadas (no coordinadas entre ellas).
• Los gusanos XSS pueden provocar un alto tráfico debido a millones de navegadores o servidores web infectados.
• Bots de Internet Tráfico no filtrado/limitado en sitios web grandes con muy pocos recursos de red (por ejemplo, ancho de banda ) y/o recursos de hardware (CPU, RAM, discos).
• La velocidad de Internet (red) se ralentiza (por ejemplo, debido a pérdidas de paquetes), por lo que las solicitudes de los clientes se atienden más lentamente y el número de conexiones aumenta tanto que se alcanzan los límites del servidor.
• Servidores web, que sirven contenido dinámico , esperan respuestas lentas provenientes de las computadoras back-end (por ejemplo, bases de datos ), tal vez debido a demasiadas consultas mezcladas con demasiadas inserciones o actualizaciones de datos de la base de datos; en estos casos, los servidores web tienen que esperar respuestas de datos back-end antes de responder a los clientes HTTP, pero durante estas esperas llegan demasiadas conexiones/solicitudes de clientes nuevos y, por lo tanto, se sobrecargan.
• Indisponibilidad parcial de servidores web ( computadoras ) . Esto puede suceder debido a mantenimiento o actualización urgente o requeridos, fallas de hardware o software, como fallas del back-end (por ejemplo, de la base de datos ); en estos casos, los servidores web restantes pueden recibir demasiado tráfico y sobrecargarse.

Los síntomas de un servidor web sobrecargado suelen ser los siguientes (por ejemplo):

• Las solicitudes se atienden con retrasos (posiblemente largos) (desde 1 segundo hasta unos cientos de segundos).
• El servidor web devuelve un código de error HTTP , como 500, 502, ^{[49] [50]} 503, ^[51] 504, ^[52] 408, o incluso un 404 intermitente .
• El servidor web rechaza o restablece (interrumpe) las conexiones TCP antes de devolver cualquier contenido.
• En casos muy raros, el servidor web devuelve solo una parte del contenido solicitado. Este comportamiento puede considerarse un error , aunque suele aparecer como síntoma de sobrecarga.

Para superar parcialmente los límites de carga superiores a la media y evitar la sobrecarga, la mayoría de los sitios web populares utilizan técnicas comunes como las siguientes (por ejemplo).

• Ajuste de los parámetros del sistema operativo según las capacidades y el uso del hardware.
• Ajustar los parámetros del servidor(es) web para mejorar su seguridad y rendimiento.
• Implementar técnicas de caché web (no sólo para contenidos estáticos sino, siempre que sea posible, también para contenidos dinámicos).
• Gestión del tráfico de red mediante:
  • Cortafuegos para bloquear tráfico no deseado que provenga de fuentes de IP incorrectas o que tengan patrones incorrectos;
  • Administradores de tráfico HTTP para descartar, redirigir o reescribir solicitudes que tengan patrones HTTP incorrectos;
  • Gestión del ancho de banda y modelado del tráfico , con el fin de suavizar los picos de uso de la red.
• Utilizando diferentes nombres de dominio , direcciones IP y computadoras para servir diferentes tipos (estáticos y dinámicos) de contenido; el objetivo es separar archivos grandes o enormes ( download.*) (ese dominio también puede ser reemplazado por un CDN ) de archivos pequeños y medianos ( static.*) y del sitio dinámico principal (tal vez donde algunos contenidos se almacenan en una base de datos de backend ) ( www.*); la idea es poder servir de manera eficiente archivos grandes o enormes (más de 10 – 1000 MB) (tal vez limitando las descargas) y almacenar en caché por completo los archivos pequeños y medianos, sin afectar el rendimiento del sitio dinámico bajo una carga pesada, mediante el uso de diferentes configuraciones para cada (grupo) de computadoras del servidor web, por ejemplo:
  • https://download.example.com
  • https://static.example.com
  • https://www.example.com
• Utilizando muchos servidores web (computadoras) que están agrupados detrás de un balanceador de carga para que actúen o sean vistos como un gran servidor web.
• Agregar más recursos de hardware (es decir , RAM , discos rápidos ) a cada computadora.
• Utilizar programas informáticos más eficientes para servidores web (ver también: eficiencia del software).
• Usar la interfaz de puerta de enlace de servidor web más eficiente para procesar solicitudes dinámicas (generando uno o más programas externos cada vez que se recupera una página dinámica, lo que afecta el rendimiento).
• Utilizando otras técnicas de programación y soluciones alternativas , especialmente si hay contenido dinámico involucrado, para acelerar las respuestas HTTP (es decir, evitando llamadas dinámicas para recuperar objetos, como hojas de estilo, imágenes y scripts), que nunca cambian o cambian muy raramente, copiando ese contenido a archivos estáticos una vez y luego manteniéndolos sincronizados con el contenido dinámico).
• Utilizar las últimas versiones eficientes de HTTP (por ejemplo, además de usar el HTTP/1.1 común, habilitando también HTTP/2 y quizás HTTP/3 también, siempre que el software de servidor web disponible tenga soporte confiable para los últimos dos protocolos) para reducir mucho la cantidad de conexiones TCP/IP iniciadas por cada cliente y el tamaño de los datos intercambiados (debido a una representación más compacta de los encabezados HTTP y quizás a la compresión de datos).

Advertencias sobre el uso de los protocolos HTTP/2 y HTTP/3

Incluso si los protocolos HTTP más nuevos (2 y 3) generalmente generan menos tráfico de red para cada dato de solicitud/respuesta, pueden requerir más recursos del sistema operativo (es decir, RAM y CPU) utilizados por el software del servidor web (debido a los datos cifrados , muchos buffers de transmisión y otros detalles de implementación); además de esto, HTTP/2 y quizás HTTP/3 también, dependiendo también de la configuración del servidor web y del programa cliente, pueden no ser las mejores opciones para la carga de datos de archivos grandes o enormes a muy alta velocidad porque sus flujos de datos están optimizados para la concurrencia de solicitudes y, por lo tanto, en muchos casos, el uso de conexiones TCP/IP HTTP/1.1 puede conducir a mejores resultados / velocidades de carga más altas (su experiencia puede variar) . ^{[53] [54]}

A continuación se muestran las últimas estadísticas de la cuota de mercado de todos los sitios de los principales servidores web en Internet de Netcraft .

NOTA: (*) porcentaje redondeado a número entero, porque sus valores decimales no son reportados públicamente por la página de origen (solo se reporta su valor redondeado en el gráfico).

• Servidor (informática)
• Servidor de aplicaciones
• Comparación de software de servidor web
• Servidor HTTP (parte central de un programa de servidor web que atiende solicitudes HTTP)
• Compresión HTTP
• Aplicación web
• Aplicación web de código abierto
• Lista de paquetes AMP
• Objeto variante
• Alojamiento virtual
• Servicio de alojamiento web
• Contenedor web
• Proxy web
• Servicio web

Interfaces de puerta de enlace de servidor web estándar utilizadas para contenidos dinámicos :

• Interfaz de puerta de enlace común CGI
• Interfaz de puerta de enlace común simple SCGI
• Interfaz de puerta de enlace común rápida FastCGI

Algunas otras interfaces de servidor web (específicas del servidor o del lenguaje de programación ) utilizadas para contenidos dinámicos:

• SSI Server Side Includes, documentos HTML estáticos que rara vez se utilizan y que contienen directivas SSI son interpretados por el software del servidor para incluir pequeños datos dinámicos sobre la marcha cuando se sirven las páginas, por ejemplo, fecha y hora, otros contenidos de archivos estáticos, etc.
• Interfaz de programación de aplicaciones del servidor SAPI :
  • Interfaz de programación de aplicaciones de servidor de Internet ISAPI
  • Interfaz de programación de aplicaciones de servidor Netscape NSAPI
• Interfaz de puerta de enlace de servidor web PSGI Perl
• Interfaz de puerta de enlace del servidor web Python WSGI
• Interfaz de puerta de enlace del servidor web en rack
• Interfaz de puerta de enlace de servidor web JavaScript JSGI
• Servlet de Java , páginas de JavaServer
• Páginas de servidor activas , ASP.NET

• Mozilla: ¿qué es un servidor web?
• Netcraft: noticias sobre la encuesta de servidores web