When does a http2 TCP connection close?

Question

I understand that http2 uses one tcp connection to serve multiple requests, for example, if I request index.html which contains a.css and a.js, these three requests will be done in one tcp connection.

What happens if user clicks index2.html? does this request still use the same previous tcp connection? If so, will the browser keep the connection open until user closes the browser? And on the server side, does the server keep many connections open all the time?

Paramagnetism

Answer 1

When using HTTP/2, browsers typically open only one connection per domain.

In your example, index2.html will be sent on the same TCP connection that was used for index.html, a.css and a.js.

In HTTP/2 requests are multiplexed on the same TCP connection, so that the browser can send them concurrently, without waiting for a previous request to be responded to.

Both browsers and servers have an idle timeout for TCP connections. If the connection is idle for long enough, it will be closed by either party - the one that has the shorter idle timeout, to save resources. For example, you may open a connection to a wikipedia.org, perform a few requests, and then leave that tab and work on something else. After a while (typically 30 seconds) the browser will close the TCP connection to wikipedia.org.

On the server side, the server will keep the connections from various clients open, until they are either closed by the client or until the server-side idle timeout fires, at which point it's the server that initiated the close of the TCP connection.

With HTTP/2, the number of connections that a server has to maintain is vastly less than it was with HTTP/1.1. With HTTP/2, a server has to maintain just 1 TCP connection per client; with HTTP/1.1, the server had to maintain typically 2-8 TCP connections per client.

Thereof

If it has to maintain just 1 TCP connection, how does it differ from HTTP/1.1 keep-alive? If it uses just 1 TCP connection, why not using web-sockets instead? I think server requirements and limitations will be equal when using web-sockets. In both cases server has to maintain just 1 connection per client. – Pathy

For MPA applications HTTP's request/response model might suffice. But for SPA applications that want some real-time capabilities and no polling, I think web-sockets would be a better choice? – Pathy

HTTP/2 maintains one multiplexed connection, while HTTP/1.1 maintains many duplexed connections. WebSocket is just a framing protocol and does not have any semantic on top, like HTTP has. For example, PUT /contracts/1 HTTP/1.1 + Content-Encoding: gzip tells the server a lot of information about the request. To rebuild on top of WebSocket the same information you have to basically reinvent the HTTP protocol on top of WebSocket. WebSocket may work in certain cases but for many others HTTP is a better choice due to its higher level semantic (completely missing in WebSocket). – Thereof

Ignoring semantics, but speaking only about transport and load on the server (which is more expensive). – Pathy

For SPA applications I think using Web sockets is a better choice than HTTP. But HTTP is still better for any content browser needs to display and/or download like images because it provides headers like content-type etc. – Pathy

"For SPA applications I think using Web sockets is a better choice than HTTP." You have to explain why (you still have to build another protocol on top of WebSocket) and provide benchmarks. Given the current REST-like server-side applications and REST supports on the browsers via JavaScript frameworks, for SPA applications HTTP may be a better choice. WebSocket shines when your application needs server-side events delivered to the client, but that is often not a common requirement. – Thereof

because if you need to send real-time updates from server, using HTTP you have 2 choices: polling or server-sent events. Frequent polling, in my opinion, is too much overload. SSE you have a persistent connection, but when you make subsequent requests there are more connections for the server to handle coming from the same IP, so I think server requirements increase. But maybe HTTP/2 solve this so it's more comparable to web sockets because in both cases there's just 1 connection for the server to handle. – Pathy

Hi folks, - For two days now, I'm really about HTTP2 but much specifically how a connection closing come into play with microservice architecture. For instance - will the workload balancer always send two requests from the same clients to the same container (microservice instance)? Or it can send it to distinct microservice instances? More - when a container that handled the first request for a client crashes, will the TCP connection be reused into another container? But I read here After that, the connection closes and the browser can render the site. yoast.com/what-is-http2 – Cottonade

Answer 2

What happens if user clicks index2.html? does this request still use the same previous tcp connection?

Yes. On top of that, multiple browser tabs/windows also share a single HTTP/2 connection.

If so, will the browser keep the connection open until user closes the browser?

Below from RFC - connection management

For best performance, it is expected that clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page) or until the server closes the connection. Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair.

And on the server side, does the server keep many connections open all the time?

Servers are encouraged to maintain open connections for as long as possible but are permitted to terminate idle connections if necessary. When either endpoint chooses to close the transport-layer TCP connection, the terminating endpoint SHOULD first send a GOAWAY (Section 6.8) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks.

More info on connection error below.

RFC connection-error-handling

A connection error is any error that prevents further processing of the frame layer or corrupts any connection state. An endpoint that encounters a connection error SHOULD first send a GOAWAY frame with the stream identifier of the last stream that it successfully received from its peer. The GOAWAY frame includes an error code that indicates why the connection is terminating. After sending the GOAWAY frame for an error condition, the endpoint MUST close the TCP connection. It is possible that the GOAWAY will not be reliably received by the receiving endpoint. In the event of a connection error, GOAWAY only provides a best-effort attempt to communicate with the peer about why the connection is being terminated.

An endpoint can end a connection at any time. In particular, an endpoint MAY choose to treat a stream error as a connection error. Endpoints SHOULD send a GOAWAY frame when ending a connection, providing that circumstances permit it.

Oversweet