Go 1.27: cómo funciona la reutilización de conexiones HTTP

sequenceDiagram
    participant C as Cliente
    participant S as Servidor
    C->>S: SYN
    S-->>C: SYN-ACK
    C->>S: ACK y ClientHello TLS
    Note over C,S: hasta aqui, 1 RTT de TCP
    S-->>C: ServerHello y certificado
    C->>S: claves negociadas
    Note over C,S: mas 1 o 2 RTT de TLS segun version
    C->>S: GET /index.html
    S-->>C: 200 OK

func getStatus(url string) (int, error) {
    resp, err := http.Get(url)
    if err != nil {
        return 0, err
    }
    defer resp.Body.Close()
    return resp.StatusCode, nil
}

sequenceDiagram
    participant App as Aplicacion
    participant Lib as net/http
    participant Conn as Conexion TCP
    App->>Lib: http.Get(url)
    Lib->>Conn: GET /status
    Conn-->>Lib: linea de estado y headers
    Lib-->>App: devuelve Response de inmediato
    Note over Lib,Conn: el cuerpo de la respuesta sigue sin leerse del socket
    App->>Lib: resp.Body.Close()
    Note over Lib,Conn: Go 1.26 abandona la conexion sin saber donde termina el cuerpo

go version

package main

import (
    "fmt"
    "net/http"
)

func getStatus(url string) (int, error) {
    resp, err := http.Get(url)
    if err != nil {
        return 0, err
    }
    defer resp.Body.Close()
    return resp.StatusCode, nil
}

func main() {
    status, err := getStatus("https://go.dev")
    if err != nil {
        panic(err)
    }
    fmt.Println("status:", status)
}

GODEBUG=http2client=0 go run main.go

status: 200

package main

import (
    "io"
    "net/http"
)

func getStatus(url string) (int, error) {
    resp, err := http.Get(url)
    if err != nil {
        return 0, err
    }
    defer resp.Body.Close()
    io.Copy(io.Discard, resp.Body)
    return resp.StatusCode, nil
}

package main

import (
    "encoding/json"
    "io"
    "net/http"
)

type statusResponse struct {
    Success bool   `json:"success"`
    Message string `json:"message"`
}

func getMessage(url string) (string, error) {
    resp, err := http.Get(url)
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()

    var out statusResponse
    if err := json.NewDecoder(resp.Body).Decode(&out); err != nil {
        return "", err
    }
    io.Copy(io.Discard, resp.Body)
    return out.Message, nil
}

package main

import (
    "fmt"
    "io"
    "net/http"
    "net/http/httptrace"
)

