stringtranslate.com

Servidor web

Clientes de PC que se comunican a través de la red con un servidor web que ofrece únicamente contenido estático
El interior y el frente de un servidor Dell PowerEdge , un equipo diseñado para montarse en un entorno de montaje en bastidor . Los servidores similares a este suelen utilizarse como servidores web.
Se pueden utilizar varios servidores web para un sitio web con mucho tráfico.
Granja de servidores con miles de servidores web utilizados para sitios web con tráfico muy alto
Módem ADSL que ejecuta un servidor web integrado que ofrece páginas web dinámicas utilizadas para la configuración del módem

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.

Historia

Primera propuesta web (1989) evaluada como "vaga pero emocionante..."
El primer servidor web del mundo, una estación de trabajo NeXT Computer con Ethernet, 1990. La etiqueta de la carcasa dice: "Esta máquina es un servidor. ¡NO LA APAGUE!"

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 ]

Proyecto inicial de la WWW (1989-1991)

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]

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]

Desarrollo rápido y salvaje (1991-1995)

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.

Crecimiento explosivo y competencia (1996-2014)

Número de sitios web activos (1996-2002) [10] [14]
Cobalt Qube 3 de Sun : un dispositivo servidor informático (2002, descontinuado)

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]

Nuevos retos (2015 y años posteriores)

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]

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 .

Descripción técnica

Clientes de PC conectados a un servidor web a través de Internet

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

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.

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

Tareas comunes

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

Leer mensaje de solicitud

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

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 .

Normalización de URL

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:

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.

Asignación de URL

"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:

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.

Traducción de la ruta URL al sistema de archivos

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:

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.

Administrar mensaje de 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]

Ofrecer contenido estático

Clientes de PC que se comunican a través de la red con un servidor web que ofrece únicamente 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 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 :

La respuesta del contenido de un archivo estático se puede acelerar mediante un 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 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.

Archivos regulares

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]

Ofrecer contenido dinámico

Clientes de PC que se comunican a través de la red con un servidor web que ofrece contenido estático y dinámico

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:

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.
Listados de directorios
Listado de directorios generado dinámicamente por un servidor web

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]

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 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 ]

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 ]

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.

Enviar mensaje de respuesta

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.

Mensaje de error

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:

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.

Autorización de URL

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

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:

Redirección de URL

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]

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.

Mensaje de éxito

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).

Caché de contenido

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:

Caché de archivos

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.

Caché dinámico

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]

Servidores web en modo kernel y en modo usuario

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).

Actuaciones

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 .

Métricas de rendimiento

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]

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.

Eficiencia del software

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

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

... 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.

Condiciones de funcionamiento

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

Evaluación comparativa

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

Límites de carga

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 .

Causas de sobrecarga

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

Síntomas de sobrecarga

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

Técnicas anti-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).

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]

Cuota de mercado

Gráfico:
Cuota de mercado de todos los sitios para los servidores web más populares 2005-2021
Gráfico:
Cuota de mercado de todos los sitios para los servidores web más populares, 1995-2005

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).

Véase también

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

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

