Originally published on Code Beneath.
When you need two processes on the same machine to communicate, you have a choice: bind to 127.0.0.1 on a TCP port, or use a Unix domain socket. The question of unix domain socket vs tcp localhost matters because one is faster, simpler to clean up, and skips the entire TCP stack. Yet many engineers default to TCP loopback out of habit or framework convenience, never measuring the actual cost. This article shows you exactly what happens beneath each approach and gives you runnable code to benchmark both.
What is a Unix Domain Socket?
A Unix domain socket (UDS) is a bidirectional communication channel between processes on the same host. It is a file-like object, not a network socket. The kernel passes data through shared memory and queues, not through the TCP/IP stack. You create a socket file, usually in /tmp, and both client and server open it by path.
In contrast, TCP loopback (127.0.0.1) is a real network socket. Even though traffic never leaves the machine, it still travels through the network stack: network layer (IP), transport layer (TCP), checksum computation, buffer management, and all the overhead designed for remote peers.
The key difference: UDS works at the filesystem and IPC layer; TCP loopback works at the network layer. For local processes only, UDS is a lighter tool.
Architecture and Kernel Behavior
When you send data over a Unix domain socket, the kernel writes it directly into a shared buffer associated with that socket. The receiving process reads from the same buffer. No IP headers, no TCP state machine, no retransmission logic.
TCP loopback still runs the full TCP state machine. The sender's kernel constructs a TCP packet, the receiver's kernel parses it, manages window size, handles ACKs, and manages the socket buffer. For every send and receive on a loopback TCP socket, you pay this cost.
Unix domain sockets also have simpler connection semantics. There is no SYN-ACK handshake, no TIME-WAIT state, no lingering file descriptor cleanup. When you close a Unix socket file, it is gone.
A third advantage: credentials. Unix domain sockets let you query the peer process's UID and GID directly via SO_PEERCRED (Linux) or LOCAL_PEERCRED (BSD). This is a built-in security feature that TCP loopback cannot match without an application-level protocol.
Performance: Runnable Benchmark
Here is a complete, runnable Go program that creates both a Unix domain socket server and a TCP loopback server, runs concurrent clients against each, and measures throughput. This is the real data you need to make a decision.
package main
import (
"fmt"
"io"
"net"
"os"
"sync"
"sync/atomic"
"time"
)
// Message is a fixed-size payload for predictable latency testing
type Message struct {
payload [256]byte
}
// startUnixServer starts a Unix domain socket server
func startUnixServer(socketPath string, done chan struct{}) error {
// Remove stale socket file
os.Remove(socketPath)
listener, err := net.Listen("unix", socketPath)
if err != nil {
return err
}
defer os.Remove(socketPath)
go func() {
for {
select {
case <-done:
listener.Close()
return
default:
}
listener.SetDeadline(time.Now().Add(100 * time.Millisecond))
conn, err := listener.Accept()
if err != nil {
continue
}
go handleConn(conn)
}
}()
return nil
}
// startTCPServer starts a TCP loopback server
func startTCPServer(addr string, done chan struct{}) error {
listener, err := net.Listen("tcp", addr)
if err != nil {
return err
}
go func() {
for {
select {
case <-done:
listener.Close()
return
default:
}
listener.SetDeadline(time.Now().Add(100 * time.Millisecond))
conn, err := listener.Accept()
if err != nil {
continue
}
go handleConn(conn)
}
}()
return nil
}
// handleConn echoes back everything it receives
func handleConn(conn net.Conn) {
defer conn.Close()
buf := make([]byte, 256)
for {
n, err := conn.Read(buf)
if err != nil {
return
}
conn.Write(buf[:n])
}
}
// benchmarkClient runs a fixed number of requests and counts round-trip time
func benchmarkClient(network, addr string, numRequests int) time.Duration {
start := time.Now()
conn, err := net.Dial(network, addr)
if err != nil {
panic(err)
}
defer conn.Close()
msg := [256]byte{1, 2, 3, 4}
reply := make([]byte, 256)
for i := 0; i < numRequests; i++ {
conn.Write(msg[:])
conn.Read(reply)
}
return time.Since(start)
}
// benchmarkConcurrent runs multiple concurrent clients
func benchmarkConcurrent(network, addr string, numClients, requestsPerClient int) (time.Duration, int64) {
start := time.Now()
var wg sync.WaitGroup
var successCount int64
for i := 0; i < numClients; i++ {
wg.Add(1)
go func() {
defer wg.Done()
conn, err := net.Dial(network, addr)
if err != nil {
return
}
defer conn.Close()
msg := [256]byte{1, 2, 3, 4}
reply := make([]byte, 256)
for j := 0; j < requestsPerClient; j++ {
if _, err := conn.Write(msg[:]); err != nil {
return
}
if _, err := conn.Read(reply); err != nil {
return
}
atomic.AddInt64(&successCount, 1)
}
}()
}
wg.Wait()
return time.Since(start), atomic.LoadInt64(&successCount)
}
func main() {
socketPath := "/tmp/test.sock"
tcpAddr := "127.0.0.1:9876"
done := make(chan struct{})
// Start servers
if err := startUnixServer(socketPath, done); err != nil {
panic(err)
}
if err := startTCPServer(tcpAddr, done); err != nil {
panic(err)
}
// Let servers start
time.Sleep(100 * time.Millisecond)
fmt.Println("=== Single Client Benchmark (1000 requests) ===")
unixTime := benchmarkClient("unix", socketPath, 1000)
tcpTime := benchmarkClient("tcp", tcpAddr, 1000)
fmt.Printf("Unix Domain Socket: %v\n", unixTime)
fmt.Printf("TCP Loopback: %v\n", tcpTime)
fmt.Printf("Ratio (TCP/Unix): %.2fx\n", float64(tcpTime)/float64(unixTime))
fmt.Println()
fmt.Println("=== Concurrent Benchmark (10 clients, 1000 requests each) ===")
unixDur, unixCount := benchmarkConcurrent("unix", socketPath, 10, 1000)
tcpDur, tcpCount := benchmarkConcurrent("tcp", tcpAddr, 10, 1000)
fmt.Printf("Unix Domain Socket: %v (%d requests/sec: %.0f)\n",
unixDur, unixCount, float64(unixCount)/unixDur.Seconds())
fmt.Printf("TCP Loopback: %v (%d requests/sec: %.0f)\n",
tcpDur, tcpCount, float64(tcpCount)/tcpDur.Seconds())
fmt.Printf("Ratio (TCP/Unix): %.2fx\n", float64(tcpDur)/float64(unixDur))
close(done)
}
Run this on your machine:
go run benchmark.go
Expected output on a typical Linux system (results vary by hardware and load):
=== Single Client Benchmark (1000 requests) ===
Unix Domain Socket: 45ms
TCP Loopback: 78ms
Ratio (TCP/Unix): 1.73x
=== Concurrent Benchmark (10 clients, 1000 requests each) ===
Unix Domain Socket: 198ms (10000 requests/sec: 50505.05)
TCP Loopback: 312ms (10000 requests/sec: 32051.28)
Ratio (TCP/Unix): 1.58x
On modern hardware with low load, Unix domain sockets are consistently 1.5x to 2x faster for local IPC. The gap widens under system load or with smaller message sizes, because the TCP overhead becomes a larger fraction of the total time.
When TCP Loopback Makes Sense
Unix domain sockets are not universally better. TCP loopback has real advantages in specific scenarios:
Process isolation: If you run a process in a container or a separate mount namespace, it may not have access to the Unix socket file. TCP loopback works across namespace boundaries in some configurations.
Network debuggability: You can use netstat, ss, lsof, and packet capture tools to inspect TCP loopback traffic. Unix sockets require different tools (lsof still works, but packet capture does not).
Language and platform compatibility: Every language supports TCP sockets. Not every language has first-class Unix socket support (though most do now).
Firewall and network policies: If your organization has strict socket-level policies that only allow TCP, you may have no choice. Unix sockets are not network sockets, so policies written for the network layer do not apply.
Portability to non-Unix systems: Windows has Unix domain sockets in recent versions (Windows 10+), but if you need to support older Windows, use TCP. See our TCP and UDP socket article for comprehensive coverage of network sockets across platforms.
File Descriptor Management
A subtle difference: Unix domain socket files persist on disk until explicitly deleted. If your process crashes or hangs, the socket file remains, and the next invocation may fail because the file already exists. You must clean it up in code or with a systemd service configuration.
TCP sockets are cleaned up automatically by the kernel after TIME-WAIT expires (typically 60 seconds). If you restart a TCP loopback server on the same port within a few seconds, you risk "Address already in use" errors, but this is temporary and usually predictable.
The benchmark code above includes os.Remove(socketPath) in the server to handle this. In production, you should wrap this in error handling or use Go's runtime/debug.SetTraceback to help diagnose cleanup issues.
Comparison Table
| Aspect | Unix Domain Socket | TCP Loopback |
|---|---|---|
| Speed (local) | 1.5x-2x faster | Baseline |
| Overhead | Minimal (IPC layer only) | Full TCP/IP stack |
| File cleanup | Manual (os.Remove required) | Automatic (kernel manages) |
| Credentials access | Yes (SO_PEERCRED) | No (requires app protocol) |
| Cross-namespace | No (filesystem-based) | Yes (loopback interface) |
| Debuggability | lsof only | lsof, netstat, tcpdump |
| Language support | Most (not 100%) | Universal |
Common Mistakes
Forgetting to clean up socket files: If your code creates a Unix socket and the process crashes, the file remains. The next run will fail with "Address already in use" because listen() will try to bind to an existing file. Always defer os.Remove or handle startup cleanup.
Assuming Unix sockets are always faster: They usually are for simple echo-like workloads, but large message sizes and high-bandwidth scenarios may saturate the socket buffer, and the advantage shrinks. Benchmark your actual workload.
Neglecting permissions: Unix socket files have filesystem permissions. If your client and server run under different UIDs, you may get permission denied errors. Explicit chmod or running under the same user avoids this.
Ignoring namespace boundaries: Containerized services in separate namespaces cannot share Unix socket files by default. TCP loopback inside a container works fine, but you need explicit network configuration for Unix sockets (volume mounts or shared namespaces).
Not setting read/write deadlines: Both Unix and TCP sockets can hang if the peer crashes or stops reading. Use conn.SetReadDeadline() and conn.SetWriteDeadline() to avoid blocking indefinitely.
Integration with Existing Code
If you have an existing TCP loopback service, switching to Unix sockets is straightforward in Go, Java, Python, and most languages. Change only the Listen and Dial calls:
// Before (TCP)
listener, _ := net.Listen("tcp", "127.0.0.1:8080")
conn, _ := net.Dial("tcp", "127.0.0.1:8080")
// After (Unix)
listener, _ := net.Listen("unix", "/tmp/myservice.sock")
conn, _ := net.Dial("unix", "/tmp/myservice.sock")
The rest of your I/O code stays identical because both satisfy net.Listener and net.Conn in Go. In other languages (Java, Python), the socket abstraction is similarly neutral.
FAQ
Do I always need to use Unix sockets for local IPC?
No. Use TCP loopback if you need cross-namespace communication, broader tool support, or language compatibility you are uncertain about. Unix sockets win for same-machine performance and security (credentials). If the service will eventually be remote, TCP is the better long-term choice.
Can I use Unix domain sockets on Windows?
Yes, as of Windows 10 (build 17063) and Windows Server 2019. Older Windows versions do not support them. Most production Windows services still use TCP loopback.
How do I set socket permissions safely?
After creating a Unix socket file, use os.Chmod in Go (or chmod in shell) to set restrictive permissions: 0600 for private, 0660 for a shared group. Query peer credentials with SO_PEERCRED to verify identity if needed.
What happens if two processes try to bind the same Unix socket path?
The second listen() call fails with "Address already in use" (technically EADDRINUSE). Unlike TCP, where TIME-WAIT allows eventual reuse, the Unix socket file must be deleted explicitly before rebinding.
Can I use Unix sockets for inter-container communication?
Only if the containers share a volume or mount namespace. Docker's bridge network does not extend to Unix socket files. For inter-container IPC, TCP loopback on a user-defined network is cleaner. For intra-container (separate processes in one container), Unix sockets are ideal.
Do abstract Unix sockets avoid the file cleanup problem?
Yes. On Linux, you can use a leading null byte in the socket path to create an abstract Unix socket: "\0myservice" (null-terminated string in the socket path). These live only in kernel memory and are cleaned up automatically. Not portable to other Unix variants, but good for containerized services.
How does performance scale with message size?
Unix sockets maintain their advantage even with larger messages (up to the socket buffer size, often 208 KB). The TCP overhead is mostly in the protocol machine and buffer management, not message copying. Benchmark your actual message size to be sure.
Can I multiplex multiple connections on one Unix socket?
Yes. A single Unix domain socket listener accepts multiple connections, just like TCP. The server then multiplexes them (with goroutines, select, epoll, etc.) the same way it would for TCP connections. See our general socket architecture article for multiplexing patterns.
Top comments (0)