Optimización de netip.Addr en Go: Desafíos y Soluciones para Sysadmins Linux

Por qué este problema importa a un sysadmin Linux en 2026

Si mantienes servicios Go en producción — colectores de logs, balanceadores, agentes de red como Akvorado, exporters de Prometheus, gateways IoT — probablemente ya cruzaste con el tipo netip.Addr. Es el reemplazo moderno de net.IP: una dirección IP como valor inmutable de 128 bits con un campo extra que distingue IPv4 de IPv6. Lo que casi nadie sabe es que tiene una asimetría que se vuelve un problema real cuando la manejas a escala: Unmap() existe, pero el camino inverso — convertir un IPv4 a un IPv4-mapped IPv6 — no. Y el workaround que Go te ofrece sale ocho veces más caro que la solución nativa.

Vincent Bernat, autor de Akvorado, publicó en octubre de 2026 una investigación donde demuestra que el patrón recomendado por los mantenedores de Go (netip.AddrFrom16(ip.As16())) genera 7.14 ns por operación, mientras que un método nativo haría lo mismo en 0.88 ns. En un colector que procesa 10 millones de flujos por minuto, la diferencia no es académica: son segundos de CPU por ciclo. En este artículo miramos el problema, las tres alternativas que probó, y por qué su solución — parchar el compilador de Go — abre un debate incómodo sobre cuánto le pedimos al optimizador.

Cómo almacena direcciones IP el paquete net/netip

Para entender la discusión hay que mirar cómo Go representa una dirección internamente. No es una clase con métodos; es un struct plano con un campo addr de 128 bits y un campo z que codifica la familia y la zona:

type Addr struct {
    addr uint128
    z    unique.Handle[addrDetail]
}
type addrDetail struct {
    isV6   bool   // IPv4 es false, IPv6 es true.
    zoneV6 string // != "" sólo si IsV6 es true.
}
var (
    z0    unique.Handle[addrDetail]
    z4    = unique.Make(addrDetail{})
    z6noz = unique.Make(addrDetail{isV6: true})
)

El truco es que AddrFrom4() toma una IPv4, la mete en los 32 bits bajos de un valor de 128 bits (rellenando con 0xffff00000000 como prefijo mapped), y setea z al sentinel z4. Unmap() hace lo inverso: si la dirección es IPv4-mapped IPv6 (::ffff:203.0.113.10), cambia z a z4 y devuelve un valor que Go trata como IPv4.

El método Map() o To6() para la dirección contraria sería trivial:

// To6 mapea una IPv4 a una IPv4-mapped IPv6. Deja una IPv6 sin cambios.
func (ip Addr) To6() Addr {
    if ip.Is4() {
        ip.z = z6noz
    }
    return ip
}

Pero el campo z es privado al paquete net/netip. Desde código externo no puedes tocarlo directamente. Por eso los mantenedores de Go rechazaron el método en issue #54365: argumentan que el usuario escriba netip.AddrFrom16(ip.As16()) y deje que el compilador optimice la cadena. Suena razonable — hasta que mides.

Las tres alternativas que probó Vincent

1. Modificar la librería estándar

Es la solución correcta: agregar func (ip Addr) To6() Addr dentro de net/netip, donde sí se tiene acceso al campo z. La función resultante cuesta 0.8775 ns por operación, según los benchmarks de Vincent con Go 1.27.1 en un AMD Ryzen 5 5600X. El ensamblador que genera el compilador es corto y limpio:

; AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 CMPQ  net/netip·z4(SB), CX     ; chequea si es IPv4
 JNE   end                      ; si no, termina
 MOVQ  net/netip·z6noz(SB), CX  ; CX = netip.z6noz
end:
 RET

Sólo tres instrucciones: comparar, saltar, mover. Esto es lo que un humano hubiera escrito. El problema es político, no técnico: agregar métodos a tipos estándar requiere pasar por el proceso de revisión del Go team, y la posición oficial es que la operación es trivial y el compilador debería optimizarla.

2. Como helper externo

Como z es privado, hay que dar el rodeo vía los métodos públicos As16() y AddrFrom16():

// AddrTo6 mapea una IPv4 a una IPv4-mapped IPv6. Deja una IPv6 sin cambios.
func AddrTo6(ip netip.Addr) netip.Addr {
    if ip.Is4() {
        ip = netip.AddrFrom16(ip.As16())
    }
    return ip
}

Esto es lo que un usuario típico escribe cuando necesita la conversión. Es limpio, no requiere unsafe, y funciona. El problema es el rendimiento: 7.137 ns por operación, casi 8 veces más caro. El ensamblador generado tiene 14 instrucciones y dos stacks pushes:

; AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 PUSHQ   BP
 MOVQ    SP, BP
 SUBQ    $32, SP
 CMPQ    net/netip·z4(SB), CX  ; chequea si es IPv4
 JNE     end                   ; si no, termina
 MOVBEQ  AX, net/netip·a16+16(SP)     ; empaca addr a16 en stack
 MOVBEQ  BX, net/netip·a16+24(SP)
 MOVUPS  net/netip·a16+16(SP), X0     ; copia 16 bytes via XMM
 MOVUPS  X0, net/netip·addr(SP)
 MOVQ    net/netip·z6noz(SB), CX
 MOVBEQ  net/netip·addr(SP), AX       ; desempaca
 MOVBEQ  net/netip·addr+8(SP), BX
end:
 ADDQ    $32, SP
 POPQ    BP
 RET

El compilador detecta que As16() y AddrFrom16() son pequeños y los inline, pero la cadena pack → copy → unpack queda visible. El round-trip por memoria a través de un array [16]byte es lo que cuesta.

3. Con unsafe

La tercera vía aprovecha que unsafe.Pointer permite construir un proxy con el mismo layout de memoria y modificar el campo z directamente:

type addrProxy struct {
    addr [2]uint64      // netip.uint128
    z    unsafe.Pointer // unique.Handle[netip.addrDetail]
}
var (
    anyIPv6    = netip.IPv6Unspecified()
    netipZ6noz = (*addrProxy)(unsafe.Pointer(&anyIPv6)).z
)
func AddrTo6(ip netip.Addr) netip.Addr {
    if !ip.Is4() {
        return ip
    }
    (*addrProxy)(unsafe.Pointer(&ip)).z = netipZ6noz
    return ip
}

Esto cuesta 0.8682 ns — el mismo rendimiento que la solución de la librería estándar, porque el ensamblador es idéntico. La diferencia filosófica: dependés de que netip.Addr mantenga su layout interno, y Go sólo lo garantiza por una versión. Cambió el layout en Go 1.22 cuando introdujeron unique. Si cambia de nuevo, tu código rompe en producción sin aviso del compilador.

El benchmark y por qué 8x importa

goos: linux
goarch: amd64
pkg: github.com/vincentbernat/go-netip-addrto6
cpu: AMD Ryzen 5 5600X 6-Core Processor
                   │     sec/op     │
AddrTo6/safe            7.137n ± 0%
AddrTo6/unsafe         0.8682n ± 2%
AddrTo6/builtin        0.8775n ± 2%

Ocho veces. Suena a número de marketing hasta que pensás en producción. Si procesás 10 millones de direcciones por minuto — número conservador para un colector de flows tipo Akvorado, un IDS que mira tráfico, o un balanceador que normaliza direcciones para rate limiting — la versión safe consume 71.37 ms de CPU por minuto, mientras que la versión nativa consume 8.78 ms. La versión safe te cuesta 62.59 ms extra por minuto, 3.75 segundos por hora, 90 segundos por día. En un servidor con 32 cores, eso no es nada. En un edge device con un ARM Cortex-A53 o un Atom viejo, es la diferencia entre procesar el tráfico y empezar a perder paquetes.

Cómo parcheó el compilador de Go

El segundo artículo de Vincent es donde la historia se vuelve una clase de compiladores. La pregunta es: ¿por qué el optimizador de Go, que se supone es bueno, no detecta que la cadena pack → copy → unpack es redundante? La respuesta corta: porque la fase de memcombine corre demasiado tarde, después de que late opt ya desordenó las instrucciones y los bytes forwarded rompen la oportunidad de combinar.

Go 1.27 introdujo un flag útil para dumpear el IR en distintos puntos:

$ GOTOOLCHAIN=go1.27.1 GOAMD64=v3 go build -a -gcflags="-d=astdump=AddrTo6Safe" .
Writing text ast output for AddrTo6Safe to AddrTo6Safe.ast
Writing html ast output for AddrTo6Safe to AddrTo6Safe.html

La fase de noding (donde se construye el IR) es el lugar para hacer la transformación. Vincent agregó un rewrite en cmd/compile/internal/noder/reader.go que detecta el patrón netip.AddrFrom16(ip.As16()) y lo reemplaza por un struct literal que evita el round-trip:

func rewriteAddrFrom16As16(n ir.Node) ir.Node {
    call, ok := n.(*ir.CallExpr)
    if !ok || call.Op() != ir.OCALLFUNC ||
        len(call.Args) != 1 || len(call.Init()) != 0 ||
        !isNetipFunc(call.Fun, "AddrFrom16") {
        return nil
    }
    inner, ok := call.Args[0].(*ir.CallExpr)
    if !ok || inner.Op() != ir.OCALLFUNC ||
        len(inner.Args) != 1 || len(inner.Init()) != 0 ||
        !isNetipFunc(inner.Fun, "Addr.As16") {
        return nil
    }
    // ... construye netip.Addr{addr: ip.addr, z: netip.z6noz}
}