Referencias

  1. ^ abc Nancy J. Yeager; Robert E. McGrath (1996). Tecnología de servidores web. Morgan Kaufmann. ISBN 1-55860-376-XArchivado desde el original el 20 de enero de 2023 . Consultado el 22 de enero de 2021 .
  2. ^ William Nelson; Arvind Srinivasan; Murthy Chintalapati (2009). Servidor web Sun: la guía esencial. Pearson Education. ISBN 978-0-13-712892-1Archivado del original el 20 de enero de 2023 . Consultado el 14 de octubre de 2021 .
  3. ^ Zolfagharifard, Ellie (24 de noviembre de 2018). «El 'padre de la web' Sir Tim Berners-Lee habla de su plan para luchar contra las noticias falsas» . The Telegraph . Londres. ISSN  0307-1235. Archivado desde el original el 11 de enero de 2022. Consultado el 1 de febrero de 2019 .
  4. ^ "Historia de las computadoras y la informática, Internet, nacimiento, la World Wide Web de Tim Berners-Lee". history-computer.com . Archivado desde el original el 4 de enero de 2019 . Consultado el 1 de febrero de 2019 .
  5. ^ abc Tim Berner-Lee (1992). «Historia del proyecto WWW (original)». CERN (proyecto World Wide Web). Archivado desde el original el 8 de diciembre de 2021. Consultado el 20 de diciembre de 2021 .
  6. ^ por Tim Berner-Lee (20 de agosto de 1991). «Aplicación de hipertexto de área amplia WorldWideWeb disponible (anuncio)». CERN (proyecto World Wide Web). Archivado desde el original el 2 de diciembre de 2021. Consultado el 16 de octubre de 2021 .
  7. ^ ab Web Administrator. «Historia de la Web». CERN (proyecto World Wide Web). Archivado desde el original el 2 de diciembre de 2021. Consultado el 16 de octubre de 2021 .
  8. ^ Tim Berner-Lee (2 de agosto de 1991). «Calificadores en enlaces de hipertexto...». CERN (Proyecto World Wide Web). Archivado desde el original el 7 de diciembre de 2021. Consultado el 16 de octubre de 2021 .
  9. ^ Ali Mesbah (2009). Análisis y prueba de aplicaciones web de una sola página basadas en Ajax. ISBN 978-90-79982-02-8. Recuperado el 18 de diciembre de 2021 .
  10. ^ de Robert H'obbes' Zakon. "Hobbes' Internet Timeline v5.1 (WWW Growth) NOTA: hasta 1996, el número de servidores web = el número de sitios web". ISOC. Archivado desde el original el 15 de agosto de 2000. Consultado el 18 de diciembre de 2021 .{{cite web}}: CS1 maint: URL no apta ( enlace )
  11. ^ Tim Smith; François Flückiger. «Licencias para la Web». CERN (Proyecto World Wide Web). Archivado desde el original el 6 de diciembre de 2021. Consultado el 16 de octubre de 2021 .
  12. ^ "NCSA httpd". NCSA (archivo web). Archivado desde el original el 1 de agosto de 2010. Consultado el 16 de diciembre de 2021 .
  13. ^ "Acerca del servidor Apache HTTPd: cómo surgió Apache". Apache: proyecto de servidor HTTPd. 1997. Archivado desde el original el 7 de junio de 2008. Consultado el 17 de diciembre de 2021 .
  14. ^ "Encuesta de servidores web, NOTA: se ha interpolado el número de sitios web activos en el año 2000". Netcraft. 22 de diciembre de 2021. Archivado desde el original el 27 de diciembre de 2021. Consultado el 27 de diciembre de 2021 .
  15. ^ "Netcraft: software de servidor web (1996)". Netcraft (archivo web). Archivado desde el original el 30 de diciembre de 1996. Consultado el 16 de diciembre de 2021 .
  16. ^ "Resumen de las nuevas características de Apache 2.2". Apache: proyecto de servidor HTTPd. 2005. Archivado desde el original el 27 de noviembre de 2021. Consultado el 16 de diciembre de 2021 .
  17. ^ "Resumen de las nuevas características de Apache 2.4". Apache: proyecto de servidor HTTPd. 2012. Archivado desde el original el 26 de noviembre de 2021 . Consultado el 16 de diciembre de 2021 .
  18. ^ "Conexiones, conexiones persistentes: consideraciones prácticas". RFC 2616, Protocolo de transferencia de hipertexto -- HTTP/1.1. págs. 46–47. sec. 8.1.4. doi : 10.17487/RFC2616 . RFC 2616.
  19. ^ "Conexiones concurrentes máximas al mismo dominio para navegadores". 2017. Archivado desde el original el 21 de diciembre de 2021. Consultado el 21 de diciembre de 2021 .
  20. ^ "Linux Web Server Performance Benchmark - 2016 results" (Balance de rendimiento de servidores web Linux: resultados de 2016). RootUsers. 8 de marzo de 2016. Archivado desde el original el 23 de diciembre de 2021. Consultado el 22 de diciembre de 2021 .
  21. ^ ab "¿HTTP/2 reemplazará a HTTP/1.x?". Grupo de trabajo HTTP de la IETF. Archivado desde el original el 27 de septiembre de 2014. Consultado el 22 de diciembre de 2021 .
  22. ^ ab "Implementaciones de HTTP/2 en software de cliente y servidor". Grupo de trabajo HTTP de IETF. Archivado desde el original el 23 de diciembre de 2021. Consultado el 22 de diciembre de 2021 .
  23. ^ "¿Por qué una única conexión TCP?". Grupo de trabajo HTTP de la IETF. Archivado desde el original el 27 de septiembre de 2014. Consultado el 22 de diciembre de 2021 .
  24. ^ ab "Mensajería cliente/servidor". RFC 7230, HTTP/1.1: Sintaxis de mensajes y enrutamiento. págs. 7–8. sec. 2.1. doi : 10.17487/RFC7230 . RFC 7230.
  25. ^ ab "Manejo de mensajes incompletos". RFC 7230, HTTP/1.1: Sintaxis de mensajes y enrutamiento. pág. 34. sec. 3.4. doi : 10.17487/RFC7230 . RFC 7230.
  26. ^ "Robustez del análisis de mensajes". RFC 7230, HTTP/1.1: Sintaxis de mensajes y enrutamiento. págs. 34–35. sec. 3.5. doi : 10.17487/RFC7230 . RFC 7230.
  27. ^ R. Bowen (29 de septiembre de 2002). «URL Mapping» (PDF) . Apache software foundation. Archivado (PDF) del original el 15 de noviembre de 2021. Consultado el 15 de noviembre de 2021 .
  28. ^ abcde "Asignación de URL a ubicaciones del sistema de archivos". Apache: proyecto de servidor HTTPd. 2021. Archivado desde el original el 20 de octubre de 2021 . Consultado el 19 de octubre de 2021 .
  29. ^ "Contenido dinámico con CGI". Apache: proyecto de servidor HTTPd. 2021. Archivado desde el original el 15 de noviembre de 2021. Consultado el 19 de octubre de 2021 .
  30. ^ Chris Shiflett (2003). Manual del desarrollador de HTTP. Sams's Publishing. ISBN 0-672-32454-7Archivado desde el original el 20 de enero de 2023 . Consultado el 9 de diciembre de 2021 .
  31. ^ abc ASF Infrabot (22 de mayo de 2019). «Listados de directorios». Fundación Apache: proyecto de servidor HTTPd. Archivado desde el original el 7 de junio de 2019. Consultado el 16 de noviembre de 2021 .
  32. ^ "Apache: listado de directorios para descargar archivos". Apache: servidor HTTPd. Archivado desde el original el 2 de diciembre de 2021 . Consultado el 16 de diciembre de 2021 .
  33. ^ "Error de cliente 4xx". RFC 7231, HTTP/1.1: Semántica y contenido. pág. 58. sec. 6.5. doi : 10.17487/RFC7231 . RFC 7231.
  34. ^ "Error de servidor 5xx". RFC 7231, HTTP/1.1: Semántica y contenido. págs. 62-63. sec. 6.6. doi : 10.17487/RFC7231 . RFC 7231.
  35. ^ "Introducción". RFC 7235, HTTP/1.1: Autenticación. pág. 3. sec. 1. doi : 10.17487/RFC7235 . RFC 7235.
  36. ^ ab "Códigos de estado de respuesta: redirección 3xx". RFC 7231, HTTP/1.1: Semántica y contenido. págs. 53–54. sec. 6.4. doi : 10.17487/RFC7231 . RFC 7231.
  37. ^ "2xx exitoso". RFC 7231, HTTP/1.1: Semántica y contenido. págs. 51-54. sección 6.3. doi : 10.17487/RFC7231 . RFC 7231.
  38. ^ "Guía de almacenamiento en caché". Apache: proyecto de servidor HTTPd. 2021. Archivado desde el original el 9 de diciembre de 2021 . Consultado el 9 de diciembre de 2021 .
  39. ^ "Almacenamiento en caché de contenido NGINX". F5 NGINX. 2021. Archivado desde el original el 9 de diciembre de 2021. Consultado el 9 de diciembre de 2021 .
  40. ^ Evangelos P. Markatos (1996). «Almacenamiento en caché de documentos web en la memoria principal». Redes informáticas y sistemas RDSI. Archivado desde el original el 20 de enero de 2023. Consultado el 9 de diciembre de 2021 .
  41. ^ "IPlanet Web Server 7.0.9: caché de archivos". Oracle. 2010. Archivado desde el original el 9 de diciembre de 2021. Consultado el 9 de diciembre de 2021 .
  42. ^ "Módulo Apache mod_file_cache". Apache: proyecto de servidor HTTPd. 2021. Archivado desde el original el 9 de diciembre de 2021 . Consultado el 9 de diciembre de 2021 .
  43. ^ «Servidor HTTP: configuración: caché de archivos». GNU. 2021. Archivado desde el original el 9 de diciembre de 2021. Consultado el 9 de diciembre de 2021 .
  44. ^ "Módulo Apache mod_cache_disk". Apache: proyecto de servidor HTTPd. 2021. Archivado desde el original el 9 de diciembre de 2021 . Consultado el 9 de diciembre de 2021 .
  45. ^ "¿Qué es la caché dinámica?". Educativo. 2021. Archivado desde el original el 9 de diciembre de 2021. Consultado el 9 de diciembre de 2021 .
  46. ^ "Tutorial de la opción de caché dinámica". Siteground. 2021. Archivado desde el original el 20 de enero de 2023. Consultado el 9 de diciembre de 2021 .
  47. ^ Arun Iyengar; Jim Challenger (2000). "Mejora del rendimiento del servidor web mediante el almacenamiento en caché de datos dinámicos". Usenix . Consultado el 9 de diciembre de 2021 .
  48. ^ Jussara M. Almeida ; Virgilio Almeida; David J. Yates (7 de julio de 1997). «WebMonitor: una herramienta para medir el rendimiento de los servidores de la World Wide Web». Primer lunes . doi : 10.5210/fm.v2i7.539 . Archivado desde el original el 4 de noviembre de 2021 . Consultado el 4 de noviembre de 2021 .
  49. ^ Fisher, Tim; Lifewire. "¿Recibe un error 502 de puerta de enlace incorrecta? Esto es lo que debe hacer". Lifewire . Archivado desde el original el 23 de febrero de 2017. Consultado el 1 de febrero de 2019 .
  50. ^ "¿Qué es un gateway 502 defectuoso y cómo solucionarlo?". IT PRO . Archivado desde el original el 20 de enero de 2023. Consultado el 1 de febrero de 2019 .
  51. ^ Fisher, Tim; Lifewire. "¿Recibe un error 503 de servicio no disponible? Esto es lo que debe hacer". Lifewire . Archivado desde el original el 20 de enero de 2023. Consultado el 1 de febrero de 2019 .
  52. ^ Fisher, Tim; Lifewire. "¿Recibe un error 504 de tiempo de espera de puerta de enlace? Esto es lo que debe hacer". Lifewire . Archivado desde el original el 23 de abril de 2021. Consultado el 1 de febrero de 2019 .
  53. ^ muchos (24 de enero de 2021). «Subidas lentas con HTTP/2». github. Archivado desde el original el 16 de noviembre de 2021 . Consultado el 15 de noviembre de 2021 .
  54. ^ Junho Choi (24 de agosto de 2020). «Mejoras en la velocidad de carga de HTTP/2». Cloudflare. Archivado desde el original el 16 de noviembre de 2021. Consultado el 15 de noviembre de 2021 .
  55. ^ "Encuesta sobre servidores web de octubre de 2021". Netcraft . 15 de octubre de 2021. Archivado desde el original el 15 de noviembre de 2021 . Consultado el 15 de noviembre de 2021 .
  56. ^ "Encuesta de servidores web de febrero de 2021". Netcraft . 26 de febrero de 2021. Archivado desde el original el 15 de abril de 2021 . Consultado el 8 de abril de 2021 .
  57. ^ "Encuesta de servidores web de febrero de 2020". Netcraft . 20 de febrero de 2020. Archivado desde el original el 17 de abril de 2021 . Consultado el 8 de abril de 2021 .
  58. ^ "Encuesta de servidores web de febrero de 2019". Netcraft . 28 de febrero de 2019. Archivado desde el original el 15 de abril de 2021 . Consultado el 8 de abril de 2021 .
  59. ^ "Encuesta de servidores web de febrero de 2018". Netcraft . 13 de febrero de 2018. Archivado desde el original el 17 de abril de 2021 . Consultado el 8 de abril de 2021 .
  60. ^ "Encuesta de servidores web de febrero de 2017". Netcraft . 27 de febrero de 2017. Archivado desde el original el 14 de marzo de 2017 . Consultado el 13 de marzo de 2017 .
  61. ^ "Encuesta de servidores web de febrero de 2016". Netcraft . 22 de febrero de 2016. Archivado desde el original el 27 de enero de 2022 . Consultado el 27 de enero de 2022 .

Enlaces externos