Servidor web

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» , solicitaba comentarios y fue leída por varias personas. En octubre de 1990, la propuesta fue reformulada y ampliada (con Robert Cailliau como coautor ) y, finalmente, fue aprobada. ^{[ 8 ] [ 9 ] [ 10 ]}

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 NeXTSTEP OS instalado en estaciones de trabajo NeXT : ^{[ 11 ] [ 12 ] [ 10 ]}

• un navegador web gráfico , llamado WorldWideWeb ;
• un navegador web portátil en modo línea ;
• un servidor web, posteriormente conocido como CERN httpd .

Esos primeros navegadores recuperaban páginas web escritas en una forma simple y primitiva 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. ^{[ 13 ]} Poco después, esos programas, junto con su código fuente , se pusieron a disposición de las personas interesadas en su uso. ^{[ 11 ]} Aunque el código fuente no fue licenciado formalmente ni puesto en el dominio público, el CERN permitió informalmente a usuarios y desarrolladores experimentar y seguir desarrollándolo. Berners-Lee comenzó a promover la adopción y el uso de esos programas, así como su adaptación a otros sistemas operativos . ^{[ 10 ]}

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

Entre 1991 y 1993, el programa de servidor web del CERN continuó 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, comenzaron a desarrollarse muchas otras implementaciones de servidores web.

En abril de 1993, el CERN emitió una declaración oficial pública en la que afirmaba que los tres componentes del software web (el cliente básico en modo línea, el servidor web y la biblioteca de código común), junto con su código fuente , pasaban a ser de dominio público . ^{[ 14 ]} Esta declaración eximió a los desarrolladores de servidores web de cualquier posible problema legal relacionado con el desarrollo de obras derivadas basadas en ese código fuente (una amenaza que, en la práctica, nunca existió).

A principios de 1994, el servidor web más destacado entre los nuevos era NCSA httpd, que funcionaba en diversos sistemas operativos basados ​​en Unix y podía servir contenido generado dinámicamente mediante la implementación del POSTmétodo HTTP y CGI para comunicarse con programas externos. Estas capacidades, junto con las funciones multimedia del navegador Mosaic de NCSA (que también podía gestionar formularios HTML para enviar datos a un servidor web), pusieron de manifiesto el potencial de la tecnología web para la publicación y las aplicaciones de computación distribuida .

En la segunda mitad de 1994, el desarrollo de NCSA httpd se estancó hasta tal punto 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 en 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 . ^{[ 17 ] [ 18 ]}

A finales de 1994, se lanzó un nuevo servidor web comercial llamado Netsite , con características específicas. Fue el primero de muchos productos similares desarrollados primero por Netscape , luego 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 que ha desempeñado y sigue desempeñando un papel clave tanto en el lado del cliente como en el del servidor de la web.

En la segunda mitad de 1995, los servidores web del CERN y del NCSA comenzaron a experimentar un declive (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, además de más funciones, más correcciones aplicadas y un mayor rendimiento que los anteriores.

A finales de 1996, ya existían más de cincuenta programas de software de servidor web diferentes y conocidos, disponibles para cualquiera que quisiera tener un nombre de dominio de Internet o alojar sitios web. ^{[ 20 ]} Muchos de ellos tuvieron una vida corta y fueron reemplazados por otros servidores web.

La publicación de los RFC sobre las versiones del protocolo HTTP/1.0 (1996) y HTTP/1.1 (1997, 1999) obligó a la mayoría de los servidores web a cumplir (aunque no siempre por completo) con dichos estándares. El uso de conexiones persistentes TCP/IP (HTTP/1.1) requirió que los servidores web aumentaran el número máximo de conexiones simultáneas permitidas y mejoraran su escalabilidad.

Entre 1996 y 1999, Netscape Enterprise Server e IIS de Microsoft se consolidaron como las principales opciones comerciales, mientras que entre los programas gratuitos y de código abierto , Apache HTTP Server se mantuvo a la cabeza como el servidor preferido (debido a su fiabilidad y sus numerosas funciones).

En aquellos años también existía otro servidor web comercial llamado Zeus ( actualmente descatalogado ) 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 fue 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 menores que Apache (véase también cuota de mercado ).

Entre 2005 y 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 nueva caché de contenido). ^{[ 21 ] [ 22 ]} Como estas nuevas mejoras de rendimiento se marcaron inicialmente como experimentales, sus usuarios no las habilitaron durante mucho tiempo y, por lo tanto, Apache sufrió aún más la competencia de los servidores comerciales y, sobre todo, de otros servidores de código abierto que, mientras tanto, ya habían alcanzado rendimientos muy superiores (principalmente al servir contenido estático) desde el comienzo de su desarrollo y, en el momento del declive de Apache, también podían ofrecer una lista suficientemente larga de características avanzadas bien probadas.

Pocos años después del inicio del año 2000, surgieron no solo otros servidores web comerciales y altamente competitivos (por ejemplo, LiteSpeed ), sino también muchos otros programas de código abierto como Hiawatha , el servidor HTTP Cherokee , Lighttpd , Nginx y otros productos derivados y relacionados que también contaban con soporte comercial.

Alrededor de 2007-2008, la mayoría de los navegadores web más populares aumentaron su límite predeterminado anterior de 2 conexiones persistentes por dominio de host (un límite recomendado por RFC-2616) ^{[ 23 ]} a 4, 6 u 8 conexiones persistentes por dominio de host, 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. ^{[ 24 ]} 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 delante de servidores web más lentos y también dio una nueva oportunidad a los nuevos servidores web emergentes que podían demostrar toda su velocidad y su capacidad para manejar un número muy alto de conexiones concurrentes sin requerir demasiados recursos de hardware (computadoras costosas con muchas CPU , RAM y discos rápidos). ^{[ 25 ]}

En 2015, los RFC publicaron una nueva versión del protocolo [HTTP/2], y como la implementación de las 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 si añadir o no soporte para esa nueva versión del protocolo. ^{[ 26 ] [ 27 ]}

De hecho, el soporte para 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 para 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 HTTP/2 (al menos en el futuro cercano) también por estas razones principales: ^{[ 26 ] [ 27 ]}

• Los protocolos HTTP/1.x habrían sido compatibles con 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;
• La implementación de HTTP/2 se consideraba una tarea de una complejidad abrumadora que podría abrir la puerta a una nueva clase de errores que hasta 2015 no existían, por lo que habría requerido inversiones notables en el desarrollo y las pruebas de la implementación del nuevo protocolo;
• Siempre se podría añadir compatibilidad con HTTP/2 en el futuro si el esfuerzo estuviera justificado.

En cambio, los desarrolladores de la mayoría de los servidores web más populares se apresuraron a ofrecer la disponibilidad del nuevo protocolo , no solo porque contaban con la mano de obra y el tiempo para hacerlo, sino también porque, por lo general, 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. Otro motivo que impulsó a esos desarrolladores a actuar con rapidez fue que los administradores web sentían la presión del tráfico web cada vez mayor y realmente querían instalar y probar, cuanto antes, algo que pudiera reducir drásticamente el número de conexiones TCP/IP y acelerar el acceso a los sitios web alojados. ^{[ 28 ]}

Entre 2020 y 2021, la dinámica de HTTP/2 en cuanto a su implementación (por parte de los principales servidores web y navegadores web populares) se replicó parcialmente tras la publicación de borradores avanzados de futuras RFC sobre el protocolo HTTP/3 .

Aunque los programas de servidor web difieren en su implementación, la mayoría ofrece las siguientes características comunes.

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

• Servicio de contenido estático : poder servir contenido estático (archivos web) a los clientes a través del protocolo HTTP.
• HTTP : compatibilidad con una o más versiones del protocolo HTTP para enviar versiones de respuestas HTTP compatibles con las versiones de las solicitudes HTTP del cliente (por ejemplo, HTTP/1.0, HTTP/1.1, HTTP/2 , HTTP/3 ).
• Registro de eventos : por lo general, 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 estadísticos y de seguridad.

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

