Quic-go instead of Go?

Hello there,

First off, I'm not a dev so maybe I'm way off base with what I'll say. From my POV, Go is more and more problematic, since the http/2 support is kind of broken with bad performances, and http/3 is not being worked on by them If I believe this thread net/http: support HTTP/3 · Issue #32204 · golang/go · GitHub

Now, can Rclone use Quic Go ? GitHub - quic-go/quic-go: A QUIC implementation in pure go for http/3 ?

I know that dropbox is implementing it : Investigating the impact of HTTP3 on network latency for search - Dropbox , and from what I understand all of google service, including drive, are supporting it.

Could this, on paper of course, give a big boost in some situations, for single file uploading ? And skip all the http/2 problems ?

Thx , have a nice day everybody : )

If http2 is giving you problems then try --disable-http2. With the current Go implementation this will be faster for pure transfer speeds (see go issue #47840. http2 can still be better for latency though.

It would probably be possible to implement this library in rclone's HTTP transport making it seamlessly available to all rclone HTTP connections.

I already use -disable-http2 everywhere, but I find it sad in the end because we're stuck with http "one", which has "problems" , not due to bad implémentation but just old age, too.

I hope we'll have a good http2 implémentation or even better quic support one day :slight_smile:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.