Better HTTP/1 connection reuse in Go 1.27
- ID
- 35877
- Status
- summarized
- Published
- 15 Oct 2026, 12:29 AM
- Fetched
- 15 Oct 2026, 11:30 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://go.dev/blog/http-connection-reuse
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.0
- Created
- 15 Oct 2026, 11:31 PM
- Tags
- Audience
- developerssaas_startup_founders
What happened
The Go blog (Nicholas Husin and Damien Neil, 14 October 2026) documents an HTTP/1 connection-reuse improvement landing in Go 1.27: a benchmark calling a small GET against index.golang.org 100 times with GODEBUG=http2client=0 drops from ~710 ms on Go 1.26 to ~150 ms on Go 1.27, roughly a 5x speedup. The post frames the win in round-trip terms — TCP handshake 1 RTT, TLS 1.2 handshake 2 RTT, so a fresh connection costs 3 RTT before the first HTTP byte, versus ~1 RTT for a request on an already-open connection. The excerpt cuts off before explaining the actual mechanism of the fix, so only the benchmark numbers and the RTT framing are verifiable here.
Why it matters
If you run Go services or CLI tools that make many short requests over HTTP/1 — including where HTTP/2 is disabled or the upstream is HTTP/1-only — the published numbers suggest re-benchmarking on Go 1.27 before you invest in connection-pool tuning or a custom transport, since ~710 ms to ~150 ms on the same 100-request loop is a bigger win than most hand-rolled pooling changes deliver. The RTT math is also a concrete argument for regional deployment: at 100 ms RTT, a cold connection burns ~300 ms in setup alone, which is what makes reuse matter more for services in Southeast Asia hitting distant endpoints. Note the article excerpt does not explain how the reuse was improved, so treat the mechanism as unconfirmed until you read the full post.
Discussion angle
Reproduce the benchmark against one of your own endpoints on 1.26 vs 1.27 — and check whether your stack even takes the HTTP/1 path (GODEBUG=http2client=0) that this fix targets.