Conversation

I re-implemented the rate limiting in , coming in the next release. A description.

https://eissing.org/icing/posts/curl-rate-limits/

1
2
0
@icing interesting! Do you do anything to limit the amount of buffering in the TCP stack when rate limiting (e.g., adjust the receive buffer size), and/or to pace out the traffic on send?
1
0
0

@toke No, we do not go into the adjusting TCP windows. Rate limits are enforced on the net data, not the overhead of TLS records or what else may be involved (like chunked encoding in HTTP/1.1).

Also, in HTTP/2 this would not be possible apart from edge cases. And HTTP/3 is another matter entirely.

1
0
0
@icing right, I do realise it would not be super portable across protocols (or OSes). So you're rate limiting the read()/write() socket calls and just letting the OS do its thing, essentially?
1
0
0

@toke On a HTTP/1.1 or FTP transfer, that is basically it, yes. With TLS it's the send/receive on the TLS API really as we do not meddle into how the TLS stack manages its records and it may try to read more from the socket.

0
0
1