HTTP/2 y HTTP/3 en Angie: configuración y rendimiento

HTTP/2 y HTTP/3 en Angie: Configuración técnica, trampas y rendimiento

Angie es un servidor web moderno y de alto rendimiento con soporte nativo para HTTP/2 y HTTP/3. A diferencia de Nginx, su implementación de estos protocolos incluye aceleración BPF, optimizaciones QUIC a nivel del kernel e integración con servidores upstream a través de UDP. Este artículo no se centra en la teoría, sino en los aspectos prácticos de habilitar, afinar y solucionar problemas comunes en entornos de producción, desde el bloqueo HOL hasta las vulnerabilidades de DoS en conexiones multiplexadas.

Por qué HTTP/2 y HTTP/3 requieren un enfoque especial en Angie

La principal diferencia entre los servidores tradicionales y Angie no radica solo en la presencia de características, sino en cómo están arquitectados alrededor del modelo de procesamiento. En HTTP/1.1, cada socket TCP es manejado por un proceso de trabajo separado, lo que distribuye naturalmente la carga. HTTP/2 y HTTP/3 rompen este patrón: un solo cliente establece una conexión de larga duración (una conexión QUIC o una sesión TLS con ALPN), que es procesada completamente por un único proceso de trabajo. Esto aumenta la eficiencia a bajas latencias, pero crea puntos calientes cuando el tráfico está muy concentrado. Esto es especialmente crítico para HTTP/2: si http2_max_concurrent_streams está configurado en 1024 y un cliente abre 900 streams, todo el tráfico de ese cliente pasará por un solo proceso, incluso con 8 núcleos de CPU. En HTTP/3, la situación es aún más compleja: aunque una conexión QUIC puede migrar entre interfaces, la implementación actual de Angie no redistribuye la carga entre los procesos durante la migración; mantiene la conexión vinculada al proceso original.

Además, Angie no solo habilita estos protocolos; también aplica optimizaciones a nivel del sistema que no están disponibles en Nginx. Por ejemplo, quic_bpf on activa programas eBPF para filtrar y preprocesar paquetes QUIC en el espacio del kernel, reduciendo los cambios de contexto. Y quic_gso on habilita la descarga genérica de segmentación a nivel de la pila de red, lo cual es crucial para disminuir la carga de la CPU al transmitir objetos grandes (como fragmentos de video o paquetes de WebAssembly).

Parámetros clave de HTTP/2: de la seguridad al rendimiento

Configurar HTTP/2 en Angie va más allá de simplemente establecer http2 on. Tres grupos de parámetros tienen un impacto real en la estabilidad y la seguridad:

1. Límites de streams y recursos

• http2_max_concurrent_streams no es solo un límite; es un factor en la distribución de la carga. El valor predeterminado de 128 funciona bien para aplicaciones web moderadamente dinámicas. Para gateways API con muchas conexiones de polling prolongado, se recomienda reducirlo a 64 para evitar sobrecargar un solo proceso.
• http2_max_requests establece el número máximo de solicitudes por conexión. El valor predeterminado es 1000. Configurarlo en 0 deshabilita el límite, pero eso es riesgoso: un cliente podría mantener una conexión indefinidamente, agotando el límite de worker_connections.
• http2_idle_timeout define cuánto tiempo permanece activa una conexión inactiva. El valor estándar de 3 minutos puede aumentarse a 5 minutos para clientes móviles con LTE inestable, pero no más; de lo contrario, aumenta el riesgo de ataques DoS mediante “conexiones zombi”.

2. Buffering y tamaños de chunk

• http2_chunk_size controla el tamaño de los chunks de respuesta. Un valor de 8 KB ofrece un equilibrio entre latencia y rendimiento. Para contenido multimedia (MSE/DASH), tiene sentido aumentarlo a 64 KB, aunque esto reduce la flexibilidad en la priorización.
• http2_recv_buffer_size ajusta el buffer para datos entrantes. Aumentarlo más allá de los 128 KB predeterminados rara vez mejora el rendimiento, pero sí incrementa el uso de memoria por conexión.
• http2_body_preread_size especifica cuánta data se lee antes de que el manejador comience. Esto es crucial para middleware que inspecciona cuerpos de solicitud (por ejemplo, filtrado WAF). Se recomienda configurarlo en 64 KB para APIs JSON y en 1 MB para subidas de archivos.

3. Desactivación de características heredadas

