curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: a HTTP/2 window sizing dilemma!

From: Daniel Stenberg via curl-library <>
Date: Fri, 21 Feb 2020 11:41:47 +0100 (CET)

On Fri, 21 Feb 2020, Daniel Jeliński via curl-library wrote:

> Sounds like the problem HPN-SSH tried to solve:
> I like their approach, but I'm not
> sure how they got hold of the current TCP receive window size; the only
> value I could find was receive buffer size, which is not necessarily
> relevant here.

Also, it's not necessarily so that a user wants to buffer as much as the TCP
window can get increased to anyway, depending on their situation - imagine for
example a program running in a small device that transfers a lot of streams
that can be paused. And then of course HTTP/2 is multiplexed so there could be
a separate high speed stream flying by when one stream is paused, and then the
TCP window needs to be really big for the fast stream...

> If you decide to go with a static value, the default max TCP window size on
> most machines is 32MB or less, and it is enough to saturate 1GBit link on
> the longest wired network (300 ms RTT, according to

That's indeed a sensible argument. Which then also implies that every stream
that gets paused might end up with up to 32MB of buffered data in memory...

> Other than that, I'd love to know who is using curlopt_pause and how;
> as far as I can tell, handling pause is only a problem on multiplexed
> connections where we can't let the data rest in system buffers.
> Correct?


  / | Commercial curl support up to 24x7 is available!
                   | Private help, bug fixes, support, ports, new features

Received on 2020-02-21