SPDY es diferente de la multiplexación http a través de conexiones keep alive

HTTP 1.1 admite mantener activas las conexiones, las conexiones no se cierran hasta que se envía "Connection: close".SPDY es diferente de la multiplexación http a través de conexiones keep alive

Por lo tanto, si el navegador, en este caso, firefox tiene network.http.pipelining habilitado y network.http.pipelining.maxrequests aumentado, ¿no tiene el mismo efecto al final?

Sé que estas configuraciones están deshabilitadas porque para algunos sitios web esto podría aumentar la carga, pero creo que un simple indicador de encabezado http podría decirle al navegador que está bien usar multiplexación y este problema se puede resolver más fácilmente.

¿No sería más fácil cambiar la configuración predeterminada en los navegadores que inventar un nuevo protocolo que aumente la complejidad especialmente en los servidores http?

Fuente

2012-04-28 codeassembly

SPDY usa compresión con estado en los encabezados de solicitud y respuesta. –

¿Eso marca una gran diferencia (especialmente a la compresión normal que ya tienes en SSL)? – Thilo

http también puede usar compresión con gzip, casi todos los navegadores lo soportan, y los encabezados son generalmente demasiado pequeños para importar – codeassembly

SPDY tiene una serie de ventajas que van más allá de lo que la canalización HTTP puede ofrecer, que se describen en el SPDY whitepaper:

Con la canalización, el servidor todavía tiene que devolver la respuesta de uno en uno en el orden fueron solicitados Esto puede ser un problema si el cliente solicita un recurso que se genera dinámicamente antes que uno que es estático: el servidor no puede enviar ninguna de las respuestas estáticas "fáciles" hasta que se genere y envíe el generado dinámicamente. Con SPDY, las respuestas se pueden devolver desordenadas o en paralelo a medida que se generan, lo que reduce el tiempo total para recibir todos los recursos.
Como señaló en su pregunta, no todos los servidores pueden hacer frente a la canalización: no es solo de carga, algunos servidores en realidad se comportan incorrectamente cuando el cliente solicita la canalización. Usar un encabezado para indicar que está bien hacer un pipeline es demasiado tarde para obtener el máximo beneficio: ya está recibiendo la primera respuesta en ese momento, por lo que aunque puede usarlo en conexiones futuras, ya es demasiado tarde para este.
SPDY comprime encabezados utilizando un algoritmo que es específico para esa tarea (con estado y con conocimiento de lo que normalmente está en los encabezados HTTP); mientras que sí, SSL ya incluye compresión, simplemente comprimirlos con desinflar no es tan eficiente. La mayoría de las solicitudes HTTP no tienen cuerpos y solo una línea GET corta, por lo que los encabezados constituyen prácticamente toda la solicitud: cualquier compresión que pueda obtener es una mejora. Muchas respuestas también son pequeñas en comparación con sus encabezados.
SPDY permite a los servidores enviar respuestas adicionales sin que el cliente las solicite. Por ejemplo, un servidor puede comenzar a enviar el CSS de una página junto con el HTML original, antes de que el cliente haya tenido la oportunidad de recibir y analizar el HTML para determinar la URL de la hoja de estilo. Esto puede acelerar las cargas de página aún más al eliminar la necesidad de que el cliente realmente analice el HTML antes de solicitar otros recursos necesarios para representar la página. También es compatible con una versión de menos ancho de banda de esta característica donde puede "dar pistas" sobre qué recursos podrían ser necesarios y permitir que el cliente decida: esto permite, por ejemplo, a los clientes que no se preocupan por las imágenes no molestarse en solicítelos, pero los clientes que deseen mostrar imágenes pueden solicitar las imágenes utilizando las URL especificadas sin necesidad de esperar el código HTML.
Otras cosas también: vea la respuesta de William Chan para aún más. solamente

Fuente

2012-04-28 09:57:03 Torne

¿No está el servidor presionando la misma función que está describiendo en el n. ° 4? –

Sí, lo es. Editado :) – Torne

El número 2 no es correcto ya que la primera conexión necesita contenido (HTML) para saber lo que tiene que recibir a continuación. Durante el análisis de HTML, la canalización ya está en efecto. – Lothar

pipelining HTTP es susceptible a la cabeza de bloqueo de línea (http://en.wikipedia.org/wiki/Head-of-line_blocking) a nivel de transacción HTTP mientras que SPDY tiene la cabeza de la línea de bloqueo en el nivel de transporte, debido a su uso de multiplexación.
HTTP pipelining tiene problemas de despliegue. Consulte http://tools.ietf.org/html/draft-nottingham-http-pipeline-01, que describe una serie de soluciones y heurísticas diferentes para mitigar esto.SPDY tal como se implementó en la naturaleza no tiene este problema ya que generalmente se implementa a través de SSL (puerto 443) usando NPN (http://technotes.googlecode.com/git/nextprotoneg.html) para negociar el soporte de SPDY. SSL es clave, ya que evita que los intermediarios interfieran.
SPDY tiene compresión de encabezado. Consulte http://dev.chromium.org/spdy/spdy-whitepaper que analiza algunos resultados de referencia de los beneficios de la compresión de encabezado. Ahora, es útil tener en cuenta que el ancho de banda es cada vez menos problemático (ver http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/), pero también es útil recordar que el ancho de banda sigue siendo clave para los dispositivos móviles. Consulte https://developers.google.com/speed/articles/spdy-for-mobile que muestra qué tan beneficioso es SPDY para dispositivos móviles.
SPDY admite funciones como la inserción del servidor. Consulte http://dev.chromium.org/spdy/spdy-best-practices para conocer las formas de utilizar el servidor push para mejorar la capacidad de almacenamiento en caché del contenido y aún así reducir los recorridos de ida y vuelta.
HTTP pipelining tiene una semántica de falla mal definida. Cuando el servidor cierra la conexión, ¿cómo sabe qué solicitudes se han procesado correctamente? Esta es una de las principales razones por las que POST y otras solicitudes no idempotentes no están permitidas a través de conexiones segmentadas. SPDY proporciona semántica para cancelar secuencias individuales en la misma conexión, y también tiene un marco GOAWAY que indica la última secuencia que se procesará con éxito.
HTTP pipelining tiene dificultades, a menudo debido a intermediarios, al permitir tuberías profundas. Esto (además de muchas otras razones, como el bloqueo HoL) significa que todavía necesita utilizar múltiples conexiones TCP para lograr la paralelización máxima. El uso de conexiones TCP múltiples significa que la información de control de congestión no se puede compartir, que los contextos de compresión no se pueden compartir (como SPDY con los encabezados), es peor para Internet (más costoso para intermediarios y servidores).