Zero-Stack Loopback: Acelerando el ingreso de red en microservicios usando eBPF Sockmaps

En la era moderna de infraestructura cloud-native, la arquitectura de microservicios se ha convertido en el estándar para construir aplicaciones escalables. Al dividir aplicaciones monolíticas en servicios más pequeños y desacoplados, los equipos de ingeniería han desbloqueado una agilidad y velocidad de despliegue sin precedentes. Sin embargo, esta arquitectura distribuida presenta un nuevo desafío formidable: la latencia de red.

Cuando una sola solicitud de usuario requiere que media docena de microservicios internos se comuniquen antes de devolver una respuesta, la sobrecarga de red acumulada puede degradar severamente el rendimiento de la aplicación. Para mitigar esto, sistemas de orquestación como Kubernetes suelen programar pods con mucha comunicación en el mismo host físico. Aunque co-localizar servicios elimina la latencia de saltos físicos en la red, expone un cuello de botella oculto — la pila de red del kernel Linux.

Incluso cuando los microservicios residen en la misma máquina, sus comunicaciones han tenido históricamente que atravesar toda la pila TCP/IP de Linux. Este artículo explora cómo la aceleración con eBPF sockmap usa redirección de paquetes a nivel de socket para ejecutar un bypass de la pila de red de Linux para ese tráfico local, reduciendo la latencia y recuperando ciclos de CPU que de otro modo se gastarían en re-derivar garantías que la memoria local ya proporciona.

---

La ilusión del Loopback: El impuesto oculto de la red local

Para entender el impacto de la aceleración de socket con eBPF, ayuda primero trazar el recorrido de un paquete de datos en un entorno Linux tradicional.

Cuando Microservicio A (el cliente) envía datos a Microservicio B (el servidor) que corre en el mismo nodo de Kubernetes, la aplicación asume que está escribiendo en un descriptor de socket simple. Sin embargo, debajo de esa abstracción, el kernel trata este tráfico local de manera notablemente similar al tráfico destinado a un servidor en el otro lado del planeta.

Cuando Microservicio A llama a sendmsg(), ocurre aproximadamente la siguiente secuencia:

1. Transición de espacio de usuario a espacio de kernel. La aplicación entra en el kernel, incurriendo en un cambio de contexto.
2. Asignación del buffer de socket. El kernel asigna un sk_buff para contener la carga útil.
3. Procesamiento en la capa TCP. La pila TCP aplica números de secuencia, sumas de comprobación y gestión de congestión — todo innecesario para una transferencia que nunca sale de la memoria del host.
4. Procesamiento en la capa IP. Se añaden cabeceras IP y se consulta la tabla de enrutamiento local.
5. Netfilter / iptables. El paquete se evalúa contra cada hook de Netfilter y regla de iptables aplicable.
6. Control de tráfico (qdisc). El paquete pasa por la capa de disciplina de encolado.
7. Dispositivo de loopback (lo). El paquete llega al controlador virtual de loopback.
8. El viaje de regreso. El controlador vuelve a poner el paquete en la pila: decapsulación, segunda pasada por Netfilter y reensamblaje TCP antes de que llegue al buffer de recepción de Microservicio B.
9. Transición de espacio de kernel a espacio de usuario. Microservicio B despierta y lee los datos mediante recvmsg().

Ese recorrido implica múltiples asignaciones de memoria, procesamiento completo de protocolos y varios cambios de contexto. Para tráfico que realmente cruza una red, esta maquinaria es indispensable. Para dos contenedores en el mismo host, representa una sobrecarga sustancial en gastar en re-derivar garantías que la memoria local ya proporciona.

---

Entrada de eBPF: Programabilidad a nivel del kernel

Extended Berkeley Packet Filter (eBPF) ha cambiado la forma en que los ingenieros interactúan con el kernel Linux. El BPF clásico fue diseñado en los años 90 como un mecanismo simple de filtrado de paquetes — la tecnología que aún sustenta herramientas como tcpdump — pero el eBPF moderno, cuya infraestructura central en el kernel comenzó a llegar con Linux 3.18 a finales de 2014, se ha convertido en una máquina virtual sandboxed que corre directamente dentro del kernel.

eBPF permite a los desarrolladores escribir programas restringidos, similares a C, y adjuntarlos en puntos de hook en todo el sistema operativo: controladores de red, llamadas al sistema, puntos de traza y más. Antes de que cualquier programa eBPF se ejecute, un verificador en el kernel comprueba de forma estática que no pueda hacer que el kernel se bloquee, entre en bucle infinito o toque memoria que no debe.