• Servicio de contenido dinámico : para poder servir contenido dinámico (generado sobre la marcha) a los clientes a través del protocolo HTTP.
• Alojamiento virtual : poder alojar muchos sitios web ( nombres de dominio ) utilizando una sola dirección IP .
• Autorización : poder permitir, prohibir o autorizar el acceso a partes de las rutas de un sitio web (recursos web).
• Caché de contenido : para poder almacenar en caché el contenido con el fin de acelerar las respuestas del servidor;
• Compatibilidad con archivos grandes : permite servir archivos cuyo tamaño sea superior a 2 GB en sistemas operativos de 32 bits .
• Limitación del ancho de banda : limitar la velocidad de respuesta del contenido para no saturar la red y poder atender a más clientes;
• Motor de reescritura : para mapear 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 está en ejecución, generalmente realiza varias tareas generales : ^{[ 1 ]}

• Se inicia, opcionalmente lee y aplica la configuración que se encuentra en sus archivos de configuración o en otro lugar, opcionalmente abre el archivo de registro, comienza a escuchar las conexiones y solicitudes de los clientes;
• Opcionalmente, intenta adaptar su comportamiento general según su configuración y sus condiciones de funcionamiento actuales ;
• Gestiona las conexiones de los clientes (aceptando nuevas o cerrando las existentes según sea necesario);
• Recibe solicitudes de clientes (leyendo mensajes HTTP):
  • lee y verifica cada mensaje de solicitud HTTP;
  • normalmente realiza la normalización de URL ;
  • normalmente realiza la asignación de URL (que por defecto puede ser la traducción de la ruta de la URL);
  • Por lo general, realiza la traducción de la ruta URL junto con varias comprobaciones de seguridad;
• ejecuta o rechaza el método HTTP solicitado:
  • Opcionalmente, gestiona las autorizaciones de URL ;
  • Opcionalmente, gestiona las redirecciones de URL ;
  • Opcionalmente, gestiona las solicitudes de recursos estáticos (contenido de archivos):
    • Opcionalmente, gestiona los archivos de índice del directorio ;
    • Opcionalmente, gestiona archivos regulares ;
  • Opcionalmente, gestiona las solicitudes de recursos dinámicos :
    • Opcionalmente, gestiona los listados del directorio ;
    • Opcionalmente, gestiona el procesamiento de programas o módulos , comprobando la disponibilidad, el inicio y, finalmente, la detención de la ejecución de programas externos utilizados para generar contenido dinámico;
    • Opcionalmente, gestiona las comunicaciones con programas externos o 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 y módulos dinámicos;
• Opcionalmente, registra (parcial o totalmente) las solicitudes del cliente 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 u otras funciones del sistema; estos mensajes de registro suelen tener un nivel de depuración, advertencia, error o alerta que se puede filtrar (no registrar) según algunas configuraciones; consulte también el nivel de gravedad .
• Opcionalmente, genera estadísticas sobre el tráfico web gestionado o su rendimiento;
• otras tareas personalizadas.

Los programas de servidor web son capaces de: ^{[ 29 ] [ 30 ] [ 31 ]}

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

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

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

GET /ruta/archivo.html HTTP/1.1 Host: www.example.com Conexión: keep-alive

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

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

GET /directorio1/directorio2 HTTP/1.1 Host: www.example.com Connection: keep-alive

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

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

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

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

Una vez que una solicitud ha sido leída, interpretada y verificada, 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 manejar la solicitud utilizando una de estas rutas de respuesta: ^{[ 33 ]}

• Si algún aspecto de la solicitud no era aceptable (en la línea de estado o en los encabezados del mensaje), el servidor web ya había enviado una respuesta de error;
• Si la solicitud tiene un método (por ejemplo, OPTIONS) que puede ser satisfecho por el código general del servidor web, entonces 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 apunta a una redirección, se envía un mensaje de redirección ;
• Si la URL se corresponde con un recurso dinámico (una ruta virtual o una lista de directorios), entonces se llama a su controlador (un módulo interno o un programa externo) y se le pasan los parámetros de la solicitud (cadena de consulta e información de la ruta) para que pueda responder a esa solicitud;
• Si la URL se corresponde con un recurso estático (normalmente un archivo en el sistema de archivos), entonces se llama al controlador estático interno para enviar ese archivo;
• Si se desconoce el método de solicitud o si existe alguna otra condición inaceptable (por ejemplo, recurso no encontrado, error interno del servidor, etc.), se envía una respuesta de error .

