Reduce netroute syscalls

[Stebalien]

Some... let's call them power users... seem to enjoy abusing their systems by dialing as fast as possible. Unfortunately, this means we're wasting a lot of CPU cycles on determining source addresses in:

go-libp2p-quic-transport/reuse.go

Lines 120 to 125 in 2e302b1

	if router, err := netroute.New(); err == nil {
	_, _, src, err := router.Route(raddr.IP)
	if err == nil && !src.IsUnspecified() {
	ip = &src
	}
	}

Ideally, we'd:

1. Skip this entire thing if we aren't actually listening on any unicast addresses (just global addresses).
2. Cache? Honestly, we can probably cache route information until our unicast listeners change.

[marten-seemann]

Ideally, we'd:

1. Skip this entire thing if we aren't actually listening on any unicast addresses (just global addresses).
2. Cache? Honestly, we can probably cache route information until our unicast listeners change.

We can probably optimize this somehow, but will it save the power user's problem? Assume for the moment that we had optimized this so far that this code path becomes essentially free. Then they'd end up with tons of QUIC connections (assuming that a non-negligible fraction of the dials succeed).
My (unproven) assumption here is that the single syscall to netroute here is cheaper than the sum of the syscalls (and the handshake crypto) that a QUIC connection would cause.

Am I missing something?

[willscott]

Making a netroute router fetches the routing table from the kernel which is fairly expensive on creation.

[whyrusleeping]

I'm not doing anything special, my connection manager has a setting of 2000/3000/1m and im running a dht node.