Un servidor web es un software informático y un 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 realizando 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 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 normalmente se puede servir más rápido y se puede almacenar 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 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 por humanos.
,_02.JPG/1280px-Ginevra,_centro_visitatori_del_cern,_primo_server_della_storia_(1989),_02.JPG)
Esta es una historia muy breve de los programas de servidores web , por lo que parte de la 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, parte de la información histórica clave que se proporciona 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.
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 el uso de un sistema de hipertexto . La propuesta, titulada "Hipertexto y CERN" , solicitó 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 las estaciones de trabajo NeXT : [6] [7] [5]
Esos 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 Berner-Lee anunció el nacimiento de la tecnología WWW y alentó 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 tenía una licencia formal ni era de dominio público, el CERN permitió informalmente a los usuarios y desarrolladores experimentar y desarrollar más sobre ellos. Berners-Lee comenzó a promover la adopción y el uso de esos programas junto con su migración a otros sistemas operativos . [5]
En diciembre de 1991 se instaló en SLAC (EE.UU.) el primer servidor web fuera de Europa . [7] Este fue un evento muy importante porque inició las comunicaciones web transcontinentales entre navegadores web y servidores web.
En 1991-1993, el grupo www continuó desarrollando activamente el programa de servidor web del CERN, mientras tanto, gracias a la disponibilidad de su código fuente y 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 afirmando que los tres componentes del software web (el cliente en modo de línea básico, el servidor web y la biblioteca de código común), junto con su código fuente , fueron puestos en el dominio público . [11] Esta declaración liberó a los desarrolladores de servidores web de cualquier posible problema legal sobre el desarrollo de trabajos derivados basados en ese código fuente (amenaza que en la práctica nunca existió).
A principios de 1994, el más notable entre los nuevos servidores web era NCSA httpd , que se ejecutaba en una variedad de 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 características multimedia del navegador Mosaic de NCSA (también capaz de administrar formularios HTML para enviar datos a un servidor web) resaltaron el potencial de la tecnología web para la publicación y 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 se aplicaron todos esos parches a la última versión del código fuente NCSA y, después de varias pruebas, se inició el proyecto del servidor Apache HTTP . [12] [13]
A finales de 1994 se lanzó un nuevo servidor web comercial, denominado Netsite , con características específicas. Fue el primero de muchos otros productos similares 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 World Wide Web, de un desarrollador y proveedor comercial muy importante que ha jugado y sigue jugando un papel clave en ambos lados (cliente y servidor) de la web.
En la segunda mitad de 1995, los servidores web del CERN y NCSA comenzaron a disminuir (en porcentaje de uso global) debido a la adopción generalizada de nuevos servidores web que tenían un ciclo de desarrollo mucho más rápido junto con más funciones, más correcciones aplicadas y más rendimiento que los anteriores. los anteriores.
A finales de 1996 ya había más de cincuenta (diferentes) programas de software de servidor web disponibles para cualquiera que quisiera poseer un nombre de dominio en Internet y/o alojar sitios web. [15] Muchos de ellos vivieron poco tiempo y fueron reemplazados por otros servidores web.
La publicación de RFC sobre las versiones de los protocolos HTTP/1.0 (1996) y HTTP/1.1 (1997, 1999), obligó a la mayoría de los servidores web a cumplir (no siempre completamente) con esos estándares. El uso de conexiones persistentes TCP/IP (HTTP/1.1) requirió que los servidores web aumentaran mucho el número máximo de conexiones simultáneas permitidas y mejoraran su nivel de escalabilidad.
Entre 1996 y 1999, Netscape Enterprise Server y IIS de Microsoft surgieron entre las principales opciones comerciales, mientras que entre los programas de código abierto y disponibles gratuitamente , Apache HTTP Server ocupó el primer lugar como servidor preferido (debido a su confiabilidad y sus numerosas características).
En esos años también existía otro servidor web comercial, muy innovador y por tanto 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 años 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 (ver también participación de mercado).
Entre 2005 y 2006, Apache comenzó a mejorar su velocidad y su nivel de escalabilidad mediante la introducción de nuevas funciones de rendimiento (por ejemplo, MPM de eventos y caché de contenido nuevo). [16] [17] Como esas nuevas mejoras de rendimiento inicialmente fueron marcadas como experimentales, no fueron habilitadas por sus usuarios durante mucho tiempo y así Apache sufrió, aún más, la competencia de los servidores comerciales y, sobre todo, de otros servidores abiertos. servidores de origen que 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 eran capaces de ofrecer también una lista suficientemente larga de características avanzadas bien probadas.
De hecho, pocos años después del 2000 comenzaron a aparecer no sólo otros servidores web comerciales y altamente competitivos, por ejemplo LiteSpeed , sino también muchos otros programas de código abierto, a menudo de excelente calidad y muy altas prestaciones, entre los que cabe destacar Hiawatha, Cherokee HTTP Surgieron server , Lighttpd , Nginx y otros productos derivados/relacionados también disponibles con soporte comercial.
Alrededor de 2007-2008, 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) [18] a 4, 6 u 8 conexiones persistentes por dominio de host, para acelerar facilitar 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 administrar. 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 podrían mostrar toda su velocidad y su capacidad. para manejar un número muy elevado de conexiones simultáneas sin requerir demasiados recursos de hardware (computadoras costosas con muchas CPU, RAM y discos rápidos). [20]
En 2015, los RFC publicaron una nueva versión del protocolo [HTTP/2], y como la implementación de nuevas especificaciones no era nada trivial, surgió un dilema entre los desarrolladores de servidores web menos populares (por ejemplo, con un porcentaje de uso inferior al 1%.. 2%), sobre agregar o no soporte para esa nueva versión del protocolo. [21] [22]
De hecho, el soporte de HTTP/2 a menudo requería cambios radicales en su implementación interna debido a muchos factores (prácticamente siempre requería 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.), por lo que algunos desarrolladores de esos servidores web optaron por no admitir la nueva versión HTTP/2 (en al menos en un futuro próximo) 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 laboral 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 utilizados lo implementaron muy rápidamente por el mismo motivo. Otra razón que impulsó a esos desarrolladores a actuar rápidamente fue que los webmasters sintieron la presión del tráfico web en constante aumento y realmente querían instalar y probar, tan pronto como fuera posible, algo que pudiera reducir drásticamente el número de conexiones TCP/IP y aumentar la velocidad. accesos a 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ó en parte después de la publicación de borradores avanzados del futuro RFC sobre el protocolo HTTP/3 .
La siguiente descripción técnica debe considerarse sólo como un intento de dar algunos ejemplos muy limitados sobre algunas características que pueden implementarse 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]
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 los servidores web.
Algunas otras funciones más avanzadas y populares ( sólo una selección muy breve ) son las siguientes.
Un programa de servidor web, cuando está en ejecución, suele realizar varias tareas generales , (por ejemplo): [1]
Los programas de servidor web son capaces de: [24] [25] [26]
Una vez que se ha decodificado y verificado un mensaje de solicitud HTTP, sus valores se pueden utilizar para determinar si esa solicitud se puede satisfacer o no. Esto requiere muchos otros pasos, incluidos controles de seguridad .
Los programas de servidor web suelen realizar algún tipo de normalización de URL ( URL que se encuentra en la mayoría de los mensajes de solicitud HTTP) en orden:
El término normalización de URL se refiere al proceso de modificar y estandarizar una URL de manera consistente. Hay varios tipos de normalización que se pueden realizar, incluida la conversión del esquema y del host a minúsculas. Entre las normalizaciones más importantes se encuentra la eliminación de "." y ".." segmentos de ruta y agregar barras diagonales a un componente de ruta que no esté vacío.
"El mapeo de URL es el proceso mediante el cual se analiza una URL para determinar a qué recurso se refiere, de modo que ese recurso pueda devolverse al cliente solicitante. Este proceso se realiza con cada solicitud que se realiza a un servidor web, con algunas de las solicitudes se atienden con un archivo, como un documento HTML o una imagen gif, otras con los resultados de ejecutar 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:
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 funciones avanzadas mencionadas anteriormente, es posible que la parte de la ruta de una URL válida no siempre coincida con una ruta del sistema de archivos existente en el árbol de directorios del sitio web (un archivo o un directorio en el sistema de archivos ) porque puede hacer referencia a un nombre virtual de un procesador de módulo interno o externo para solicitudes dinámicas.
Los programas de servidor web pueden traducir una ruta URL (toda o parte de ella), que hace referencia a una ruta del sistema de archivos físico, a una ruta absoluta en 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 rutas al sistema de archivos se realiza para los siguientes tipos de recursos web:
El servidor web agrega la ruta que se encuentra 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 suele ser /home/www/website(en máquinas Unix , normalmente es /var/www/website:). Vea los siguientes ejemplos de cómo puede resultar.
Traducción de 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:
OBTENER /ruta/archivo.html HTTP/1.1Anfitrión: www.ejemplo.comConexión: mantener vivo
El resultado es el recurso del sistema de archivos local:
/home/www/www.example.com/ruta/archivo.html
Luego, 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 aparecerá un mensaje de error que indicará que el archivo no existe o que su acceso está prohibido.
Traducción de 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:
OBTENER /directorio1/directorio2 HTTP/1.1Anfitrión: www.ejemplo.comConexión: mantener vivo
El resultado es la ruta del directorio local:
/home/www/www.example.com/directorio1/directorio2/
Luego, el servidor web verifica 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 solicitud a un módulo interno o a un programa dedicado. a listados de directorios y finalmente lee la salida de datos y envía una respuesta al navegador web del cliente. La respuesta describirá el contenido del directorio (lista de subdirectorios y archivos contenidos) o aparecerá un mensaje de error diciendo que el directorio no existe o su acceso está prohibido.
Traducción de 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 resultados:
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.ejemplo.comConexión: mantener vivo
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 desde el 15 de octubre de 2021). Además de esto, el servidor web lee los datos enviados desde el programa externo y los reenvía al cliente que realizó la solicitud.
Una vez que una solicitud ha sido leída, interpretada y verificada, debe gestionarse según 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: [28]
OPTIONS) que puede satisfacerse mediante el código general del servidor web, entonces se envía una respuesta exitosa;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) que de un archivo existente en el directorio raíz de un sitio web y el archivo tiene atributos que coinciden con los requeridos por las reglas internas del programa del servidor web. [28]
Ese tipo de contenido se llama estático porque generalmente el servidor web no lo cambia cuando se envía a los clientes y porque permanece igual hasta que algún programa lo modifica (modificación de archivo).
NOTA: cuando solo se sirve contenido estático , un programa de servidor web generalmente no cambia 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 solo estos métodos HTTP :
OPTIONSHEADGETLa respuesta del contenido de un archivo estático se puede acelerar mediante un caché de archivos .
Si un programa de servidor web recibe un mensaje de solicitud de cliente con una URL cuya ruta coincide con una de un directorio existente y ese directorio es accesible y el servidor de archivos de índice de directorio está habilitado, entonces un programa de servidor web puede intentar servir el primero de los conocidos ( o configurado) nombres de archivos de índice estáticos (un archivo normal) que se encuentran 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áticos son index.html: index.htmy Default.htm.
Si un programa de servidor web recibe un mensaje de solicitud de cliente con una URL cuya ruta coincide con el nombre de archivo de un archivo existente y el programa de servidor web puede acceder a ese archivo 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 servidor web están preconfigurados para servir sólo archivos normales o para evitar el uso de tipos de archivos especiales como archivos de dispositivo , junto con enlaces simbólicos o físicos a ellos. El objetivo es evitar efectos secundarios indeseables al ofrecer recursos web estáticos. [30]
Si un programa de servidor web es capaz de servir contenido dinámico y ha sido configurado para hacerlo, entonces puede comunicarse con el módulo interno o programa externo adecuado (asociado con la ruta URL solicitada) para pasarle parámetros de solicitud de cliente; después de eso, el programa del 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. [ cita necesaria ]
NOTA: cuando se sirve contenido estático y dinámico , un programa de servidor web generalmente debe admitir también 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 pueden enviar grandes conjuntos de datos (por ejemplo, mucha entrada de datos o carga de archivos ) al servidor web/programas/módulos externos:
POSTPara poder comunicarse con sus módulos internos y/o programas externos, un programa de servidor web debe haber implementado una o más de las muchas interfaces de puerta de enlace disponibles (consulte también Interfaces de puerta de enlace del servidor web utilizadas para contenido dinámico).
Las tres interfaces de puerta de enlace estándar e histórica son las siguientes.
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 una ruta URL solicitada coincide con un directorio existente y su acceso está permitido y no se encuentra ningún archivo de índice estático en ese directorio, entonces aparecerá una página web (generalmente en formato HTML) que contiene la lista de archivos. y/o subdirectorios del directorio mencionado anteriormente, se genera dinámicamente (sobre la marcha). 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). ej. index.tpl, o el uso de HTML y código fuente integrado que se interpreta y ejecuta sobre la marcha, ej. index.asp, y/o apoyando el uso de programas de índice dinámico como CGI, SCGI, FCGI, ej. 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 esa generación requiere muchos más recursos del sistema operativo que enviar 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 de modificación o atributos de archivo pueden cambiar aleatoriamente o con frecuencia) tal como están, sin necesidad de proporcionar más información al usuario que los solicita . [32]
Un programa externo o un módulo interno ( unidad de procesamiento ) puede ejecutar algún tipo de función de aplicación que puede usarse para obtener datos o almacenarlos en uno o más repositorios de datos , por ejemplo: [ cita necesaria ]
Una unidad de procesamiento puede devolver cualquier tipo de contenido web, también utilizando datos recuperados de un repositorio de datos, por ejemplo: [ cita necesaria ]
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 los ajustes de configuración, generalmente se genera dinámicamente.
Los programas de servidor web pueden enviar mensajes de respuesta como respuestas a mensajes de solicitud de clientes. [24]
Se puede enviar un mensaje de respuesta de error porque un mensaje de solicitud no se pudo leer, decodificar, analizar o ejecutar correctamente. [25]
NOTA: las siguientes secciones se presentan sólo como ejemplos para ayudar a comprender qué hace, más o menos, un servidor web; Estas secciones no son de ningún modo exhaustivas ni completas.
Un programa de servidor web puede responder a un mensaje de solicitud de un cliente con muchos tipos de mensajes de error; de todos modos, estos errores se dividen principalmente en dos categorías:
Cuando el 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), normalmente ese mensaje de error se muestra en alguna ventana/mensaje del navegador. .
Un programa de servidor web puede verificar si la ruta URL solicitada: [35]
Si la función de autorización/derechos de acceso se ha implementado y habilitado y no se otorga acceso al recurso web, entonces, dependiendo de los derechos de acceso requeridos, un programa de servidor web:
Un programa de servidor web puede tener la capacidad de realizar redirecciones de URL a nuevas URL (nuevas ubicaciones), lo que consiste en responder a un mensaje de solicitud del 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 URL de la ubicación: [36]
Ejemplo 1: una ruta URL apunta a un nombre de directorio pero no tiene una barra diagonal 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]
De:
/directory1/directory2
A:
/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.
De:
/directory1/directory2/2021-10-08/
A:
/directory1/directory2/2021/10/08/
Ejemplo 3: se ha movido un conjunto completo de documentos a un nuevo sitio web y ahora es obligatorio utilizar conexiones HTTPS seguras para acceder a ellos.
De:
http://www.example.com/directory1/directory2/2021-10-08/
A:
https://docs.example.com/directory1/2021-10-08/
Los ejemplos anteriores son sólo algunos de los posibles tipos de redirecciones.
Un programa de servidor web puede responder a un mensaje de solicitud de cliente válido con un mensaje exitoso, que opcionalmente contiene datos de recursos web solicitados . [37]
Si los datos de recursos web se envían de vuelta al cliente, entonces pueden ser contenido estático o contenido dinámico dependiendo de cómo se hayan recuperado (de un archivo o de la salida de algún programa/módulo).
Para acelerar las respuestas del servidor web reduciendo los tiempos promedio de respuesta HTTP y los recursos de hardware utilizados, muchos servidores web populares implementan uno o más cachés de contenido , cada uno de ellos especializado en una categoría de contenido. [38] [39]
El contenido generalmente se almacena en caché por su origen, por ejemplo:
Históricamente, los contenidos estáticos encontrados en archivos a los que había que acceder con frecuencia, aleatoria y rápidamente se han almacenado principalmente en discos electromecánicos desde mediados de los años 1960 y 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 lo tanto, 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 relativa/ocasional lentitud de las operaciones de E/S que involucran 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 alto nivel, especialmente desde mediados de los años 1990. cuando el tráfico web 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 los años 1990, con el objetivo de proponer modelos de caché útiles que podría 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 propia caché de archivos de usuario , adaptada al uso de un servidor web y utilizando su implementación y parámetros específicos. [41] [42] [43]
La amplia adopción de RAID y/o unidades rápidas de estado sólido (hardware de almacenamiento con muy alta velocidad de E/S) ha reducido ligeramente, pero por supuesto no eliminado, la ventaja de tener un caché de archivos incorporado en un servidor web.
Es posible que el contenido dinámico, generado por un módulo interno o un programa externo, no siempre cambie con mucha frecuencia (dada una URL única con claves/parámetros) y, por lo tanto, tal vez durante un tiempo (por ejemplo, de 1 segundo a varias horas o más), el resultado La salida se puede almacenar 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 a las que accede una gran cantidad de clientes por minuto. hora; en esos casos también es útil devolver el contenido almacenado 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 las cachés de sus navegadores. [45]
De todos modos, en la mayoría de los casos, ese 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 servidor(es) web. [46] [47]
Un software de servidor web puede incorporarse al sistema operativo y ejecutarse en el espacio del kernel , o puede ejecutarse en el espacio del usuario (como otras aplicaciones normales).
Los servidores web que se ejecutan en modo kernel (generalmente llamados servidores web de espacio kernel ) pueden tener acceso directo a los recursos del kernel y por lo tanto pueden ser, en teoría, más rápidos que aquellos que se ejecutan en modo usuario; De todos modos, existen desventajas al ejecutar un servidor web en modo kernel, por ejemplo: dificultades para desarrollar ( 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 de usuario deben solicitar permiso al sistema para utilizar más memoria o más recursos de CPU . Estas solicitudes al kernel no sólo toman tiempo, sino que es posible que no siempre se cumplan porque el sistema reserva recursos para su propio uso y tiene la responsabilidad de compartir recursos de hardware con todas las demás aplicaciones en ejecución. La ejecución en modo de usuario también puede significar el uso de más copias de datos/búfer (entre el espacio de usuario y el espacio del kernel), lo que puede provocar una disminución en el 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 antes mencionadas se han superado con 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 de software de servidor web para descubrir cuál de ellos se ejecuta en modo kernel o en modo usuario (también conocido como espacio de kernel o espacio de usuario).
Para mejorar la experiencia del usuario (en el lado del cliente/navegador), un servidor web debe responder rápidamente (lo antes posible) a las solicitudes de los clientes; A menos que la respuesta del contenido esté limitada (por configuración) para algún tipo de archivos (por ejemplo, archivos grandes o enormes), el contenido de los datos devueltos también debe enviarse lo más rápido posible (alta velocidad de transferencia).
En otras palabras, un servidor web siempre debe tener una gran capacidad de respuesta , incluso bajo una gran carga de tráfico web, para mantener la espera total del usuario (suma del tiempo del navegador + tiempo de la red + tiempo de respuesta del servidor web ) para obtener una respuesta lo más baja posible .
Para el software de servidor web, las principales métricas clave de rendimiento (medidas en diferentes condiciones operativas) suelen ser al menos las siguientes (es decir): [48]
Entre las condiciones operativas, el número (1 .. n ) de conexiones de clientes simultáneas utilizadas durante una prueba es un parámetro importante porque permite correlacionar el nivel de concurrencia admitido por el servidor web con los resultados de las métricas de rendimiento probadas.
El diseño y modelo de software de servidor web específico adoptado (por ejemplo):
... 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.
Existen muchas condiciones operativas que pueden afectar el rendimiento de un servidor web; Los valores de rendimiento pueden variar dependiendo de (es decir):
El rendimiento de un servidor web normalmente se compara mediante el uso de una o más de las herramientas de prueba de carga automatizadas disponibles .
Un servidor web (instalación de programa) normalmente tiene límites de carga predefinidos para cada combinación de condiciones operativas, también porque está limitado por los recursos del sistema operativo y porque sólo puede manejar un número limitado de conexiones de clientes simultáneas (generalmente entre 2 y varias decenas de miles por cada proceso de servidor web activo, consulte también el problema C10k y el problema C10M ).
Cuando un servidor web está cerca de sus límites de carga o los supera, se sobrecarga y, por lo tanto, puede dejar de responder .
En cualquier momento los servidores web pueden verse sobrecargados debido a una o más de las siguientes causas (por ejemplo).
Los síntomas de un servidor web sobrecargado suelen ser los siguientes (p. ej.).
Para superar parcialmente los límites de carga superiores al promedio y evitar la sobrecarga, los sitios web más populares utilizan técnicas comunes como las siguientes (por ejemplo).
download.*) (ese dominio también podría ser reemplazado por una CDN ) de archivos pequeños y medianos ( static.*) y del sitio dinámico principal (tal vez donde algunos contenidos se almacenan en una base de datos backend ) ( www.*) ; La idea es poder servir eficientemente archivos grandes o enormes (más de 10 – 1000 MB) (tal vez limitando las descargas) y almacenar en caché por completo archivos pequeños y medianos, sin afectar el rendimiento del sitio dinámico bajo carga pesada, mediante el uso de diferentes configuraciones. para cada (grupo) de computadoras servidor web, por ejemplo:https://download.example.comhttps://static.example.comhttps://www.example.comAdvertencias sobre el uso de los protocolos HTTP/2 y HTTP/3
Incluso si los protocolos HTTP (2 y 3) más nuevos generalmente generan menos tráfico de red para cada solicitud/datos de 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 flujo y otros detalles de implementación); Además de esto, HTTP/2 y quizás también HTTP/3, 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 HTTP/1.1 TCP/IP puede conducir a mejores resultados/mayores velocidades de carga (su kilometraje puede variar) . [53] [54]
.svg/1280px-Usage_share_of_web_servers_(Source_Netcraft).svg.png)
_1995-2005.svg/1280px-Usage_share_of_web_servers_(Source_Netcraft)_1995-2005.svg.png)
A continuación se muestran las últimas estadísticas de la cuota de mercado de todos los sitios de los principales servidores web de Internet de Netcraft .
NOTA: (*) porcentaje redondeado a un número entero, porque sus valores decimales no se informan públicamente en la página fuente (solo su valor redondeado se informa en el gráfico).
Interfaces de puerta de enlace de servidor web estándar utilizadas para contenidos dinámicos :
Algunas otras interfaces de servidor web (servidor o lenguaje de programación específico) utilizadas para contenidos dinámicos:
{{cite web}}: CS1 maint: unfit URL (link)