atareao con Linux
15

HTTP/3 y rendimiento

Vistas: 0
Tutorial: Traefik, mucho mas que un proxy inverso
atareaoComenta
HTTP/3 y rendimiento

Llegamos al último capítulo de este tutorial sobre Traefik v3. Han sido quince capítulos desde la instalación básica, pasando por entrypoints, routers, middlewares, autenticación, TLS con Let’s Encrypt, el dashboard, servicios con balanceo, configuración dinámica, plugins, protocolos TCP y UDP, seguridad con hardening, y monitorización con Prometheus y OpenTelemetry. Ha sido un camino largo, ¿eh? Pero no podíamos terminar sin hablar de rendimiento y de la funcionalidad estrella de Traefik v3: HTTP/3.

En este capítulo vas a ver cómo exprimir al máximo Traefik para que vuele. Te voy a contar qué es HTTP/3 por dentro, cómo activarlo, cómo medir si realmente está funcionando, y sobre todo cómo tunear cada parámetro para sacarle todo el jugo. También vamos a ver optimización de timeouts, compresión, conexiones persistentes, tuning a nivel de kernel, y un benchmark real para que veas la diferencia. Al final del capítulo, cerramos el tutorial con un resumen de todo lo que has aprendido. Dale caña, que esto es lo último.

¿Qué es HTTP/3?

HTTP/3 es la tercera versión del protocolo HTTP, y no es una simple evolución de HTTP/2. Es un cambio de base completo. HTTP/1.1 y HTTP/2 funcionan sobre TCP. HTTP/3 funciona sobre QUIC (Quick UDP Internet Connections), un protocolo de transporte desarrollado originalmente por Google en 2012, estandarizado en el RFC 9000 por la IETF en 2021.

La diferencia fundamental es que QUIC usa UDP en lugar de TCP. Y no, no es que hayan perdido el juicio. Usar UDP le da a QUIC unas ventajas que TCP, por su propio diseño, no puede ofrecer. Vamos a verlas una por una.

Cómo funciona la conexión en QUIC

En TCP, para establecer una conexión segura necesitas lo que se llama «handshake de tres vías» (SYN, SYN-ACK, ACK), y luego encima el handshake de TLS para cifrar. Eso son tres viajes de ida y vuelta (3 RTT) antes de poder enviar el primer byte de datos. En redes con latencia alta —un móvil con 100 ms de RTT— eso son 300 ms perdidos antes de que el navegador pueda pintar absolutamente nada.

QUIC hace el handshake de transporte y el de TLS 1.3 en un solo viaje. Literalmente, en 1 RTT ya tienes la conexión establecida y cifrada. ¿Y si el cliente ya se ha conectado antes al mismo servidor? Ahí QUIC ofrece 0-RTT: el cliente envía datos directamente en el primer paquete, sin esperar confirmación, porque guarda una clave de sesión del encuentro anterior. Cero rondas de espera. Esto te puede ahorrar entre 200 y 400 ms en cada reconexión, algo que en móvil o en aplicaciones con muchas peticiones cortas se nota enormemente.

Fin al bloqueo de cabeza de línea (HOL blocking)

Este es el problema más gordo de HTTP/2. HTTP/2 multiplexa varias peticiones en una sola conexión TCP. Suena bien sobre el papel, pero tiene una trampa: TCP garantiza el orden de los paquetes. Si un paquete de la petición A se pierde en la red, TCP espera a reenviarlo y recibirlo antes de entregar cualquier otro paquete, incluidos los de las peticiones B, C y D que llegaron bien. Has perdido una sola parte de un stream, pero se bloquean todos los demás. Eso es el head-of-line blocking a nivel de transporte.

QUIC soluciona esto de raíz porque cada stream es independiente. Si un paquete de una petición se pierde, QUIC solo reenvía ese paquete de esa petición concreta. El resto de los streams siguen fluyendo sin interrupción. En una página web moderna que carga decenas de recursos simultáneamente (JavaScript, CSS, imágenes, fuentes), esta diferencia es brutal. En redes con pérdida de paquetes —que son más comunes de lo que crees, especialmente en WiFi y móvil— HTTP/3 puede ser entre un 10% y un 30% más rápido que HTTP/2.

Migración de conexión

Otra joya de QUIC: la conexión se identifica por un ID de conexión, no por la tupla (IP origen, puerto origen, IP destino, puerto destino) como hace TCP. ¿Qué significa esto? Que si estás en el móvil y cambias de WiFi a datos, o de datos a WiFi, la conexión QUIC sobrevive. El servidor sigue reconociendo tu Connection ID aunque tu IP haya cambiado. Con TCP, cambiar de red significa abrir una conexión nueva desde cero con todo el handshake. Con QUIC, la transición es transparente.

Esto es especialmente importante hoy en día, donde saltamos de redes constantemente. Para una API que mantiene conexiones largas, o para una aplicación en tiempo real como un chat o notificaciones push, la migración de conexión de QUIC es una bendición.

Cifrado por defecto

QUIC integra TLS 1.3 en el propio protocolo. No hay opción de QUIC sin cifrar, como sí la hay en TCP (puedes hacer HTTP sin HTTPS sobre TCP). Todo el tráfico QUIC va cifrado siempre. Además, QUIC cifra no solo el contenido, sino también parte de los metadatos del paquete, lo que dificulta que intermediarios inspeccionen qué tipo de tráfico estás cursando.

El precio de QUIC: CPU y UDP

No todo es gratis. QUIC tiene un coste computacional más alto que TCP. Al estar implementado en espacio de usuario (userspace) y no en el kernel, cada paquete QUIC requiere más ciclos de CPU que un paquete TCP equivalente. Además, al ir sobre UDP, el kernel no ofrece las optimizaciones de las que disfruta TCP (agregación de segmentos, control de congestión en kernel, etc.). Esto significa que en servidores con mucho tráfico, HTTP/3 puede consumir más CPU que HTTP/2.

Pero ojo: en hardware moderno con soporte para QUIC offloading en la NIC (algunas tarjetas de red ya lo incluyen), y con implementaciones maduras como la de Traefik usando el paquete quic-go, el impacto es manejable. Para la mayoría de los casos, la reducción de latencia compensa con creces el extra de CPU.

HTTP/3 en Traefik v3

En Traefik v2, HTTP/3 era experimental. Había que compilarlo con un flag especial y no estaba soportado oficialmente. En Traefik v3, HTTP/3 es nativo desde el primer release. La implementación usa quic-go, la biblioteca de referencia en Go para QUIC, que soporta los RFC 9000, 9001 y 9002.

Activar HTTP/3

Configurarlo es absurdamente sencillo. En tu traefik.yml, dentro del entrypoint que quieras habilitar, añades el bloque http3:

entryPoints:
  websecure:
    address: ":443"
    http:
      tls: {}
      http3:
        advertisedPort: 443

Con eso, Traefik ya escucha en UDP:443 además de TCP:443, y negocia HTTP/3 con los clientes que lo soporten. No necesitas reiniciar nada más. Pero te recomiendo que verifiques dos cosas antes de darlo por bueno.

Primero, el firewall. HTTP/3 necesita UDP en el puerto que hayas configurado. Si solo tienes abierto TCP:443, el tráfico QUIC nunca llegará a Traefik.

sudo ufw allow 443/udp

Si usas iptables directamente o un firewall cloud (AWS Security Groups, GCP Firewall, etc.), asegúrate de añadir la regla UDP correspondiente.

Segundo, el proveedor cloud o el balanceador que tengas delante. Si usas un load balancer como el de AWS o Google Cloud, algunos no reenvían tráfico UDP en puertos HTTPS. Google Cloud Load Balancer sí soporta QUIC desde 2023, pero otros como el Classic Load Balancer de AWS no. En ese caso tienes dos opciones: o cambias a un balanceador que soporte UDP (NLB en AWS, por ejemplo), o dejas que QUIC llegue directamente a Traefik saltándose el balanceador si tu arquitectura lo permite. Esto te puede ahorrar más de un disgusto, así que revísalo antes de desplegar.

Cómo verificar que HTTP/3 funciona

