HTTP2 support

[folbricht]

HTTP2 support in the chunk-server and client was first requested by @limbo127 in #10. At the time it didn't seem reasonable to implement H2C, but now that may be doable with https://godoc.org/golang.org/x/net/http2/h2c

[folbricht]

Implemented on the http2-support branch (https://github.com/folbricht/desync/tree/http2-support). When https:// stores are used, this will use HTTP2 by defaults. In order to use it with http:// stores, a new option --h2c is required to enable HTTP2 over non-TLS connections on the client-side. This option has no effect when HTTPS is enabled.

[folbricht]

My testing suggests that accessing a chunk store via HTTP2 (and H2C as well) is noticeable slower than HTTP1.1. And with larger -n on the client, the difference becomes more pronounced to the point that at -n 50, HTTP1.1 is 3 or 4 times faster.

It might depend on other factors such as latency etc, but at this point I'm not sure it's a good idea to turn this on by default.

[om26er]

Would be interesting to explore HTTP/2 support again. I think that would ultimately result in using lesser network traffic since the overhead of each HTTP handshake will come down from number of chunks to just one

[om26er]

Or maybe why not just explore HTTP/3 support altogether, I believe many CDNs out there already support that

[folbricht]

HTTP2 support has certainly improved, including in the standard library. It should probably be an option though not the default yet, in case there's still a performance issue. Is that something you'd be interested in working on?

HTTP3 (HTTP over QUIC) is an interesting option too. Perhaps a new flag to switch between them.

[om26er]

I just looked into this. It seems HTTP/2 is already supported and enabled. It's taken care by this line

desync/remotehttp.go

Line 79 in c508eeb

ForceAttemptHTTP2: true,

-- So nothing to do here.

I also played with HTTP/3 using https://github.com/lucas-clemente/quic-go and my current testing suggests Cloudfront + HTTP/2 is fastest combination, so I guess we could wait for HTTP/3 to mature more in the coming years and visit that again. Ideally once the stdlib has HTTP/3 support.