func main() {
    client := &http.Client{}
    for i := 0; i El valor por defecto de MaxIdleConnsPerHost en net/http es de apenas 2 conexiones por host.
## Errores comunes y buenas prácticas

- **Ignorar el cuerpo porque no lo necesitás**: aunque tu lógica no use el cuerpo, igual hay que drenarlo. El costo de un `io.Copy(io.Discard, ...)` es minúsculo comparado con el de un handshake nuevo.- **Confundir Close() con ya leí todo**: cerrar el `Body` libera recursos, pero no le avisa a `net/http` que consumiste el contenido. Son dos cosas distintas.- **Decodificar JSON y no drenar el resto**: como vimos en el Ejemplo 3, `json.Decoder` puede dejar bytes sin leer aunque tu struct ya esté completo.- **No revisar el tamaño del pool de conexiones**: si tu servicio hace muchas peticiones concurrentes al mismo host, el valor por defecto de `Transport.MaxIdleConnsPerHost` (2) puede ser insuficiente y forzar handshakes de todas formas.- **Medir sin descartar el efecto de HTTP/2**: si tu cliente negocia HTTP/2 automáticamente, no vas a ver este problema porque los streams multiplexados no lo sufren. Para comparar versiones de Go de forma justa, forzá HTTP/1 con `GODEBUG=http2client=0`.

## Comparativa con alternativas

Actualizar la versión de Go no es la única manera de resolver esto. Depende de cuánto control tenés sobre tu código y sobre el servidor del otro lado.
OpciónCuándo usarlaVentajaLimitaciónActualizar a Go 1.27+Proyectos que ya controlan su versión de Go en producciónArregla el problema para todo el código existente sin tocarloNo ayuda si el servidor usa HTTP/1.0 sin keep-aliveio.Copy(io.Discard, resp.Body) manualVersiones de Go anteriores a 1.27, o librerías que no controlásFunciona en cualquier versión de GoHay que acordarse de hacerlo en cada llamadaForzar HTTP/2Cuando el servidor lo soporta y controlás ambos ladosEl problema no existe: los streams no bloquean la conexiónNo todos los servidores ni proxies intermedios lo soportan igualCliente con pool propioCargas muy altas donde el Transport por defecto no alcanzaControl fino sobre el pool de conexionesPerdés compatibilidad directa con el ecosistema estándar de net/http
## Profundizando: cómo decide net/http si reutiliza una conexión

Internamente, `net/http.Transport` mantiene un pool de conexiones ociosas organizado por host. Cuando llamás a `resp.Body.Close()`, el `Transport` decide si esa conexión vuelve al pool o se cierra para siempre.

Esa decisión depende de dos cosas: si `net/http` puede determinar con certeza dónde termina el cuerpo de la respuesta, vía `Content-Length` o el frame final de `Transfer-Encoding: chunked`, y si esos bytes ya fueron consumidos. Hasta Go 1.26, bastaba con que quedaran bytes sin leer para que la conexión se descartara de inmediato, sin intentar nada más.

Go 1.27 cambia exactamente ese punto: en lugar de abandonar la conexión en cuanto detecta cuerpo sin leer, `net/http` intenta leer y descartar esos bytes antes de decidir que no se puede reutilizar, tal como describe el [post oficial del equipo de Go](https://go.dev/blog/http-connection-reuse). Esto hace que una reutilización de conexiones HTTP exitosa ya no dependa de que la aplicación drene el cuerpo a mano.

HTTP/2 nunca tuvo este problema porque no manda las respuestas en un único stream secuencial: multiplexa frames de distintos streams sobre la misma conexión, así que un cuerpo sin leer en un stream no bloquea a los demás.

> **💡 Tip:** para reproducir el comportamiento exacto del benchmark original, corré tus pruebas con `GODEBUG=http2client=0`: así te asegurás de estar midiendo HTTP/1 y no un cliente que ya saltó a HTTP/2 por su cuenta.

📖 Resumen en Telegram: [Ver resumen](https://telegra.ph/Go-127-cómo-funciona-la-reutilización-de-conexiones-HTTP-10-14)

Tu próximo paso: cronometrá tu propia versión de `getStatus` en un loop de 100 llamadas, con y sin `io.Copy(io.Discard, resp.Body)`, usando `time.Since`, y compará los dos tiempos en tu propia red.

## Preguntas frecuentes

### ¿Qué diferencia hay entre el keep-alive de HTTP/1.0 y la persistencia de HTTP/1.1?

En HTTP/1.0 hay que pedirlo explícitamente con la cabecera `Connection: keep-alive`, y cualquiera de los dos lados puede cortarlo en cualquier momento. En HTTP/1.1 las conexiones son persistentes por defecto: se mantienen abiertas salvo que se declare `Connection: close`.

### ¿Por qué una reutilización de conexiones HTTP falla si no leo el cuerpo completo?

Porque en HTTP/1 las respuestas viajan una detrás de otra en el mismo flujo de bytes. Si no leíste el cuerpo actual hasta el final, `net/http` no puede saber con certeza dónde empieza la siguiente respuesta, así que prefiere cerrar la conexión en vez de arriesgarse a leer datos mezclados.

### ¿HTTP/2 sufre el mismo problema con las conexiones persistentes HTTP/1.1?

No. HTTP/2 multiplexa varios streams de frames sobre una sola conexión TCP, así que un cuerpo sin leer en un stream no bloquea la lectura de los demás. El problema descrito en este artículo es específico de HTTP/1.

### ¿Cómo verifico si Go está haciendo keep-alive de HTTP en mi programa?

Usando `net/http/httptrace` con un `ClientTrace.GotConn` que lea el campo `Reused` de `httptrace.GotConnInfo`, como se muestra en la sección de verificación más arriba.

### ¿Necesito Go 1.27 para que mi pool de conexiones TCP funcione bien en producción?

No necesariamente. Si drenás el cuerpo de la respuesta con `io.Copy(io.Discard, resp.Body)` antes de cerrarlo, el pool de conexiones ociosas de `net/http` funciona igual en versiones anteriores. Go 1.27 simplemente hace ese trabajo por vos aunque te olvides.

## Referencias

- [Go Blog: Better HTTP/1 connection reuse](https://go.dev/blog/http-connection-reuse): el post original del equipo de Go con el benchmark y la explicación del cambio en 1.27.- [pkg.go.dev: paquete net/http](https://pkg.go.dev/net/http): documentación oficial de Transport, incluido el valor por defecto de MaxIdleConnsPerHost.- [pkg.go.dev: paquete net/http/httptrace](https://pkg.go.dev/net/http/httptrace): referencia del campo Reused usado en la sección de verificación.- [MDN: Connection management in HTTP/1.x](https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x): explicación de keep-alive y conexiones persistentes en HTTP/1.- [Wikipedia: HTTP persistent connection](https://en.wikipedia.org/wiki/HTTP_persistent_connection): contexto histórico sobre el keep-alive en HTTP/1.0 y HTTP/1.1.

📱 **¿Te gusta este contenido?** Únete a nuestro canal de Telegram [@programacion](https://t.me/programacion) donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.