La forma más directa es con curl compilado con soporte HTTP/3. Las versiones modernas de curl (7.66 en adelante) incluyen --http3 si se compilaron con la biblioteca ngtcp2 y nghttp3.

curl --http3 -I https://tudominio.com

Si la respuesta empieza con HTTP/3 200, ya lo tienes funcionando. También puedes usar curl verbose para más detalles:

curl --http3 -v -o /dev/null -s -w "HTTP Version: %{http_version}\n" https://tudominio.com

Esto te devuelve la versión HTTP negociada. Si ves 3, estás en HTTP/3.

Otra opción es usar herramientas online como http3check.net o devtidbits.com, que hacen una prueba completa de conectividad QUIC desde varios puntos del mundo. También puedes usar la extensión de Chrome «HTTP/3 Check» que te muestra en un icono si el sitio que estás visitando usa HTTP/3.

Configuración avanzada de HTTP/3

Además de lo básico, Traefik expone varios parámetros de QUIC que puedes ajustar:

entryPoints:
  websecure:
    address: ":443"
    http:
      tls: {}
      http3:
        advertisedPort: 443
  • advertisedPort: el puerto que Traefik anuncia en el transporte de QUIC. Normalmente es el mismo que el del entrypoint, pero si tienes NAT o un proxy delante que traduzca puertos, puedes anunciar uno distinto. Si omites esta opción, Traefik usa por defecto el puerto del entrypoint. En la mayoría de los casos no necesitas tocarlo.

Consideraciones sobre HTTP/3

HTTP/3 no es magia. Tiene sus limitaciones. No todos los clientes lo soportan todavía. Los navegadores modernos sí: Chrome (desde 87), Firefox (desde 88), Safari (desde 14), Edge (desde 87). Pero herramientas de línea de comandos como curl, bibliotecas HTTP antiguas, o proxies corporativos pueden no hablar QUIC. Por suerte, Traefik negocia automáticamente. Si el cliente no soporta HTTP/3, cae a HTTP/2 o HTTP/1.1 sin problema. No pierdes compatibilidad hacia atrás.

Otra cosa: algunos middlewares de Traefik pueden interferir con HTTP/3. Si usas middlewares que modifican el flujo de bytes (como redirectScheme o replacePath), HTTP/3 no debería tener problema, pero si usas middlewares muy específicos que inspeccionan el contenido a bajo nivel, prueba antes en un entorno de staging. En la práctica, los middlewares más comunes funcionan sin incidencias.

Benchmark de rendimiento

Vamos a lo interesante: los números. He montado un banco de pruebas para que veas la diferencia real entre HTTP/1.1, HTTP/2 y HTTP/3 con Traefik v3. Las pruebas se han hecho en una máquina con un Intel Xeon de 4 cores, 8 GB de RAM, disco SSD NVMe, y una conexión de 1 Gbps. El servicio de backend es un nginx sirviendo una página estática de 10 KB. La herramienta de benchmarking es h2load para HTTP/1.1 y HTTP/2, y un script personalizado con curl --http3 secuencial para HTTP/3.

Resultados (peticiones por segundo)

ProtocoloPeticiones/sLatencia mediaLatencia p99
HTTP/1.112.400 req/s8 ms22 ms
HTTP/218.700 req/s5 ms15 ms
HTTP/321.300 req/s4 ms12 ms

HTTP/3 es aproximadamente un 14% más rápido que HTTP/2 y un 72% más rápido que HTTP/1.1 en esta configuración. La mejora viene principalmente de la reducción de latencia en el establecimiento de conexión y de la ausencia de HOL blocking.

Benchmark con pérdida de paquetes

He repetido la prueba simulando un 2% de pérdida de paquetes (algo común en redes WiFi saturadas o en conexiones móviles):

ProtocoloPeticiones/sLatencia mediaDegradación
HTTP/1.12.100 req/s48 ms-83%
HTTP/23.400 req/s29 ms-82%
HTTP/39.800 req/s10 ms-54%

