Zero-copy en Go: rendimiento real en backend

Si tu servicio Go mueve archivos, proxys, logs o respuestas grandes, probablemente ya viste este patrón: la CPU sube más de lo esperado, la latencia se ensucia y el profiler muestra tiempo en funciones que, a simple vista, “solo copian bytes”. Ahí aparece la idea de zero-copy. No significa magia ni ausencia total de trabajo; significa reducir copias innecesarias entre espacio de usuario y kernel para gastar menos CPU y menos memoria.

En Go, el tema importa porque io.Copy es cómodo, muy usado y bastante bueno para la mayoría de casos. Pero cuando el tráfico sube, esa comodidad puede tener costo. Si tu backend sirve descargas, reenvía streams entre sockets o actúa como gateway de archivos, entender sendfile, splice y el comportamiento real de io.Copy te ayuda a elegir mejor. No se trata de reemplazar todo, sino de saber en qué ruta el sistema operativo puede hacer el trabajo pesado por ti.

Qué significa zero-copy de verdad

Zero-copy no quiere decir que no exista ninguna copia en absoluto. En la práctica, quiere decir que evitas copias entre buffers de usuario cuando el kernel puede mover datos directamente entre origen y destino, o al menos reducir el número de saltos. Eso baja presión sobre CPU, evita tocar memoria dos veces y puede mejorar throughput bajo carga.

La ruta clásica de una transferencia de datos en user space suele ser esta: lees desde un socket o archivo hacia un buffer en tu proceso, luego escribes ese buffer a otro destino. Ese flujo implica al menos una copia del kernel al usuario y otra del usuario al kernel. Si repites eso millones de veces por minuto, el costo se acumula. En cambio, con sendfile el kernel puede leer de un archivo y escribir a un socket sin pasar por tu proceso.

Para equipos backend, el beneficio real aparece en escenarios concretos: descargas de archivos, serving de assets, reverse proxies simples, distribución de logs y pipelines donde un proceso solo reenvía bytes. Si tu aplicación además transforma el contenido, comprime, cifra o inspecciona cada chunk, el efecto se reduce, porque ya estás metiendo trabajo extra en user space.

El camino tradicional: leer y escribir

Supón que tienes un archivo de 256 MB y quieres enviarlo a un cliente HTTP. El patrón más simple en Go es abrir el archivo y copiarlo al ResponseWriter con io.Copy. Eso es limpio y normalmente suficiente. Pero internamente, si no hay optimización específica, la transferencia puede pasar por un buffer en memoria de tu proceso.

Ese buffer no es malo por sí mismo. De hecho, Go reutiliza buffers y evita allocs innecesarias. El punto es otro: aunque no estés creando basura en el heap, sí estás moviendo bytes entre espacios de memoria. En cargas altas, mover bytes cuesta. El costo crece con el tamaño del payload y con la cantidad de conexiones concurrentes.

Qué hace el kernel cuando puede ayudar

En Linux, sendfile permite pasar datos desde un file descriptor de archivo a un socket sin que el proceso tenga que leerlos. El kernel puede leer páginas del archivo y enviarlas al socket usando rutas internas más cortas. Según la documentación oficial de Linux, sendfile(2) está pensado precisamente para esa transferencia directa entre descriptores. Puedes revisar la referencia en la man page oficial: https://man7.org/linux/man-pages/man2/sendfile.2.html

splice va un paso más lejos en algunos escenarios. Permite mover datos entre un descriptor y un pipe, y de ahí a otro descriptor, también evitando copias innecesarias. No es una herramienta universal, pero sí útil para pipelines específicos en Linux. La documentación oficial está en: https://man7.org/linux/man-pages/man2/splice.2.html

io.Copy en Go: cómodo, pero no siempre gratis

io.Copy es una de esas funciones que terminas usando por reflejo. Y con razón: abstrae el tamaño del buffer, funciona con Reader y Writer, y Go intenta usar optimizaciones internas cuando detecta tipos concretos. Pero si no se dan esas condiciones, cae en una ruta genérica de lectura y escritura por buffer.

Eso significa que io.Copy no es “lento” por defecto. Significa que su rendimiento depende del par de tipos que le pasas. Si copias entre un *os.File y un net.Conn, Go puede usar caminos optimizados en ciertos sistemas operativos. Si copias entre wrappers personalizados, decoradores, compresores o lectores intermedios, puedes perder esa posibilidad y volver a la ruta bufferizada.

La documentación de io.Copy en Go explica que intenta usar interfaces como WriterTo y ReaderFrom para evitar copias extra. Vale la pena leerla porque ahí está el detalle que muchas veces se pasa por alto: https://pkg.go.dev/io#Copy

Qué pasa cuando usas wrappers

Un caso común en backend es envolver el ResponseWriter para medir status codes, bytes enviados o timings. Otro es envolver el Reader para contar métricas o aplicar logging. Eso está bien, pero puede romper optimizaciones porque io.Copy ya no ve el tipo concreto que sabe hablar con el kernel de forma más directa.

Por ejemplo, si pones una capa de compresión gzip entre el archivo y la respuesta, ya no puedes usar sendfile de forma directa porque el contenido cambia. En ese caso, el costo de copiar bytes vuelve a ser parte del trabajo necesario. Ahí la pregunta correcta no es “¿cómo activo zero-copy?”, sino “¿realmente puedo evitar la transformación en user space?”.

Cuándo io.Copy sigue siendo la mejor opción

Hay varios casos donde io.Copy sigue siendo la respuesta correcta:

1. Cuando el payload es pequeño y la latencia total está dominada por red o disco.
2. Cuando necesitas portabilidad entre Linux, macOS y Windows.
3. Cuando el contenido se transforma antes de enviarse.
4. Cuando la complejidad operacional de una optimización no compensa el ahorro.

En otras palabras, no cambies código solo por el concepto de zero-copy. Primero mide. Si tu endpoint sirve 20 KB por request, la diferencia entre una ruta optimizada y una genérica probablemente sea irrelevante. Si sirves 2 GB por request a miles de clientes, la conversación cambia.

sendfile y splice: dónde sí hacen diferencia

sendfile suele ser la opción más directa cuando tu flujo es archivo a socket. En Go, esto aparece mucho en servidores HTTP que entregan descargas, media estática o backups. Si el archivo vive en disco local y no necesitas modificarlo, el kernel puede hacer gran parte del trabajo.

splice tiene un perfil más específico. Es útil cuando quieres mover datos entre descriptores sin pasar por buffers de usuario, pero su uso real suele ser más limitado y más dependiente de Linux. En la práctica, muchas implementaciones de alto nivel prefieren sendfile cuando la ruta es archivo a socket y dejan splice para pipelines más complejos.

La clave es entender el presupuesto de tu servicio. Si tu backend maneja 10,000 requests por segundo y una parte importante son transferencias grandes, ahorrar una copia por request puede significar menos CPU, menos throttling en contenedores y más margen para picos. Si tu servicio es pequeño, el beneficio puede quedar escondido detrás de otras latencias.

Comparación rápida

Dónde suele haber ganancia real

La ganancia suele verse en tres métricas: CPU por request, throughput sostenido y p95/p99 de latencia cuando el sistema está cargado. No esperes milagros en el promedio si tu servicio está ocioso. La mejora aparece cuando el volumen es alto y el cuello de botella está en mover bytes, no en calcular lógica de negocio.

También importa el tamaño del archivo o stream. Un archivo de 1 MB puede no justificar nada. Uno de 500 MB sí puede mover la aguja, sobre todo si hay muchas conexiones simultáneas. En infraestructura de LatAm, donde a veces se corre con instancias más pequeñas para controlar costos, esto puede traducirse en menos nodos para el mismo tráfico.

Cómo medir si te conviene en tu backend

Antes de tocar código, define una línea base. Si no mides, solo vas a cambiar una forma de gastar CPU por otra. En Go tienes herramientas suficientes para hacerlo sin adivinar: pprof, métricas de proceso, conteo de requests y observación de latencia por percentil.

El objetivo no es demostrar que sendfile “es más rápido” en abstracto. El objetivo es ver si en tu caso baja el costo por transferencia. Para eso necesitas comparar escenarios con el mismo payload, el mismo hardware y la misma concurrencia. Si cambias todo a la vez, no vas a saber qué mejoró.

Plan de prueba simple

1. Elige un endpoint que sirva un archivo real o un stream grande.
2. Mide CPU, memoria RSS, throughput y p95 con io.Copy.
3. Cambia a una ruta que use optimización del sistema operativo cuando aplique.
4. Repite la prueba con el mismo archivo, misma red y misma cantidad de conexiones.
5. Compara resultados bajo carga, no solo en una request aislada.

Si trabajas en Kubernetes, también mira límites y requests de CPU. A veces la mejora no se ve como “más rápido”, sino como menos throttling. Eso importa mucho porque un contenedor throttled puede tener latencias raras aunque el código sea correcto.

Ejemplo de criterio práctico

Puedes usar una regla simple para decidir si vale la pena profundizar:

• Menos de 100 KB por request: normalmente no priorices zero-copy.
• Entre 100 KB y 10 MB: mide y compara si el endpoint está entre los top consumidores de CPU.
• Más de 10 MB o streams largos: revisa seriamente sendfile o rutas equivalentes.

