Cuando los servidores web envían una página, ¿por qué no envían todos los CSS, JS e imágenes requeridos sin que se les solicite?

Cuando una página web contiene un solo archivo CSS y una imagen, ¿por qué los navegadores y servidores pierden tiempo con esta ruta tradicional que consume mucho tiempo?

1. el navegador envía una solicitud GET inicial para la página web y espera la respuesta del servidor.
2. el navegador envía otra solicitud GET para el archivo css y espera la respuesta del servidor.
3. el navegador envía otra solicitud GET para el archivo de imagen y espera la respuesta del servidor.

¿Cuándo podrían utilizar esta ruta corta, directa y que ahorra tiempo?

1. El navegador envía una solicitud GET para una página web.
2. Los servidores web responde con ( index.html seguido de style.css y imagen.jpg )

La respuesta corta es "Porque HTTP no fue diseñado para eso".

Tim Berners-Lee no diseñó un protocolo de red eficiente y extensible. Su único objetivo de diseño era la simplicidad. (El profesor de mi clase de redes en la universidad dijo que debería haber dejado el trabajo a los profesionales). El problema que usted describe es solo uno de los muchos problemas con el protocolo HTTP. En su forma original:

• No había una versión de protocolo, solo una solicitud de un recurso
• No hubo encabezados
• Cada solicitud requería una nueva conexión TCP
• No hubo compresión

El protocolo fue revisado posteriormente para abordar muchos de estos problemas:

• Las solicitudes fueron versionadas, ahora las solicitudes se ven como GET /foo.html HTTP/1.1
• Se agregaron encabezados para metainformación con la solicitud y la respuesta
• Se permitió reutilizar las conexiones con Connection: keep-alive
• Se introdujeron respuestas fragmentadas para permitir que las conexiones se reutilicen incluso cuando el tamaño del documento no se conoce con anticipación.
• Se agregó compresión Gzip

En este punto, HTTP se ha llevado lo más lejos posible sin romper la compatibilidad con versiones anteriores.

No es la primera persona en sugerir que una página y todos sus recursos se envíen al cliente. De hecho, Google diseñó un protocolo que puede hacerlo llamado SPDY .

Hoy, tanto Chrome como Firefox pueden usar SPDY en lugar de HTTP para los servidores que lo admiten. Desde el sitio web SPDY, sus características principales en comparación con HTTP son:

• SPDY permite al cliente y al servidor comprimir encabezados de solicitud y respuesta, lo que reduce el uso de ancho de banda cuando los encabezados similares (por ejemplo, cookies) se envían una y otra vez para múltiples solicitudes.
• SPDY permite múltiples solicitudes multiplexadas simultáneamente en una sola conexión, ahorrando viajes de ida y vuelta entre el cliente y el servidor y evitando que los recursos de baja prioridad bloqueen las solicitudes de mayor prioridad.
• SPDY permite que el servidor envíe recursos activamente al cliente que sabe que el cliente necesitará (por ejemplo, archivos JavaScript y CSS) sin esperar a que el cliente los solicite, permitiendo que el servidor haga un uso eficiente del ancho de banda no utilizado.

Si desea servir su sitio web con SPDY a los navegadores que lo admiten, puede hacerlo. Por ejemplo, Apache tiene mod_spdy .

SPDY se ha convertido en la base de HTTP versión 2 con tecnología push de servidor.

Su navegador web no conoce los recursos adicionales hasta que descarga la página web (HTML) del servidor, que contiene los enlaces a esos recursos.

Quizás se pregunte, ¿por qué el servidor no analiza su propio HTML y envía todos los recursos adicionales al navegador web durante la solicitud inicial de la página web? Esto se debe a que los recursos pueden estar distribuidos en varios servidores y es posible que el navegador web no necesite todos esos recursos, ya que algunos de ellos ya están almacenados en caché o pueden no ser compatibles.

El navegador web mantiene una memoria caché de recursos para que no tenga que descargar los mismos recursos una y otra vez desde los servidores que los alojan. Al navegar por diferentes páginas en un sitio web que usan la misma biblioteca jQuery, no desea descargar esa biblioteca cada vez, solo la primera vez.

Entonces, cuando el navegador web obtiene una página web del servidor, verifica qué recursos vinculados NO tiene en la caché, luego realiza solicitudes HTTP adicionales para esos recursos. Bastante simple, muy flexible y extensible.

Un navegador web generalmente puede realizar dos solicitudes HTTP en paralelo. Esto no es diferente a AJAX: ambos son métodos asincrónicos para cargar páginas web: carga asincrónica de archivos y carga de contenido asincrónico. Con keep-alive , podemos hacer varias solicitudes usando una conexión, y con la canalización podemos hacer varias solicitudes sin tener que esperar las respuestas. Ambas técnicas son muy rápidas porque la mayoría de los gastos generales generalmente provienen de abrir / cerrar conexiones TCP:

Un poco de historia web ...