El primer intento — reemplazar durante noding — funcionó sobre el papel pero no en la práctica: las reglas de rewrite corren antes de que memcombine tenga oportunidad de colapsar las operaciones. La cadena de bytes forwarding queda fragmentada: cuatro bytes forwarded y cuatro bytes cargados, y memcombine no puede combinarlos. La solución fue ejecutar memcombine antes de late opt:

; commit netipmap-fix4
; cmd/compile/internal/ssacompile: run memcombine before late opt

Después de ese cambio, el benchmark confirma el objetivo: el helper vuelve al rendimiento nativo.

                   │   Go 1.26.8    │             Our branch              │
                   │     sec/op     │    sec/op     vs base               │
AddrTo6/safe          6.5470n ±  0%   0.8944n ± 4%  -86.34% (p=0.002 n=6)
AddrTo6/unsafe        0.9071n ±  3%   0.8682n ± 1%   -4.28% (p=0.002 n=6)
AddrTo6/builtin       0.8871n ±  2%   0.8785n ± 1%        ~ (p=0.310 n=6)

Qué decisión tomar hoy como sysadmin

Vincent abrió issue #81994 proponiendo agregar Addr.To6() a la librería estándar. Si te importa el rendimiento y puedes esperar, dale 👍 al issue y sigue la discusión. Mientras tanto, las opciones reales son tres:

1. Usar el helper externo y aceptar el costo de 7 ns/op. Es la opción honesta y portable. Para la mayoría de servicios (que no procesan millones de IPs por segundo), el costo es invisible. Para servicios con throughput alto, no.
2. Usar el wrapper con unsafe y congelar la versión de Go. Pinneá tu código a una versión específica de Go en go.mod, agregá tests que detecten cambios de layout en netip.Addr, y documentá que la dependencia rompe si actualizás Go sin revalidar.
3. Fork local de Go con el parche de memcombine. Es lo que Vincent terminó haciendo para Akvorado. Es viable si tu organización mantiene su propia toolchain Go, pero no es razonable para un sysadmin que quiere mantener un colector simple.

Para la mayoría de sysadmins que mantienen colectores de logs, exporters, o balanceadores, mi recomendación es la primera opción. El helper externo es legible, no rompe con actualizaciones de Go, y el costo de 7 ns por dirección sólo importa si ya tienes un cuello de botella identificado en CPU y un dataset de direcciones que justifique la optimización. Si llegaste a este artículo porque viste el pico de CPU y sospechas de netip, el primer paso es perfilar antes de cambiar nada.

Por qué esto es un debate abierto, no un bug

El Go team no agregó To6() por una razón de filosofía: la librería estándar debe ser pequeña y el compilador debe mejorar con el tiempo. La promesa es que escribir el patrón “obvio” (AddrFrom16(ip.As16())) va a ser igual de rápido que un método nativo una vez que el optimizador madure. Esa promesa tiene dos partes: una técnica (¿puede el optimizador detectar la redundancia?) y una política (¿es razonable pedirle al usuario que confíe en que va a mejorar?).

La respuesta de Vincent muestra que la promesa técnica ya está cerca — su parche a memcombine logra el rendimiento nativo sin tocar la API. Pero la respuesta política sigue abierta: si el parche se acepta en upstream, todos los usuarios obtienen el beneficio sin cambiar una línea de código; si no, queda como branch personal y la asimetría entre Unmap() y la dirección inversa se convierte en deuda técnica de la comunidad. Mientras tanto, si tu servicio depende de esta conversión y mediste que es un problema, ya sabes qué parche aplicar.

Resumen

El tipo netip.Addr tiene una asimetría documentada: Unmap() convierte IPv4-mapped IPv6 a IPv4, pero el camino inverso no existe en la API pública. El workaround recomendado (AddrFrom16(ip.As16())) cuesta 8 veces más que una operación nativa porque el compilador no logra colapsar el round-trip por memoria. Vincent Bernat demostró que un parche en memcombine del compilador de Go elimina la brecha, pero el Go team tiene que decidir si aceptar el cambio. Mientras tanto, para sysadmins Linux: usar el helper externo, perfilar primero, y sólo escalar a unsafe si tienes un cuello de botella real.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux
• Guía Definitiva para Sysadmins: Configuración de Bonding de Interfaces de Red en Linux
• Guía Definitiva: Configura AppArmor para Proteger tus Aplicaciones en Linux