net: pass SO_REUSEADDR sockopt when establishing TCP connection if local IP address is set

[valyala]

Currently go apps are limited by 64K outgoing connections when running on hosts with multiple IP addresses if local IP address is passed to net.DialTCP(). This limit can be eliminated when setting SO_REUSEADDR sockopt to the socket before connection establishing according to https://idea.popcount.org/2014-04-03-bind-before-connect/ . Below are the corresponding quotes from the article:

• When using the bind before connect trick only a single connection can use a single outgoing source port. With SO_REUSEADDR flag, it's possible for many connections to reuse the same source port, given that they connect to different destination addresses.
• If you need to select a source IP manually, for whatever reason, normally you'll be limited to one outgoing connection for one ephemeral port: destination address is not taken into account. This limits number of outgoing connections considerably.
• Therefore if you need to specify a source IP consider setting SO_REUSEADDR flag to enable address reuse. This will increase number of possible connections, but you will need to handle possible connect() EADDRNOTAVAIL errors.

[adg]

We do this for listening and multicast sockets, but not for regular outbound sockets.

http://golang.org/src/net/sockopt_linux.go

I'm not sure what the drawbacks are to doing this always, if there are any.

cc @mikioh

[mikioh]

See http://golang.org/src/net/tcpsock_posix.go#L155.

Yup, TCP's simultaneous connections and derived techniques such as hole-punching are fun.

I have no concrete opinion on this stuff unless it harms, a) the top-half stuff of user IPC subsystem inside kernel, which handles bump-in-the-API mech for dual IP stack on some platform, b) the bottom-half stuff of user IPC subsystem inside kernel, which takes care of protocol integration including destination/source address selection by using IP routing/prefix lookup.

Perhaps, it may be fine on all the supported platforms, not sure. If you want to try a contribution (writing a patch and pushing it down to review process), please include a few test cases that satisfy the point of views above; both dual IP stack and IP routing behavior--from unspecified addresses (0.0.0.0 or ::) to specified addresses for source and/or destination address selection with validating IP address reachability.

[mikioh]

Merged into #9661.