Zabbix may create and close quite some network connections during operation, because it does not maintain permanent connections - neither between its components nor to monitored entities.

In some areas this has been mitigated by requesting respectively exchanging data in a bulk over a single network connection.

However, this is not the case for most agent-less checks and as well not for Zabbix agent (passive) checks.
Especially the latter has the tendency to cause lots of network connections being created per monitored host.

While extending the use of bulk-requests might be an obvious option, it could also be worth to introduce a new process type "Connection manager" (Iirc suggested by wiper).

Such a Connection manager could possibly be implemented as a kind of "TCP connection pool". Instead of creating a connection directly, it gets requested from the connection pool, which returns the corresponding socket. If the socket does not exist in the pool yet, it gets created first and then returned.

The pool size could be configurable to a fixed volume. Setting it to zero could disable this feature completely, what leads to previous resp. current behavior.
TCP sockets could be closed when not used for a (configurable?) period.
If the pool is exhausted the system could either fall back to legacy behavior or close the connection not been used for the longest time.

I haven't done something like that before and could imagine, that it is not that easy to implement as special care has likely to be taken for maintaining the different protocol contexts/handles.

Finally this request is about the "best" way to avoid or at least reduce frequent TCP connection creation and not about a "Connection manager". Further I'd consider it even more related to Zabbix agent (passive) checks. So any good idea is very welcomed!

Anyway, when there is a decent solution to cover more aspects, even if only in future steps, this is appreciated too, of course