On 01/07/2018 07:49 PM, David Kalnischkies wrote: > 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). Well, we could also go and let mirrors flag a connection limit themselves that cannot be overwritten by local configuration... >> 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". That said, you just went the other way. Not that I liked the cURL https transport, given that it was fairly stupid^Wstraightforward. But at least it used a library. So I guess I'm curious if you'd be open to picking a library and then rewriting everything to use that single one for all of HTTP(S) 1.1/2. (Assuming such a library exists by now.) > [HTTP/2 has an unencrypted variant aka "h2c" btw. At least on paper > – I know that browsers aren't going to implement it.] Well, question is then also if you can assume that nodes in the path would implement this (like reverse proxies/load balancers etc). Otherwise it will only exist on paper rather than real setups. >> 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). That's actually an excellent idea. We'll try that out. I actually wrote code for it already and it's a pretty straightforward approach, but we'll take another stab at attempting to reduce time to first byte latency first. Kind regards and thanks a lot! Philipp Kern
Attachment:
signature.asc
Description: OpenPGP digital signature