HTTP/2 y HTTP/3 sobre QUIC en WPO

Vamos a empezar por el principio antes de hablar de HTTP/2 y HTTP/3.

Los inicios de Internet se hicieron con HTTP 0.9 y, dado que se empezó muy despacio, vamos a considerar la versión 1.0 como el inicio del protocolo HTTP.

En el año 1996 aparece el RFC 1945. Por lo tanto, HTTP/1.0 se utiliza durante poco tiempo porque en 1999 se actualiza con la RFC 2616, es decir, HTTP/1.1. Desde ese momento, HTTP/1.1 es el protocolo que acompaña al crecimiento de Internet desde el año 2000 hasta el 2015.

Desde 1999 hasta 2015, el protocolo HT , TP/1.1 se va quedando obsoleto y no se actualiza. Sin embargo, en 2015 aparece HTTP/2.0 con importantes actualizaciones en todos los sentidos.

Ahora parece que se han venido arriba con las actualizaciones, ya que en 2018/2019 empieza a sonar HTTP/3.0 y algunos navegadores web empiezan a implementarlo en sus versiones beta.

Este esquema que está en Wikipedia es lo que mejor define la evolución del protocolo HTTP y las versiones a lo largo de los años:

En este post, vamos a hablar de HTTP/2 y HTTP/3 y de las mejoras que han aportado estas actualizaciones del protocolo HTTP al WPO actual.

HTTP/2

El primer borrador de HTTP/2, donde ya se podían ver las actualizaciones, se publicó en el año 2012. No obstante, los navegadores no empezaron a implementarlo hasta 2015.

HTTP/2 llegó en un momento clave en el que se buscaba más velocidad al servir contenidos. El protocolo SPDY estaba desarrollado, pero no había demasiada aceptación y el objetivo era reducir la latencia en las comunicaciones.

En 2012, el IETF inició el proyecto HTTP/2 utilizando como base SPDY. Cuando se empieza a implementar HTTP/2, se abandona el proyecto SPDY ya que no tiene ningún sentido.

Aunque para notar cierta mejoría a nivel WPO en la carga de una web deben darse una serie de circunstancias, la verdad es que en teoría HTTP/2 mejora bastante en temas de WPO en comparación con su antecesor, HTTP/1.1.

En entornos donde se cargan muchas imágenes pequeñas en una página, HTTP/2 va a mejorar mucho los tiempos de carga,por ejemplo.

Esto puedes verlo en una de las muchas demostraciones que han ido surgiendo por Internet, como esta: http://www.http2demo.io/

A nivel práctico hay otra cosa interesante en HTTP/2 que no tiene nada que ver con el WPO: desde que se extendió el protocolo HTTP/2, todas las webs cargan con HTTPS. Esto se debe a que es un requisito de HTTP/2.

En la práctica la cosa cambia un poco, aunque las mejoras están ahí:

Multiplexación: En HTTP/1.1 se abría una conexión TCP para cada elemento que debía cargarse en la web. Ahora con HTTP/2 se abre una única conexión TCP y se envía a través de esa conexión todo lo que sea necesario, sin tener que estar abriendo y cerrando conexiones. Esto hace que el Domain Sharding como técnica WPO quede completamente obsoleto.

Server Push: En HTTP/1.1 se iban realizando las peticiones a los recursos como imágenes, CSS, JS, etc. según se iban “leyendo” en el HTML de la página. Sin embargo, en HTTP/2 el servidor web puede enviar ciertos recursos incluso antes de leer el contenido del HTML.

Compresión de cabeceras: En HTTP/2 las cabeceras se comprimen con HPACK para transmitir lo mismo en menos volumen de datos. Esto no mejora la velocidad radicalmente, pero algo influye.

Eliminación de la redundancia: En algunos casos, al hacer peticiones a través de HTTP/1.1 se enviaban los mismos datos varias veces. Con HTTP/2 esto desaparece, es decir, se elimina la redundancia de datos y las comunicaciones son más eficientes.

HTTP/2 tiene algunos cambios más, pero no son relevantes para el WPO. Aunque algunas mejoras, como el control de flujo, resultan bastante interesantes al aplicarlas a entornos reales.