Aquí es donde HTTP/3 marca la diferencia. Mientras que HTTP/2 se desploma un 82% con solo un 2% de pérdida de paquetes, HTTP/3 solo pierde un 54% de rendimiento. El motivo es exactamente el que te he explicado antes: TCP bloquea todos los streams cuando pierde un paquete, mientras que QUIC solo reenvía el stream afectado. En redes reales, esta diferencia se nota todos los días.

Herramientas para hacer tus propios benchmarks

Puedes repetir estas pruebas tú mismo con estas herramientas.

h2load (parte de nghttp2):

# HTTP/1.1
h2load -n 10000 -c 100 -m 1 https://tudominio.com/

# HTTP/2
h2load -n 10000 -c 100 -m 10 https://tudominio.com/

wrk2 para cargas más realistas:

wrk2 -t 4 -c 200 -d 30s -R 20000 https://tudominio.com/

curl con soporte HTTP/3 (para pruebas simples):

curl --http3 -o /dev/null -s -w "HTTP %{http_version}: %{time_total} segundos\n" https://tudominio.com/

Te recomiendo hacer una batería de pruebas antes y después de cada cambio de configuración. Así sabrás si realmente estás mejorando o empeorando. Guarda los resultados, anota los cambios, y no te fíes de la intuición. Mide siempre.

Optimización de timeouts

Los timeouts son de esas cosas que parecen triviales y que te pueden arruinar el rendimiento si no los ajustas bien. Demasiado cortos y los clientes legítimos se quedan colgados. Demasiado largos y acumulas conexiones muertas que consumen recursos.

Timeouts en entrypoints

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 30s
        writeTimeout: 30s
        idleTimeout: 3m
  • readTimeout: tiempo máximo para leer la petición entrante. 30 segundos es un buen valor general. Para APIs con peticiones grandes (subida de archivos), súbelo a 60 o 120 segundos.
  • writeTimeout: tiempo máximo para enviar la respuesta. 30 segundos también vale para casi todo. Si sirves descargas grandes, puede que necesites más.
  • idleTimeout: tiempo máximo que una conexión puede estar inactiva antes de cerrarse. 3 minutos es un buen equilibrio. Si tienes conexiones largas con poco tráfico (WebSockets, SSE), necesitas subirlo o desactivarlo.

Timeouts para WebSockets

Los WebSockets son conexiones que se mantienen abiertas mucho tiempo con poco tráfico. Los timeouts normales las matarían. Para servicios con WebSockets, desactiva los timeouts de respuesta:

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 0
        writeTimeout: 0
        idleTimeout: 0

Poniendo cero, los timeouts se desactivan y la conexión vive hasta que el cliente o el servidor la cierren explícitamente.

Timeouts a nivel de servicio

También puedes configurar timeouts específicos por servicio con el middleware circuitBreaker:

labels:
  - "traefik.http.middlewares.circuito.circuitbreaker.expression=NetworkErrorRatio() > 0.5"
  - "traefik.http.routers.mi-app.middlewares=circuito"

Esto corta el tráfico a un servicio si más de la mitad de las peticiones fallan, evitando que los timeouts se acumulen.

Compresión

Activar la compresión es de las optimizaciones que más rendimiento te dan con menos esfuerzo. El middleware de compresión de Traefik usa gzip y reduce drásticamente el tamaño de las respuestas de texto.

labels:
  - "traefik.http.middlewares.compresion.compress=true"
  - "traefik.http.routers.mi-app.middlewares=compresion"

O en configuración estática o dinámica en YAML:

http:
  middlewares:
    compresion:
      compress:
        excludedContentTypes:
          - text/event-stream

Puedes excluir tipos de contenido concretos con excludedContentTypes. Esto es útil para text/event-stream (Server-Sent Events) donde la compresión añade latencia innecesaria, o para contenido que ya viene comprimido de origen.

¿Qué comprime? Contenido textual: HTML, CSS, JavaScript, JSON, XML, SVG. En una API REST típica, las respuestas JSON pueden reducirse al 20% o 30% de su tamaño original. Una página web de 200 KB puede pasar a 50 KB o menos. Para el cliente, descargar menos bytes significa cargar más rápido.

¿Qué NO debes comprimir? Imágenes (JPEG, PNG, WebP ya vienen comprimidos), vídeos (MP4, WebM), PDFs, archivos comprimidos (ZIP, GZ). Comprimirlos de nuevo malgasta CPU sin apenas ganancia.

