HTTP/2 en claro llega a Go 1.24

Go 1.24 trae una capacidad que, aunque no va a cambiar cómo despliegas todo tu stack, sí abre una puerta bastante útil para casos muy concretos: HTTP/2 en claro, también conocido como h2c. Si vienes trabajando con Go en servicios internos, proxies, sidecars o entornos donde TLS termina antes de llegar a tu aplicación, esto te interesa de verdad.

Hasta ahora, si querías HTTP/2 en Go, lo normal era ir por HTTPS. Eso funciona bien para internet público, pero no siempre encaja con arquitecturas internas, redes privadas o plataformas que ya hacen terminación TLS en otro punto. Ahí es donde h2c entra como opción práctica: te deja usar las ventajas de HTTP/2 sin cifrar el transporte entre cliente y servidor. No es para todo, pero en ciertos despliegues te ahorra complejidad y te evita inventar parches raros.

Qué es HTTP/2 en claro y por qué importa

HTTP/2 en claro significa que la conexión usa HTTP/2 sin TLS. En la práctica, esto suele referirse a h2c, que es el mecanismo de upgrade o de conexión previa para hablar HTTP/2 sobre TCP sin cifrado. No es el camino más común en producción pública, pero sí aparece en entornos internos donde el tráfico ya viaja dentro de una red confiable o detrás de otro componente que se encarga del cifrado.

La razón por la que importa es simple: HTTP/2 no solo es “la versión nueva” de HTTP. Trae multiplexación, mejor manejo de conexiones y menos fricción cuando tu servicio hace muchas solicitudes concurrentes. Si tu app interna tiene tráfico repetitivo entre microservicios, o si un proxy frontal ya centraliza TLS, usar HTTP/2 entre capas puede reducir overhead y hacer más eficiente el uso de conexiones.

Go 1.24 hace más natural usar este patrón desde el lado del servidor. Según la documentación oficial del soporte de HTTP/2 en Go, el paquete net/http ya tenía piezas para HTTP/2, pero la historia de h2c era menos directa y dependía de configuraciones específicas o de librerías auxiliares. Con 1.24, el soporte se vuelve más accesible para ciertos escenarios de servidor. Puedes revisar la documentación oficial de Go en https://pkg.go.dev/net/http y las notas de la versión en https://go.dev/doc/go1.24.

H2C no es lo mismo que HTTPS

Aquí vale separar conceptos porque se confunden fácil. HTTPS es HTTP sobre TLS. H2C es HTTP/2 sin TLS. Los dos pueden usar HTTP/2, pero el contexto de seguridad cambia por completo. Si el tráfico sale de tu red privada o pasa por internet, h2c no te conviene.

En cambio, si tu servicio corre dentro de Kubernetes, en una VPC privada, en una red de Cloud Run con un proxy que termina TLS antes de llegar al backend, o entre componentes que ya se autentican por otros medios, h2c puede ser razonable. La clave no es “usar HTTP/2 porque sí”, sino reducir complejidad donde el cifrado ya está resuelto en otra capa.

Qué gana tu servicio con HTTP/2

No esperes magia. Lo que obtienes es una mejor forma de transportar muchas solicitudes sobre menos conexiones. Eso puede ayudar cuando tienes fan-out entre servicios, streams cortos o clientes que hacen varias llamadas seguidas al mismo backend.

En un sistema interno típico, eso se traduce en menos conexiones abiertas, menos handshakes y una mejor utilización de recursos. No significa que tu API vaya a responder 10 veces más rápido. Sí puede bajar latencia en ciertos flujos y mejorar la eficiencia del servidor cuando el patrón de tráfico encaja con HTTP/2.

Cuándo sí te conviene usarlo

La mejor forma de pensar h2c es como una herramienta para arquitecturas controladas. No la pongas por defecto en cualquier API pública. Úsala cuando el entorno te da garantías de red y cuando el costo de TLS entre capas no aporta valor real.