Actualmente, la mayoría de navegadores web en sus versiones actuales son compatibles con HTTP/2. Sin embargo, en versiones antiguas aún podemos encontrar navegadores que no son compatibles. En este enlace puedes consultar la tabla de compatibilidad: https://caniuse.com/#search=http2

En cuanto a los servidores web, creo que actualmente el 99,99% de los servidores web que están en producción ya tienen HTTP/2 implementado.

HTTP3 (o HTTP/2 sobre QUIC)

Como dice el título de este apartado, el protocolo HTTP/3 es simplemente HTTP/2 sobre QUIC, aunque también se eliminan algunas funcionalidades de HTTP/2 que ya son implementadas por QUIC.

¿Tan bueno es QUIC que al añadirlo al HTTP/2 creamos un nuevo protocolo?

Pues… en un análisis que publicó Google en su blog de Google Cloud Platform dicen que la velocidad de carga de los sitios web mejorará una media de un 10% con la implementación de QUIC.

La mejor forma de explicar QUIC es el gráfico que Google tiene en este artículo precisamente:

Con QUIC se sacrifica el sistema de ACK (verificación de datos) de TCP a cambio de la velocidad de transmisión de UDP. QUIC gestiona las conexiones y se encarga de que, aunque exista pérdida de datos, se pueda reconstruir todo del otro lado. Actualmente, los vídeos y el audio en streaming ya se transmitían por UDP en lugar de TCP, ya que UDP es más rápido en la transmisión de datos.

Estas son algunas de las ventajas que encontramos en QUIC de cara al WPO:

Multiplexación: Esto ya estaba en HTTP/2, aunque en HTTP/3 la cosa cambia, ya que la multiplexación la realiza QUIC y no el protocolo HTTP/2.

Sin ACK: QUIC no espera una corrección de datos cuando se pierden paquetes. Esto hace que, al no tener ACK, la transmisión se realice sin esperas y mucho más rápidamente (como en UDP).

Control de la congestión: QUIC puede gestionar mejor las conexiones en caso de congestiones de red.

Además, otra de las ventajas de QUIC es que las conexiones pueden sobrevivir a cambios de dirección IP, ya que se identifican mediante un ID único. Esto puede “facilitar” el balanceo de datos entre varias conexiones.

En el momento de escribir este artículo aún no ha salido la versión final del protocolo. Sigue siendo un borrador sin RFC, aunque la mayoría de los navegadores web son compatibles con HTTP/3 y existen servidores web como LiteSpeed (servidor web que usamos en Raiola Networks) y servicios como CloudFlare que ya son compatibles.

También quiero aclarar que QUIC está orientado a conexiones congestionadas o muy «lentas» donde exista pérdida de paquetes. Por ejemplo, las conexiones móviles 3G inestables y similares. En estos entornos se aprovechan las características de QUIC.

HTTP/2 en la práctica (WordPress)

Algunas características del HTTP/2 son nativas y funcionan en el servidor web sin que nosotros tengamos que hacer nada, siempre y cuando el servidor web y el navegador web sean totalmente compatibles.

Sin embargo, otras como el Server Push deben configurarse, es decir, el sitio web debe dar órdenes al servidor web para enviar recursos antes que el HTML. Por ejemplo, LiteSpeed Cache (el plugin de cache de LiteSpeed Web Server) integra la posibilidad de configurar Server Push desde hace bastante tiempo, ya que LiteSpeed es compatible totalmente:

Si queremos hacer server push sin LiteSpeed Cache, podemos usar plugins gratuitos como Better Resource Hints o HTTP/2 Push. Ambos también permiten configurar una buena estrategia de Resource Hints.

Además, con HTTP/2 y HTTP/3 ya no hace falta combinar los archivos JS y CSS, al igual que el Domain Sharding, ya que pueden ser incluso contraproducentes.

HTTP/3 en la práctica

Al tratarse de HTTP/2 con el añadido de QUIC, simplemente con hacer lo mismo que para HTTP/2 bastará. No tenemos que hacer nada si el servidor y el navegador son completamente compatibles con HTTP/3.

En algunos servicios, como CloudFlare, si queremos utilizar HTTP/3 debemos activarlo desde su panel de control.

El problema es que, en el momento de escribir este artículo, no existe versión final de HTTP/3 y los cambios en los borradores que hacen continuamente no ayudan a estabilizar el asunto.