Las páginas web comenzaron como correo electrónico de texto sin formato, con sistemas informáticos diseñados en torno a esta idea, formando una plataforma de comunicación algo libre para todos; los servidores web todavía eran propietarios en ese momento. Más tarde, se agregaron más capas a la "especificación de correo electrónico" en forma de tipos MIME adicionales, como imágenes, estilos, scripts, etc. Después de todo, MIME significa Extensión de correo de Internet multipropósito . Tarde o temprano tuvimos lo que es esencialmente comunicación de correo electrónico multimedia, servidores web estandarizados y páginas web.

HTTP requiere que los datos se transmitan en el contexto de mensajes tipo correo electrónico, aunque los datos con mayor frecuencia no son realmente correos electrónicos.

A medida que evoluciona una tecnología como esta, debe permitir a los desarrolladores incorporar progresivamente nuevas características sin romper el software existente. Por ejemplo, cuando se agrega un nuevo tipo MIME a la especificación, digamos JPEG, los servidores web y los navegadores web tardarán un tiempo en implementarlo. No solo fuerza repentinamente JPEG en la especificación y comienza a enviarlo a todos los navegadores web, sino que permite que el navegador web solicite los recursos que admite, lo que mantiene contentos a todos y la tecnología avanza. ¿Un lector de pantalla necesita todos los archivos JPEG en una página web? Probablemente no. ¿Debería verse obligado a descargar un montón de archivos Javascript si su dispositivo no es compatible con Javascript? Probablemente no. ¿Googlebot necesita descargar todos sus archivos Javascript para indexar su sitio correctamente? No.

Fuente: he desarrollado un servidor web basado en eventos como Node.js. Se llama Rapid Server .

Referencias

• Conexión persistente HTTP (mantener vivo)
• Canalización HTTP
• Conexiones HTTP / 1.1 (RFC 2616)

Otras lecturas:

• ¿Es SPDY diferente de la multiplexación http sobre mantener conexiones activas?
• Por qué HTTP / 2.0 no parece interesante

Porque no saben cuáles son esos recursos. Los activos que requiere una página web están codificados en el HTML. Solo después de que un analizador determine cuáles son esos activos, el agente de usuario puede solicitarlo.

Además, una vez que se conocen esos activos, deben servirse individualmente para que se puedan servir los encabezados adecuados (es decir, el tipo de contenido) para que el agente de usuario sepa cómo manejarlos.

Porque, en su ejemplo, el servidor web siempre enviaría CSS e imágenes independientemente de si el cliente ya las tiene, lo que desperdiciará mucho el ancho de banda (y por lo tanto la conexión será más lenta , en lugar de hacerlo más rápido, reduciendo la latencia, que presumiblemente era su intención). Tenga en cuenta que los archivos CSS, JavaScript e imágenes generalmente se envían con tiempos de caducidad muy largos por exactamente ese motivo (ya que cuando necesita cambiarlos, simplemente cambia el nombre del archivo para forzar una nueva copia que nuevamente se almacenará en caché durante mucho tiempo).

Ahora, puede intentar evitar ese desperdicio de ancho de banda diciendo " OK, pero el cliente podría indicar que ya tiene algunos de esos recursos, por lo que el servidor no lo volvería a enviar ". Algo como:

GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: "686897696a7c876b7e"
Connection: Keep-Alive

GET /style.css HTTP/1.1
Host: www.example.com
If-None-Match: "70b26618ce2c246c71"

GET /image.png HTTP/1.1
Host: www.example.com
If-None-Match: "16d5b7c2e50e571a46"

Y luego, solo los archivos que no han cambiado se envían a través de una conexión TCP (usando la canalización HTTP a través de una conexión persistente). ¿Y adivina qué? Es la forma en que ya funciona (también se puede utilizar If-Modified-Since en lugar de Si-None-Match ).

Pero si realmente desea reducir la latencia desperdiciando mucho ancho de banda (como en su solicitud original), puede hacerlo hoy usando HTTP / 1.1 estándar al diseñar su sitio web. La razón por la que la mayoría de las personas no lo hacen es porque no creen que valga la pena.

Para hacerlo, no necesita tener CSS o JavaScript en un archivo separado, puede incluirlos en el archivo HTML principal mediante el uso de <style>y <script>etiquetas (probablemente ni siquiera necesite hacerlo manualmente, su motor de plantillas probablemente pueda hacerlo automáticamente) . Incluso puede incluir imágenes en el archivo HTML utilizando URI de datos , como este:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

Por supuesto, la codificación base64 aumenta ligeramente el uso del ancho de banda, pero si no le importa el ancho de banda desperdiciado, eso no debería ser un problema.

Ahora, si realmente le importaba, incluso podría hacer que sus scripts web fueran lo suficientemente inteligentes como para obtener lo mejor de ambos mundos: a primera solicitud (el usuario no tiene una cookie), envíe todo (CSS, JavaScript, imágenes) incrustado solo en un solo HTML archivo como se describió anteriormente, agregue un enlace rel = "prefetch" para copias externas de los archivos y agregue una cookie. Si el usuario ya tiene una cookie (por ejemplo, la ha visitado antes), envíele un HTML normal con <img src="example.jpg">, <link rel="stylesheet" type="text/css" href="style.css">etc.

