¿Qué es HTTP/3?

HTTP/3 es la tercera versión del Protocolo de Transferencia de Hipertexto (HTTP) desarrollada por el IETF y se considera la sucesora de HTTP/2.
A diferencia de su predecesor, está construido sobre un protocolo diferente, QUIC.
¿Por qué tenía que existir HTTP/3 cuando HTTP/2 no se estandarizó hasta 2015?
Para entender y sondear esta pregunta adecuadamente, necesitas comprender cómo evolucionó HTTP como protocolo de Internet.

Breve historia de HTTP (HTTP/1.1, HTTP/2, HTTP/3)

La versión oficial de HTTP se finalizó e implantó en 1996.
Al año siguiente, 1997, se publicó HTTP/1.1 para resolver los problemas prácticos de implementación que tenía la primera versión y actualizar parte de las normas generales de funcionamiento.
A medida que la tecnología evolucionaba, la velocidad y el tiempo de respuesta de los sitios web y las aplicaciones a gran escala adquirieron mayor importancia, y las limitaciones de HTTP/1.1 se hicieron más evidentes.
En la práctica, HTTP/1.1 solicita un recurso cada vez a través de una conexión TCP.
Posteriormente, la solicitud de varios archivos de forma secuencial plantearía un problema de retardo.
Cuando hay un problema con la solicitud de un archivo, el resto de las solicitudes pendientes tendrían que esperar a que se resolviera el problema antes de poder iniciar su transmisión.
Dicho de otro modo, un problema con una solicitud de archivo pone en espera las solicitudes entrantes hasta que se resuelva.
Este fenómeno se denomina bloqueo de cabecera de línea(HoL).
HTTP/1.1 tiene una solución para minimizar el efecto de HoL.
Los navegadores pueden abrir varias conexiones TCP y solicitar recursos en paralelo, pero esto consume muchos recursos.
Abrir una conexión TCP requiere un apretón de manos TLS para garantizar que el cliente y el servidor existen, y establecer mecanismos de encriptación para proporcionar seguridad durante la transmisión de datos.
Este cuello de botella y otros relacionados condujeron al desarrollo de HTTP/2.
HTTP/2 se publicó 18 años después, en 2015, tras estandarizarse mediante el RFC 7540 como la siguiente versión principal de HTTP.
Esto supuso un hito para Internet en su conjunto porque esta nueva versión de HTTP esperaba resolver muchos problemas en torno a la velocidad de las aplicaciones en Internet.
HTTP/2 surgió con una solución a la velocidad de transmisión de datos mediante la multiplexación.
Conceptualmente, la multiplexación se utiliza para combinar múltiples señales de comunicación (analógicas o digitales) en una sola señal para procesarla y devolver los resultados como señales diferentes.
HTTP/2 utiliza esta técnica para solicitar múltiples recursos en una conexión TCP (ahorrando costes de recursos) y descargar las respuestas en paralelo.
Este enfoque limita el efecto HoL, pero no lo elimina.
¿Por qué?
El inconveniente de HoL en HTTP/2 procede de TCP, no de HTTP/2.
Al igual que con HTTP/1.1, un problema con la solicitud de un recurso (normalmente la pérdida de paquetes) provoca un retraso inminente en la solicitud de otros recursos.
Esto se debe a que TCP gestiona la pérdida de paquetes retransmitiendo los datos antes de procesar las solicitudes entrantes.
Técnicamente, una mejora en TCP garantizaría que HTTP/2 siguiera siendo una solución viable a los problemas de velocidad más importantes en la transmisión de datos, incluido el bloqueo HoL.
En lugar de eso, ¡Internet recibió HTTP/3!
HTTP/3, a diferencia de sus predecesores, tiene QUIC (del que hablaremos más adelante) como capa de transporte en lugar de TCP.
QUIC está construido sobre el Protocolo de Datagramas de Usuario (UDP).
Como verás más adelante en este artículo, HTTP/3 no es más que HTTP/2 sobre QUIC, la capa de transporte marca la diferencia.

¿Qué es QUIC?

QUIC (pronunciado «quick») era inicialmente un acrónimo de Quick UDP Internet Connections (Conexiones Rápidas UDP a Internet), pero más tarde se le dio el nombre de protocolo propiamente dicho.
QUIC se diseñó para mejorar el rendimiento de las aplicaciones web que actualmente utilizan TCP para la transmisión de datos.
Se diseñó para servir a Internet como TCP pero con menor latencia (el tiempo que tarda la transmisión de datos), gracias a UDP.

Principales características de QUIC.