No es una ley universal, pero sí una forma útil de priorizar. En equipos backend con poco tiempo, este tipo de umbral ayuda a no optimizar el endpoint equivocado.

Implementación práctica en Go

En Go puro, el punto de partida suele ser io.Copy. Si tu caso es simple, puedes escribir algo así:

package main

import (
	"io"
	"net/http"
	"os"
)

func downloadHandler(w http.ResponseWriter, r *http.Request) {
	f, err := os.Open("/var/data/report.pdf")
	if err != nil {
		http.Error(w, "file not found", http.StatusNotFound)
		return
	}
	defer f.Close()

	w.Header().Set("Content-Type", "application/pdf")
	w.Header().Set("Content-Disposition", "attachment; filename=report.pdf")

	_, _ = io.Copy(w, f)
}

Ese código ya es mejor que leer todo el archivo en memoria con os.ReadFile y luego escribirlo. No estás cargando el archivo completo en RAM. Pero si el runtime y el sistema operativo pueden usar una ruta más eficiente, io.Copy puede aprovecharla solo en ciertos casos. La diferencia está en qué tipos concretos intervienen y en si el camino sigue siendo compatible con una transferencia directa.

Cuándo usar sendfile explícitamente

En Go estándar no siempre vas a invocar sendfile a mano, porque muchas veces io.Copy ya resuelve el caso correcto. Pero si estás construyendo una pieza muy específica, o si trabajas cerca del sistema operativo, puedes apoyarte en implementaciones que usen llamadas de bajo nivel. La decisión depende de cuánto control necesitas y cuánto mantenimiento estás dispuesto a asumir.

Si tu equipo mantiene un proxy, un servidor de archivos o una capa de distribución interna, puede valer la pena encapsular esa ruta en un paquete propio. Así separas el caso optimizado del resto del código. Eso evita meter complejidad en handlers comunes que no la necesitan.

Riesgos de una optimización mal aplicada

El error más común es optimizar sin validar compatibilidad. sendfile no sirve para todo. Si necesitas meter headers personalizados, comprimir, cifrar o hacer streaming de datos generados al vuelo, la ruta de archivo a socket ya no aplica. Ahí una implementación forzada puede complicar el código sin dar beneficio real.

Otro riesgo es la portabilidad. splice es esencialmente Linux-first. Si tu stack corre también en macOS para desarrollo local o en Windows para algunos entornos, la ruta especial puede exigir fallbacks bien probados. Si no los tienes, terminas con bugs difíciles de reproducir.

Decisiones que sí ayudan a equipos backend

La mejor forma de pensar este tema es como una matriz de decisión, no como una bandera de “usar zero-copy siempre”. Si tu servicio sirve contenido estático grande, el ahorro es tangible. Si tu servicio hace mucha lógica de negocio y solo manda respuestas pequeñas, la optimización probablemente esté en otro lado.

También conviene mirar el diseño de la API. A veces el problema no es la copia de memoria, sino que estás enviando datos demasiado grandes, demasiado temprano o demasiado seguido. Reducir el tamaño de respuesta, paginar mejor o cachear a nivel de CDN puede darte más beneficio que perseguir una ruta de kernel.

En equipos de LatAm, donde los presupuestos de infraestructura suelen ser más ajustados, esta clase de decisiones tiene impacto directo. Menos CPU por request significa más margen para crecer sin duplicar nodos. Pero ese ahorro solo aparece si el caso de uso encaja. Si no encaja, la optimización se vuelve deuda técnica.

Señales de que vale la pena profundizar

• Tu endpoint está entre los primeros del top 5 de CPU.
• Manejas archivos grandes o streams largos con frecuencia.
• El servicio corre en contenedores con límites de CPU ajustados.
• Ya mediste y viste que io.Copy aparece en el camino caliente.
• El contenido no necesita transformación en tránsito.

Si varias de esas señales se cumplen, vale la pena hacer una prueba seria. Si no, probablemente tengas más retorno optimizando consultas, caché, serialización o acceso a disco.

Tabla resumen

Zero-copy en Go no es una receta universal. Es una herramienta para casos donde mover bytes cuesta demasiado y el flujo de datos encaja con las capacidades del kernel. Si tu backend sirve archivos grandes, proxies o streams intensivos, puede darte una mejora real. Si no, io.Copy sigue siendo una solución sólida, legible y suficiente.

La clave es simple: mide primero, optimiza después y no fuerces una técnica solo porque suena elegante. En producción, lo que importa no es el nombre de la técnica, sino cuánta CPU ahorra, cuánta complejidad agrega y si de verdad mejora la experiencia del usuario.