Regarding reasons for using the protocol: It will indeed make HTTP faster in most cases, because of the dropped need to create a new TCP/TLS connection for each

Regarding reasons for using the protocol: It will indeed make HTTP faster in most cases, because of the dropped need to create a new TCP/TLS connection for each request. Yes, pipelined HTTP/1.1 and connection pools could that too to a little extend, but browsers and other applications had limitations on how much connections and therefore parallel requests could be made, which were quite low compared to todays need. With HTTP/2 one connection is sufficient for everything. With HTTP/2 you can now do also things like creating 200 parallel SSE connections to a server to receive events with low overhead. This was neither possible with HTTP/1.1 (where browsers would limit to you 8 or something like that connections) nor efficient. But once again - this was a browser limitation, not necessarily an HTTP/1.1 one. Regarding caching I don't see a difference, as the caching happens on a higher layer. I have implemented HTTP/2 to about 65% for myself. I think the protocol is mostly OKish. It can be implemented with a reasonable effort (assuming you have a very good understanding of protocol implementation in general - there's more chances to fuck up in it than in HTTP/1.1) and should provide a reasonable performance. There is some stuff in there which I don't like e.g. race conditions during SETTINGs negotiation, the question why strings can be encoded with and without huffman encoding and the use of default frame sizes which make it less suitable for embedded devices (where it would otherwise be much better than HTTP/1.1). But in the meantime I came to the conclusion that there are no perfect protocols - all of them have some strange things incorporated, because somebody involved in standardization has a usecase for it and a consent needs to be reached. I didn't came to a complete conclusion regarding the required computing resources. On the one hand header handling is a lot more efficient (no need to search for line breaks, etc.). But the stream multiplexing might require an additional memory copy operation (from the received socket payload into the buffer that is dedicated for that stream) depending on the architecture of the library. Need to do some benchmarking on that. However benchmarking for HTTP/2 is difficult, because it's currently mostly deployed with TLS (and many libraries and tools only support HTTP/2 with TLS and not the h2c variant), which affects all results.