eBPF usa estructuras de datos especializadas llamadas mapas eBPF — tablas hash, arreglos, buffers circulares — para mantener estado y intercambiar datos con el espacio de usuario. Frameworks como XDP (eXpress Data Path) aceleran la entrada en el nivel del controlador NIC, pero XDP está demasiado bajo en la pila para ayudar con tráfico de loopback que nunca llega a una NIC física. Para resolver el problema de loopback en microservicios, el punto de hook útil está más arriba en la pila: la capa de socket misma.

---

Decodificando la redirección de paquetes a nivel de socket

La solución al cuello de botella del loopback es lo que comúnmente se llama aceleración con eBPF sockmap: adjuntar programas eBPF directamente a la capa de socket para que intercepten los datos en el momento en que una aplicación llama a sendmsg(), y luego los copien directamente en el buffer de socket del receptor — saltándose toda la pila TCP/IP.

1. Los tipos de mapas sockmap y sockhash

En el centro de este mecanismo están dos tipos de mapas eBPF diseñados específicamente. BPF_MAP_TYPE_SOCKMAP es un mapa respaldado por arreglos que almacena referencias a sockets abiertos, y fue introducido en kernel 4.14. BPF_MAP_TYPE_SOCKHASH es una variante basada en hash que soporta claves más flexibles — por ejemplo, un 5-tuple completo — y llegó en kernel 4.18, según la documentación oficial del sockmap del kernel. Ambos tipos de mapas fueron desarrollados originalmente por John Fastabend y han sido parte del subsistema BPF en el kernel desde entonces.

Un sockmap es más que una tabla de búsqueda — se pueden adjuntar programas de parser y de veredicto directamente a él. Cuando un agente en espacio de usuario (como un daemon CNI, por ejemplo) inserta un descriptor de socket en el mapa, el kernel intercambia de forma transparente los callbacks del mapa por ese socket, convirtiendo el mapa en un registro activo de conexiones aceleradas.

2. El tipo de programa SK_MSG

Con los sockets rastreados en un mapa, los desarrolladores adjuntan un programa eBPF del tipo BPF_PROG_TYPE_SK_MSG, que engancha la ruta sendmsg()/sendfile() para cualquier socket que pertenezca al mapa, como se documenta en la referencia del tipo de programa eBPF. El programa recibe el buffer del mensaje antes de que existan cabeceras TCP o IP, y devuelve un veredicto: SK_PASS para dejar pasar los datos (opcionalmente redirigiéndolos), o SK_DROP para descartarlos.

3. La ayuda de redirección: bpf_msg_redirect_map()

Dentro de un programa SK_MSG, la lógica eBPF inspecciona hacia dónde va el dato. Si el destino no es un socket que el programa reconozca, devuelve SK_PASS y el mensaje sigue su camino normal hacia la NIC. Pero si el destino coincide con un socket ya registrado en el sockmap — es decir, el par vive en el mismo host — el programa llama a bpf_msg_redirect_map() (o su contraparte en hash-map, bpf_msg_redirect_hash()).

Esa función copia la carga útil directamente del buffer del socket emisor al del socket receptor. Se saltan el procesamiento TCP/IP, Netfilter, iptables y el controlador de loopback. Esto no es solo teórico: un tutorial de eBPF demuestra que el tráfico redirigido realmente desaparece de tcpdump — capturar la interfaz de loopback durante una transferencia acelerada por sockmap muestra solo el handshake TCP y la desconexión, porque la carga útil en sí nunca vuelve a entrar en la parte de la pila que tcpdump captura.

También vale la pena saber que sockmap empezó como un mecanismo solo TCP. El soporte completo bidireccional para UDP, además de un tipo de redirección BPF_SK_SKB_VERDICT entre protocolos, llegó más tarde: la serie de parches que lo implementan comenzó a circular en la comunidad del kernel en 2021, cerrando una brecha que los ingenieros de Cloudflare habían señalado como una futura función en sus experimentos iniciales con sockmap.

---

Implementación en el mundo real: Aceleración en Service Mesh

Los beneficios teóricos de la redirección a nivel de socket son convincentes, pero la tecnología demuestra su valor en despliegues de service mesh, donde ha sido utilizada por proyectos como Cilium, Calico y Merbridge.

El problema clásico del sidecar

