Habilitar HTTP/3 en ASP.NET Core
HTTP/3 es la última evolución del protocolo HTTP y representa una importante mejora de cara a su versión predecesora HTTP/2. HTTP/3 es una especificación finalizada en junio del 2022, con una versión diseñada para mejorar el rendimiento, la confiabilidad y la seguridad. Las principales diferencias con la versión predecesora son las siguientes:
- El protocolo de transporte. Usa QUIC en lugar de TCP. QUIC ofrece un mejor rendimiento, menor latencia y mayor confiabilidad
- Conexiones. QUIC puede establecer conexiones muy rápido, incluso de tiempo cero para clientes recurrentes. Adicionalmente, QUIC soporta que la conexión migre si se cambia de IP (por ejemplo, cambiar de red Wi-Fi a móvil). Esto es importante para mejorar la experiencia del usuario
- Mejoras en la multiplexación y los bloqueos de cabecera con respecto a su predecesor. Por ejemplo, en TCP un retraso en el flujo podía bloquear al resto; en cambio, QUIC, al usar UDP, proporciona secuencias independientes, por lo cual la pérdida de paquetes en una no detiene al resto de secuencias.
- Cifrado por defecto con TLS 1.3; en HTTP/2 es opcional.
Situación actual de la adopción de HTTP/3
Aunque HTTP/3 es un protocolo cuya especificación estuvo lista desde 2022, su adopción ha sido progresiva. Por el lado de la plataforma, los sistemas operativos y las últimas versiones de navegadores ya lo soportan por defecto o se puede habilitar. Sin embargo, hay muchos servicios de nube como CDNs, servicios de routing y servicios para desplegar aplicaciones tipo PaaS que aún no lo soportan, y otros que lo van incluyendo en modo preview.
Por ejemplo, en Azure, App Service, Azure Container Apps, Azure Front Door y Azure API Management no lo soportan, y no se tiene un roadmap claro para cuándo tendrán soporte. Esta situación es bastante parecida en muchos servicios y plataformas de nube. Pero hay algunos que llevan la delantera, como AWS y GCP, que cuentan con balanceadores y puertas frontales que ya lo soportan para poder habilitarlo.
¿Cómo podemos implementar el uso de HTTP/3 en ASP .NET Core?
Usar HTTP/3 significa usar QUIC como protocolo de transporte; por lo tanto, se depende de una librería que agregue las capacidades de QUIC. Esta librería es msquic para Windows y libmsquic para Linux y macOS. En el SDK y Runtime de ASP .NET Core viene incluido por defecto en el caso de Windows. En el caso de Linux se debe instalar manualmente.
Este enfoque está basado en implementaciones sin contenedor, es decir, ejecución en un servidor físico o en una máquina virtual, ya sea con Windows o Linux. Por lo tanto, se tienen dos opciones:
- Habilitar HTTP/3 con Kestrel: En .NET, Kestrel es el servidor ligero que corre de caja para .NET Core. Para hacer que Kestrel use HTTP/3 bastan las siguientes líneas desde .NET 6; o incluso desde .NET 8/9 se puede manejar desde configuración.
- Habilitar HTTP/3 con IIS: El requisito en IIS es que debe ir de la mano con Windows Server 2022 o superior y habilitar el soporte de Windows para HTTP/3, ya que no viene habilitado por defecto. Aquí dejo un enlace de cómo habilitarlo. Además, se deben agregar las siguientes líneas para devolver el encabezado “alt-svc”, todo esto para ASP .NET Core alojado en IIS en modelo InProcess.
¿Qué pasa si quiero implementar HTTP/3 en contenedores o en un clúster de contenedores como Kubernetes?
Si tienes acceso y capacidad de administración del clúster y la infraestructura, esto se puede lograr mediante nginx compilado con QUIC, o con una versión comercial como nginx Plus, u optar por alternativas open source de proxy como Traefik, Envoy o Caddy.
Todo lo mencionado anteriormente es aplicable para activar HTTP/3 por el lado del servidor, ya sea en un Web o en una Web API.
¿Cómo habilitar HTTP/3 en el lado del cliente?
Para el caso de una aplicación o sitio web, casi todos los navegadores modernos ya soportan resolver y conectarse a un servidor HTTP/3; solo basta con que el servicio indique la cabecera de respuesta “alt-svc”. Por ejemplo:
Un poco diferente es cuando desde el código de backend consumimos una API que soporta HTTP/3; por ejemplo, un microservicio que consume una API externa o interna. En ese caso, el host o contenedor donde está corriendo el microservicio debe tener instalada la librería msquic/libmsquic y aplicar un código como el siguiente:
¿Cuál es el valor real de implementar HTTP/3?
Más allá de los puntos técnicos y de que es obvio que lo que se busca con HTTP/3 es mejorar los problemas que tenía HTTP/2, ¿cómo se ve reflejado esto de cara al usuario? La respuesta está en las redes inestables; un claro ejemplo de estas redes son las redes móviles. Por lo tanto, las aplicaciones móviles que implementen APIs REST y clientes que soporten HTTP/3 se verán enormemente beneficiadas.
En la siguiente imagen busco demostrar esto: se muestra un benchmark con una “simulación” de red inestable; para ello usé Clumsy, que es una herramienta open de Windows que permite “entorpecer” el tráfico para simular pérdida de paquetes al consumir un servicio. Los resultados son notorios: el cliente HTTP/3 supera en más del doble la eficiencia y los tiempos del cliente HTTP/2.
Para este benchmark, los clientes se conectaron a servicios HTTP/3 y HTTP/2 respectivamente, ambos servicios corriendo sobre una máquina virtual de Azure Windows Server 2025 habilitada para HTTP/3 en IIS.
¿Cuál es la realidad de implementar HTTP/3?
En la realidad, por la adopción progresiva de HTTP/3 y a pesar de que, a nivel de protocolo y capa de transporte, los browsers y sistemas operativos ya se puedan considerar estables, solo el 30% y un poco más de los sitios web del mundo soportan HTTP/3. Por lo tanto, a menos que controles todos los componentes de tu solución, incluyendo los dispositivos de tus usuarios, podrás garantizar el uso “total” de HTTP/3. De lo contrario, por más que lo habilites en tus APIs y sitios web, es más que probable que los consumidores no lo usen y sigan resolviendo en HTTP/2.
Repositorio de ejemplo
Dejo el repositorio del cual están basadas todas las capturas de código y el benchmark.
Repositorio HTTP/3 en dotnet :)
Conclusión
HTTP/3 es una versión del protocolo más que necesaria. A pesar de su adopción progresiva y lenta, es necesario tenerla en el mapa, para que en algún momento los usuarios se puedan ver beneficiados de esta gran mejora.
Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades