Socket Options That Matter - Go Optimization Guide

Skip to content

Initializing search

GitHub

Concurrency and Synchronization

I/O Optimization and Throughput

Compiler-Level Optimization and Tuning

Practical Networking Patterns

Foundations and Core Concepts

Scaling and Performance Engineering

Diagnostics and Resilience

Transport-Level Optimization

Low-Level and Advanced Tuning

Tuning DNS Performance in Go Services

Optimizing TLS for Speed

Connection Lifecycle Observability

Version Performance Tracking

Low-Level Network Optimizations: Socket Options That Matter¶

Socket settings can limit both throughput and latency when the system is under load. The defaults are designed for safety and compatibility, not for any particular workload. In practice they often become the bottleneck before CPU or memory do. Go lets you reach the underlying file descriptors through syscall, so you can change key socket options without giving up its concurrency model or the standard library.

Disabling Nagle’s Algorithm: TCP_NODELAY¶

Nagle’s algorithm exists to make TCP more efficient. Every tiny packet you send carries headers that add up to a lot of wasted bandwidth if left unchecked. Nagle fixes that by holding back small writes until it can batch them into a full segment, cutting down on overhead and network chatter. That trade-off — bandwidth at the expense of latency — is usually fine, which is why it’s on by default. But if your application sends lots of small, time-critical messages, like a game server or a trading system, waiting even a few milliseconds for the buffer to fill can hurt.

sequenceDiagram<br>participant App as Application<br>participant TCP as TCP Stack<br>participant Net as Network

App->>TCP: Send 1 byte<br>note right of TCP: Buffering (no ACK received)<br>App->>TCP: Send 1 byte<br>note right of TCP: Still buffering...

TCP-->>Net: Send 2 bytes (batched)<br>Net-->>TCP: ACK received

App->>TCP: Send 1 byte<br>TCP-->>Net: Immediately send (ACK received, buffer clear)<br>Nagle’s algorithm trades latency for efficiency by holding back small packets until there’s more data to send or an acknowledgment comes back. That delay is fine for bulk transfers but a problem for anything that needs fast, small messages. Setting TCP_NODELAY turns it off so data goes out immediately. This is critical for workloads like gaming, trading, real-time video, and other interactive systems where you can’t afford to wait.

In Go, you can turn off Nagle’s algorithm with TCP_NODELAY:

func SetTCPNoDelay(conn *net.TCPConn) error {<br>return conn.SetNoDelay(true)

SO_REUSEPORT for Scalability¶

SO_REUSEPORT lets multiple sockets on the same machine bind to the same port and accept connections at the same time. Instead of funneling all incoming connections through one socket, the kernel distributes new connections across all of them, so each socket gets its own share of the load. This is useful when running several worker processes or threads that each accept connections independently, because it removes the need for user-space coordination and avoids contention on a single accept queue. It also makes better use of multiple CPU cores by letting each process or thread handle its own queue of connections directly.

Typical scenarios for SO_REUSEPORT:

High-performance web servers where multiple worker processes call bind() on the same port. The kernel distributes incoming connection requests across the accept() queues of all bound sockets, typically using a hash of the 4-tuple or round-robin, eliminating the need for a user-space dispatcher.

Multi-threaded or multi-process servers that accept connections in parallel. When combined with Go’s GOMAXPROCS, each thread or process can call accept() independently on its own file descriptor, avoiding lock contention on a single queue and fully utilizing all CPU cores.

Fault-tolerant designs where multiple processes bind to the same port to increase resilience. If one process exits or is killed, the others continue to service connections without interruption, because each maintains its own independent accept() queue.

In Go, SO_REUSEPORT isn’t exposed in the standard library, but it can be set via syscall when creating the socket. This is done with syscall.SetsockoptInt, which operates on the socket’s file descriptor. You pass the protocol level (SOL_SOCKET), the option (SO_REUSEPORT), and the value (1 to enable). This must happen before calling bind(), so it’s typically placed in the Control callback of a net.ListenConfig, which runs before the socket is bound.

listenerConfig := &net.ListenConfig{<br>Control: func(network, address string, c syscall.RawConn) error {<br>return c.Control(func(fd uintptr) {<br>syscall.SetsockoptInt(int(fd), syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1)<br>})<br>},<br>listener, err := listenerConfig.Listen(context.Background(), "tcp", ":8080")

Tuning Socket Buffer Sizes: SO_RCVBUF and SO_SNDBUF¶

Socket buffer sizes — SO_RCVBUF for receiving and SO_SNDBUF for sending — directly affect throughput...