En la arquitectura original de sidecar de Istio, el tráfico entre microservicios es interceptado por proxies Envoy que corren junto a cada contenedor de aplicación. Si Microservicio A habla con Microservicio B, el flujo es aproximadamente así:

1. Microservicio A escribe en lo que piensa que es un socket normal.
2. Una regla iptables redirige de forma transparente el paquete al sidecar Envoy en el Pod A.
3. Envoy procesa el tráfico — mTLS, trazabilidad, enrutamiento.
4. Envoy envía el paquete al Pod B a través de la red.
5. El paquete llega al Pod B y es interceptado por iptables nuevamente.
6. Se pasa al sidecar Envoy en el Pod B para descifrado e inspección.
7. Finalmente, Envoy reenvía a Microservicio B.

Cuando Pod A y Pod B comparten un host, este flujo obliga a los datos a atravesar la pila TCP/IP de Linux varias veces, en un solo host que se comunica consigo mismo. Estudios recientes cuantifican esto: un artículo de febrero de 2026 de la Universidad de Pekín sobre un sistema llamado XLB encontró que el tráfico entrante y saliente en este modelo atraviesa la pila TCP/IP del kernel tres veces, y que este procesamiento duplicado — junto con las llamadas al sistema necesarias para el splicing de conexiones entre el sidecar y la aplicación — representa más de la mitad de la latencia total por salto. Solo una quinta parte de ese tiempo se dedica a la lógica de balanceo de carga, que en realidad es el objetivo del proxy.

Es importante notar que Istio ha lanzado desde entonces una segunda opción sin sidecar, dirigida exactamente a este problema. El modo Ambient, basado en un proxy Rust compartido por nodo llamado ztunnel y proxies “waypoint” opcionales por namespace para servicios que necesitan funciones de capa 7, alcanzó disponibilidad general en Istio 1.24 en noviembre de 2024. Este modo elimina la sobrecarga del sidecar por pod para tráfico L4 (mTLS, identidad, autorización básica), pero como señalan los investigadores de XLB, una malla L4 sin sidecar aún no tiene suficiente contexto para tomar decisiones de enrutamiento HTTP o gRPC en capa 7 — eso lo dejan a los proxies waypoint, que reintroducen una versión del mismo salto proxy para cualquier servicio que realmente lo requiera.

La aceleración con sockmap de Cilium

El datapath de eBPF de Cilium ha utilizado enforcement basado en sockmap durante años para acelerar conexiones locales — tanto tráfico pod a pod en el mismo nodo como el salto entre una aplicación y la instancia de Envoy integrada de Cilium, que Cilium usa para políticas de red en capa 7. La documentación de arquitectura de Cilium describe un hook de operaciones de socket que observa conexiones TCP a un par local (incluyendo un proxy local) y adjunta un camino rápido de envío/recepción basado en sockmap una vez que se detecta, permitiendo que los mensajes eviten las capas de política y NAT de Cilium en ruta al socket del par.

Ejecutar Cilium debajo de Istio específicamente — en lugar de usar las capacidades nativas de mesh de Cilium — requiere cuidado. La guía de integración actual de Cilium con Istio indica que el balanceo de carga basado en socket de Cilium para Servicios de Kubernetes (un mecanismo relacionado, pero distinto, usado para reemplazar kube-proxy) puede interferir con la redirección iptables de Istio, a menos que se configure explícitamente con la opción socketLB.hostNamespaceOnly, y que el CNI esté configurado como cni-exclusive: false para que Cilium y el plugin CNI de Istio puedan coexistir en el mismo nodo.

Cilium no es la única CNI que adopta este enfoque, y es importante ser honesto sobre cómo se compara. Calico implementó una característica de aceleración similar basada en eBPF sockmap ya en Calico 3.8 en 2019, con un blog de ingeniería de Tigera que lo describía en ese momento como una forma de evitar gran parte de la sobrecarga de red del arquitectura sidecar. Curiosamente, la documentación actual de Tigera aún marca esa función como experimental y advierte explícitamente contra su uso en clusters de producción, citando problemas de fiabilidad que requieren correcciones en el kernel upstream — un recordatorio útil de que “basado en eBPF” y “listo para producción” no son sinónimos, incluso años después de que una función se lanza.

Merbridge, un proyecto open-source más pequeño, adopta un enfoque similar, reemplazando la redirección iptables usada por Istio, Linkerd y Kuma con redirección basada en sockmap.

---

Balanceo de carga en kernel de próxima generación

La redirección con sockmap resuelve la mitad Layer-4 del problema — mover bytes entre dos sockets locales — pero no tiene concepto de solicitudes HTTP, flujos gRPC o reglas de enrutamiento. Como dicen los investigadores de XLB, las herramientas L4 como sockmap son bloques de construcción útiles, pero no llevan suficiente contexto por sí solas para manejar decisiones de enrutamiento o balanceo en capa 7; eso históricamente ha implicado devolver el mensaje a un proxy en espacio de usuario completo como Envoy, independientemente de la velocidad del salto de socket.

XLB, desarrollado por Yuejie Wang, Chenchen Shou, Jiaxu Qian y Guyue Liu en la Universidad de Pekín y publicado en febrero de 2026, avanza más: en lugar de redirigir bytes a un proceso proxy separado, mueve la lógica de balanceo en capa 7 directamente al kernel. El diseño extiende la abstracción de socket con dos nuevos tipos — un “proxy socket” que contiene la lógica de balanceo para una conexión cliente, y “sockets de instancia” preestablecidos con cada backend — y usa mapas eBPF anidados para representar la configuración de enrutamiento estilo Envoy (clusters, rutas, listeners) como estructuras de datos en kernel, haciéndolo compatible con las herramientas de control de Envoy e Istio sin requerir cambios en la aplicación.

Los números reportados son sorprendentes. Medido contra Istio y Cilium en despliegues de 50 o más microservicios, el artículo reporta hasta 1.5x mayor throughput y una reducción del 60% en la latencia promedio de extremo a extremo. En un microbenchmark más granular con 128 conexiones concurrentes, XLB entregó 2.18x y 1.83x el throughput de Istio y Cilium respectivamente. En una prueba separada con tasa de solicitudes fija en 60,000 por segundo, XLB usó aproximadamente un 75% y 76% menos CPU que Istio y Cilium en ese mismo throughput — los autores atribuyen la mayor parte de esa diferencia a eliminar los costos de programación, cambio de contexto y coherencia de caché entre procesos, que implica correr el proxy como proceso separado de la aplicación, un costo que persiste incluso cuando el salto de socket entre ellos está acelerado por sockmap.

El artículo también describe una implementación en producción real: un cliente bancario que ejecuta microservicios de procesamiento de pagos en más de 100 nodos ARM (Kunpeng-920), donde XLB redujo la latencia de transacción en aproximadamente un 41%, disminuyó el consumo de CPU relacionado con proxies en un orden de magnitud, y permitió que aproximadamente un 30% más de instancias de servicio corrieran en cada nodo — un margen útil para absorber picos de transacción durante períodos de alta demanda. Los autores lo describen como el primer balanceador de carga L7 basado en eBPF que conocen y que sirve a clientes externos en una nube pública.

Es importante ser precisos: XLB es un sistema de investigación descrito en un artículo académico reciente con un estudio de caso en producción, no — según se puede confirmar — un proyecto open-source disponible para descargar hoy. Es una señal fuerte de hacia dónde va la red en kernel, más que una herramienta lista para usar en un proyecto de fin de semana.

---

Impacto en rendimiento de la red Zero-Stack

1. Menor latencia, con advertencias

Eliminar la sobrecarga de la disciplina de enrutamiento, la tabla de enrutamiento y el encapsulado de protocolos reduce medible la latencia de interprocesos local. Benchmarkings informales independientes de una carga de eco redirigida con sockmap han encontrado una reducción de aproximadamente el 30% en la latencia en comparación con la ruta sin aceleración — una ganancia significativa, aunque más modesta que la idea de “casi instantáneo”.

También vale la pena saber que la tecnología tuvo un inicio más complicado que su madurez actual sugiere. Cuando ingenieros de Cloudflare compararon una implementación temprana de TCP splicing basada en sockmap en 2019 en un kernel 4.14 recién lanzado, sockmap fue la opción más lenta en todas las pruebas, con paradas ocasionales de varios milisegundos atribuidas a bugs del kernel de esa época. Comparaciones académicas más recientes muestran un panorama más positivo pero aún matizado: un artículo de 2023 sobre la arquitectura FlatProxy encontró que la redirección simple con sockmap tuvo solo un efecto menor en la latencia en su configuración de prueba, y que la ventaja en throughput sobre un proxy Envoy completo desaparecía cuando las conexiones TCP concurrentes superaban aproximadamente cuatro — limitación que los autores atribuyen a la falta de gestión nativa de conexiones en sockmap. Resumen justo: sockmap es una victoria duradera para cargas altas de bytes y muchas conexiones, pero no es una solución gratuita ni universal, y esa brecha impulsa la investigación hacia sistemas L7 en kernel más completos como XLB.

