El HTTP/3 está cada vez más extendido. Cloudflare ahora soporta HTTP/3, que ya es parte de Chrome Canary y será añadido a Firefox Nightly pronto. Este nuevo estándar hará que su navegación por la web sea más rápida y segura.
¿Qué es HTTP/3?
HTTP/3 es la tercera versión del Protocolo de Transferencia de Hipertexto (Hypertext Transfer Protocol), la cual es utilizada para intercambiar información en la World Wide Web. Esta versión está llamada a ser el nuevo estándar oficial de Internet.
HTTP/3 es más bien una reescritura del protocolo HTTP. En lugar de usar TCP, HTTP/3 usa el protocolo QUIC de Google. HTTP/3 fue inicialmente conocido como HTTP-over-QUIC. HTTP/3 también incluye encriptación TLS 1.3, por lo que no hay necesidad de un HTTPS separado que refuerce la seguridad del protocolo, como ocurre hoy en día.
¿Qué es Quic?
Quic (Quick UDP Internet Connections) es un protocolo que está diseñado para ser más rápido con una latencia menor que el TCP. QUIC ofrece menos gastos generales al establecer una conexión y transferencias de datos más rápidas a través de la conexión. A diferencia de TCP, un error como la perdida de un dato en el camino no hará que la conexión se detenga y espere a que se solucione el problema. QUIC seguirá transfiriendo otros datos mientras se resuelve el problema.
De hecho, QUIC fue añadido a Google Chrome en 2013. Chrome lo usa cuando se comunica con los servicios de Google y algunos otros sitios web como Facebook, y está disponible para las aplicaciones de Android. Pero QUIC no es un estándar integrado en otros navegadores web. Con HTTP/3 la tecnología también viene de forma estándar a otros navegadores.
¿Por qué HTTP/3 y QUIC son tan importantes?
Mientras que HTTP/2 nos dio multiplexación, y el poder mitigar el head-of-line-blocking, este es limitado por TCP. Usted puede utilizar una sola conexión TCP para múltiples flujos multiplexados juntos para transferir datos, pero cuando uno de estos flujos sufre de la pérdida de un paquete, toda la conexión (y todos sus flujos) son retenidos, por así decirlo, hasta que TCP haga lo suyo (retransmitir el paquete perdido).
Esto quiere decir que todos los paquetes, incluso si ya han sido transmitidos y están en espera, en el buffer del nodo destino, están siendo bloqueados hasta que el paquete perdida es retransmitido. Daniel Stenberg en su libro sobre http/3 llama a esto como un “TCP- based head of like block.” El declara que, con el 2% de pérdida de paquete, a los usuarios les irá mejor con HTTP/1, con seis conexiones para cubrir el riesgo.
QUIC no está limitado por esto. Con QUIC construyendo sobre los protocolos UDP sin conexión, el concepto de conexión no carga las limitaciones de TCP y las fallas de un flujo no tienen que influenciar al resto.
Con un enfoque en flujos UDP, QUIC logra hacer un multiplexor sin la necesidad de depender de una conexión TCP. QUIC construye su conexión en un nivel mucho mayor que TCP. Nuevos flujos dentro de las conexiones QUIC no son forzadas a esperar a que terminen las demás. Las conexiones QUIC se benefician al hacer esto con la sobrecarga de handshake de TCP, lo cual reduce la latencia.
Dicho todo esto, las nuevas tecnologías siguen avanzando a pasos agigantados y, así como las actualizaciones de Windows piden más RAM cada vez, Internet también está exigiendo mayor velocidad, lo que obliga a que desarrollos como el de HTTP/3 y Quic empiecen a surgir con mayor frecuencia.
¡Hagamos un poco de historia!
En el HTTP/1.0 se creó una nueva conexión TCP para cada intercambio request/response entre clientes y servidores, lo que significa que todos los request incurren en una penalización por latencia a medida que se completan los protocolos de enlace TCP y TLS antes de cada solicitud.
Peor aún, en vez de enviar los datos pendientes tan rápido como fuere posible mientras la conexión se había establecido, TCP impone un periodo warm-up llamado “slow start”, el que pemitía a un algoritmo de control de congestión determinar la cantidad de datos que podían estar “volando” en cualquier momento antes de que se presentara la congestión en la red y evitar inundar la red con cantidades de paquetes que no podía controlar.
Debido a que las nuevas conexiones tenían que lidiar con el proceso “slow start”, era imposible que aprovecharan el ancho de banda de la red inmediatamente.
La revisión de las especificaciones HTTP para el HTTP/1.0 intentaron resolver estos problemas introduciendo el concepto de conexiones “keep-alive” algunos años más tarde, lo que permitió a los clientes reutilizar conexiones TCP, lo que amortizaba el costo de establecer las conexiones inicialmente y los inicios lentos entre múltiples request. Pero esto no fue tan maravilloso como lo pensaron: mientras que múltiples request podían compartir la misma conexión, aún tenían que ser serializados uno a uno.
HTTP/2, por su parte, introdujo un framing binario y una multiplexing layer para mejorar la latencia sin modificar la capa de transporte. Sin embargo, debido a que la naturaleza paralela de la multiplexación de HTTP/2 no es visible para los mecanismos de recuperación de pérdidas TCP, un paquete perdido o reordenado hace que todas las transacciones activas experimenten un bloqueo independientemente de si esa transacción se vio afectada por el paquete perdido.
HTTP/2 es un estándar que, de acuerdo a W3Techs, actualmente tiene un 34% de rango de adopción y, de acuerdo a Can I Use, también es soportado por todos los navegadores modernos.