1. Reducción de la sobrecarga durante la configuración de la conexión

   Como se ha dicho antes, las conexiones cliente/servidor realizadas mediante TCP requieren prácticos handshakes TLS de los servidores remotos, y estos handshakes están sujetos a las distancias físicas de los servidores entre sí.
   QUIC no elimina la necesidad de este apretón de manos, como afirman algunos recursos, sino que emplea una forma más compleja de apretón de manos que garantiza la seguridad de los datos transferidos.
   Cabe destacar que UDP, como protocolo subyacente de QUIC, no realiza ninguna forma de handshake antes de la transmisión.

2. Multiplexación sin bloqueo de cabecera de línea

   QUIC envía varias peticiones a un servidor como una única petición para su procesamiento, y si se produce una pérdida de paquetes, continúa la descarga de la respuesta del servidor sin esperar a la retransmisión de los datos perdidos.
   La retransmisión de paquetes perdidos se gestiona mediante flujos de conexión abiertos a nivel QUIC en futuras transmisiones.
   Esto también es un error común; que QUIC utilice UDP no significa que no compense los datos perdidos.
   Sólo los gestiona de forma diferente a TCP, lo que permite un mecanismo de transmisión de datos de mayor rendimiento con el bloqueo HoL fuera del camino.

Aunque QUIC se presenta como una solución al bloqueo HoL, los flujos de conexión adicionales en uso también pueden consumir muchos recursos cuando se producen pérdidas voluminosas de paquetes y, finalmente, el bloqueo HoL puede volver a aparecer.
Pero eso es en casos extremos.
Un beneficiario de QUIC con una conexión a Internet muy lenta seguirá disfrutando de sus ventajas.
De lo contrario, no habría mucha diferencia entre HTTP/2 y HTTP/3 para un internauta medio con una buena conexión a Internet.

Usos de UDP frente a TCP.

Una vez sentadas las bases de QUIC, ¿qué impacto directo tiene en el rendimiento de la web a través de HTTP/3?

¿Cuál es el impacto de HTTP/3 en el rendimiento web?

Uniendo los puntos, HTTP/3 es HTTP/2 sobre QUIC funcionando sobre UDP, un protocolo sin conexión que no requiere establecer una conexión para la transmisión de datos.
Esta implementación de HTTP proporciona una serie de ventajas a la web, pero como verás estas ventajas sólo pueden disfrutarse en determinados casos.

1. 0-RTT o tiempo de ida y vuelta cero y establecimiento de conexión más rápido.

   El RTT es el tiempo que tarda un viaje completo de ida y vuelta desde un cliente (por ejemplo, un navegador web) a un servidor.
   En HTTP/2, el apretón de manos TCP-TLS tiene que producirse en diferentes peticiones antes de que pueda comenzar la transmisión de datos.
   Esto lleva exactamente 3-RTT en TLS 1.2 y 2-RTT en TLS 1.3 (el más reciente).
   Contrariamente a la idea generalizada de que HTTP/3 es de dos a tres veces más rápido que HTTP/2, esto sólo es cierto a medias, ya que su validez se limita a TLS 1.2.
   HTTP/3 realiza el handshake QUIC-TLS en un solo vuelo, ahorrando como máximo un viaje de ida y vuelta más con respecto a HTTP/2.
   Técnicamente, el Round-Trip-Time cero es más bien 1-RTT que cero (para anular el concepto erróneo), pero el establecimiento de la conexión es más rápido.

2. Eliminación del bloqueo de la cabeza de línea.

   Esta función de rendimiento está pensada para que QUIC sea más rápido en redes con mucha pérdida de paquetes.
   Sin embargo, depende de muchos factores.
   Normalmente, el mejor escenario para este beneficio de HTTP/3 es para los recursos que bloquean la renderización.
   En este caso, varios flujos activos compensarán la pérdida de paquetes retransmitiendo los paquetes perdidos como nuevos al cliente, en lugar de esperarlos.

3. Seguridad.

   Como HTTP/3 está en QUIC, no hay forma posible de enviar datos sin cifrar o (más técnicamente), HTTP en texto claro.
   Esto limita las opciones de escucha de los fisgones y, de paso, proporciona una mayor seguridad a la red.

Como habrás observado, la mayor parte de las ventajas de rendimiento de HTTP/3 proceden de QUIC.
Esto también significa que la aceptación generalizada de HTTP/3 surgirá del soporte de servidor que se implementará para QUIC en un futuro próximo.

Compatibilidad del navegador web con HTTP/3