Un caso muy común es el de servicios internos detrás de un balanceador o proxy que ya termina TLS. Otro caso es un servicio que solo habla con otros servicios dentro del mismo cluster. También encaja en escenarios de plataforma donde el runtime o el mesh gestiona seguridad y autenticación aparte del transporte.

Casos reales donde tiene sentido

1. Microservicios dentro de Kubernetes que se comunican por red interna y usan service mesh o mTLS en otra capa.
2. Backends detrás de un proxy inverso que termina TLS y reenvía tráfico interno por TCP plano.
3. Servicios de administración o control plane que nunca se exponen a internet público.
4. Despliegues en Cloud Run o plataformas similares donde el frontend maneja TLS y tu contenedor recibe tráfico ya controlado.
5. Entornos de laboratorio, staging o integración donde quieres probar HTTP/2 sin montar certificados en cada nodo.

En todos esos casos, la pregunta no es si h2c es “más moderno”. La pregunta correcta es si te simplifica la arquitectura sin abrir una superficie de riesgo innecesaria. Si la respuesta es sí, vale la pena considerarlo.

Tabla rápida de decisión

Qué cambia en Go 1.24

Go ya tenía soporte para HTTP/2 en el cliente y en servidores TLS, pero el uso de h2c en servidor era menos directo y, en la práctica, mucha gente terminaba dependiendo de paquetes externos o de configuraciones más enredadas. Con Go 1.24, el soporte para este caso se vuelve más accesible para servidores que necesitan hablar HTTP/2 sin TLS.

Eso no significa que ahora debas migrar todo tu stack. Significa que si tienes un caso concreto, puedes resolverlo con menos piezas. Y menos piezas suele ser mejor, sobre todo cuando administras infraestructura en equipos pequeños o medianos donde cada dependencia extra se traduce en más mantenimiento.

La documentación oficial de Go sigue siendo la fuente que conviene revisar antes de tocar producción. Si vas a implementar esto, mira también el comportamiento de tu proxy, tu balanceador y tu plataforma de despliegue. El servidor puede soportar h2c, pero tu infraestructura alrededor puede bloquearlo, convertirlo o simplemente no pasarlo como esperas.

Ejemplo mínimo de servidor

Un ejemplo básico ayuda a aterrizarlo. La idea es que tu servidor escuche en TCP y acepte solicitudes HTTP/2 en claro cuando el cliente lo negocia de forma compatible.

package main

import (
	"fmt"
	"net/http"
)

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("Content-Type", "text/plain")
		fmt.Fprintln(w, "ok")
	})

	server := &http.Server{
		Addr:    ":8080",
		Handler: mux,
	}

	if err := server.ListenAndServe(); err != nil {
		panic(err)
	}
}

Ese código por sí solo no te garantiza h2c en todos los casos, porque el soporte real depende de cómo configures el servidor y del modo de negociación que use tu cliente o proxy. La idea aquí es mostrar que el punto de entrada sigue siendo net/http, no una arquitectura completamente distinta.

Cómo implementarlo sin romper tu infraestructura

Antes de activar h2c en un servicio real, revisa la ruta completa del tráfico. Muchas veces el problema no está en Go, sino en el balanceador, el ingress o el proxy que tienes delante. Si ese componente no entiende HTTP/2 en claro, tu servidor puede estar listo y aun así no recibir tráfico como esperas.

También conviene pensar en observabilidad. Si hoy monitoreas latencia, errores 5xx y número de conexiones, compara esos datos antes y después. No asumas mejora automática. En algunos entornos, HTTP/2 ayuda bastante. En otros, el beneficio es marginal y no justifica tocar algo que ya funciona.

Pasos recomendados antes de producción

1. Confirma si el tráfico será interno o controlado. Si sale a internet, descarta h2c.
2. Revisa si tu proxy o ingress soporta HTTP/2 en claro o si solo hace passthrough de TCP.
3. Prueba con una sola ruta, por ejemplo /health o un endpoint de bajo riesgo.
4. Mide latencia p50, p95 y número de conexiones antes y después.
5. Verifica logs y métricas del lado del cliente y del servidor.
6. Documenta qué capa termina TLS para que nadie asuma mal el flujo.

