miji.beHTTP/3 es la versión de HTTP que adopta QUIC como capa de transporte, y se estandarizó en 2022 como RFC 9114. Los principales navegadores y CDN ya lo admiten, y una cierta proporción de las solicitudes que circulan en la práctica se intercambia por HTTP/3. Como la velocidad percibida de la redirección de una URL corta cambia según la versión de HTTP, la compatibilidad con HTTP/3 también es un aspecto a estudiar en los acortadores de URL.
Donde HTTP/3 tiene efecto en las URLs cortas es en el tiempo del handshake de la primera conexión. Hasta HTTP/2, el establecimiento de la conexión TCP y el handshake de TLS se ejecutan por separado, por lo que se necesitan varios viajes de ida y vuelta (round trips) antes de empezar a enviar datos. En HTTP/3, como QUIC integra el handshake de transporte y el criptográfico, la primera conexión se resuelve en 1 viaje de ida y vuelta, y en la reconexión a un interlocutor con el que ya se ha conectado se puede empezar a enviar datos con 0-RTT. Al hacer clic en una URL corta se producen varios viajes de ida y vuelta: la resolución DNS, el handshake de TLS, la solicitud HTTP, la ida y vuelta de la respuesta de redirección y la reconexión al destino de la redirección. Al adoptar HTTP/3 se reduce el número de viajes de ida y vuelta del handshake, por lo que baja la latencia de la primera conexión, y en las líneas móviles con mucho retraso o pérdida de paquetes puede notarse la diferencia.
El tratamiento de las respuestas 3xx básicamente no cambia en HTTP/3. La semántica de 301 (traslado permanente), 302 (traslado temporal), 307 (temporal, conserva el método) y 308 (permanente, conserva el método) es la misma que en HTTP/2. Sin embargo, si en la primera conexión el servidor devuelve la cabecera HTTP Alt-Svc o lo anuncia mediante el registro HTTPS del DNS, las conexiones siguientes pueden pasar a HTTP/3.
También existe la configuración que usa HTTP/3 en combinación con una CDN. CloudFront (desde agosto de 2022), Cloudflare y Fastly admiten HTTP/3, y si el procesamiento de la redirección se completa en la ubicación de borde, se puede responder sin ida y vuelta al origen. Si los datos de redirección de las URLs cortas se guardan en un almacén de datos que se pueda leer en los puntos del borde, como Cloudflare Workers KV, se obtiene una configuración que devuelve la respuesta en el borde sin consultar al origen.
El uso de 0-RTT tiene puntos a tener en cuenta. 0-RTT es eficaz para reducir los viajes de ida y vuelta en la reconexión, pero como conlleva el riesgo de ataques de repetición, solo se aplica a solicitudes con métodos seguros como GET. Lo estándar es no aplicarlo a solicitudes POST ni a operaciones que cambian el estado. La redirección de una URL corta es una solicitud GET, por lo que en algunos casos se puede aplicar 0-RTT. Sin embargo, como incluso los métodos seguros pueden producir efectos secundarios, la condición previa es un diseño en el que no se dupliquen cosas como el registro de los clics.
Algo que suele pasarse por alto en la operación de HTTP/3 es el problema del filtrado de UDP. Algunas LAN corporativas y cortafuegos antiguos bloquean UDP 443, y en esos entornos no se puede establecer la conexión HTTP/3 y se recurre a HTTP/2 sobre TCP. Si la decisión de recurrir a la alternativa tarda, la primera conexión puede volverse incluso más lenta. Con una configuración que comunique de antemano al cliente la compatibilidad con HTTP/3 mediante el registro HTTPS del DNS y añada persist=1 a Alt-Svc para que la información del servicio alternativo se conserve aunque cambie la red, se puede contener el retraso al recurrir a la alternativa.
La combinación de HTTP/3 y URLs cortas tiene que ver con la experiencia de usuario en móviles, la evaluación de la velocidad de página en SEO y la afinidad con las CDN. Si se acorta el tiempo total de una redirección de un solo paso, se reduce el tiempo de espera de los usuarios.