Reputation: 7693
I'm running service A and service B on the same host. They connect to each other using TCP loopback. The sender always creates a new TCP connection each time it sends a message and closes the connection immediately. Because most of the closed connections stay in TIME_WAIT state, it runs out of ephemeral ports soon given the QPS is high.
I wonder if using unix domain socket solves this problem. Does it have the same TIME_WAIT state as TCP?
Upvotes: 2
Views: 1767
Reputation: 1362
TIME_WAIT is a TCP construct designed to protect against problems due to "half-open" connections, or misaligned connection state between remote and local parties. See [3] state diagram on p23, half-open connections around p33.
With Unix sockets, the OS completely knows the connection state of both ends of the socket - it's local-only. There's no FIN/FIN-ACK handshake in Unix sockets, and TIME_WAIT is not necessary.
I'm not sure if TIME_WAIT is used with local TCP connections. It should not be necessary for the same reason that Unix sockets don't need it, but is likely still present to a) avoid optimizing for the unusual local-only case and b) avoid deviations in behavior between "localhost" TCP connections and remote connections.
And a quick thing to look at from your command line: netstat -anop. You'll never see unix sockets in a TIME_WAIT state. :)
So yes: Unix domain sockets should address the "time-wait loading" issue. If your interface is local-only, Unix sockets have less overhead to deal with as well - some slight performance gains to be had there. And once connected or listening, their behavior from an API standpoint is indistinguishable from TCP sockets.
References:
Upvotes: 3