Servir contenido estático

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, traducción y redirección de URL) con la de un archivo existente en 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. ^{[ 33 ]}

Ese tipo de contenido se denomina estático porque, por lo general, el servidor web no lo modifica cuando se envía a los clientes y porque permanece igual hasta que algún programa lo modifica (modificación de archivos).

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

• OPTIONS
• HEAD
• GET

La respuesta del contenido de archivos estáticos se puede acelerar mediante una caché de archivos .

Archivos de índice de directorio

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 dicho directorio es accesible y está habilitado el servicio de archivos de índice de directorio, entonces el programa de servidor web puede intentar servir el primero de los nombres de archivos de índice estáticos conocidos (o configurados) (un archivo regular ) que se encuentren 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 los archivos de índice estático son: index.html, index.htmy Default.htm.

Archivos regulares

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

Por lo general, por motivos de seguridad, la mayoría de los programas de servidor web vienen preconfigurados para servir solo archivos regulares o para evitar el uso de tipos de archivo 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. ^{[ 35 ]}

Ofrecer contenido dinámico

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

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

• POST

Para poder comunicarse con sus módulos internos o programas externos, un programa de servidor web debe haber implementado una o más de las numerosas interfaces de puerta de enlace disponibles (véase 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

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

SCGI

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

FastCGI

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

Listados de directorio

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

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

Algunos programas de servidor web permiten la personalización de listados de directorios mediante 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 son reemplazados con los valores de campo de cada entrada de archivo encontrada en el directorio por el servidor web (por ejemplo, index.tpl) o el uso de HTML y código fuente incrustado que es interpretado y ejecutado (por ejemplo, index.asp) o mediante el soporte del uso de programas de índice dinámico como CGI, SCGI, FCGI (por ejemplo, index.cgi, index.php, index.fcgi).

Por lo general, se evita el uso de listados de directorios generados dinámicamente o se limita a unos pocos directorios seleccionados de un sitio web, ya que esa generación consume 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 de forma aleatoria y frecuente) tal como están, sin necesidad de proporcionar información adicional al usuario solicitante . ^{[ 38 ]}

Procesamiento de programas o módulos

Un programa externo o un módulo interno ( unidad de procesamiento ) puede ejecutar algún tipo de función de aplicación que puede utilizarse para obtener datos de uno o más repositorios de datos o para almacenarlos en ellos :

• 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, incluso utilizando datos recuperados de un repositorio de datos:

• un documento (por ejemplo, HTML , XML , etc.);
• una imagen;
• un vídeo;
• 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 tal vez fueron solicitados por una API XMLHttpRequest ) (ver también: página dinámica ).

En la práctica, siempre que haya contenido que pueda variar en función de uno o más parámetros contenidos en la solicitud del cliente o en la configuración, normalmente se genera de forma dinámica.

Los programas de servidor web pueden enviar mensajes de respuesta como réplicas a los mensajes de solicitud del cliente. ^{[ 29 ]}

Es posible que se envíe un mensaje de respuesta de error porque un mensaje de solicitud no pudo leerse, decodificarse, analizarse o ejecutarse correctamente. ^{[ 30 ]}

NOTA: Las siguientes secciones se presentan únicamente como ejemplos para ayudar a comprender qué hace, más o menos, un servidor web; estas secciones no son en absoluto exhaustivas ni completas.

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

