Connection: keep-alive, close and hop by hop headers

In HTTP/1.0 every request meant a new connection, and keep-alive was the opt in that changed that. HTTP/1.1 reversed the default: connections persist unless something says close. Sending keep-alive on an HTTP/1.1 message is therefore harmless but redundant, and the value that actually changes behaviour is close.

The second job is less well known. The header can list other header names, and a proxy must remove every header named there before forwarding the message. That is the mechanism that makes headers like Upgrade hop by hop: they describe this connection, and passing them along would apply them to a different one.

HTTP/2 and HTTP/3 removed the concept entirely. Multiplexing means one connection carries many streams, so a per message instruction about closing it makes no sense, and connection specific headers are forbidden. A message carrying one is treated as malformed, which is a real source of trouble when translating HTTP/1.1 messages onto an HTTP/2 connection.

Sending close is still useful in narrow cases: a client making exactly one request, or a server shedding load by refusing to keep sockets open. It is a per message instruction rather than a setting, so it has to appear on each message where you want it, and a server may close a connection whether or not anyone asked.

Persistent connections are also why a slow response blocks the ones behind it on HTTP/1.1. Requests on a single connection are answered in order, so browsers open several connections per host to work around it. That head of line blocking is the problem multiplexing solved, and it is the reason the header stopped making sense in the newer protocols.