Hi, On Thu, Dec 21, 2017 at 11:02:22AM +0100, Philipp Kern wrote: > An easy workaround (few lines changed) would be to just spawn multiple > transports for a given host target, to make use of multiple connections. The apt team was always against doing this which eventually spawned stuff like the enormously hacky "apt-fast". The problem we see with this is that as soon we add this to mainline users will activate such options even if it makes no longterm sense for them because it feels faster in the shortterm against our shared mirror network as adding more own cars is always a good strategy to combat a traffic jam (until everyone else has adopted that strategy as well and so everyone is worse off). > Another solution to solve this problem would be to implement HTTP/2 > support, which allows to answer the requests non-linearly. In this case I am pretty sure that will eventually happen. Especially if it is in its own transport package as you can do everything there. It is currently not that high on the list of things to do through as the current focus in that area is for the moment to improve what we have in terms of security and co. Not to bad an idea given that protocols we deal with tend to increase in complexity… hello HTTP/2. :P What makes HTTP/2 perhaps a bit "complicated" is the strong relation with HTTP/1, so things would need to be shared and exchanged. Would be sad if we end up in another http/https or tor/http(s) situation until we find the time to make it "proper". [HTTP/2 has an unencrypted variant aka "h2c" btw. At least on paper – I know that browsers aren't going to implement it.] > Happy to hear your thoughts on how to solve this. You could do something similar to what httpredir.d.o was doing or work with the (now reimplemented) -mirror method. That hard-depends on your "behind load-balancer" servers to be reachable directly through. But it gets you parallel connections without changing clients (at least in the first case, in the second you will need to wait a few years until this becomes true I guess). Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature