SPDY vs. protocolos actuales
Los servidores que implementan SPDY son compatibles con versiones anteriores (todavía pueden servir tanto HTTP como HTTPS), al igual que los navegadores (cuando el servidor no admite SPDY, simplemente recurren a otros protocolos). Esto sucede gracias a la forma en que se negocia la conexión SPDY: durante la negociación de la conexión HTTPS (esta es también la razón por la que no ve SPDY implementado para HTTP sin formato).
Entonces, si SPDY tiene éxito, se implementará gradualmente tanto en servidores como en clientes (en su mayoría navegadores). Dado que los navegadores más modernos (Firefox, Chrome, Opera) ya implementaron estos protocolos, esperaría que otros (Safari, IE) los sigan tarde o temprano. Los dispositivos móviles también lo admiten principalmente (aunque Safari móvil sigue siendo una excepción).
Valor de SPDY: no para todos
A partir de los datos que tengo, SPDY ha demostrado su valor (~ 20-70% de disminución en términos de tiempo necesario para viajes de ida y vuelta específicos al servidor en varias condiciones) y está ganando impulso. Esperaría una adopción más amplia en lugares donde los equipos de desarrollo son conscientes de la necesidad de un protocolo mejor / más rápido (por ejemplo, en casos en los que se trata de una conexión débil, como celular o a través de WiFi de mala calidad), pero que tienen ventajas de una solución madura (es decir, HTTP protocolo).
- ¿Cuáles son las mejores prácticas para diseñar e implementar protocolos de red?
- ¿Los sockets TCP ponen en cola múltiples mensajes en un búfer para leerlos uno a la vez? ¿O el búfer solo almacena el mensaje recibido más recientemente?
- ¿Por qué necesitamos ACK en TCP mientras ya tenemos ACK en Link Layer (ex CSMA / CA)?
- Cómo iniciar una red informática con CCNA
- ¿Qué es el Protocolo de Internet (IP)?
Sin embargo, es un buen lugar para mencionar que SPDY puede no ajustarse a las necesidades de todos, ya que en algunos casos es más lento que HTTP simple (debido a la capa de cifrado) y requiere algunos ajustes de la aplicación web para utilizar su poder. A lo largo de los años, los desarrolladores encontraron formas de eludir las limitaciones de servir páginas web a través de HTTP (como si estuvieran usando compresión, minificación fuerte, sprites en lugar de múltiples gráficos más pequeños, y confiaban cada vez más en el lado del cliente para realizar el procesamiento sin rapidez y conexión estable al servidor) y estos resultados ajustados pueden no beneficiarse mucho de SPDY debido a una optimización ya significativa.
Si bien SPDY tiene algunas características interesantes (como Server Push y Server Hints), su aplicación web debe ajustarse para admitirlas, y muchos frameworks / servidores aún no son capaces de permitir eso. Significa que para usarlos, a menudo debe esperar la implementación en su servidor web y marco web. Eso también puede ser un desafío cognitivo, ya que esto implica un procesamiento asincrónico (puede impulsar el contenido fuera del proceso habitual de solicitud-respuesta).
Implementación básica de SPDY – sitio web vs. API
Dado que las implementaciones del lado del servidor son en su mayoría las mismas que para HTTP / HTTPS (desde la aplicación web SPDY se parece principalmente a HTTPS), solo necesita un módulo (como mod_spdy para Apache2) para instalarlo en su servidor web, esto también debería facilitar el adopción. Dado que los navegadores lo usan principalmente, no necesita hacer mucho en el lado del cliente. Pero eso solo se aplica a los sitios web, que funcionan en los navegadores web.
Si está desarrollando algunas aplicaciones que funcionan fuera de los navegadores (como las API), esperaría que esta área específica tome más tiempo en desarrollo que solo la implementación en servidores y navegadores. Esto solo requiere algo de tiempo, hasta que las aplicaciones y scripts personalizados adapten ampliamente SPDY en el lado del cliente.
Futuro de SPDY
A largo plazo, esperaría que la mayoría de los conceptos SPDY se incluyeran en la especificación HTTP 2.0, ya que recientemente se reveló que SPDY se utilizará como base para HTTP 2.0. Dependiendo del enfoque, la próxima versión de HTTP probablemente tendrá un camino similar al de SPDY (implementación gradual en servidores y navegadores, luego aplicaciones independientes), pero esta vez respaldada por el organismo oficial de estandarización (W3C). Esto debería ayudar a convencer a los que aún no están convencidos de la implementación (como Apple) y debería dar más incentivos para finalmente pulir todas las bibliotecas que los desarrolladores podrían usar tanto para servir las respuestas como para utilizarlas en el lado del cliente (como en los dispositivos iOS).
En resumen: cuando piense en SPDY reemplazando (o más bien “extendiendo”) HTTP / HTTPS, piense más en “evolución”, menos en “revolución”.
Descargo de responsabilidad: acabo de desarrollar la biblioteca JavaScript condetect (https://github.com/tadeck/condetect) responsable de verificar, por ejemplo. si se ha accedido al sitio web actual utilizando SSL / SPDY. La biblioteca está en la fase inicial y la API seguramente cambiará (principalmente debido a varias formas en que el navegador comunica el hecho de usar SPDY). Es bastante complejo distinguir SPDY de la conexión no SPDY desde el punto de vista de las aplicaciones web, pero el código lo maneja. Esperaría que la detección de SPDY también se mejore en el futuro tanto en JavaScript como en soluciones del lado del servidor.