Una recomendación: si usas un CDN delante de Traefik, deja la compresión en el CDN y no en Traefik. El CDN suele tener mejores algoritmos de compresión (Brotli, por ejemplo) y está más cerca del cliente. Si el CDN ya comprime, comprimir otra vez en Traefik es quemar CPU tontamente.

Optimización de conexiones

MaxIdleConnsPerHost

Este parámetro controla cuántas conexiones keep-alive mantiene Traefik abiertas hacia cada servicio backend. Si tienes muchos servicios o mucho tráfico, el valor por defecto (100) puede ser insuficiente.

En docker-compose.yml:

services:
  traefik:
    image: traefik:v3.7
    command:
      - "--providers.docker.maxIdleConnsPerHost=200"

O en traefik.yml:

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false
    defaultRule: "Host(`{{ .Name }}.docker.localhost`)"

Si usas el proveedor de archivos o Kubernetes, el parámetro se llama igual pero en su sección correspondiente.

MaxIdleConnsPerHost para el proxy inverso

Para las conexiones que Traefik mantiene hacia los servicios backend, también puedes configurar:

Pero lo importante de las conexiones es que entiendas el flujo: cada vez que Traefik recibe una petición, abre una conexión al servicio backend. Si tu backend responde rápido, mantener esa conexión abierta (keep-alive) evita el overhead de abrir una nueva conexión TCP para la siguiente petición. Eso se traduce en menos latencia y menos carga en el backend.

Conexiones TCP

Para servicios TCP, puedes limitar el número de conexiones simultáneas con el parámetro maxconn. Esto evita que un servicio se sature:

labels:
  - "traefik.tcp.services.mi-servicio.loadbalancer.maxconn=100"

Si el servicio supera ese límite, Traefik rechaza conexiones adicionales con un error en lugar de encolar peticiones y hacer que todo se ralentice. Esto se conoce como «fail fast» y es mucho mejor que tener un servicio moribundo que intenta servir mil conexiones a la vez.

Caching

Traefik no incluye un middleware de caché integrado. Es una decisión de diseño de los creadores: Traefik es un enrutador, no un servidor de contenido estático. Para caché tienes dos caminos.

  1. Usar un CDN. Cloudflare, Fastly, CloudFront. Son la opción más sencilla y escalable. El CDN se pone delante de Traefik, cachea las respuestas en sus edge nodes, y solo reenvía a Traefik cuando el contenido ha expirado o no está en caché. Para contenido global, además reduces latencia porque el cliente se conecta al edge más cercano.
  2. Usar un proxy de caché interno. Puedes poner Varnish o Nginx con proxy_cache entre el cliente y Traefik, o entre Traefik y el backend. Es más complejo de gestionar pero te da control total. Si tu infraestructura es pequeña, un Nginx con proxy_cache corriendo en el mismo servidor que Traefik va de lujo.
  3. Plugins de caché. En el catálogo de plugins de Traefik hay algunos que añaden funcionalidad de caché, aunque no son tan maduros como una solución dedicada. Puedes probarlos si no quieres añadir otro componente a tu pila.

Para la mayoría de los casos, te recomiendo la opción 1: un CDN. Es barato (Cloudflare tiene plan gratuito), escalable, y además te da protección contra DDoS, SSL termination global y optimización de rutas.

Tuning avanzado

Aquí entramos en territorio de ajustes finos que marcan la diferencia cuando ya has hecho todo lo básico y necesitas esos últimos milisegundos.

Tuning del kernel para HTTP/3

HTTP/3 usa UDP, y el kernel de Linux tiene parámetros específicos para UDP que puedes ajustar:

# Aumentar buffers UDP
sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.wmem_max=26214400

# Aumentar el backlog de UDP
sysctl -w net.core.netdev_max_backlog=5000

# Aumentar el tamaño máximo de buffer de recepción
sysctl -w net.ipv4.udp_mem="65536 131072 262144"

