It's from this answer:
A UNIX 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.
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. AIUI 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?
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 "sockets API" as we know it was introduce 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.
- domain selects the family of protocols/addresses in use, e.g. AF_INET for ipv4, AF_INET6 for ipv6, AF_Unix for unix filesystem paths etc.
- type selects the communication semantics, the main ones being datagram and stream but there are also other more specialised types.
- protocol selects the protocol to use, if it is set to 0 a default protocol for the combination of Domain and type will be used.