Según caniuse.com, el 75,33% de los navegadores de Internet soportan actualmente HTTP/3.
Estos navegadores incluyen Google Chrome, Mozilla Firefox y Microsoft Edge.
Es probable que hayas utilizado HTTP/3 si has visitado google.com recientemente.
Si quieres comprobar si tu navegador utiliza http3, visita https://cloudflare-quic.com.

Compatibilidad del servidor web con HTTP/3

Los servidores web, los equilibradores de carga, los cortafuegos y el resto del firmware disponible en Internet utilizan protocolos de Internet como TCP y UDP para comunicarse entre sí.
Aunque es bastante fácil configurar HTTP/3 en un navegador moderno, no ocurre lo mismo con estas middleboxes.
Como estas middleboxes existen entre el cliente y el servidor, cambiar el protocolo de red en el servidor requiere un cambio en el protocolo de red también en su extremo.
Sin embargo, si un servidor web ya utiliza HTTP/2, no sería necesario ningún cambio inmediato, porque HTTP/3 no es más que HTTP/2-sobre-QUIC.
Curiosamente, algunos servidores web ya soportan HTTP/3 (aunque la mayoría son experimentales).
Entre ellos están:

• NGINX(quic.nginx.com), con soporte experimental, ya que están trabajando para lanzar una versión oficial en un futuro próximo.
• Apache.
• Nodejs.
  Utiliza internamente la biblioteca ngtcp2.
  Planean actualizar a una bifurcación QUIC-TLS para introducir una pizca de HTTP/3 en el ecosistema.
• IIS.
  Como servidor nativo para la mayoría de las aplicaciones de Microsoft, lo más probable es que utilice la biblioteca MsQuic.
• Caddy.
  Caddy utiliza la biblioteca quicgo con soporte completo.
• Litespeed.
  Litespeed utiliza LSQUIC con soporte completo.

De todos estos servidores, sólo Litespeed y el parche NGINX de Cloudflare fueron desarrollados por personas muy implicadas en la normalización QUIC-HTTP/3.
Sin duda, estas implementaciones verán más avances en un futuro próximo que el resto.
Como se ha dicho antes, aunque hay algunos servidores que soportan HTTP/3, ése es sólo el primer paso.
Configurar HTTP/3 para el resto de tu red (equilibradores de carga, cortafuegos, etc.) es mucho más difícil.

Biblioteca compatible con HTTP/3.

Si eres desarrollador o propietario de un sitio web y quieres experimentar con HTTP/3 en código, las siguientes bibliotecas proporcionan librerías para este fin.

• JavaScript – Actualmente, la biblioteca ngtcp2 que se ejecuta internamente en Nodejs es su oportunidad con HTTP/3.
  Sin embargo, las actualizaciones de Nodejs v15 dicen que viene con soporte experimental para QUIC.
• Ir – quicgo
• Python – http3 y aioquic
• Óxido – quiche, nego y quinn
• C – nghttp3 e isquic

Cambiar a HTTP/3 para sitios WordPress.

Habilitar HTTP/3 en un sitio WP depende en gran medida de tu proveedor de alojamiento.
Lamentablemente, proveedores de alojamiento populares como Hostgator y BlueHost no admiten HTTP/3 actualmente.
NameHero, por otro lado, presume de ser compatible con HTTP/3 en producción mediante el uso de servicios de CDN en la nube QUIC que se vinculan directamente a Litespeed.
Es importante que tengas en cuenta todos los demás servicios que se estén ejecutando en tu sitio de WordPress antes de elegir migrar a HTTP/3.
Esto se debe a que configurar todos los dispositivos de tu red es mucho más difícil en la práctica.
Por supuesto, puedes optar por experimentar con un sitio de prueba.

Nota

10Web no soporta actualmente HTTP/3, pero se implementará más adelante.
Para saber cuándo se añadirá esta compatibilidad, mantente al día en nuestro blog.

Fallback para navegadores que no soportan HTTP/3.

Como habrás adivinado, o un navegador es compatible con HTTP/3 o no lo es, ya que la mayoría de los sitios y aplicaciones web no son compatibles con HTTP/3.
HTTP/2 y HTTP/1.1 siguen utilizándose en gran medida, sin advertencias de velocidad significativas para un usuario medio.
Tanto si eres propietario de un sitio como si eres desarrollador web, puedes beneficiarte al máximo de HTTP/3 teniendo en cuenta la experiencia de tu usuario medio y examinando cómo influirían en su experiencia las características de rendimiento comentadas anteriormente.
A partir de ahí, debes tener muy en cuenta el coste de los recursos y el valor que aportaría tu elección.