MaxIdleConnsPerHost in Client

[gobwas]

Hi!
Thanks for the library! 🚀

Am I understand it right, that there is no ability to reuse connections in manner of net/http – when the client tries to use idle (free connection) when it possible, or create new one, even if MaxIdleConnsPerHost limit exceeded?

[valyala]

fasthttp client reuses keep-alive connections by default.

There is MaxConnsPerHost in the Client and MaxConns in the HostClient for limiting the maximum number of (keep-alive) concurrent connections per host.

fasttp doesn't allow creating more than MaxConnsPerHost connections per host. It returns ErrNoFreeConns if this limit is reached. This effectively limits resource usage on both client and server side unlike net/http, which lacks the ability to limit the maximum number of concurrent connections per host.

[valyala]

Closing this issue, since this is not a bug :)

[gobwas]

Thanks!
Yep, this is not a bug =)

In my case it will be more useful, to set both MaxIdleConnsPerHost and MaxConnsPerHost (or just MaxIdleConnsPerHost), cause its ok to get more connections in moment than idle limit, and then simply drop them after peak. Its too tough to return ErrNoFreeConns to client in high load moments.

Does it makes sense?

[valyala]

Fasthttp client drops unused connections after 10 seconds. So MaxConnsPerHost may be quite high (1000 or more) for peak load if you are sure both client and server have enough resources to handle this load. Otherwise I'd recommend limiting the number of concurrent goroutines calling fasthttp client methods, so it doesn't exceed MaxConnsPerHost.

[shalako]

Hello @valyala

In considering fasthttp for use in the router for Cloud Foundry, we are concerned that the lack of control of idle Keepalive connections exposes a vulnerability. With many open keepalive connections, a denial of service attack could be executed far more easily than when most connections are closed after handling the request. Managing total open connections is also important, but it isn't the same thing. We would prefer to limit keepalive connections to something much lower than total connections.

Would you be open to reconsidering support of this feature? We would be willing to offer a PR. We are also exploring workarounds that involve counting the number of connections ourselves and appending Connection close when reaching a configured idle keepalive limit.

Thank you!
CF Routing team