Does Go's http.Server reuse a client connection for later requests by default, and how do you stop it?

## What "keep-alive" means on the server side When Go's `net/http` server accepts a TCP connection it starts one goroutine to serve it. With HTTP/1.1 that goroutine does not stop after one request/response pair: it loops, reading another request off the same socket. That reuse is what "keep-alive" (persistent connections) means from the server's point of view, and it is the reason a Go server's *connection count* is a different number from its *request rate*. ## The default Keep-alives are **on by default** for any `http.Server` you construct, and for `http.ListenAndServe`. You do not enable them; you can only disable them. HTTP/1.1 clients get reuse automatically. An HTTP/1.0 client only gets it if it explicitly asks with a `Connection: keep-alive` request header, and the server answers in kind. ## Lever one: the server-wide switch ```go srv := &http.Server{Addr: ":8080", Handler: mux} srv.SetKeepAlivesEnabled(false) ``` `Server.SetKeepAlivesEnabled(bool)` is a method, not a struct field, and it is safe to call while the server is running. With it set to false the server stops reusing connections: each response carries a `Connection: close` token and the socket is closed once the response is written. The `net/http` documentation says in as many words that only very resource-constrained environments, or servers that are shutting down, should do this. ## Lever two: one response at a time A handler can close just its own connection: ```go w.Header().Set("Connection", "close") ``` The server notices the token while writing the response header, emits `Connection: close` on the wire and closes that connection afterwards. Every other connection the server holds is unaffected. This is the surgical version — useful for evicting one abusive or wedged client, or for a request you know left the connection in a state you do not want to reuse. ## What it costs to turn reuse off Every request then pays: * a TCP three-way handshake, and a full TLS handshake if the listener is TLS; * an `accept` on the listener and a fresh serving goroutine with its own stack; * a new set of per-connection read and write buffers. On a chatty client that is a large latency and CPU tax, and it pushes socket churn onto the client too. So disabling keep-alives is a memory-for-CPU trade, not a free safety measure. ## Why the default matters for capacity Because reuse is on, the number of connections a server holds is decided by whoever is talking to it, not by its own request rate. Put an ingest endpoint behind a load balancer that maintains a pool of upstream connections and the server can sit on thousands of mostly idle connections while serving a modest number of requests per second. Each of those connections is real memory: a serving goroutine and its stack, plus roughly a few kilobytes of read and write buffering, plus TLS state if the connection is encrypted. That is the thing to internalise early: `http.Server` has **no field that caps how many connections it will hold**. Keep-alives being on by default is exactly why the count can climb far above anything the request rate suggests, and why a Go HTTP server's memory can be dominated by connections rather than by handler work. ## Common confusions * Disabling keep-alives does not stop the server from serving concurrent requests — concurrency comes from one goroutine per connection either way. * It does not change how bodies are framed or streamed; responses still stream. * Setting the header in one handler does not disable reuse globally, and calling `SetKeepAlivesEnabled(false)` does not tear down connections already in flight — it changes how subsequent responses are answered. ## What to say in an interview "On by default; `SetKeepAlivesEnabled(false)` is the global off switch and the docs reserve it for very constrained servers; `w.Header().Set(\"Connection\", \"close\")` closes one connection. And because reuse is the default, connection count is a capacity dimension of its own."