Escrito por Ramón Saquete
Índice
En el año 2015 anunciábamos la publicación del estándar del protocolo HTTP/2. Solo 5 años después, ya podemos analizar la próxima implantación del protocolo HTTP/3 y el protocolo QUIC en el que se apoya. Según Google, va a mejorar el rendimiento entre un 8% y un 15%.
HTTP/2 trajo mejoras de rendimiento y la capacidad del servidor de enviar archivos no solicitados con las transferencias server push, aunque todavía es difícil encontrar servicios de hosting que permitan esto último.
Puesto que desde la definición del estándar HTTP/1.1 al HTTP/2 pasaron 15 años y desde el HTTP/2 al HTTP/3 van a pasar solo unos 5 o 6 años, no va a dar tiempo a que HTTP/2 reemplace por completo a HTTP/1.1, por lo que los más rezagados pasarán directamente a HTTP/3. Entre estos rezagados, podemos incluir a la araña de Google (Googlebot), que sigue indexando solo con HTTP/1.1 cuando debería aprovechar la velocidad de HTTP/2 si el servidor de la web rastreada lo permite.
La razón por la que debería hacer este cambio es que muchas webs han desechado la técnica de optimización domain sharding, que es contraproducente con HTTP/2 y HTTP/3, pero sí tenía sentido bajo HTTP/1.1.
En la siguiente gráfica vemos que el uso de HTTP/2 aún no ha llegado al 50%, con un crecimiento actual aproximadamente de un 10% por año:
¿Qué es QUIC?
QUIC son las siglas del protocolo Quick UDP Internet Connections y es mucho más importante que HTTP/3, ya que rompe con los cimientos de Internet al reinventar la arquitectura en capas del modelo TCP/IP, asumiendo las funciones del protocolo de la capa de transporte TCP y las funciones de la capa de seguridad TLS. Esto es un cambio radical porque desde que se inventó Internet en los 70-80, sus únicos protocolos de transporte han sido TCP y UDP.
Para que se pueda implantar QUIC sin tener que cambiar todos los dispositivos de red de Internet, este se apoya en el protocolo de transporte UDP, como su propio nombre indica, aunque esto no evita que existan problemas en la regulación de tráfico QUIC aún no resueltos y que son la principal razón de que el protocolo siga en fase experimental. Así que a pesar de utilizar UDP, muchos routers y firewalls se tendrán que adaptar a este nuevo protocolo.
¿Cómo funciona?
Visualmente, la pila de protocolos quedaría como en la siguiente imagen, en la cual hemos asignado colores a las distintas funciones de cada protocolo. Así, vemos cómo QUIC asume las siguientes funciones:
- Funciones de la capa de seguridad: garantiza que nadie modifica los datos, que nadie los vea y la identidad de la empresa que ofrece el servicio.
- Funciones de la capa de transporte TCP: detección y corrección de errores y control de la congestión.
- Funciones de transporte que se habían incluido en HTTP/2: HTTP/2 incluía las funciones de multiplexación y priorización de flujos, que son funciones de transporte. Al asumir QUIC estas funciones se quitan de HTTP/2, dando lugar a HTTP/3.
TCP es un protocolo orientado a conexión que se asegura de que los datos llegan sin errores al destino. En cambio, el protocolo UDP es un protocolo de transporte que se usa para comunicaciones rápidas, sin establecer conexión y a través del cual los datos pueden llegar con errores. Este último se usa en aplicaciones como la transmisión de vídeo, donde es más importante recibir la imagen en tiempo real a que un trozo de un fotograma falle. Pero en una web sí necesitamos datos fiables. Así que QUIC realiza las funciones que hacía TCP y que no hace UDP. Además, lo hace de forma más eficiente, consiguiendo datos fiables, seguros y a mayor velocidad. La función que realiza UDP es simplemente la de trocear la información en paquetes llamados datagramas.
QUIC, en un principio, se va a utilizar solo con el protocolo de aplicación HTTP/3, pero es probable que en el futuro otros protocolos de aplicación se apoyen en QUIC.
Puesto que en la práctica HTTP/2 está obligado a funcionar sobre TLS, no se puede usar si la web no tiene HTTPS. Lo mismo ocurre con HTTP/3 que, al estar obligado a funcionar encima de QUIC, no se puede usar en una web que no tenga HTTPS.
Con HTTP/3 y QUIC la mejora de velocidad no se va a notar tanto como de HTTP/1.1 a HTTP/2, pero va a suponer una mejora sobre todo en situaciones en las que se produzcan errores en la transmisión, como en conexiones débiles o inestables, algo muy importante teniendo en cuenta que el móvil es el medio preferido de navegación de los usuarios y que no siempre se dan las mejores condiciones de cobertura. Pero veamos en detalle las características.
Características del protocolo QUIC:
- Multiplexación y mejor manejo de los errores: al igual que HTTP/2 permitía enviar todos los archivos de la web multiplexados en una sola conexión TCP, HTTP/3 permite enviar varios archivos multiplexados sobre QUIC, con una conexión por archivo. Con HTTP/2, un error en un paquete hacía que el resto de paquetes fueran descartados hasta que el servidor retransmitía el paquete con el error. En cambio, con HTTP/3 y QUIC los paquetes se pueden seguir recibiendo, aunque alguno haya llegado con error. Este defecto que podía hacer a HTTP/2 más lento que HTTP/1.1 con una tasa de errores elevada, con HTTP/3 no ocurre.
- QUIC evita el arranque lento de TCP y controla la congestión de la red mejor: el protocolo TCP usa un algoritmo de ventana deslizante para controlar la cantidad de datos enviados y no saturar la red. Este algoritmo inicialmente va aumentando la cantidad de datos enviados poco a poco, por lo que los primeros bytes se descargan de forma más lenta. QUIC usa un algoritmo más inteligente que carece de este arranque lento.
- QUIC usa el mecanismo de prioridad de HTTP/2, permitiendo tener varios flujos con distintas prioridades.
- Menos ciclos de ida y vuelta y mayor aprovechamiento de la red, ya que al contrario que con TCP, el servidor no necesita esperar a que lleguen las confirmaciones de recepción de los paquetes por parte del cliente para que el servidor envíe los siguientes. A la hora de establecer una conexión cifrada, requiere solo un ciclo de ida y vuelta, al contrario que TCP + TLS que pueden requerir hasta 3. Además, para establecer varias conexiones, una vez establecida la primera, QUIC solo necesita un viaje de ida para ello. Al tener que hacer menos viajes los paquetes, el tiempo de latencia afectará menos, con lo que el margen de mejora al usar un CDN será menor.
- QUIC requiere menos uso de CPhttps://www.humanlevel.com/blog/seo/cdn-cuando-y-como-utilizar-uno.htmlU, lo que se traduce en un pequeño ahorro de batería en los móviles.
- QUIC permite la migración de conexiones: esto permite reutilizarlas cuando te desconectas de una red y te conectas a otra. Por ejemplo, cuando pasas de 4G a WiFi o de una WiFi a otra.
Breve historia de QUIC
QUIC empezó siendo desarrollado por Jim Roskind en Google en 2012. Inicialmente usaba una solución propietaria de cifrado y estaba pensado para funcionar solo con una versión distinta de HTTP/2 de la oficial. No obstante, al presentarse el trabajo como un borrador en 2015 a la IETF (la Internet Engineering Task Force define los estándares de Internet) y empezar a ser desarrollado por un grupo de trabajo dentro de esta, se cambió su cifrado por el que usa TLS 1.3 y teóricamente ahora admite cualquier protocolo de aplicación. Por eso, a la versión original ahora se le llama gQUIC.
Durante el desarrollo de QUIC, a la especificación se le ha llamado HTTP/2 sobre QUIC cuando en realidad no era realmente HTTP/2, sino una versión distinta del protocolo que, aparte de delegar la multiplexación a QUIC, redefine sus sintaxis, por lo que finalmente se decidió renombrar la especificación a HTTP/3, término que a veces se usa para referirse tanto al nuevo protocolo HTTP como a QUIC.
Uso actual de HTTP/3
Respecto a servicios web: lo implementa Google en Youtube, Gmail y el buscador. En Facebook se implementa solo en algunas partes.
En cuanto a servicios de hosting: los pioneros en ofrecer HTTP/3 son el CDN de CloudFlare (en fase de pruebas beta) y el hosting de SiteGround.
En los navegadores, actualmente está soportado por Chromium, Firefox, Opera y Chrome pero, al ser un protocolo experimental, no viene activado por defecto en algunos de ellos.
Para que HTTP/3 funcione es necesario que tanto el cliente como el servidor lo permitan y tengan una implementación compatible del protocolo: recordemos que esto es algo experimental y la especificación está en un estado de borrador que puede cambiar, por lo que no sería raro que se diera el caso de que algunas implementaciones cliente-servidor no sean compatibles entre sí.
¿Cómo saber si una web usa HTTP/3?
Para comprobar si una web utiliza HTTP/3, se pueden utilizar una de estas herramientas online: HTTP/3 Test o HTTP/3 Check.
También se puede comprobar desde los navegadores que ya lo soportan.
HTTP/3 se activa en Chrome desde chrome://flags/#enable-quic, en Opera desde opera://flags/#enable-quic y en Firefox escribiendo en la barra about:config, y después activando la propiedad network.http.http3.enabled. Luego reiniciamos el navegador y podremos ver en la ventana de red el protocolo HTTP/3 si el cliente y el servidor están usando la misma versión del protocolo. En la siguiente captura de Firefox podéis ver un ejemplo:
Conclusión
HTTP/3 y QUIC van a reducir el tiempo que pasamos esperando a que carguen las páginas web y, cuando esté finalmente estandarizado, será prioritario tenerlo para dar un buen rendimiento a los usuarios frente a la competencia. Pero, de momento, habrá que esperar a que se resuelvan los problemas para su implantación y a que los navegadores y servicios web implementen la versión definitiva.
Un artículo muy interesante Ramón, enhorabuena!
Gracias por la información. Habrá que esperar hasta el momento de los días que se pueda.