Sockets & Ports (Network Programming Basics)

In UNIX-like operating systems, "everything is a file." A socket is an operating system file descriptor (integer handle) representing a communication endpoint.

When a server starts:

1. socket(): Creates the socket descriptor.
2. bind(): Associates the socket with an IP address and Port (e.g. 0.0.0.0:8080).
3. listen(): Puts socket in passive listening mode with a backlog queue.
4. accept(): Blocks/waits until a client connects, returning a new socket descriptor dedicated to that specific client connection.

package main

import (
    "fmt"
    "net"
)

func main() {
    listener, err := net.Listen("tcp", ":8080")
    if err != nil {
        panic(err)
    }
    defer listener.Close()
    fmt.Println("🚀 Server listening on port 8080...")

    for {
        conn, err := listener.Accept()
        if err != nil {
            continue
        }
        // Spawn lightweight goroutine per socket
        go handleClient(conn)
    }
}

func handleClient(conn net.Conn) {
    defer conn.Close()
    buf := make([]byte, 1024)
    n, _ := conn.Read(buf)
    conn.Write([]byte("HTTP/1.1 200 OK\r\nContent-Length: 13\r\n\r\nHello Socket!"))
    _ = n
}

A common misconception is that a web server can only accept 65,535 simultaneous connections because ports are 16-bit integers.

Reality: The 65,535 limit applies to outgoing connections sharing a single source IP. Because a connection is identified by the full 5-Tuple (Protocol, Src IP, Src Port, Dst IP, Dst Port), a single server listening on port 443 can easily hold millions of concurrent open connections, constrained only by available RAM (socket buffer memory) and OS file descriptor limits (ulimit -n).

The C10K Problem (Dan Kegel, 1999) asked: how can a single server handle 10,000 concurrent client connections efficiently? The naive approach — 1 OS thread per connection — fails because:

• Each thread consumes 1–8MB of stack memory (10,000 threads = 8–80 GB RAM)
• Context-switching 10,000 OS threads generates massive scheduler overhead

Solution: I/O Multiplexing

• select() / poll() (old): Scan all file descriptors linearly — O(N) per wakeup. Becomes slow at thousands of connections.
• epoll (Linux 2.6+): Kernel maintains an event-driven watch list. Only notifies the application about FDs with actual data — O(1) per event. Nginx, Node.js, and Redis all use epoll internally.
• kqueue (BSD/macOS): Equivalent to epoll, used by Nginx and Go's runtime on macOS.
• io_uring (Linux 5.1+): Next-generation async I/O interface using shared memory ring buffers between kernel and userspace, eliminating syscall overhead entirely. Dramatically higher throughput for disk + network I/O at extreme scales.

SO_REUSEPORT (Linux 3.9+) is a socket option that allows multiple processes or threads to bind to the same port simultaneously. The kernel load-balances incoming connections across all listening sockets using a hash of the 4-tuple (src IP, src port, dst IP, dst port).

Before SO_REUSEPORT: A single process ran the accept loop, becoming a bottleneck on multi-core CPUs. After SO_REUSEPORT: Each CPU core can run its own accept loop on the same port, eliminating the accept lock contention bottleneck. Nginx uses SO_REUSEPORT to scale across all CPU cores.

Configuration in Nginx: listen 443 ssl reuseport; This can increase connection throughput by 3-4x on high-core-count machines.