2. Ahorro real de CPU

El caso de CPU es más fácil de cuantificar con números concretos. Más allá del principio general de que menos cambios de contexto y menos procesamiento de protocolos significan menos ciclos desperdiciados, los benchmarks de XLB muestran aproximadamente un 75% menos de CPU a una tasa de 60K req/s comparado con Istio, y un 76% menos respecto a Cilium, con una reducción de CPU en orden de magnitud en la implementación de producción bancaria de XLB. Para hosts con muchos contenedores, la CPU ahorrada en proxying es CPU — o densidad de instancias — recuperada para el trabajo real de la aplicación.

3. La seguridad es real, pero no automática

Una suposición común es que saltarse iptables significa renunciar a la firewall y la política de seguridad. En la práctica, sistemas basados en eBPF como Cilium reimplementan la política de forma nativa: el datapath de Cilium mapea cada paquete a una identidad derivada de etiquetas de Kubernetes y aplica políticas L3/L4 (y, a través de su proxy, L7) antes de que cualquier camino rápido de sockmap pueda activarse, asegurando que las conexiones aceleradas no queden sin control.

Eso sí, “implementado en eBPF” no es sinónimo de “libre de bugs.” El código kernel de sockmap ha tenido problemas de seguridad reales. Solo en 2025, el subsistema BPF-TCP/sockmap fue parcheado por una vulnerabilidad de uso-after-free en tcp_bpf_send_verdict() (CVE-2025-39913) que podría ser activada por una asignación de memoria fallida durante el “corking” de mensajes, y fue lo suficientemente grave como para causar un bloqueo del kernel o escalada de privilegios local. También se corrigieron problemas en sockmap/vsock con null-pointer (CVE-2025-21854) y en una interacción de kTLS que afectaba sockmap (CVE-2025-38166). Nada de esto es motivo para evitar sockmap, pero sí para tratarlo como cualquier otra superficie de ataque del kernel: seguir los CVEs de tu distribución y mantener los parches actualizados, en lugar de asumir que “es eBPF” garantiza seguridad.

---

Desafíos y perspectivas futuras

eBPF sockmap acceleration es realmente útil, pero conlleva consideraciones operativas.

Primero, los requisitos de versión del kernel son más precisos que “reciente suficiente.” BPF_MAP_TYPE_SOCKMAP requiere al menos kernel 4.14; BPF_MAP_TYPE_SOCKHASH, que la mayoría de despliegues reales usan por su mayor flexibilidad, requiere 4.18; y si tu carga incluye UDP, querrás un kernel lo suficientemente nuevo para incluir la ruta de redirección BPF_SK_SKB_VERDICT entre protocolos, que empezó a llegar en 2021. Las organizaciones que usan kernels empresariales de soporte a largo plazo más antiguos deben verificar el estado de backport de su distribución en lugar de asumir que “tenemos eBPF” es suficiente.

Segundo, la resolución de problemas requiere nuevas herramientas. Capturas tradicionales como tcpdump que se conectan a las capas inferiores del controlador de red y TCP no muestran los payloads redirigidos por sockmap — solo la configuración y desconexión de conexiones aparecerán en una captura de loopback. Los equipos de plataforma necesitan observabilidad nativa en eBPF, como Hubble de Cilium, para ver qué pasa realmente con el tráfico local acelerado.

Tercero — y esto puede pasar desapercibido en marketing de proveedores — la madurez varía mucho según la implementación. La aceleración basada en sockmap de Cilium ha sido parte estable y documentada de su arquitectura durante años. La característica comparable de Calico, en cambio, ha tenido una advertencia explícita de experimental en la documentación de Tigera desde su introducción en 2019. Antes de adoptar sockmap en un CNI o service mesh, conviene verificar el estado actual de producción de esa implementación en lugar de asumir que todas las funciones de eBPF sockmap están igual de probadas.

Conclusión

El cambio a microservicios cloud-native trajo flexibilidad arquitectónica real, pero también una carga significativa en la pila de red de Linux diseñada para internet abierto, no para contenedores adyacentes en un solo host. A medida que aumenta la densidad de contenedores, enrutar el tráfico local de proceso a proceso a través de toda la encapsulación TCP/IP se vuelve cada vez más costoso.

