wget-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Wget-dev] wget2 | Recursive downloads with HTTP/2 not uniformly div


From: Tim Rühsen
Subject: Re: [Wget-dev] wget2 | Recursive downloads with HTTP/2 not uniformly divided (#397)
Date: Fri, 21 Sep 2018 13:52:28 +0000

> Mostly because some bad ISPs often throttle the bandwidth on a per-connection 
> basis. This is never official policy, but I've seen it all too often that 
> multiple connections to the same server get a higher total bandwidth than the 
> a single connection.

I have never seen this. That means downloading single files would suffer from 
this as well. And people are very keen on getting the bandwidth they pay for. 
That would mean heavy trouble for an ISP.
I think it's more likely that the server(s) themselves limit the bandwidth or 
are limited in some way (bandwidth, cpu, ...). Using more parallel connections 
can circumvent this if you think about load-balancers (which are very common) 
or other means of distributing traffic to several servers.

And please don't forget why HTTP/2 was introduced. The main reason was to put 
*less* load on the server by just having *one* connection instead of many. BTW, 
curl just raised it's request window to 100 for HTTP/2 (from 20 or 30 before).

Then, we already have `--http2-request-window` to configure the max parallel 
requests per HTTP/2 connection. If you really experience regular `throttling` 
on a single connection, put this into your config file. HTTP/1.1 requests will 
be shared through all threads anyways, since even with persistent connections 
we do just one request/response cycle after the other. Putting this value down 
to 1 means you are basically back at HTTP/1 speed and behavior (maybe even 
worse since some HTTP/2 protocol overhead).

So I don't see why we should take action here and now.

-- 
Reply to this email directly or view it on GitLab: 
https://gitlab.com/gnuwget/wget2/issues/397#note_103413086
You're receiving this email because of your account on gitlab.com.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]