Teórico: ¿Es posible/factible servir contenido estático a través de Websockets?

Question

En el mundo de la web, un navegador web realiza una nueva solicitud para cada archivo estático que tiene que recuperar, entonces; una hoja de estilo, un archivo javascript, una imagen en línea; todos inician una nueva solicitud del servidor. Aunque mi conocimiento de la web es bastante bueno, las tecnologías subyacentes, como los websockets, son algo nuevo para mí en cuanto a cómo funcionan y de qué son capaces.

Mi pregunta es bastante teórica, pero me pregunto si es posible ahora o si alguna vez sería posible servir archivos estáticos a través de un websocket? Teniendo en cuenta que los websockets son una conexión persistente del cliente (navegador web) al servidor, tiene sentido que los websockets se puedan usar para servir a algunos, si no a todos los contenidos estáticos, ya que solo sería una conexión en lugar de muchos.

Para aclarar un poco.

Me doy cuenta de que mi redacción sobre las conexiones era incorrecta, como lo señala Greg a continuación. Pero por lo que entiendo, el motivo por el que se crearon las CDN y aún se usan hoy en día es abordar el problema con navegadores y/o servidores que tienen un límite estricto en el número de descargas concurrentes, una vez que alcanzas ese límite tus solicitudes se ponen en cola y se agregan al tiempo de carga de página. Soy consciente de que también fueron creados para proporcionar solicitudes sin cookies. Así que realmente mi pregunta debería ser: "¿Se pueden usar websockets en lugar de CDN?"

BrowserScope tiene algunas métricas útiles, parece que el límite de solicitud es de aproximadamente 6 por nombre de host para la mayoría de los navegadores modernos e incluso IE8. Pero como dije, a veces las personas tienen más de 6 recursos, ¿significa esto que están en cola y ralentizando el tiempo de carga de la página donde websockets podría reducirlo a uno?

Answer 1

Es definitivamente posible, pero hay algunas razones por las que es probable que no desee utilizar esto para recursos estáticos:

• Se necesita al menos un recurso que se entrega de forma estática sobre el mecanismo estándar HTTP que significa necesita algo capaz de servir recursos estáticos de todos modos. En general, desea mantener Javascript separado de su HTML, lo que significaría otra carga estática. O puede ser complicado y poner el código de WebSocket incrustado en la página principal, pero todavía está realmente mejor.
• No puede abrir conexiones de WebSocket hasta que un script en la página comience a ejecutarse. Establecer la conexión WebSocket agrega cierta latencia inicial.
• La mayoría de los navegadores cargarán recursos estáticos no conflictivos en paralelo (algunos navegadores antiguos tienen un límite severo en el número de conexiones paralelas, pero aún tienen cierta paralelización). Puede abrir múltiples conexiones WebSocket para diferentes recursos estáticos, pero hacer esto de manera confiable y eficiente requerirá un gran esfuerzo. Los navegadores ya han resuelto la mayoría de estos problemas en busca de recursos estáticos.
• Cada conexión WebSocket es un transporte basado en mensajes de orden garantizado. En combinación con la naturaleza serializada de la ejecución de Javascript, esto significa que puede procesar un mensaje WebSocket a la vez. Puede utilizar Web Workers para poder procesar más de una conexión WebSocket en paralelo, pero la secuencia de comandos de procesamiento principal seguirá siendo serializada en esas conexiones.Ciertamente puede hacer esto eficiente, pero una vez más, este no es un problema trivial y los navegadores ya han resuelto muchos de estos problemas de carga de recursos estáticos.
• Muchos servidores web admiten recursos gziping antes de entregarlos. WebSocket todavía no tiene soporte de compresión (se está discutiendo como una extensión en el grupo de trabajo). Esto significa que si desea comprimir sus recursos a través de WebSocket tendrá que hacer esto en Javascript, lo que agregará más latencia.

Si tiene partes de su página en la que se actualizan dinámicamente utilizando recursos estáticos (por ejemplo, carga en nuevas imágenes en un juego canvas de HTML5), a continuación, WebSockets puede ser su mejor opción porque una conexión WebSocket ya establecida tendrá una baja latencia y sobrecarga para recibir actualizaciones del servidor y luego entregarlas a través de HTTP. Pero no recomendaría usar WebSockets para los recursos estáticos iniciales cuando la página se carga por primera vez.

Answer 2

Esta respuesta no se refiere realmente a su pregunta tomas web, pero puede que sea obsoleta:

La tecnología de próxima generación que se supone debe resolver el problema de la transferencia de varios activos a través de una única conexión es SPDY, que es Actualmente es candidato para HTTP 2.0. Tiene implementaciones en funcionamiento en Chrome y Firefox y ya cuenta con un soporte experimental en el lado del servidor de la talla de Google y Twitter.