HTTP/3: un poco más de poder a la velocidad de carga.
HTTP/3: un poco más de poder a la velocidad de carga.
Vamos a explicarte qué es exactamente el HTTP/3, la nueva versión de uno de los protocolos más importantes para el funcionamiento de internet. Se trata de un protocolo que lleva ya unos años desarrollándose, y que llega ofrecer unas cargas más rápidas en todo internet gracias a algunos cambios importantes en la manera en la que se intercambian los datos en la red.
Como para entender la importancia de este cambio hay que saber un poco cómo funciona internet en general, en este artículo vamos a intentar explicártelo todo. Primero, te diremos qué es y cómo ha evolucionado el protocolo HTTP con sus diferentes versiones. Luego, te intentaremos explicar de la forma más sencilla posible qué es el HTTP/3 y los cambios que propone, y terminaremos dándote una idea de los sitios en los que ya se ha implementado.
Para entender todo esto, te vamos a explicar varios conceptos que pueden llegar a ser densos y difícil de entender para los usuarios de a pie. Por eso, como solemos hacer en MediaWeb, vamos a intentar no centrarnos tanto en los tecnicismos para intentar explicar las cosas de una manera más fácil de entender.
Qué es el HTTP
Las comunicaciones de internet funcionan a través de protocolos. Por una parte tienes el Protocolo de Internet, Internet Protocol o IP en inglés. Esto significa -en términos simples- que se le otorga a cada dispositivo que se conecta a internet una dirección con la que identificarse en la red. Nadie puede navegar por la red sin una dirección IP, y cuando escribes mediaweb.com.ve, lo que hace tu navegador es comunicarse con un servidor de nombres DNS, que le indica la IP relacionada para conectar con el servidor de la web, donde está alojado ese sitio al que estás intentando ingresar.
Y otro igualmente importante es el Protocolo de Transferencia de Hipertexto, Hypertext Transfer Protocol o HTTP en inglés. Es el protocolo que utilizan los navegadores para comunicarse con los servidores web, y el que deben seguir el resto de software perteneciente a la arquitectura de la web, como los servidores, proxies y los mencionados navegadores.
También es el que define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web para comunicarse. Además, se usa también para la transferencia de imágenes y el resto de elementos que componen una web, desde el servidor al navegador, y en las apps para comunicarse con las APIs.
De dónde vienen los elementos que ves en una página web
Este protocolo sigue el modelo de cliente-servidor. Esto quiere decir que cuando tú estableces una conexión, realizas peticiones a un servidor para que este te muestre el contenido de la página. Este contenido se mostrará en tu navegador usando el código HTML, que es el estandarizado para colocar los elementos que hay en cada web, pero para cargar estos elementos, te llegarán a través de la conexión establecida.
En esta imagen puedes ver los diferentes campos que tiene una petición de HTTP. El primero es el método que define el tipo de operación que se quiere realizar, y que suele ser un verbo como GET (obtener) o POST, o un nombre como OPTIONS o HEAD.
A la derecha viene la dirección del recurso que se ha pedido, o la URL de este recurso. A esta dirección se le quitan los elementos obvios del contexto, como el http:// inicial, el puerto o el nombre del dominio. Le acompañan la versión del protocolo HTTP, y debajo ya tienes las cabeceras opcionales que aportan información adicional a los servidores. Si se usan métodos como POST, también puede haber un cuerpo de mensaje para enviar información al servidor.
Cómo ha evolucionado el HTTP
El HTTP fue desarrollado durante años por el World Wide Web Consortium y la Internet Engineering Task Force (IETF). La primera versión fue la 0.9 lanzada en 1991, que fue mejorada con el el HTTP/1.0 lanzado en 1996, y culminada en 1999 con el lanzamiento de la versión 1.1.
Llegados a este punto, puedes entender que el Internet y las webs de 1999 no tienen nada que ver con lo que puedes encontrarte hoy en día en la red. Es por eso, que a lo largo de los años el protocolo también ha tenido que actualizarse. Al hacerlo no ha habido grandes cambios, pero sí se ha perfeccionado la manera en la que se transfieren los datos en la red.
HTTP 2 puede enviar más de un recurso en una sola conexión TCP
En 2012 se publicaron los primeros borradores de la nueva versión mejorada de HTTP, que acabó lanzándose oficialmente en mayo del 2015 con el nombre HTTP/2. Este protocolo permitió enviar más de un recurso en una sola conexión de TCP, lo que hizo que se redujese el número de peticiones para cargar una web. En pocas palabras, se aceleró la carga de las webs al permitir que la transferencia de elementos fuera más rápida.
Para la próxima versión no tendremos que esperar tanto, ya que tras años de trabajo, en 2018 se le da nombre al que será el próximo paso en la cadena evolutiva. Es el HTTP/3 que llegó en 2020 según su documentación oficial para conseguir un internet todavía más rápido que el que tenemos hasta ahora.
Qué es el HTTP/3 y qué es lo que cambia
Esta nueva versión tiene un cambio muy importante, pues será la que deje de utilizar por primera vez el protocolo TCP que hasta ahora se ha venido utilizando en el HTTP, y lo sustituirá un nuevo protocolo llamado QUIC, e inicialmente desarrollado por Jim Roskind en Google, aunque al ser un proyecto de código abierto el desarrollo ha sido conjunto por la comunidad.
El TCP es un protocolo desarrollado en los años 70 del pasado siglo, y desde entonces forma parte del protocolo IP. Es el encargado para crear conexiones entre los ordenadores, a través de las cuales se envía después el flujo de datos. Este protocolo es utilizado por otros protocolos como el HTTP, SMTP, SSH y FTP, y es el encargado de garantizar que los datos se entregan sin errores en el destino previsto, y en el mismo orden en el que fueron transmitidos.
Para realizar conexiones, este protocolo realiza una conexión de múltiples pasos entre cliente y servidor, asegurando el orden de los paquetes, con confirmaciones paquete a paquete recibido, y retransmitiendo si es necesario los paquetes perdidos. También se realizan comprobaciones de la computación por si hubiera errores. Esto quiere decir que cuando se envía un paquete de datos, el receptor y el emisor intercambian información de forma constante para asegurarse de que todo se está haciendo correctamente.
Esto hace del TCP un protocolo seguro que lleva siendo utilizado desde el principio de los tiempos (de Internet), pero también tiene un aspecto negativo. Y es que supone una carga adicional en las transmisiones por el intercambio continuo de datos, provocando cuellos de botella que hacen que una web pueda tardar en cargarse algunos segundos aunque las peticiones se realicen en milisegundos.
El sustituto para este protocolo en HTTP/3 será QUIC, siglas que significan Quick UDP Internet Connections. En castellano, significa Conexiones UDP Rápidas en Internet. Está basado en otro viejo protocolo de los años 80 llamado UDP, y que a diferencia del TCP no requiere del intercambio continuo de información entre el emisor y el receptor del paquete de información. El protocolo de transferencia ya no se encarga de la integridad de los datos, ese peso recaerá de cada aplicación que lo use.
Con UDP los paquetes se envían al receptor sin más, y el emisor no espera a que el receptor le diga si han llegado o no: los sigue enviando pase lo que pase, lo que hace que no haya garantías de que el receptor está recibiendo todos los paquetes. El protocolo se usa con frecuencia en emisiones en broadcasts e incluso en juego online, y Google ya ha integrado soporte en Chrome.
Otra de las características clave de QUIC es que está cifrado por defecto con TLS 1.3. La propia estructura de QUIC hace que plantee algún que otro quebradero de cabeza a las operadoras, ya que hace imposible tratar de estimar cosas como el RTT (Round Trip Time), un parámetro con la que las operadoras pueden analizar y evaluar la calidad y prestaciones de sus redes.
Qué supone cambiar TCP por QUIC
En esta tabla de arriba tienes una comparativa en la que ves cómo son las conexiones con el TCP normal, el TCP con el cifrado TLS para proteger la privacidad de los datos, y QUIC. La conexión se deshace de las conexiones continuas con las que emisor y receptor se aseguran de que los datos se envían y reciben correctamente, y también se elimina el intercambio de datos con el que establecer el cifrado TLS. QUIC simplemente envía los datos.
Este cambio mejorará la latencia de la conexión con menos intercambio de datos entre emisor y receptor. También tiene soporte para varias conexiones multiplexadas, lo que significa que se combinan dos o más señales para transmitirlas por un único medio de transmisión, algo que ahorra tiempo reduciendo el número de medios de transmisión, y se ahorrará tiempo enviando los datos cifrados por defecto.
Además de esto, QUIC introduce secuencias con la posibilidad de otorgar prioridades en la capa de transporte. Las secuencias QUIC se entregan de forma independiente, lo que quiere decir que en la mayoría de casos, si en una secuencia se pierde algún paquete esto no afectará a las demás. Además, si se pierde algún paquete serán las propias aplicaciones las que se encarguen de volver a solicitarlo.
¿Y por qué lanzar una nueva versión HTTP/3 en vez de adaptar HTTP/2 a QUIC? Si bien es verdad que HTTP/2 también tiene función de miltiplexación de flujo, y que algunas de sus características pueden ser asignadas a QUIC con relativa facilidad, hay partes de su código que dependen de cómo funciona el protocolo TCP.
Por ejemplo, el esquema de compresión de encabezado de HTTP/2 tiene cierta dependencia al orden en el que se intercambian solicitudes y las respuestas HTTP en una conexión. QUIC no garantiza el orden entre las diferentes secuencias, por lo que en HTTP/3 se han tenido que hacer cambios en el encabezado HTTP. También se han eliminado algunas características de HTTP/2 que QUIC es capaz de ofrecer por si mismo, por lo que se quitaron del código de HTTP/3 para simplificarlo y eliminar redundancias.
En las pruebas iniciales, el Google Cloud Platform introdujo soporte para QUIC en 2018 para la carga de determinados elementos, y comunicó que los tiempos de carga de las páginas mejoraron en un 8% a nivel global, y en hasta un 13% en regiones de latencia más altas. Todavía habrá que esperar hasta que se termine de implementar este protocolo para ver hasta qué punto llegan a mejorar las cargas de webs en términos generales.
Dónde se ha implementado ya el HTTP/3
Toda esta teoría está muy bien, ¿pero qué pasa con la práctica? ¿Dónde está ya implementado el HTTP/3? Pues tras llevar haciendo pruebas desde mediados de 2019, tanto Firefox como Chrome han implementado ya el nuevo protocolo en las versiones estables del navegador. Chrome lo tiene desde la build 79 lanzada en diciembre, y Firefox desde su build 72 de enero de 2020.
También Cloudflare ha implementado la compatibilidad de este protocolo. Y esta empresa es muy importante, porque actúa como intermediaria entre el cliente y el servidor, y son muchas las empresas que han apostado por sus servicios a nivel mundial, tanto que si Cloudflare tose, a internet le sube la fiebre. Una caída de este servicio hace que miles de webs dejen de funcionar, y por eso es importante que ya esté preparada.
También se implementa en librerías de código abierto pertenecientes a grandes empresas, y que sirven tanto para los servicios de estas empresas como para los desarrolladores que las utilicen. Entre ellas están quiche de Cloudflare, neqo de Mozilla, proxygen de Facebook, las del navegador Chromium en el que se basan Chrome, Edge y muchos otros, o lsquic de LiteSpeed.
En cualquier caso, lo que debes tener claro es que el salto al HTTP/3 no va a ser algo que vayas a notar demasiado a nivel de usuario. Las empresas de internet se están preparando para él, por lo que cuando sea lanzado oficialmente en 2020 no habrá ningún tipo de apagón, simplemente poco a poco veremos cómo algunos servicios adaptados empezarán a cargar un poco más rápido.
Entérate también sobre estos temas relacionados:
 |