HTTP/3, nueva versión del protocolo de comunicación web

2020/09/01 Leturia Azkarate, Igor - Informatikaria eta ikertzaileaElhuyar Hizkuntza eta Teknologia Iturria: Elhuyar aldizkaria

• Internet
• Softwarea

La red de Internet está compuesta por una infraestructura física (routers, cables, emisores y receptores de ondas electromagnéticas...) y por diferentes protocolos y sistemas de comunicación (WiFi, TCP, UDP, IP, DNS...). Y los servicios constituidos sobre esta red (web, correo electrónico, SSH, FTP, etc.) también tienen sus propios protocolos. Pues bien, la web se basa principalmente en formato HTML (formato utilizado para escribir y codificar páginas web) y en el protocolo de comunicación HTTP.

Las siglas HTTP significan HyperText Transfer Protocol, es decir, protocolo de transferencia de hipertexto. Este protocolo define la comunicación entre el navegador web y un servidor web, por lo que los navegadores lo muestran al inicio de las direcciones web “http://” (o “https://” en sitios web seguros). El protocolo HTTP establece cómo el navegador debe codificar la solicitud de página al servidor (GET, POST, HEAD, PUT, DELETE u otro tipo de solicitudes, cómo se enviarán los parámetros y cookies…) y cómo responderá el servidor (una página web codificada en HTML o un error: Error 404 cuando la dirección no existe, 301 cuando la dirección se ha redirigido, 403 cuando no tenemos permiso para acceder a la página, 500 cuando se ha producido un error en el servidor, etc.).

Histórico Protocolo HTTP

El inventor de la web Sir Tim Berners-Lee creó en 1989 la web, el protocolo HTTP y el formato HTML. W3C o World Wide Web Consortium, creada por el propio Berners-Lee y que actualmente dirige, ha guiado la evolución de tres hasta fechas recientes: El formato HTML es gestionado por el grupo WHATWG desde 2019 y el protocolo HTTP está en manos de la IETF o Internet Engineering Task Force en los últimos años.

En esta primera versión sólo existían solicitudes GET y la respuesta era siempre una página web. Esta versión fue publicada como versión 0.9 del estándar en 1991. En 1996 se publicó la versión HTTP 1.0 que incorporaba al protocolo más tipos de solicitudes y respuestas y la información de cabecera. Y en 1997 se lanzó la versión HTTP 1.1, cuya principal novedad era que todos los componentes que componen una página web (página HTML, imágenes, ficheros CSS y Javascript...) podían ser descargados mediante una única conexión, a diferencia de las versiones existentes que exigían una nueva conexión para cada una de ellas.

HTTP/2, publicada en 2015. Se basaba en el protocolo experimental SPDY desarrollado por Google, sobre el que escribimos en 2013. Su novedad y ventajas consistían en utilizar una conexión única para todas las peticiones de página que se realizan a un servidor, que el servidor pueda enviar notificaciones Push al navegador y enviar los encabezados comprimidos.

Características HTTP/3

El HTTP/3 tiene una historia similar a la HTTP/2, ya que tiene detrás un protocolo experimental creado por Google en 2012, en este caso QUIC. Las siglas indican Quick UDP Internet Connections, y como se indica en ella, dos son las principales características o novedades del HTTP/3: rapidez y uso del protocolo UDP.

De hecho, versiones anteriores del HTTP usaban el protocolo TCP (Transmission Control Protocol) en la capa de transporte inferior para llevar los paquetes de datos desde el navegador al servidor y viceversa. La característica principal de este protocolo es que garantiza la fiabilidad de los datos: los paquetes de datos se envían ordenados, disponen de mecanismos para asegurar la integridad de cada uno de ellos, y tras cada paquete se espera un acuse de recibo antes de enviar el siguiente; si no se recibe el acuse de recibo, se reenvía el pack. Por tanto, es fiable, pero también es relativamente lento debido a los datos adicionales que envía y a la necesidad de esperar a los mensajes de confirmación de recepción.

Por el contrario, QUIC utiliza el protocolo UDP (User Datagram Protocol) en la capa de transporte. En UDP el remitente envía los packs y punto, da igual si han llegado al destinatario o no y si los packs se han perdido en el camino se han perdido. Al no necesitar confirmación periódica, es más rápido. En la web, sin embargo, es importante que todos los paquetes de datos lleguen bien, pensemos si en una web faltaran o se equivoquen fragmentos de texto o imágenes. Lo cierto es que cuando se creó la web la red era diferente a la actual, había más errores en las comunicaciones y por eso eran necesarios mecanismos para garantizar la fiabilidad, pero hoy en día son menos necesarios. Además, en el QUIC se pusieron varios mecanismos para pedir y reenviar las partes perdidas y evitar esos errores.

En 2015 se envió al IETF el protocolo QUIC, proponiendo su inclusión en la siguiente versión del estándar del protocolo HTTP, y tras una serie de modificaciones y mejoras, el grupo lo aceptó como propuesta del nuevo estándar en 2018: Llamaron HTTP/3.

A pesar de que el objetivo y el principal logro del HTTP/3 es el aumento de la velocidad de las comunicaciones web, por todo lo dicho es evidente que no se trata sólo de una sencilla mejora técnica: desde su creación y tras basarse en el protocolo de transporte TCP durante casi 30 años, el protocolo HTTP, base de la web, ha pasado a utilizar UDP.

Implementación y difusión

Siendo su creador, Google lleva años usando QUIC para comunicaciones entre su navegador Chrome y algunos de sus servicios (Gmail, Drive, Youtube...). El propio Chrome y otros navegadores (Firefox, Safari, Edge...) han empezado a implementar HTTP/3 este año, pero de momento no viene por defecto, quien quiera usarlo o probar tiene que cambiar los ajustes manualmente. Pero seguro que, en breve, todos utilizarán el HTTP/3 por defecto.

No obstante, para poder utilizar HTTP/3 es necesario que también se coloque en los servidores web. A la vista de que mejora la velocidad, los principales servicios web y redes sociales probablemente lo pondrán en breve. En otras webs, como viene siendo habitual, necesitará algo más de tiempo.

En cualquier caso, el cambio vendrá. Además, para los usuarios será inconsciente de que sólo notaremos que se mejorará la velocidad de la web (o quizás también porque el peso de las webs es cada vez mayor). Pero son importantes este tipo de mejoras para que la web no pierda competitividad y, por tanto, su influencia y presencia frente a apps que utilizan otros protocolos no estándar y ocultos.