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.
,_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 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.
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]
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 comenzaron 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.
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 libremente disponibles , Apache HTTP Server se mantuvo como el servidor preferido (debido a su confiabilidad y sus múltiples características).
En aquellos años también había otro servidor web comercial, muy innovador y por ello notable, llamado Zeus ( ahora descontinuado ), que era conocido como uno de los servidores web más rápidos y escalables disponibles en el mercado, al menos hasta la primera década de los 2000, a pesar de su bajo porcentaje de uso.
Apache resultó ser el servidor web más utilizado desde mediados de 1996 hasta finales de 2015, cuando, tras unos años de declive, fue superado inicialmente por IIS y luego por Nginx. Posteriormente, IIS cayó a porcentajes de uso mucho más bajos que Apache (véase también cuota de mercado).
A partir de 2005-2006, Apache comenzó a mejorar su velocidad y su nivel de escalabilidad mediante la introducción de nuevas características de rendimiento (por ejemplo, MPM de eventos y nuevo caché de contenido). [16] [17] Como esas nuevas mejoras de rendimiento inicialmente fueron marcadas como experimentales, sus usuarios no las habilitaron durante mucho tiempo y, por lo tanto, Apache sufrió, aún más, la competencia de servidores comerciales y, sobre todo, de otros servidores de código abierto que, mientras tanto, ya habían logrado rendimientos muy superiores (principalmente al servir contenido estático) desde el comienzo de su desarrollo y en el momento del declive de Apache podían ofrecer también una lista suficientemente larga de características avanzadas bien probadas.
De hecho, pocos años después de iniciado el 2000, surgieron no sólo otros servidores web comerciales y altamente competitivos, como por ejemplo LiteSpeed , sino también muchos otros programas de código abierto, a menudo de excelente calidad y altísimas prestaciones, entre los que cabe destacar Hiawatha , Cherokee HTTP server , Lighttpd , Nginx y otros productos derivados/relacionados también disponibles con soporte comercial.
Entre 2007 y 2008, los navegadores web más populares aumentaron su límite predeterminado anterior de 2 conexiones persistentes por host-dominio (un límite recomendado por RFC-2616) [18] a 4, 6 u 8 conexiones persistentes por host-dominio, con el fin de acelerar la recuperación de páginas web pesadas con muchas imágenes y mitigar el problema de la escasez de conexiones persistentes dedicadas a objetos dinámicos utilizados para notificaciones bidireccionales de eventos en páginas web. [19] En un año, estos cambios, en promedio, casi triplicaron el número máximo de conexiones persistentes que los servidores web tenían que gestionar. Esta tendencia (de aumentar el número de conexiones persistentes) definitivamente dio un fuerte impulso a la adopción de proxies inversos frente a servidores web más lentos y también dio una oportunidad más a los nuevos servidores web emergentes que podían mostrar toda su velocidad y su capacidad para manejar cantidades muy altas de conexiones concurrentes sin requerir demasiados recursos de hardware (computadoras costosas con muchas CPU, RAM y discos rápidos). [20]
En 2015, los RFC publicaron una nueva versión del protocolo [HTTP/2], y como la implementación de nuevas especificaciones no era nada trivial, surgió un dilema entre los desarrolladores de servidores web menos populares (por ejemplo, con un porcentaje de uso inferior al 1%... 2%), sobre agregar o no soporte para esa nueva versión del protocolo. [21] [22]
De hecho, soportar HTTP/2 a menudo requería cambios radicales en su implementación interna debido a muchos factores (prácticamente siempre se requerían conexiones cifradas, capacidad de distinguir entre conexiones HTTP/1.x y HTTP/2 en el mismo puerto TCP, representación binaria de mensajes HTTP, prioridad de mensajes, compresión de encabezados HTTP, uso de flujos también conocidos como subconexiones TCP/IP y control de flujo relacionado, etc.) y por eso algunos desarrolladores de esos servidores web optaron por no soportar la nueva versión de HTTP/2 (al menos en el futuro cercano) también por estas razones principales: [21] [22]
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 utilizados lo implementaron muy rápidamente por la misma razón. Otra razón que impulsó a esos desarrolladores a actuar rápidamente fue que los webmasters sintieron la presión del tráfico web cada vez mayor y realmente querían instalar y probar, lo antes posible, algo que pudiera reducir drásticamente el número de conexiones TCP/IP y acelerar los accesos a los sitios web alojados. [23]
En 2020-2021, la dinámica de HTTP/2 sobre su implementación (por parte de los principales servidores web y navegadores web populares) se replicó parcialmente después de la publicación de borradores avanzados del futuro RFC sobre el protocolo HTTP/3 .
La siguiente descripción técnica general debe considerarse solo como un intento de brindar 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 incluyen 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 servidores web.
Algunas otras características más avanzadas y populares ( sólo una selección muy corta ) son las siguientes.
Un programa de servidor web, cuando se está ejecutando, generalmente realiza varias tareas generales , (por ejemplo): [1]
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 .
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.
"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.
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.
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]
OPTIONS) que puede satisfacerse mediante el código general del servidor web, 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) 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 :
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 la de un directorio existente y ese directorio es accesible y la función de servir archivos de índice de directorio está habilitada, entonces un programa de servidor web puede intentar servir el primero de los nombres de archivo de índice estático conocidos (o configurados) (un archivo normal) que se encuentre en ese directorio; si no se encuentra ningún archivo de índice o no se cumplen otras condiciones, se devuelve un mensaje de error.
Los nombres más utilizados para archivos de índice estático son: index.html, index.htmy Default.htm.
Si un programa de servidor web recibe un mensaje de solicitud de cliente con una URL cuya ruta coincide con el nombre de archivo de un archivo existente y ese archivo es accesible por el programa de servidor web y sus atributos coinciden con las reglas internas del programa de servidor web, entonces el programa de servidor web puede enviar ese archivo al cliente.
Por lo general, por razones de seguridad, la mayoría de los programas de servidores web están preconfigurados para servir solo archivos normales o para evitar el uso de tipos de archivos especiales como archivos de dispositivo , junto con enlaces simbólicos o enlaces duros a ellos. El objetivo es evitar efectos secundarios indeseables al servir recursos web estáticos. [30]
Si un programa de servidor web es capaz de servir contenido dinámico y ha sido configurado para ello, entonces es capaz de comunicarse con el módulo interno o programa externo adecuado (asociado con la ruta URL solicitada) para pasarle los parámetros de la solicitud del cliente. Después de eso, el programa de servidor web lee de él su respuesta de datos (que ha generado, a menudo sobre la marcha) y luego la reenvía al programa cliente que realizó la solicitud. [ cita requerida ]
NOTA: al servir contenido estático y dinámico , un programa de servidor web generalmente también debe soportar el siguiente método HTTP para poder recibir datos de forma segura de los clientes y así poder alojar también sitios web con formularios interactivos que puedan enviar grandes conjuntos de datos (por ejemplo, muchas entradas de datos o cargas de archivos ) al servidor web/programas externos/módulos:
POSTPara 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.
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 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 o con frecuencia) tal como están, sin necesidad de proporcionar información adicional al usuario solicitante . [32]
Un programa externo o un módulo interno ( unidad de procesamiento ) puede ejecutar algún tipo de función de aplicación que puede usarse para obtener datos de uno o más repositorios de datos o para almacenar datos en ellos, 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.
Los programas de servidor web pueden enviar mensajes de respuesta como contestaciones 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, más o menos, hace un servidor web; estas secciones no son de ninguna manera exhaustivas ni completas.
Un programa de servidor web puede responder a un mensaje de solicitud de cliente con muchos tipos de mensajes de error, de todos modos estos errores se dividen principalmente en dos categorías:
Cuando un navegador de un cliente recibe una respuesta/mensaje de error, si está relacionado con la solicitud principal del usuario (por ejemplo, una URL de un recurso web como una página web), generalmente ese mensaje de error se muestra en alguna ventana/mensaje del navegador.
Un programa de servidor web puede verificar si la ruta URL solicitada: [35]
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:
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 URL de ubicación: [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.
Un programa de servidor web puede responder a un mensaje de solicitud de cliente válido con un mensaje exitoso, que opcionalmente contiene los datos del recurso web solicitado . [37]
Si los datos de recursos web se envían de vuelta al cliente, pueden ser contenido estático o dinámico dependiendo de cómo se hayan recuperado (de un archivo o de la salida de algún programa/módulo).
Para acelerar las respuestas del servidor web reduciendo los tiempos de respuesta HTTP promedio y los recursos de hardware utilizados, muchos servidores web populares implementan uno o más cachés de contenido , cada uno especializado en una categoría de contenido. [38] [39]
El contenido generalmente se almacena en caché según su origen, por ejemplo:
Históricamente, los contenidos estáticos que se encuentran en archivos a los que se debe acceder con frecuencia, de forma aleatoria y rápida, se han almacenado principalmente en discos electromecánicos desde mediados de los años 1960/1970; lamentablemente, las lecturas y escrituras en ese tipo de dispositivos siempre se han considerado operaciones muy lentas en comparación con la velocidad de la RAM y, por eso, desde los primeros sistemas operativos , primero se desarrollaron cachés de disco y luego también subsistemas de caché de archivos del sistema operativo para acelerar las operaciones de E/S de datos/archivos a los que se accede con frecuencia.
Incluso con la ayuda de un caché de archivos del sistema operativo, la lentitud relativa/ocasional de las operaciones de E/S que involucraban directorios y archivos almacenados en discos pronto se convirtió en un cuello de botella en el aumento del rendimiento esperado de los servidores web de nivel superior, especialmente desde mediados de los años 1990, cuando el tráfico de Internet comenzó a crecer exponencialmente junto con el aumento constante de la velocidad de las líneas de Internet/red.
El problema de cómo acelerar aún más eficientemente el servicio de archivos estáticos, aumentando así el número máximo de solicitudes/respuestas por segundo (RPS), comenzó a estudiarse/investigarse desde mediados de la década de 1990, con el objetivo de proponer modelos de caché útiles que pudieran implementarse en programas de servidor web. [40]
En la práctica, hoy en día, muchos programas de servidores web populares y de alto rendimiento incluyen su propio caché de archivos de usuario , adaptado para el uso del servidor web y que utiliza su implementación y parámetros específicos. [41] [42] [43]
La adopción generalizada de RAID y/o unidades de estado sólido rápidas (hardware de almacenamiento con una velocidad de E/S muy alta) ha reducido ligeramente, pero por supuesto no eliminado, la ventaja de tener un caché de archivos incorporado en un servidor web.
El contenido dinámico, generado por un módulo interno o un programa externo, puede no cambiar siempre con mucha frecuencia (dada una URL única con claves/parámetros) y por lo tanto, tal vez por un tiempo (por ejemplo, desde 1 segundo hasta varias horas o más), la salida resultante puede almacenarse en caché en la RAM o incluso en un disco rápido . [44]
El uso típico de un caché dinámico es cuando un sitio web tiene páginas web dinámicas sobre noticias, clima, imágenes, mapas, etc. que no cambian con frecuencia (por ejemplo, cada n minutos) y que son accedidas por una gran cantidad de clientes por minuto/hora; en esos casos es útil devolver también contenido en caché (sin llamar al módulo interno o al programa externo) porque los clientes a menudo no tienen una copia actualizada del contenido solicitado en los cachés de sus navegadores. [45]
De todos modos, en la mayoría de los casos, este tipo de cachés se implementan mediante servidores externos (por ejemplo, proxy inverso ) o almacenando la salida de datos dinámicos en computadoras separadas, administradas por aplicaciones específicas (por ejemplo, memcached ), para no competir por los recursos de hardware (CPU, RAM, discos) con el servidor o servidores web. [46] [47]
Un software de servidor web puede incorporarse al sistema operativo y ejecutarse en el espacio del kernel , o puede ejecutarse en el espacio del usuario (como otras aplicaciones normales).
Los servidores web que se ejecutan en modo kernel (generalmente llamados servidores web de espacio kernel ) pueden tener acceso directo a los recursos del kernel y, por lo tanto, pueden ser, en teoría, más rápidos que los que se ejecutan en modo usuario; de todos modos, existen desventajas en ejecutar un servidor web en modo kernel, por ejemplo: dificultades en el desarrollo ( depuración ) de software, mientras que los errores críticos en tiempo de ejecución pueden provocar problemas graves en el kernel del sistema operativo.
Los servidores web que se ejecutan en modo de usuario deben pedirle permiso al sistema para usar más memoria o más recursos de CPU . Estas solicitudes al núcleo no solo llevan tiempo, sino que también pueden no ser siempre satisfechas porque el sistema reserva recursos para su propio uso y tiene la responsabilidad de compartir los recursos de hardware con todas las demás aplicaciones que se estén ejecutando. La ejecución en modo de usuario también puede implicar el uso de más copias de búfer/datos (entre el espacio de usuario y el espacio del núcleo), lo que puede provocar una disminución del rendimiento de un servidor web en modo de usuario.
Hoy en día, casi todo el software de servidor web se ejecuta en modo de usuario (porque muchas de las pequeñas desventajas mencionadas anteriormente se han superado gracias a un hardware más rápido, nuevas versiones del sistema operativo, llamadas al sistema operativo mucho más rápidas y un nuevo software de servidor web optimizado). Consulte también la comparación del software de servidor web para descubrir cuál de ellos se ejecuta en modo kernel o en modo de usuario (también conocido como espacio kernel o espacio de usuario).
Para mejorar la experiencia del usuario (en el lado del cliente/navegador), un servidor web debe responder rápidamente (lo antes posible) a las solicitudes del cliente; a menos que la respuesta del contenido esté limitada (por configuración) para algún tipo de archivos (por ejemplo, archivos grandes o enormes), también el contenido de datos devuelto debe enviarse lo más rápido posible (alta velocidad de transferencia).
En otras palabras, un servidor web siempre debe ser muy receptivo , incluso bajo una gran carga de tráfico web, para mantener el tiempo total de espera del usuario (suma del tiempo del navegador + tiempo de red + tiempo de respuesta del servidor web ) para una respuesta lo más bajo posible .
Para el software de servidor web, las principales métricas de rendimiento clave (medidas en diferentes condiciones de funcionamiento) suelen ser al menos las siguientes (es decir): [48]
Entre las condiciones de operación, el número (1 .. n ) de conexiones de cliente simultáneas utilizadas durante una prueba es un parámetro importante porque permite correlacionar el nivel de concurrencia soportado por el servidor web con los resultados de las métricas de rendimiento probadas.
El diseño y modelo de software de servidor web específico adoptado (por ejemplo):
...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 (por ejemplo):
El rendimiento de un servidor web normalmente se evalúa mediante una o más de las herramientas de prueba de carga automatizadas disponibles .
Un servidor web (instalación de programa) normalmente tiene límites de carga predefinidos para cada combinación de condiciones de funcionamiento, también porque está limitado por los recursos del sistema operativo y porque sólo puede manejar un número limitado de conexiones de cliente simultáneas (normalmente entre 2 y varias decenas de miles para cada proceso de servidor web activo, véase también el problema C10k y el problema C10M ).
Cuando un servidor web está cerca o por encima de sus límites de carga, se sobrecarga y puede dejar de responder .
En cualquier momento los servidores web pueden sobrecargarse debido a una o más de las siguientes causas (por ejemplo).
Los síntomas de un servidor web sobrecargado suelen ser los siguientes (por ejemplo):
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).
download.*) (ese dominio también puede ser reemplazado por un CDN ) de archivos pequeños y medianos ( static.*) y del sitio dinámico principal (tal vez donde algunos contenidos se almacenan en una base de datos de backend ) ( www.*); la idea es poder servir de manera eficiente archivos grandes o enormes (más de 10 – 1000 MB) (tal vez limitando las descargas) y almacenar en caché por completo los archivos pequeños y medianos, sin afectar el rendimiento del sitio dinámico bajo una carga pesada, mediante el uso de diferentes configuraciones para cada (grupo) de computadoras del servidor web, por ejemplo:https://download.example.comhttps://static.example.comhttps://www.example.comAdvertencias 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]
.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 en Internet de Netcraft .
NOTA: (*) porcentaje redondeado a número entero, porque sus valores decimales no son reportados públicamente por la página fuente (solo se reporta su valor redondeado 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 (específicas del servidor o del lenguaje de programación ) utilizadas para contenidos dinámicos:
{{cite web}}: CS1 maint: URL no apta ( enlace )