Conceptos básicos de SPDY
En cuanto a la seguridad de HTTP, podemos utilizar HTTPS para solucionarlo. Sin embargo, HTTP se lanzó hace más de diez años y algunas de sus reglas están desactualizadas. Sin embargo, las funciones de las reglas HTTP/1.1 pueden compensarse completamente mediante el desarrollo de un nuevo protocolo, ya que los navegadores web siguen el protocolo HTTP. Se han extendido por todo el mundo y no se pueden abandonar por completo. Solo podemos agregar algunas funciones nuevas sobre la base de HTTP para satisfacer las necesidades acumuladas. SPDY es uno de ellos.
SPDY (derivado de SPeeDY, pronunciado veloz) fue lanzado por Google en 2010. Su objetivo de desarrollo es resolver el cuello de botella en el rendimiento de HTTP y acortar el tiempo de carga de las páginas web.
SPDY no es un sustituto de HTTP, sino una versión mejorada del protocolo HTTP. El nuevo protocolo presenta nuevos mecanismos como multiplexar flujos de datos, priorizar solicitudes y comprimir encabezados HTTP. Google dice que con la introducción del protocolo SPDY, la velocidad de carga de las páginas web aumentó un 64% en pruebas de laboratorio.
Después de la aparición de SPDY, los sitios web o aplicaciones de muchas empresas de Internet conocidas como Baidu, Taobao y UPYUN han adoptado los protocolos de la serie SPDY porque su mejora de rendimiento es muy obvia. Los principales navegadores (Google, Firefox, Opera) ya son compatibles con SPDY y lo consideran un estándar de la industria (de hecho, este ya no es el caso y este tema se deja para discusión futura. El grupo de trabajo HTTP finalmente decidió construir HTTP). /2 en SPDY/ Sobre la base de 2.
SPDY se agrega como una sesión y exige el uso de SSL/TLS por motivos de seguridad. Obliga al uso de SSL/TLS para controlar el flujo de datos, pero aún utiliza HTTP para establecer conexiones de comunicación.
Después de una breve introducción a la historia y el desarrollo de SPDY, primero echemos un vistazo a los cuellos de botella de HTTP y la necesidad de introducir SPDY.
En primer lugar, en el HTTP/1.0 original, solo se podía enviar una solicitud HTTP a través del enlace TCP a la vez, lo que resultaba en una transmisión HTTP particularmente ineficiente.
El beneficio de HTTP/1.1 es la introducción de enlaces y canalizaciones persistentes, lo que mejora la eficiencia de la transmisión HTTP (consulte Conceptos básicos de HTTP para obtener más detalles). Un enlace persistente que satisface un enlace TCP puede enviar múltiples solicitudes HTTP, pero cada solicitud HTTP debe esperar la respuesta HTTP anterior antes de enviar una nueva solicitud HTTP. El mecanismo de canalización permite enviar múltiples solicitudes HTTP simultáneamente a través de un enlace persistente, pero las respuestas deben ser consecutivas (como se muestra a continuación).
Antes de HTTP/1.1, las solicitudes HTTP solo podían ser iniciadas por el cliente y devueltas por el servidor. Este modo evita que el servidor envíe información activamente al cliente, por lo que cierta información urgente, como las acciones, no se puede enviar al cliente de manera oportuna. Por supuesto, la gente también ha desarrollado algunas soluciones, como encuestas, encuestas largas, transmisión de medios, etc. La famosa es la tecnología Comet. Pero también tiene problemas que no son el tema central de este artículo y que se presentarán en detalle.
La primera parte de la solicitud o respuesta HTTP enviará información relevante cada vez, pero HTTP/1.1 tiene que enviar la información repetidamente antes de cada solicitud HTTP, por lo que hay una cierta pérdida de ancho de banda, y ahora Primera parte A medida que se dispone de más y más información, este problema se vuelve más grave.
HTTP/1.0 propone un campo de codificación de contenido para comprimir datos, pero el formato de compresión de datos se puede elegir arbitrariamente y no se fuerza el envío del formato comprimido.
Para abordar el problema de cuello de botella HTTP mencionado anteriormente, Google lanzó SPDY en 2010.
Se pueden procesar múltiples solicitudes HTTP a través de un único enlace TCP sin restricciones, y todas las solicitudes se procesan a través de una única conexión TCP, por lo que se mejora la eficiencia del procesamiento de TCP.
SPDY no solo puede procesar solicitudes simultáneamente sin límite, sino que también puede asignar un orden de prioridad a las solicitudes caso por caso. Esto es principalmente para resolver el problema de la respuesta lenta debido al ancho de banda insuficiente al enviar múltiples solicitudes.
Comprime los encabezados de solicitud y respuesta HTTP. Esto dará como resultado comunicaciones que generen menos paquetes y envíen menos bytes.
Admite la función del servidor que envía datos activamente al cliente. Esto permite que el servidor envíe datos directamente sin esperar una solicitud del cliente.
El servidor puede solicitar proactivamente al cliente que solicite los recursos necesarios. Debido a que el cliente puede conocer la existencia del recurso antes de que sea descubierto, puede evitar enviar solicitudes innecesarias si, por ejemplo, el recurso está almacenado en caché.
Se ha hablado mucho de las ventajas de SPDY, pero
Ahora puedes aprender sobre HTTP/2 directamente. El grupo de trabajo HTTP finalmente decidió utilizar SPDY/2 como base. para desarrollar HTTP/2 Esto es algo bueno.