Más allá de epoll: Arquitectura de Túneles Inversos de Latencia Ultra-Baja con Linux io_uring

Por décadas, la base de las redes de alto rendimiento en Linux ha sido indiscutible. Si estabas construyendo un servidor web, un balanceador de carga o un proxy inverso diseñado para manejar el famoso problema C10K (y posteriormente C10M), utilizabas epoll. Gigantes de la industria como NGINX, HAProxy y Envoy se construyeron sobre este modelo de readiness basado en eventos, demostrando su robustez en todo el mundo. Sin embargo, a medida que empujamos los límites del ingreso local de alto rendimiento en 2026, las fallas en la arquitectura de epoll se vuelven claramente evidentes.

El problema ya no es gestionar miles de conexiones; se trata del costoso cambio de contexto. Cuando las velocidades de red se miden en cientos de gigabits por segundo y los presupuestos de latencia se reducen a microsegundos en cifras únicas, la oscilación continua entre espacio de usuario y espacio del kernel se convierte en un cuello de botella catastrófico para la CPU.

Entra io_uring, el avance más significativo en I/O de Linux en la última década. Al migrar binarios modernos de túneles y proxies inversos a esta API avanzada de I/O asíncrono — que aprovecha anillos de memoria compartida — los ingenieros están eliminando la sobrecarga de syscall en la ruta crítica. Este cambio de paradigma permite crear proxies de red ultra eficientes capaces de gestionar millones de paquetes multiplexados con picos de CPU casi nulos.

Este artículo explora las diferencias técnicas entre epoll y io_uring en redes, detallando cómo funciona un túnel Linux asíncrono construido sobre io_uring, por qué el proxy inverso io_uring está transformando fundamentalmente el diseño de arquitecturas de ingreso local de alto rendimiento, y cuáles son las consideraciones de seguridad y ecosistema en 2026.

---

La Anatomía del Cuello de Botella de epoll

Para entender por qué un proxy inverso con io_uring representa un salto tan significativo, primero debemos analizar por qué epoll falla en altas tasas de throughput.

Una Breve Historia

epoll fue introducido en el kernel Linux 2.5.44 en octubre de 2002 como un reemplazo escalable para las llamadas al sistema select() y poll() más antiguas. A diferencia de sus predecesores, que operan en tiempo O(n) a medida que crece el número de descriptores de archivos vigilados, epoll funciona en O(1) para notificaciones de readiness — una mejora crítica para servidores de alta concurrencia. Sostuvo toda la era de soluciones C10K y alimenta virtualmente cada entorno de servidor de alto rendimiento en producción hoy, incluyendo libuv (Node.js), el sondeador de red estándar de Go y los bucles de eventos en NGINX y HAProxy.

El Paradigma de Readiness

epoll es un mecanismo de notificación de readiness. Cuando un proxy inverso gestiona miles de sockets de cliente, usa epoll para preguntar al kernel: “¿Qué de estos descriptores de archivo tienen datos listos para leer, o espacio en buffer disponible para escribir?”

El flujo típico de un proxy basado en epoll es así:

1. El proxy llama a epoll_wait(), bloqueando hasta que uno o más sockets estén listos (cambio de contexto: usuario → kernel → usuario).
2. El kernel devuelve una lista de descriptores listos.
3. Para cada socket listo, el proxy emite una llamada read() o write() al sistema (cambio de contexto: usuario → kernel → usuario, otra vez).
4. Si un socket devuelve EAGAIN (indicando que la operación bloquearía), el proxy se detiene y espera el siguiente ciclo de epoll_wait().

Los Costos Ocultos del Cambio de Contexto

Aunque epoll_wait escala mucho mejor que sus predecesores, las operaciones de I/O reales aún requieren llamadas al sistema independientes. Cada read(), write(), accept() y close() fuerza un cambio de contexto en la CPU. Durante un cambio de contexto, la CPU debe guardar el estado de los registros en espacio de usuario, vaciar ciertas entradas TLB, saltar a la ejecución en espacio del kernel, validar punteros, realizar la operación y volver a saltar. A 10,000 solicitudes por segundo, este overhead es insignificante. A 1,000,000 de paquetes por segundo, domina el perfil de CPU. En entornos de alta concurrencia, el proxy puede terminar gastando más tiempo en atravesar la frontera usuario–kernel que en la lógica de la aplicación.

Además, epoll separa estrictamente I/O de red de I/O de archivos. Los archivos regulares en Linux siempre se consideran “listos” por epoll, pero las lecturas contra ellos aún pueden bloquear en disco. Esto obliga a los desarrolladores de proxies a mantener pools de hilos separados para I/O de archivos junto a su ciclo de epoll, introduciendo contención por mutex, sobrecarga adicional de memoria y complejidad de coordinación.

---

Entra io_uring: Redefiniendo el I/O Asíncrono

Desarrollado por Jens Axboe en Facebook (ahora Meta), io_uring fue fusionado por primera vez en el kernel Linux principal en la versión 5.1, lanzada en mayo de 2019. Fue diseñado explícitamente para abordar las limitaciones de la antigua interfaz Linux AIO — que solo soportaba I/O directo, sufría de comportamiento de bloqueo no determinista y requería al menos dos llamadas al sistema por operación de I/O. La interfaz io_uring descarta completamente el modelo de readiness en favor de un modelo de finalización.

En lugar de preguntar al kernel “¿Está listo este socket?”, una aplicación usando io_uring dice: “Aquí hay un búfer. Lee datos desde este socket en este búfer, y notifícame cuando hayas terminado completamente.”

Los Anillos de Memoria Compartida

La magia de io_uring reside en sus homónimos: los anillos de memoria compartida. Cuando un proxy inicializa una instancia de io_uring mediante io_uring_setup(), crea dos buffers circulares en anillo mapeados en memoria compartida accesible tanto por espacio de usuario como por el kernel:

• Cola de Envío (SQ): La aplicación en espacio de usuario escribe aquí las Entradas de Cola de Envío (SQEs). Un SQE describe una operación de I/O: un readv, un writev, un accept, un temporizador, etc.
• Cola de Finalización (CQ): El kernel escribe aquí las Entradas de Cola de Finalización (CQEs). Una vez que una operación de I/O termina, el kernel empuja el resultado — bytes leídos/escritos o un código de error — a la CQ.

Debido a que estas colas residen en memoria compartida, la aplicación puede encolar muchas operaciones de I/O sin hacer una sola llamada al sistema. Una vez que la cola está poblada, una única llamada io_uring_enter() notifica al kernel para comenzar a procesar el lote. El kernel procesa las solicitudes de forma asíncrona, escribiendo los resultados directamente de vuelta a la CQ para que la aplicación los consuma.

Al agrupar operaciones, io_uring amortiza inmediatamente el costo de las llamadas al sistema a través de muchas operaciones de I/O. Para un túnel Linux asíncrono de alto rendimiento, esto por sí solo es una mejora significativa. Pero io_uring va mucho más allá.

Un Modelo Unificado de I/O

A diferencia de epoll, io_uring presenta una interfaz unificada para I/O de red y I/O de archivos. Un proxy puede enviar lecturas de sockets, escrituras en sockets, operaciones sendfile y lecturas de disco todas en el mismo anillo, recibiendo sus finalizaciones en la misma CQ. Esto elimina la necesidad de pools de hilos separados para manejar I/O de archivos, simplificando dramáticamente la arquitectura de proxies que sirven tanto flujos de red como cachés basados en archivos locales.

---

Arquitectura del Proxy de Red con Casi Cero Syscalls

El objetivo para los arquitectos de proxies con io_uring es reducir — y en la ruta crítica, eliminar casi por completo — las llamadas al sistema. io_uring hace esto posible mediante una bandera de función conocida como IORING_SETUP_SQPOLL.

SQPOLL: Evitando io_uring_enter

Cuando una instancia de io_uring se inicializa con IORING_SETUP_SQPOLL, el kernel Linux genera un hilo dedicado específicamente para ese anillo. Este hilo continuamente hace sondeo en la cola de envío compartida en lugar de esperar ser despertado por una llamada io_uring_enter().

Así funciona el proxy bajo SQPOLL:

1. La aplicación del proxy escribe nuevas operaciones de red (lectura, escritura, accept) en la SQ en memoria compartida.
2. El proxy no llama a io_uring_enter().
3. El hilo dedicado del kernel detecta instantáneamente los SQEs nuevos y ejecuta las operaciones de red.
4. El kernel escribe los resultados en la CQ.
5. La aplicación del proxy lee los resultados de la CQ en memoria compartida.

Durante la transmisión continua de datos, el proceso del proxy evita desencadenar un cambio de contexto por cada operación de I/O individual. La aplicación permanece en espacio de usuario, alimentando operaciones en memoria compartida y leyendo resultados. El hilo del kernel maneja el resto.

Una nuance importante: si el hilo de sondeo del kernel queda inactivo tras un tiempo de espera configurable (establecido mediante sq_thread_idle en milisegundos), la aplicación debe despertarlo nuevamente mediante io_uring_enter(). Un proxy bajo carga continua puede mantener el hilo vivo indefinidamente y evitar este costo por completo.

Requisitos de privilegios han evolucionado considerablemente desde la introducción de SQPOLL. Los kernels tempranos requerían CAP_SYS_ADMIN. El kernel 5.11 relajó esto a CAP_SYS_NICE. A partir del kernel 5.13, ya no se necesitan privilegios especiales para SQPOLL en kernels modernos — convirtiéndolo en una opción de despliegue realista fuera de contenedores que requieran privilegios elevados.

Buffers Fijos y Archivos Registrados

Para eliminar la sobrecarga restante, los proxies modernos con io_uring usan io_uring_register_buffers() y io_uring_register_files(). En proxies tradicionales con epoll, cada read() o write() requiere que el kernel traduzca punteros de memoria de espacio de usuario y busque en las tablas de descriptores de archivos en cada llamada. Registrando buffers y archivos fijos de antemano, el proxy fija permanentemente las páginas de memoria y almacena en caché los mapeos de descriptores en el kernel. Cuando el proxy envía un SQE usando un índice de buffer registrado, el kernel evita la sobrecarga de búsqueda por operación, habilitando caminos DMA directos entre la NIC y la memoria del espacio de usuario.

Accept Multi-Shot

Una característica particularmente potente para proxies inversos es IORING_OP_ACCEPT con la bandera IORING_ACCEPT_MULTISHOT, introducida en Linux 5.19. Una llamada tradicional a accept() — incluso dentro de io_uring — requiere reenvío tras cada conexión aceptada. Con accept multi-shot, un solo SQE genera continuamente CQEs para cada nueva conexión entrante sin necesidad de reenviarlo. Para un proxy de ingreso de alta concurrencia manejando millones de conexiones cortas, esto elimina toda una clase de sobrecarga de reenvío.

---

Networking Zero-Copy: La Frontera de Linux 6.15

Quizás el desarrollo más importante reciente en redes con io_uring llegó en Linux 6.15 en 2025: soporte nativo de recepción zero-copy (ZC Rx). Antes de esto, io_uring soportaba transmisión sin copia (enviando datos desde buffers de usuario al NIC sin copias en kernel), pero la recepción aún requería un paso de copia kernel a usuario.

La nueva función ZC Rx configura una cola de recepción hardware para DMA de los payloads de paquetes entrantes directamente en memoria del usuario. El kernel procesa los encabezados de los paquetes a través del stack TCP/IP normal, pero los datos del payload nunca tocan memoria del kernel. “Leer” desde un socket se convierte efectivamente en un mecanismo de notificación: el kernel indica a la aplicación dónde en memoria del usuario ya llegaron los datos. En una demostración usando esta función, se saturó un enlace de 200 Gbit/s usando un solo núcleo de CPU.

Esto lleva a proxies basados en io_uring a un nuevo nivel: no solo reducción del overhead de syscall, sino un camino hacia una recepción verdaderamente zero-copy a nivel de hardware, sin la complejidad de bypass del kernel de frameworks como DPDK.

---

El Túnel Asíncrono Linux en 2026: Rust y Cambios en el Runtime

La transición a io_uring no es solo un cambio en la API del kernel; requiere repensar el runtime interno del proxy. epoll se basa en readiness, por lo que los proxies tradicionales gestionan sus propios buffers de memoria, entregando un puntero al kernel solo en el momento exacto en que un socket está listo. Con io_uring, el modelo cambia a transferencia de propiedad del buffer (a veces llamado “buffer renting”): dado que el kernel ejecuta la lectura o escritura de forma asíncrona, debe ser dueño del buffer de memoria hasta que la operación finalice. Si el proxy muta o descarta el buffer mientras el kernel aún escribe en él, se produce corrupción de memoria.

Runtimes en Hilo-por-Núcleo en Rust

Para aprovechar completamente io_uring, los desarrolladores de binarios de túneles modernos han adoptado en gran medida Rust y runtimes especializados hilo-por-núcleo. Dos opciones prominentes son:

• Monoio (ByteDance / CloudWeGo): Un runtime Rust puro de io_uring/epoll/kqueue con modelo de hilo-por-núcleo. Monoio requiere Linux kernel 5.6+ para soporte de io_uring y implementa el alquiler de buffers nativamente en su abstracción de I/O. Las pruebas de ByteDance muestran que su implementación de gateway basada en Monoio supera a NGINX en hasta un 20% en escenarios optimizados, con implementaciones RPC mostrando una ganancia del 26% sobre stacks similares basados en Tokio.
• Glommio (originalmente Datadog): Un runtime cooperativo de hilo-por-núcleo para Rust construido sobre io_uring, que requiere kernel 5.8+ y al menos 512 KiB de memoria bloqueada (RLIMIT_MEMLOCK). Glommio crea de manera única tres instancias io_uring por hilo — un anillo principal, uno sensible a la latencia y uno de sondeo — para ofrecer un control de programación más fino sobre cargas críticas de latencia versus throughput.

Ambos aplican un modelo de sin compartición en todos los núcleos CPU:

• Sin robo de trabajo: Cada hilo de CPU tiene su propia instancia io_uring aislada y gestiona su propio subconjunto de conexiones.
• Alquiler de buffers: El proxy “alquila” la propiedad de un buffer de memoria al runtime. Cuando la lectura de red termina, el runtime devuelve la propiedad del buffer a la lógica de la aplicación.
• Localidad de caché: Debido a que las tareas nunca migran entre núcleos CPU, las cachés L1 y L2 permanecen calientes. No hay contención por mutex, ni sobrecarga de bloqueo, ni sincronización entre hilos.

Pruebas independientes de servidores HTTP estáticos comparando runtimes Rust con io_uring frente a Tokio estándar muestran que en un solo hilo, Monoio alcanza aproximadamente 656,000 req/s versus unos 399,000 req/s de Tokio estándar — una ventaja de ~64%. En cuatro hilos, los runtimes con io_uring superan 1.1 millones de req/s, liderados por tokio-uring y Monoio. En cuatro hilos, los runtimes basados en io_uring superan aproximadamente 2.3× a fasthttp de Go.

En un escenario de túnel de ingreso — donde un proxy local descifra streams multiplexados entrantes (como HTTP/3 sobre QUIC) y los reenvía a microservicios locales — esta arquitectura brilla. Un solo anillo gestiona lecturas de red del exterior, escrituras de red al servicio local y eventos de temporizador para keepalive, todo en transacciones de memoria compartida.

La Realidad del Ecosistema

Es importante ser honestos sobre la madurez del ecosistema. Glommio, originalmente desarrollado por Glauber Costa en Datadog, ha visto reducir su desarrollo activo a medida que su autor original se fue y el equipo de Datadog cambió de enfoque. Monoio recibe parches y sigue siendo funcional, pero su cobertura de API para las nuevas funciones de io_uring se queda algo atrás respecto a la interfaz en rápida evolución del kernel. Apache Iggy, un broker de mensajes de alto rendimiento, publicó a principios de 2026 un relato detallado de su migración a una arquitectura io_uring de hilo-por-núcleo y encontró fricciones reales: los runtimes Rust disponibles no exponen completamente primitivas de io_uring como encadenamiento de solicitudes, APIs de recepción/envío de una sola vez y pools de buffers registrados, al nivel que los usuarios de liburing en C pueden acceder directamente.

El ecosistema está madurando, pero los desarrolladores que necesitan la frontera absoluta de las funciones de io_uring pueden encontrarse trabajando más cerca de la API en C de liburing de lo que inicialmente esperaban.

---

Redes: epoll vs io_uring — La Nuance en el Mundo Real

¿Está epoll muerto? En absoluto. Para la mayoría de los servicios web estándar, APIs y aplicaciones de tráfico moderado a bajo, epoll sigue siendo maduro, profundamente integrado en los entornos existentes y perfectamente adecuado. Node.js (libuv) y Go estándar usan epoll en el fondo y manejan millones de cargas de trabajo en producción diariamente.

El caso de io_uring se fortalece en umbrales operativos específicos:

• Tasas de solicitud extremadamente altas, donde el overhead por syscall se vuelve un impuesto medible en la CPU.
• Cargas de trabajo mixtas de I/O (red + disco), donde un modelo asíncrono unificado simplifica la arquitectura.
• Sensibilidad a la latencia de cola, donde el modelo de hilos de epoll introduce jitter en la programación en p99/p999.
• Path de recepción sin copia donde el hardware NIC y Linux 6.15+ permiten DMA directo a memoria del usuario.

La documentación de desarrolladores de Red Hat es apropiadamente mesurada en este punto: io_uring ha sido una victoria clara para I/O de archivos, pero para I/O de red — que ya cuenta con APIs no bloqueantes — las ganancias dependen en gran medida de si la carga de trabajo está limitada por syscall. Siempre realiza benchmarks en condiciones realistas antes de comprometerte con una reescritura arquitectónica.

---

Consideraciones de Seguridad: La Doble Cara de la Interfaz

Ninguna discusión sobre io_uring en producción está completa sin abordar su superficie de seguridad. En junio de 2023, el equipo de seguridad de Google reportó que el 60% de las explotaciones reportadas en su programa de recompensas por bugs en kernel en 2022 estaban dirigidas a io_uring. Google ha pagado aproximadamente 1 millón de USD en recompensas por vulnerabilidades relacionadas con io_uring. Como resultado, io_uring fue deshabilitado para aplicaciones de terceros en Android (con políticas SELinux limitando el acceso a procesos del sistema confiables), deshabilitado completamente en ChromeOS y restringido en servidores de producción de Google.

CVEs destacados incluyen:

• CVE-2021-41073: Manejo incorrecto de memoria que permite escalada de privilegios local.
• CVE-2023-2598: Acceso fuera de límites que permite LPE.
• CVE-2023-21400: Vulnerabilidad de doble liberación en kernel 5.10, explotada con éxito en Google Pixel 7 en una prueba de concepto.

La superficie de ataque proviene de la complejidad de io_uring y su capacidad para sortear la monitorización convencional. Herramientas EDR y sistemas de detección de intrusiones basados en syscall que interceptan read(), write(), sendmsg() y recvmsg() son efectivamente ciegos ante un proceso que opera únicamente a través de los anillos. Las herramientas estándar como strace permanecen en silencio durante la ruta activa de datos — porque no se están haciendo syscalls.

Para despliegues en producción, las mitigaciones recomendadas son:

• Utilizar herramientas de monitoreo basadas en eBPF que instrumenten puntos de trazado del kernel de io_uring en lugar de interceptar syscalls.
• Restringir la creación de instancias de io_uring mediante /proc/sys/kernel/io_uring_disabled y io_uring_group en sistemas multiinquilino.
• Fijar despliegues a versiones de kernel bien parcheadas; las versiones LTS 5.15 y 6.x han recibido backports de seguridad completos.
• Auditar políticas de seguridad en contenedores — el acceso a io_uring debe estar explícitamente gobernado en perfiles seccomp.

---

Superando los Desafíos de io_uring

A pesar de su potencia, diseñar un proxy inverso con io_uring presenta desafíos de ingeniería específicos:

Dependencia del kernel. io_uring debutó en 5.1, pero funciones críticas de red llegaron en versiones posteriores: accept multi-shot en 5.19, SQPOLL confiable sin privilegios en 5.13, transmisión sin copia en 5.15 y recepción sin copia en 6.15. Desplegar túneles avanzados de io_uring en distribuciones Linux empresariales con kernels más antiguos (por ejemplo, RHEL 8.x con kernel 4.18) resultará en fallback a epoll o en fallos completos de funciones. La versión del kernel objetivo debe ser explícita.

Consumo de memoria. Los buffers en anillo y los buffers fijos requieren memoria bloqueada en kernel (RLIMIT_MEMLOCK). Glommio documenta un mínimo de 512 KiB por hilo de ejecutor. A escala extrema con muchos anillos, esto requiere ajuste cuidadoso del sistema para evitar OOM. Cada anillo SQPOLL también ocupa un hilo de kernel dedicado, que consume un núcleo CPU.

Orden y serialización. Los CQEs pueden llegar en cualquier orden, incluso cuando los SQEs se enviaron secuencialmente (a menos que estén explícitamente vinculados con IOSQE_IO_LINK o IOSQE_IO_HARDLINK). En sockets TCP orientados a flujo, tener más de una operación de envío o recepción pendiente sin orden explícito es inseguro, ya que el kernel puede reordenar su ejecución durante el armado del sondeo. Los desarrolladores deben rastrear el contexto de la solicitud mediante punteros user_data adjuntos a cada SQE.

Opacidad en depuración. Herramientas estándar como strace son efectivamente ciegas ante un proxy sin syscalls en la ruta crítica. La depuración requiere bpftrace o programas eBPF personalizados que accedan directamente a los puntos de trazado internos de io_uring para inspeccionar el estado del anillo y los hilos del kernel. Esto implica una sobrecarga operacional no trivial.

Seguridad en cancelaciones. Debido a que el kernel posee los buffers durante operaciones asíncronas, eliminar o reutilizar un buffer antes de que llegue el CQE causa corrupción de memoria. El modelo de propiedad en Rust, combinado con alquiler de buffers en runtimes como Monoio y Glommio, aborda esto a nivel de lenguaje — pero solo si el código de la aplicación está estructurado correctamente en torno a esas abstracciones.

---

Lo que Esperar en 2026

La trayectoria de io_uring sigue siendo ascendente:

• PostgreSQL 18 está introduciendo un backend opcional de io_uring para I/O de datos y WAL, con benchmarks tempranos mostrando una aceleración 3× en escaneos en frío sobre readahead bloqueante y una ganancia acumulada del 11–15% con buffers registrados y SQPOLL habilitado.
• Recepción zero-copy a nivel NIC (Linux 6.15) abre la puerta a arquitecturas proxy donde los datos del payload se mueven directamente del NIC a la memoria de la aplicación, saltándose completamente los buffers del kernel en hardware compatible.
• Kernel 7.0 (lanzado en abril de 2026) introdujo el modo IORING_SETUP_NO_SQARRAY con IORING_SETUP_LINEAR_SEQNO, un modo de cola no circular diseñado para mantener los SQEs en caché L1 para envíos frecuentes y pequeños.

---

Conclusión: Una Evaluación Medida del Cambio

La arquitectura epoll ha entregado un valor tremendo durante más de dos décadas y no está cerca de quedar obsoleta. Pero para equipos que operan en la frontera del ingreso local de alto rendimiento — donde arrays NVMe entregan millones de IOPS y NICs de 400 Gbit/s son una realidad en los datacenters — el costo por syscall del modelo de readiness es un cuello de botella medible.

La API del kernel io_uring no es una simple sustitución; es una reinvención fundamental de cómo se comunican el espacio de usuario y el espacio del kernel. Sus anillos de memoria compartida, semántica de alquiler de buffers, modo SQPOLL y ahora recepción zero-copy a nivel de hardware ofrecen una arquitectura de extremo a extremo que puede extraer rendimiento del hardware moderno que los diseños basados en epoll no pueden igualar.

Las desventajas son reales: requisitos de versión del kernel, una superficie de seguridad compleja y en evolución, visibilidad limitada en strace, y runtimes en ecosistema Rust que aún no exponen completamente las funciones más profundas de io_uring. Ninguno de estos obstáculos es insalvable para un equipo que planifique cuidadosamente, apunte a kernels LTS modernos, utilice eBPF para instrumentación y realice perfiles bajo carga real antes de comprometerse con la arquitectura.

Si estás construyendo infraestructura para ingreso local de ultra alto rendimiento, tunneling inverso o gateways de API de baja latencia, io_uring merece una evaluación seria. No es la opción adecuada para todas las cargas, pero en aquellas donde encaja, la brecha entre io_uring y epoll no es marginal — es arquitectónica.