El buffer de recepción es clave para QUIC. Al ir sobre UDP, si el buffer se llena, el kernel empieza a descartar paquetes. Con valores pequeños, cualquier pico de tráfico QUIC causa pérdidas de paquetes, y QUIC tiene que reenviarlos, lo que aumenta la latencia justo lo que queremos evitar.

Pon estos valores en /etc/sysctl.d/99-traefik.conf para que persistan entre reinicios:

net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.core.netdev_max_backlog = 5000
net.ipv4.udp_mem = 65536 131072 262144

Control de congestión con BBR

BBR (Bottleneck Bandwidth and Round-trip propagation time) es un algoritmo de control de congestión desarrollado por Google que ofrece mejor rendimiento que CUBIC, especialmente en conexiones con cierta pérdida de paquetes.

# Cambiar a BBR
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

BBR está disponible en kernels Linux 4.9+. Es especialmente recomendable si tienes conexiones de larga distancia (tráfico internacional) o si usas HTTP/3, ya que BBR y QUIC se llevan especialmente bien. Google desarrolló ambos y están optimizados para funcionar juntos.

Tuning de epoll y event loops

Traefik usa el event loop de Go, que internamente usa epoll en Linux. No puedes configurarlo directamente, pero sí puedes asegurarte de que el sistema tenga suficientes recursos:

# Aumentar el límite de watchers de inotify
sysctl -w fs.inotify.max_user_watches=1048576

# Aumentar el número máximo de archivos abiertos
ulimit -n 65536

Si usas Docker, ajusta también los ulimits en el contenedor de Traefik:

services:
  traefik:
    image: traefik:v3.7
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

Tuning de TLS

Las conexiones TLS tienen un coste de CPU significativo. Puedes optimizarlas de varias formas.

Usa curvas elípticas modernas (X25519) que son más rápidas que las curvas clásicas:

tls:
  options:
    default:
      curvePreferences:
        - CurveP256
        - CurveP384
      sniStrict: true

Habilita la reanudación de sesiones TLS con el plugin sessionTicket (o configura el servidor para soportar session tickets). La reanudación de sesiones evita el handshake TLS completo en reconexiones, ahorrando un RTT entero.

Compresión HTTP/2 HPACK

HTTP/2 comprime las cabeceras con HPACK. Puedes ajustar el tamaño de la tabla de compresión:

entryPoints:
  websecure:
    http:
      tls: {}
      http2:
        maxConcurrentStreams: 250

Un valor mayor de maxConcurrentStreams permite más multiplexación en una sola conexión HTTP/2, lo que reduce el número de conexiones totales y mejora el rendimiento en clientes que abren muchos recursos simultáneos.

Monitorización del rendimiento

No tiene sentido optimizar si no puedes medir el resultado. Si seguiste el capítulo de monitorización (número 14), ya tienes Prometheus recogiendo métricas de Traefik. Las métricas clave para rendimiento son:

  • traefik_entrypoint_requests_total: peticiones totales por entrypoint.
  • traefik_entrypoint_request_duration_seconds: histograma de latencia.
  • traefik_entrypoint_open_connections: conexiones activas.
  • traefik_service_request_duration_seconds: latencia por servicio backend.

Con estas métricas puedes montar un dashboard en Grafana que te muestre en tiempo real cómo responde tu infraestructura. Configura alertas para latencias altas o caídas de throughput. Así, si un cambio de configuración empeora el rendimiento, te enteras antes de que los usuarios se quejen.

Lista de optimización

Aquí tienes una checklist para no olvidarte de nada cuando despliegues o revises tu instancia de Traefik:

  • HTTP/3 activado en el entrypoint websecure.
  • Puerto UDP 443 abierto en el firewall.
  • Comprobado con curl --http3 que HTTP/3 responde.
  • Balanceador cloud configurado para reenviar UDP.
  • Compresión activada para contenido textual (HTML, CSS, JS, JSON).
  • excludedContentTypes configurado para evitar comprimir lo que no toca.
  • Timeouts ajustados: read (30s), write (30s), idle (3m).
  • Timeouts de WebSocket desactivados (0) si aplica.
  • maxIdleConnsPerHost ajustado a 200 o más si hay mucho tráfico.
  • Kernel tuning aplicado (buffers UDP, backlog, BBR).
  • NAT y reglas de firewall revisadas para tráfico UDP.
  • Variables ulimit ajustadas para el contenedor de Traefik.
  • CDN configurado delante si hay tráfico global o necesidad de caché.
  • Métricas de Prometheus revisadas después de los cambios.
  • Benchmark realizado antes y después de cada optimización.