La aceleración con eBPF sockmap cierra una parte importante de esa brecha hoy, y es lo suficientemente madura — al menos en implementaciones como Cilium — para estar en producción ya. La frontera avanza más allá: desde la simple redirección de bytes a sistemas como XLB que trasladan decisiones de balanceo en capa 7 al kernel, eliminando el proceso sidecar en lugar de solo acelerar el salto hacia él. La capa que mejor se adapte a cada carga de trabajo está clara: la red residente en kernel, no los proxies en espacio de usuario, será donde provengan las próximas mejoras de rendimiento en microservicios.

---

Registro de cambios

Metadatos eliminados - Se eliminó la línea de meta-descripción SEO en negrita del borrador original.

Corregido - Requisito de versión del kernel para sockmap: el borrador afirmaba que eBPF “ha estado presente desde el versión 4.4”. Verificado en la documentación oficial del kernel y corregido a los requisitos precisos: BPF_MAP_TYPE_SOCKMAP requiere kernel 4.14 y BPF_MAP_TYPE_SOCKHASH requiere kernel 4.18. - La estimación de “tres a cuatro veces” de la cantidad de saltos en la pila para los saltos de sidecar ahora está acompañada de una cifra precisa y documentada (tres recorridos) de un estudio de medición académico de 2026, en lugar de una aproximación sin fuente.

Verificado como preciso, sin cambios sustantivos - La explicación del recorrido de 9 pasos del paquete loopback, los mecanismos de sockmap/sockhash/SK_MSG/bpf_msg_redirect_map() y la afirmación de que tcpdump no puede ver los payloads redirigidos por sockmap — todo confirmado en la documentación del kernel, referencias de eBPF y tutoriales independientes. - La afirmación de rendimiento de XLB (“hasta 1.5x mayor throughput, 60% menor latencia vs. Istio y Cilium”) ya era precisa en el borrador original. Ahora se atribuye a la fuente real — un artículo reciente (febrero de 2026) de la Universidad de Pekín — con detalles verificables adicionales (arquitectura, desglose de benchmarks y un caso de estudio en producción).

Agregado (información nueva y verificada) - Estado de disponibilidad general del modo Ambient de Istio (Istio 1.24, noviembre de 2024) y su relación con el problema de capa 7 que trata este artículo, extraído del blog de Istio. - Detalle operativo actual (no histórico) sobre cómo correr Cilium debajo de Istio, incluyendo las banderas específicas de configuración para evitar conflictos, extraído de la documentación actual de Cilium. - La característica de aceleración de sidecar de Calico y su estado de “experimental, no para producción” según la documentación actual de Tigera, además de una mención breve del proyecto Merbridge. - Contexto de rendimiento equilibrado, basado en fuentes verificadas (benchmark de Cloudflare en 2019, artículo de FlatProxy en 2023 y una prueba independiente de aproximadamente un 30% de reducción en latencia real), reemplazando la idea de “latencia casi cero / velocidad de memoria pura” con cifras verificables. - Una advertencia de seguridad que cubre tres CVEs de 2025 que afectan al subsistema kernel BPF-TCP/sockmap, incluyendo un bug de uso-after-free que puede causar escalada de privilegios. - Soporte de UDP en sockmap (TCP inicialmente, soporte completo bidireccional añadido mediante parches desde 2021). - Nota aclaratoria sobre qué es actualmente XLB (un sistema de investigación con despliegue en producción documentado) versus lo que no es (un proyecto open-source disponible para descarga), para evitar sobreestimar su disponibilidad.

Formato - Reducción de la repetición en negrita de las mismas frases clave SEO a lo largo del cuerpo; los términos técnicos ahora se enfatizan en su primera mención en lugar de cada recurrencia.

Fuentes consultadas

• Documentación del sockmap en Linux
• Documentación de eBPF: BPF_PROG_TYPE_SK_MSG
• Tutorial de sockops en eunomia.dev
• LWN: parches UDP / BPF_SK_SKB_VERDICT
• Cloudflare: “SOCKMAP – TCP splicing del futuro” (2019)
• Cilium: guía de integración con Istio
• Tigera/Calico: documentación de aceleración de sidecar
• Artículo XLB (arXiv, feb. 2026)
• Istio: “Ambient Mode alcanza disponibilidad general en v1.24”
• Artículo FlatProxy (arXiv, 2023)
• eBPFChirp: benchmark de latencia en socket local
• CVE-2025-39913 análisis profundo; CVE-2025-21854