El contenido suele almacenarse en caché según su origen:

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

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

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, en teoría, pueden ser más rápidos que los que se ejecutan en modo usuario, pero existen desventajas al ejecutar un servidor web en modo kernel (por ejemplo, dificultades para desarrollar y depurar 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 usuario deben solicitar al sistema permiso para usar más memoria o más recursos de CPU . Estas solicitudes al núcleo no solo consumen tiempo, sino que además no siempre se satisfacen, ya que el sistema reserva recursos para su propio uso y tiene la responsabilidad de compartir los recursos de hardware con todas las demás aplicaciones en ejecución. La ejecución en modo usuario también puede implicar un mayor uso de búferes o copias de datos (entre el espacio de usuario y el espacio del núcleo), lo que puede provocar una disminución del rendimiento del servidor web.

Actualmente, casi todo el software de servidor web se ejecuta en modo usuario (ya que 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 mucho más rápidas y software de servidor web optimizado). Consulte también la comparación de software de servidor web para descubrir cuáles se ejecutan en modo kernel o en modo usuario (también conocido como espacio kernel o espacio de usuario).

Para el software de servidor web, las principales métricas de rendimiento clave (medidas bajo diversas condiciones de funcionamiento ) suelen ser al menos las siguientes: ^{[ 54 ]}

• 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 de funcionamiento);
• 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 o respuestas por conexión, es decir, 1 .. 20);
• latencia de red + tiempo de respuesta para cada nueva solicitud del cliente; por lo general, la herramienta de evaluación comparativa muestra cuántas solicitudes se han satisfecho dentro de una escala de intervalos de tiempo (por ejemplo, dentro de 1 ms, 3 ms, 5 ms, 10 ms, 20 ms, 30 ms, 40 ms) o el tiempo de respuesta más corto, el promedio y el más largo;
• Rendimiento de las respuestas , en bytes por segundo.

Entre las condiciones de funcionamiento, el número (1 .. n ) de conexiones de clientes concurrentes 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 específico del software del servidor web adoptado :

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

... y otras técnicas de programación , tales como:

• minimización de posibles fallos de caché de la CPU ;
• Minimización de posibles errores de predicción de bifurcaciones de la CPU en rutas críticas para optimizar la velocidad;
• minimización del número de llamadas al sistema utilizadas para realizar una determinada función o tarea;
• otros trucos;

