Are there performance advantages in http2 over http1.1 for service-to-service communication?

Question

I'm just curious if I'm missing something in http2 that would make it more efficient in service-to-service communication, for example in a microservice architecture.

Are its improvements just related to end-users (browsers)?

Perissodactyl

Answer 1

If you are issuing many concurrent requests between microservices, then there's benefit from connection multiplexing. You do not need to manage TCP connection pools on the client, and restrict the number of incoming TCP connections at the service side.

Some services might benefit from server push, though it really depends on what the service does. Headers compression can be useful if you have high traffic volumes to the service with repeated meta-data. More information can be found here.

In summary, yes, it is designed more with end users in mind, but there's value for RESTful microservices as well, especially due to connection multiplexing.

Yoghurt

Answer 2

HTTP/2 adds an additional aspect to service-to-service communication that was not mandatory with HTTP/1.1. And that is security in form of SSL/TLS.

Although not required by the RFC standard, almost all HTTP/2 servers and clients will only support HTTP/2 over TLS, which makes encryption de facto mandatory.

So if you want to offer and consume microservices over HTTP/2, you have to think about ways to create, manage and distribute SSL-certificates to servers and clients.

Consequently, moving to HTTP/2 means introducing a new stack of technology, e.g. a public key infrastructure, to your service eco system.

Another way to make your services HTTP/2-ready for your service consumers would be to place a reverse proxy between your HTTP/2-enabled consumers and your HTTP/1.1 services.

The proxy would terminate the HTTP/2 connections from the consumers and translate them into HTTP/1.1 requests for your servers (and vise-versa).

This would implement a separation of concern, where your services would only be responsible for their business-logic stuff, while the proxies would handle the certificates and encryption. But again, you would add more complexity to your system.

More Complexity, but also better use of network resources

More complexity is what you are paying with. But you get a smarter consumption of network resources for it. With HTTP/1.1 you can have multiple TCP connections between one client and a server. And opening multiple connection is almost always necessary to overcome HTTP/1.1's performance drawbacks.

Establishing TCP connections is an expensive task, though. In order to create them DNS lookup, TCP handshake and SSL handshake are necessary.

HTTP/2 limits the number of open TCP-connections between one client and one server to exactly one (1). But at the same time, HTTP/2 brings us connection multiplexing, i.e. you can have multiple HTTP conversations simultaneously over the same TCP connection (HTTP/1.1: 1 TCP-connection = 1 HTTP connection).

Contact

One can use a pool of reusable HTTP/1.1 connections to avoid re-establishing the connections. Bearing in mind the heavier usage of CPU in the case of HTTP/2 and fast network between the services, will there be a significant performance benefit of HTTP/2? – Animation

Using a pool will help if you only need a little number of connections. If you have a request-burst, connections will still become a scarce resource. A pool might still run out of connections. It is only a workaround for a problem that http/2 solves much better in cases where a lot of requests must be served. – Contact