Unix socket vs TCP/IP host:port
Solution 1:
Unix sockets are a little bit faster as you don't have the tcp-overhead. If you realize this performance loss is a question of server load. If you don't have very high server load you won't recognize it.
If you use Jails (FreeBSD) or some other virtualisation technology to separate the e.g. MySQL-Server from the Webserver, you often use the tcp/ip setup instead of sockets. The firewall rules need to restrict the access though.
You need to find out if your system is under heavy load so that a socket is a must or you can focus on a nice system design (separating services), then a tcp/ip solution would be better.
So make a long answer short:
Yes, there is a performance difference, sockets are faster. If you are not suffering high server load, just choose what fits better to your system's design.
Solution 2:
It's basically a tradeoff between performance and flexibility. Unix domain sockets will give you a bit better performance, while a socket connected to localhost gives you a bit better portability. You can easily move the server app to another OS by just changing the IP address from localhost to a different hostname.
A Unix domain socket uses the local file system to create an IPC mechanism between the server and client processes. You will see a file in /var somewhere when the Unix domain socket is connected.
If you are looking for purely the ultimate performance solution you may want to explore a shared memory IPC. But, that's a little bit more complex.
Solution 3:
Pros of Unix domain sockets.
- Access can be managed through the Unix user permission system either by setting the permissions on the socket itself or by the server reading the usename of the connecting client.
- Less chance of inadvertently exposing the socket to the outside world. For example if the server also runs a web proxy then that may inadvertently allow connections to sockets on localhost.
Cons of Unix domain sockets
- Not portable to non-unix systems.
- Can be awkward with chroots, jails or similar