Entonces, en la primera visita, el navegador solicitará solo un archivo HTML y obtendrá y mostrará todo. Entonces (cuando está inactivo) precargaría CSS, JS, imágenes externas especificadas. La próxima vez que el usuario visite, el navegador solicitará y solo obtendrá recursos modificados (probablemente solo HTML nuevo).

Los datos adicionales de las imágenes CSS + JS + solo se enviarían dos veces, incluso si hace clic cientos de veces en el sitio web. Mucho mejor que cientos de veces como sugirió su solución propuesta. Y nunca (ni la primera vez ni las próximas veces) usaría más de un viaje de ida y vuelta que aumenta la latencia.

Ahora, si eso suena como demasiado trabajo, y no desea usar otro protocolo como SPDY , ya hay módulos como mod_pagespeed para Apache, que pueden hacer automáticamente algo de ese trabajo por usted (fusionando múltiples archivos CSS / JS en uno, alineando automáticamente un CSS pequeño y minimizándolos, haga pequeñas imágenes en línea de marcador de posición mientras espera que se carguen los originales, cargue imágenes diferidas, etc.) sin requerir que modifique una sola línea de su página web.

HTTP2 se basa en SPDY y hace exactamente lo que sugiere:

En un nivel alto, HTTP / 2:

• es binario, en lugar de textual
• está completamente multiplexado, en lugar de ordenado y bloqueado
• por lo tanto, puede usar una conexión para paralelismo
• usa compresión de encabezado para reducir los gastos generales
• permite a los servidores "empujar" respuestas de forma proactiva en cachés de clientes

Más información está disponible en HTTP 2 Faq

Porque no supone que estas cosas sean realmente necesarias .

El protocolo no define ningún manejo especial para ningún tipo particular de archivo o agente de usuario. No conoce la diferencia entre, digamos, un archivo HTML y una imagen PNG. Para hacer lo que está pidiendo, el servidor web tendría que identificar el tipo de archivo, analizarlo para averiguar a qué otros archivos hace referencia, y luego determinar qué otros archivos son realmente necesarios, dado lo que pretende hacer con el archivo . Hay tres grandes problemas con esto.

El primer problema es que no existe una forma estándar y sólida de identificar los tipos de archivos en el servidor . HTTP se gestiona a través del mecanismo de tipo de contenido, pero eso no ayuda al servidor, que tiene que resolver esto por sí mismo (en parte para que sepa qué poner en el tipo de contenido). Las extensiones de nombre de archivo son ampliamente compatibles, pero frágiles y fáciles de engañar, a veces con fines maliciosos. Los metadatos del sistema de archivos son menos frágiles, pero la mayoría de los sistemas no lo admiten muy bien, por lo que los servidores ni siquiera se molestan. El rastreo de contenido (como algunos navegadores y el filecomando Unix intentan hacer) puede ser robusto si está dispuesto a hacerlo costoso, pero el rastreo robusto es demasiado costoso para ser práctico en el lado del servidor, y el rastreo barato no es lo suficientemente robusto.

El segundo problema es que analizar un archivo es costoso, computacionalmente hablando . Esto se relaciona con el primero de alguna manera, ya que necesitaría analizar el archivo de muchas maneras diferentes si quisiera rastrear el contenido de manera sólida, pero también se aplica después de haber identificado el tipo de archivo, porque necesita para averiguar cuáles son las referencias. Esto no es tan malo cuando solo está haciendo unos pocos archivos a la vez, como lo hace el navegador, pero un servidor web tiene que manejar cientos o miles de solicitudes a la vez. Esto se suma, y ​​si va demasiado lejos, en realidad puede ralentizar las cosas más de lo que lo harían múltiples solicitudes. Si alguna vez ha visitado un enlace de Slashdot o sitios similares, solo para descubrir que el servidor es extremadamente lento debido al alto uso, ha visto este principio en acción.

El tercer problema es que el servidor no tiene forma de saber qué piensa hacer con el archivo . Un navegador puede necesitar que se haga referencia a los archivos en el HTML, pero puede que no, según el contexto exacto en el que se ejecute el archivo. Eso sería lo suficientemente complejo, pero hay más en la Web que solo navegadores: entre las arañas, los agregadores de feeds y los mashups de raspado de página, hay muchos tipos de agentes de usuario que no necesitan los archivos a los que se hace referencia en el HTML : solo se preocupan por el HTML en sí. Enviar estos otros archivos a dichos agentes de usuario solo desperdiciaría el ancho de banda.

La conclusión es que descubrir estas dependencias en el lado del servidor es más problemático de lo que vale . Entonces, en cambio, dejan que el cliente descubra lo que necesita.