... utilizado para implementar un programa de servidor web, puede influir mucho en el rendimiento y, en particular, en el nivel de escalabilidad que se puede lograr bajo una carga pesada o cuando se utiliza hardware de gama alta (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 correctamente y, por lo tanto, alcanzar el rendimiento deseado.

Existen muchas condiciones de funcionamiento que pueden afectar el rendimiento de un servidor web; los valores de rendimiento pueden variar dependiendo de:

• la configuración del servidor web (incluido el hecho de que el archivo de registro esté habilitado o no, 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 o el cliente);
• ya sea que el contenido se comprima sobre la marcha (al transferirse), se precomprima (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 comprima en absoluto;
• tanto si las conexiones están cifradas como si no;
• 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 gestionados por el servidor web (incluidos los programas externos CGI, SCGI y FCGI);
• las limitaciones o configuraciones de hardware y software del sistema operativo de los ordenadores en los que se ejecuta el servidor web;
• otras afecciones menores.

El rendimiento de un servidor web se suele evaluar mediante el uso de una o más de las herramientas de prueba de carga automatizadas disponibles .

En cualquier momento, los servidores web pueden sobrecargarse debido a una o más de las siguientes causas:

• Tráfico web legítimo excesivo . Miles o incluso millones de clientes conectándose 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 ataque de denegación de servicio distribuido (ataque DDoS) es un intento de dejar un recurso informático o de red inaccesible para sus usuarios previstos.
• Gusanos informáticos que a veces provocan tráfico anormal debido a millones de ordenadores infectados (sin coordinación entre ellos).
• Los gusanos XSS pueden provocar un alto tráfico debido a los millones de navegadores o servidores web infectados.
• Bots de Internet Tráfico no filtrado ni limitado en sitios web grandes con muy pocos recursos de red (por ejemplo, ancho de banda ) o recursos de hardware (CPU, RAM, discos).
• La ralentización de Internet (red) (por ejemplo, debido a la pérdida de paquetes) provoca que las solicitudes de los clientes se atiendan más lentamente y que el número de conexiones aumente tanto que se alcancen los límites del servidor.
• Los servidores web, que sirven contenido dinámico , esperan respuestas lentas provenientes de los ordenadores de back-end (por ejemplo, bases de datos ), tal vez debido a demasiadas consultas combinadas con demasiadas inserciones o actualizaciones de datos de la base de datos; en estos casos, los servidores web tienen que esperar las respuestas de datos del back-end antes de responder a los clientes HTTP, pero durante estas esperas llegan demasiadas conexiones o solicitudes de clientes nuevos y, por lo tanto, se sobrecargan.
• Indisponibilidad parcial de los servidores web ( ordenadores ) . Esto puede ocurrir debido a tareas de mantenimiento o actualización necesarias o urgentes, fallos de hardware o software, como fallos en el sistema (por ejemplo, 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:

• Las solicitudes se atienden con demoras (posiblemente largas) (de un segundo a varios cientos de segundos).
• El servidor web devuelve un código de error HTTP , como 500, 502, ^{[ 55 ] [ 56 ]} 503, ^{[ 57 ]} 504, ^{[ 58 ]} 408, o incluso un 404 intermitente .
• El servidor web rechaza o restablece (interrumpe) las conexiones TCP antes de devolver cualquier contenido.
• En casos muy excepcionales, el servidor web devuelve solo una parte del contenido solicitado. Este comportamiento puede considerarse un error , aunque suele ser 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:

• Ajuste de los parámetros del sistema operativo según las capacidades y el uso del hardware.
• Optimización de los parámetros de los servidores web para mejorar su seguridad y rendimiento.
• Implementar técnicas de almacenamiento en caché web (no solo para contenido estático, sino también, siempre que sea posible, para contenido dinámico).
• Gestionar el tráfico de red, mediante el uso de:
  • Cortafuegos para bloquear el tráfico no deseado procedente de direcciones IP maliciosas o con patrones sospechosos;
  • Los gestores de tráfico HTTP se encargan de descartar, redirigir o reescribir las solicitudes que presenten 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.
• Utilizar diferentes nombres de dominio , direcciones IP y ordenadores para servir distintos tipos de contenido (estático y dinámico); el objetivo es separar los archivos grandes o enormes ( download.*) (ese dominio también podría ser reemplazado por una CDN ) de los archivos pequeños y medianos ( static.*) y del sitio dinámico principal (quizás donde algunos contenidos se almacenan en una base de datos backend ) ( www.*); la idea es poder servir eficientemente archivos grandes o enormes (de más de 10 a 1000 MB) (quizás limitando las descargas) y almacenar en caché completamente los archivos pequeños y medianos, sin afectar el rendimiento del sitio dinámico bajo una carga pesada, utilizando diferentes configuraciones para cada (grupo) de ordenadores del servidor web:
  • https://download.example.com
  • https://static.example.com
  • https://www.example.com
• Utilizar muchos servidores web (ordenadores) agrupados detrás de un balanceador de carga para que actúen o sean vistos como un único servidor web de gran tamaño.
• 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 (véase también: eficiencia del software ).
• Utilizar la interfaz de puerta de enlace del servidor web más eficiente para procesar solicitudes dinámicas (generar uno o más programas externos cada vez que se recupera una página dinámica perjudica el rendimiento).
• Utilizar 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 sola vez y luego manteniéndolos sincronizados con el contenido dinámico.
• Utilizar las versiones más recientes y eficientes de HTTP (por ejemplo, además de usar HTTP/1.1, habilitar también HTTP/2 y posiblemente HTTP/3 , siempre que el software del servidor web disponible ofrezca soporte fiable para estos dos últimos protocolos) para reducir considerablemente el número 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 las cabeceras HTTP y posiblemente a la compresión de datos). Esto podría no evitar las sobrecargas de RAM y CPU causadas por la necesidad de cifrado. Tampoco solucionaría las sobrecargas causadas por archivos excesivamente grandes cargados a alta velocidad, ya que están optimizados para la concurrencia. ^{[ 59 ] [ 60 ]}