It's from this answer:
https://stackoverflow.com/questions/2482411/is-this-pdo-bug-fixed-now/2482424#2482424
When the host is "localhost", MySQL Unix clients use a Unix socket, AKA Unix Domain Socket, rather than a TCP/IP socket for the connection, thus the TCP port doesn't matter.
A UNIX socket, AKA Unix Domain Socket, is an inter-process communication mechanism that allows bidirectional data exchange between processes running on the same machine.
IP sockets (especially TCP/IP sockets) are a mechanism allowing communication between processes over the network. In some cases, you can use TCP/IP sockets to talk with processes running on the same computer (by using the loopback interface).
UNIX domain sockets know that they’re executing on the same system, so they can avoid some checks and operations (like routing); which makes them faster and lighter than IP sockets. So if you plan to communicate with processes on the same host, this is a better option than IP sockets.
Edit: As per Nils Toedtmann's comment: UNIX domain sockets are subject to file system permissions, while TCP sockets can be controlled only on the packet filter level.
You can list your own machine local unix sockets with the following command:
Linux:
netstat -a -p --unix
MacOS: [jbmeerkat comment]
netstat -a -f unix
Have fun!
netstat does however work on Windows.
Commented
Jul 17, 2012 at 14:29
What's the difference between Unix socket and TCP/IP socket?
A TCP/IP socket is used for communication across TCP/IP networks. A connected TCP socket is identified by the combination of local IP, local port, remote IP and remote port. A listening TCP socket is identified by local port and possibly local IP. As I understand it, at least on linux TCP/IP sockets always result in the generation and decoding of TCP/IP packets, even if the client and server are on the same machine.
A unix domain socket (sometimes shortened to unix socket) on the other hand operates on a single machine. Listening sockets live in the filesystem hierarchy and access to them can be controlled by filesystem permissions.
Furthermore a process accepting a connection on a Unix socket can determine the user ID of the process that connects. This can avoid the need for an authentication step. Rather than generating a password for your database server and including a copy of it in your webapp's code you can just tell the database server that the user running the webapp has access to the corresponding user account in the database.
TCP sockets are handled by Unix too?
Of course
TCP sockets is part of the TCP protocol specification
Internet protocol specifications only tend to concern what happens on the wire, the TCP spec contains a definition of Socket but that definition is not the same as how the term is used by the "sockets API". The TCP RFC definition of Socket is closer to what the Sockets API calls sockaddr_in.
The "sockets API" as we know it was introduced by BSD but was later copied all over the place and is included as part of the posix standard. The basic stuff for TCP and UDP sockets tends to be much the same across different platforms but more advanced stuff and stuff that interacts with other parts of the OS varies, for example on unix-like systems a socket is identified by a file handle and can be read/written by the file APIs, this is not the case on windows.
Some extensions to the sockets API have been documented in rfcs but those RFCs are only "informational".
or any protocol could use IP Sockets ?
When an application explicitly creates a socket using the "socket" function (sockets are also created by the accept function) it passes three parameters, "domain", "type" and "protocol". Between them these three parameters can be used to select many different types of socket.
Unix domain sockets support ancillary data with different options compared to AF_INET or AF_INET6 TCP/IP sockets. This is explained in man unix (in this example from AlmaLinux 8.10).
UNIX domain sockets support passing file descriptors or process creden‐ tials to other processes using ancillary data.
SO_PASSCRED Enables the receiving of the credentials of the sending process in an ancillary message. When this option is set and the socket is not yet connected a unique name in the abstract namespace will be generated automatically. Expects an integer boolean flag.
Ancillary data is sent and received using sendmsg(2) and recvmsg(2). For historical reasons the ancillary message types listed below are specified with a SOL_SOCKET type even though they are AF_UNIX specific. To send them set the cmsg_level field of the struct cmsghdr to SOL_SOCKET and the cmsg_type field to the type. For more information see cmsg(3). SCM_RIGHTS Send or receive a set of open file descriptors from another process. The data portion contains an integer array of the file descriptors. The passed file descriptors behave as though they have been created with dup(2). SCM_CREDENTIALS Send or receive UNIX credentials. This can be used for authen‐ tication. The credentials are passed as a struct ucred ancil‐ lary message. Thus structure is defined in <sys/socket.h> as follows: struct ucred { pid_t pid; /* process ID of the sending process */ uid_t uid; /* user ID of the sending process */ gid_t gid; /* group ID of the sending process */ };
Where SCM_CREDENTIALS is related to exchanging UNIX credentials, which was mentioned in the other answer.
SCM_RIGHTS is an additional feature of UNIX domain sockets to pass a file descriptor between processes on the same machine. As an example of how this can be used, in the past have used this to implement the following:
AF_INET sockets.AF_UNIX socket is used to pass the connected TCP socket to the launched program, using SCM_RIGHTS, so that the launched program can communicate with the external client.For SCM_RIGHTS another use could be for files which the Linux Kernel only allows a single process to open. E.g. the IOMMU group files in /dev/vfio can only be opened by one process at a time, with attempts to open from a second process failing with EBUSY. In theory should be able to use SCM_RIGHTS to pass the file descriptor for an opened IOMMU group between processes to allow multiple processes to use the same VFIO device at once.