El Server Push ha sido eliminado del código base de Angie, no por un error de configuración, sino como una decisión deliberada. Cualquier intento de usar http2_push o http2_push_preload resultará en un error de análisis de configuración. Esto elimina el clásico problema de caché: los recursos de push no pueden entregarse de manera condicional y a menudo duplican datos ya almacenados en la caché del cliente.

Configuración de HTTP/3: QUIC, TLS 1.3 y preparación de la red

Habilitar HTTP/3 en Angie requiere tres niveles de preparación: bibliotecas, red y infraestructura DNS.

Bibliotecas y TLS

Un requisito obligatorio es OpenSSL ≥ 1.1.1 para HTTP/3 básico y ≥ 3.5.1 para 0-RTT. Sin embargo, la versión de OpenSSL no garantiza la compatibilidad: algunas distribuciones (por ejemplo, RHEL 9.3) usan un fork openssl-fips que no admite extensiones QUIC. Puede verificar esto con el comando:

angie -V 2>&1 | grep -i quic

Si la salida está vacía, QUIC fue deshabilitado durante la compilación.

Requisitos de red

UDP/443 debe estar abierto no solo en el firewall, sino también en todos los dispositivos intermedios: balanceadores de carga L4, sistemas de protección contra DDoS y gateways SD-WAN. QUIC utiliza paquetes de longitud variable, y muchos filtros estatales bloquean paquetes mayores de 1500 bytes sin permiso explícito. También debe deshabilitar PMTU Discovery a nivel del kernel (net.ipv4.ip_no_pmtu_disc = 1); de lo contrario, la fragmentación en el lado del cliente provocará pérdida de paquetes.

Mecanismos de anuncio

Angie admite dos formas de informar a los clientes sobre HTTP/3:

• Encabezado Alt-Svc—la opción estándar y más compatible. Aquí hay una configuración de ejemplo:

add_header Alt-Svc 'h3=":443"; ma=86400, h3-29=":443"; ma=86400';

Aquí, ma=86400 es la vida útil del anuncio en segundos. No se recomienda establecer ma=0 para “desactivarlo”; el cliente ignorará tal encabezado.

• Registros HTTPS en DNS—requiere soporte del cliente (Chrome ≥ 117, Safari ≥ 17) y una configuración adecuada de DNSSEC. El formato del registro es:

_https.example.com. IN HTTPS 1 . alpn="h3,h3-29" port=443

Ambos métodos pueden combinarse: los clientes que admiten anuncios DNS los utilizan, mientras que otros dependen de Alt-Svc.

Lo que importa

• HTTP/2 y HTTP/3 en Angie crean una única conexión por cliente, totalmente vinculada a un solo proceso de trabajo; esto requiere revisar los límites de worker_connections y events { use epoll; }.
• Server Push ha sido eliminado permanentemente de Angie; cualquier mención en la configuración causará un error de análisis.
• Para HTTP/3, el soporte de TLS 1.3 es obligatorio, pero no todas las compilaciones de OpenSSL lo incluyen; verifique con angie -V.
• Las conexiones QUIC requieren que UDP/443 esté abierto en todos los niveles de la red, incluidos los balanceadores de carga L4 y los sistemas de DDoS.
• quic_bpf on y quic_gso on son optimizaciones clave que reducen la carga de la CPU en un 15–22% al transferir >100 Mbps.

Rendimiento y monitoreo en producción

Evaluar la efectividad de HTTP/2/3 es imposible sin métricas a nivel de conexión. Angie proporciona las siguientes variables de registro internas:

• $http2—1 si la conexión usa HTTP/2, de lo contrario vacío;
• $http3—1 para HTTP/3;
• $quic_version—la versión de QUIC (por ejemplo, ff00001d);
• $bytes_sent y $request_length—permiten calcular la sobrecarga a nivel de protocolo.

Para analizar el bloqueo HOL, utilice un gráfico que muestre la relación entre request_time y http2_stream_id: un aumento brusco en el tiempo a altos IDs de stream indica retrasos en la cola. En HTTP/3, este efecto no ocurre; cada stream se procesa de forma independiente.

Al realizar pruebas de carga con wrk o hey, siempre especifique las banderas -H "Connection: keep-alive" y -H "Accept-Encoding: gzip, br"; de lo contrario, las pruebas emularán el comportamiento de HTTP/1.1. Para HTTP/3, use hey -h3 o curl --http3.

Un error común es confiar únicamente en ab (ApacheBench): no admite HTTP/2 ni HTTP/3, por lo que los resultados serán sesgados.

— Editorial Team