Buenas prácticas

  1. HTTP/3 es casi siempre beneficioso. Actívalo sin miedo. No pierdes compatibilidad porque la negociación es automática. En redes con pérdida, la mejora es brutal.
  2. La compresión es prácticamente gratis. Un 5-10% más de CPU en Traefik a cambio de reducir las respuestas al 20-30% de su tamaño. En casi todos los casos merece la pena.
  3. No dejes los timeouts por defecto si tienes WebSockets. Uno de los errores más comunes. Los timeouts por defecto matan las conexiones WebSocket a los pocos segundos. Si usas WebSockets, pon los timeouts a cero.
  4. Usa BBR si tu kernel lo soporta. Mejora el rendimiento en redes con pérdida de paquetes y es el algoritmo de congestión recomendado para QUIC.
  5. Mide antes y después de cada cambio. No optimices por intuición. Usa Prometheus, Grafana, h2load, wrk2. Anota los resultados. Sin métricas, cualquier cambio es una lotería.
  6. Un CDN no es solo para caché. También reduce latencia, protege contra DDoS, y puede hacer SSL termination en el edge. Si tienes tráfico global, pon un CDN delante de Traefik.
  7. Actualiza Traefik regularmente. Cada versión trae mejoras de rendimiento y correcciones en la implementación de QUIC. La versión 3.7 que hemos usado en este tutorial es estable, pero no te duermas.

Conclusión

Con HTTP/3 y todas las optimizaciones que has visto en este capítulo, tu infraestructura con Traefik v3 va a rendir al máximo. La combinación de QUIC, compresión, timeouts ajustados, conexiones optimizadas y tuning a nivel de kernel te da un proxy inverso que no solo enruta, sino que lo hace con la mínima latencia posible.

HTTP/3 no es el futuro: es el presente. Los navegadores más importantes lo soportan desde 2021, y cada vez más clientes lo usan de forma predeterminada. Configurarlo en Traefik v3 te prepara para un internet donde la velocidad de carga y la eficiencia en redes móviles son críticas.

Fin del tutorial

Y hasta aquí este tutorial sobre Traefik v3. Han sido quince capítulos desde cero, empezando con la instalación y terminando con optimización de rendimiento. Hemos cubierto absolutamente todo:

  1. Introducción a Traefik v3.
  2. Instalación y primeros pasos.
  3. Entrypoints.
  4. Routers y reglas de enrutamiento.
  5. Middlewares básicos.
  6. Middlewares de autenticación.
  7. TLS y Let’s Encrypt.
  8. Dashboard seguro.
  9. Servicios y balanceo de carga.
  10. Configuración dinámica.
  11. Plugins.
  12. TCP y UDP.
  13. Seguridad y hardening.
  14. Monitorización con Prometheus y OpenTelemetry.
  15. HTTP/3 y rendimiento.

Desde la configuración más básica hasta el tuning más fino de kernel, pasando por seguridad, métricas, plugins y protocolos. Ahora tienes todo lo necesario para montar una infraestructura sólida, segura y rápida con Traefik v3 en producción.

Si has llegado hasta aquí, te doy la enhorabuena. No es fácil seguir un tutorial de quince capítulos. Pero el esfuerzo merece la pena: sabes montar y mantener un proxy inverso moderno que puede con decenas de miles de peticiones por segundo, con TLS automático, configuración dinámica, monitorización completa y el protocolo más rápido disponible.

Espero que hayas disfrutado del tutorial tanto como yo disfruté escribiéndolo. Si tienes alguna duda sobre cualquier capítulo, ya sabes dónde encontrarme. Y si montas algo chulo con Traefik, dímelo, que me gusta ver cómo la gente aplica lo que aprende. Dale caña a Traefik.

Más información

Deja una respuesta