Go 1.27 brings a notable improvement to HTTP/1 connection reuse that cuts the latency of repeated requests dramatically. In a simple benchmark, calling http.Get 100 times against index.golang.org and returning only the status code took about 710 milliseconds on Go 1.26. The same program runs in roughly 150 milliseconds on Go 1.27, almost a five‑fold speedup.
The performance gap stems from how the net/http package handles connection reuse when the response body is left unread. HTTP/1 (both HTTP/1.0 and HTTP/1.1) sends responses back‑to‑back on a single TCP connection. The package can only locate the start of the next response after it has consumed the entire current response body, as indicated by Content‑Length or Transfer‑Encoding. If a program calls resp.Body.Close() without reading the body, net/http sees that there is still unread data, concludes that the connection cannot be safely reused, abandons it, and creates a fresh TCP connection for the next request. Each new connection incurs the full cost of a TCP handshake, TLS negotiation, and HTTP request setup—typically several round‑trips of latency.
In Go 1.26, the benchmark program suffered from this behavior: every iteration discarded the connection after checking the status code, forcing a new handshake for each request and inflating the total time to ~710 ms.
Go 1.27 modifies the net/http implementation so that invoking resp.Body.Close() no longer forces connection abandonment when the body is unread. Instead, the package automatically discards any remaining data (up to an internal limit) and marks the connection as reusable. Consequently, subsequent requests can reuse the same TCP connection, avoiding repeated handshakes and TLS negotiations. The benchmark shows the elapsed time dropping to ~150 ms for the same 100‑request workload.
The improvement benefits any code that only needs headers or status codes, such as health‑checks or lightweight API calls, where developers previously had to manually drain the response body with io.Copy(io.Discard, resp.Body) or similar work‑arounds. By eliminating that manual step, Go 1.27 reduces boilerplate and prevents silent performance degradation caused by a single unread byte at the end of a response.
The post notes that HTTP/2 was already unaffected by this issue because its multiplexing allows streams to be independent; the change specifically targets HTTP/1 clients.
Overall, the update makes HTTP/1 workloads significantly faster without requiring developers to alter their code, delivering a measurable latency reduction for typical Go‑based services that perform many short‑lived requests.
Key facts
- Go 1.26: ~710 ms for 100 GETs returning only status code.
- Go 1.27: ~150 ms for the same workload.
- Unread response bodies previously caused net/http to abandon connections.
- Go 1.27 changes net/http to reuse connections even when the body is unread.