Si usas Kubernetes, también vale revisar cómo entra el tráfico al pod. Muchas veces el ingress habla HTTP/1.1 hacia atrás aunque el cliente externo use HTTP/2. En ese caso, activar h2c en tu app no aporta nada si la capa intermedia no lo aprovecha.

Compatibilidad con proxies y balanceadores

Este es el punto que más suele generar confusión. Un proxy puede aceptar HTTP/2 desde el cliente y reenviarlo como HTTP/1.1 al backend. Eso no está mal, solo significa que tu aplicación no verá los beneficios de HTTP/2 entre capas.

Si quieres aprovechar h2c de verdad, debes confirmar que el proxy haga passthrough o que el backend hable directamente con el cliente interno. Plataformas como Cloud Run o ciertos gateways pueden tener comportamientos específicos, así que conviene leer la documentación de la plataforma además de la de Go. En ambientes gestionados, una decisión de routing puede cambiar por completo el resultado.

Límites, riesgos y cosas que no debes asumir

El mayor límite de h2c es obvio: no hay cifrado. Eso lo vuelve inapropiado para tráfico expuesto o redes que no controlas. Si alguien puede interceptar la conexión, puede leer el contenido. No hay atajo aquí.

Otro límite es operativo. No todos los clientes, proxies o SDKs soportan h2c igual de bien. Algunos esperan HTTPS como estándar y otros requieren flags o configuración especial. Eso significa que el costo de adopción puede subir si tu ecosistema es mixto.

También hay un riesgo de falsa sensación de seguridad. A veces la gente ve “está dentro de la red” y asume que todo está bien. Pero una red privada no reemplaza autenticación, autorización, segmentación ni auditoría. Si vas a usar h2c, hazlo porque el transporte en claro tiene sentido dentro de una arquitectura ya protegida, no porque te ahorra cinco minutos de configuración.

Qué revisar antes de decidir

• ¿El servicio recibe tráfico desde fuera de tu red privada?
• ¿Hay un proxy o mesh que ya maneja TLS?
• ¿Tu cliente soporta h2c sin hacks?
• ¿Tienes métricas para comparar antes y después?
• ¿Puedes revertir el cambio rápido si algo falla?

Si respondes “no” a varias de esas preguntas, probablemente aún no es el momento. Y eso también es una buena decisión técnica.

Ejemplo de uso en un despliegue interno

Imagina un servicio de facturación que solo consume otro servicio de catálogo dentro del mismo cluster. Hoy ambos se hablan con HTTP/1.1 sobre TCP interno, y cada request abre más carga de la necesaria. Si migras esa comunicación a HTTP/2 en claro, puedes mejorar el uso de conexiones sin meter certificados entre pods.

Otro ejemplo: una plataforma con API gateway público y varios servicios internos. El gateway termina TLS, autentica al usuario y luego habla con backends internos. En ese tramo interno, h2c puede ser una opción si el gateway y los backends lo soportan. No cambias la experiencia del usuario final, pero sí puedes simplificar la capa interna.

En LatAm esto también aparece mucho en equipos pequeños que operan en nubes gestionadas y quieren evitar el mantenimiento de certificados por servicio. Ojo: eso no significa renunciar a seguridad. Significa moverla a la capa correcta y no duplicar trabajo donde no hace falta.

Tabla resumen

Go 1.24 no convierte h2c en el nuevo estándar, pero sí lo vuelve una herramienta más accesible para quien tiene una necesidad real. Si administras servicios internos, despliegues controlados o arquitecturas donde TLS ya se resuelve en otra capa, vale la pena evaluarlo con números y no con intuición.

La decisión correcta no es “usar HTTP/2 porque sí”. Es preguntarte si el tráfico, la red y la plataforma justifican quitar TLS de ese tramo concreto. Si la respuesta es sí, Go 1.24 te da una forma más limpia de hacerlo.