Boosting Local Communication Performance with Local Sockets

What is a Socket? A socket enables communication between processes. In operating system terminology, this is known as inter-process communication (IPC).

More specifically, this post focuses on Unix Domain Sockets. A Unix socket creates an endpoint for communication and returns a descriptor (as per the Unix man page), which can be used to send and receive data.

Types of Sockets

In Unix/Linux systems, sockets are created using the socket() function (man page) . The first parameter of this function is an integer value called domain ( 😅 not types ), which defines the communication domain — essentially, where the communication will take place.

Unix/Linux provides several domains for sockets:

• macOS has 9 domains, one of them is deprecated.
• FreeBSD has 12 domains.
• Linux? Well, it has more, why not…

The most commonly used domains are:

• PF_INET (for IPv4 communication over the network)
• PF_INET6 (for IPv6 communication over the network)

However, in this post, we’re particularly interested in PF_LOCAL, also known as Local Sockets.

Local Sockets:

Sockets in the PF_LOCAL domain facilitate communication between processes on the same machine (local IPC). Instead of relying on IP addresses or network protocols, they use the file system as a communication medium. Each Unix socket is represented as a special file.

Why to use Local Sockets? In my case since Local sockets don’t pass through the network stack, they offer:

• Low-latency communication
• Reduced overhead (no need for IP routing, TCP handshakes, etc.)

Just like network sockets, socket() returns a file descriptor, which can be used to send and receive data through standard read/write operations.

Where Are Local Sockets Used?

A well-known example is the Docker API. Instead of exposing the API over an IP address, Docker uses a Unix socket for security and performance reasons. The Docker daemon typically listens on:

/var/run/docker.sock

You can find more details in the Docker documentation.

My Use Case

I explored Unix sockets as a communication method between two services inside the same Kubernetes pod (sidecar pattern).

• Service A provides an API.
• Service B sends data to Service A for validation.
• Data is sent using a normal HTTP GET request, but instead of using TCP, it uses a Unix socket.

Benchmarking (Performance Comparison)

I built a simple server that operates in two modes:

1. HTTP over TCP
2. HTTP over a Local Sockets.

To benchmark performance, I used a simple Bash script that runs curl requests and measures response times. The code is available here. Results

TCP Benchmark Results:
 - - - - - - - - - - -
Latency Statistics (seconds):
Minimum: 0.002243s
Maximum: 0.002243s
Average: 0.002243s
Unix Domain Socket Benchmark Results:
 - - - - - - - - - - - - - - - - - -
Latency Statistics (seconds):
Minimum: 0.000176s
Maximum: 0.000176s
Average: 0.000176s
Summary Statistics:
 - - - - - - - - - 
Number of requests: 1000
Concurrency level: 1

**Key Takeaways

• **Local Sockets are ~92.2% faster than TCP for local communication.
• Both show stable performance across 1,000 requests with 1 thread.
• These numbers aren’t perfect, but they give a good starting point for further testing.

Final Thoughts

• Local sockets offer low-latency communication without significant changes to how applications work.
• Best suited for one-to-one communication.
• Not ideal for multi-party communication because each connection requires a separate socket file (unless managed via a central node).

👋 Salam