Socket Programming Basics: Complete Beginner's Guide

Socket programming is how applications talk to each other over a network. A socket is an endpoint for communication, identified by an IP address plus a port number — for example, a web server listens on a socket at its IP address, port 80. Programs create sockets, connect them, and then simply read and write bytes, while the operating system handles packets, retransmission, and routing.

This matters because every networked app — browsers, chat apps, games, APIs — is built on sockets. Understanding sockets reveals what actually happens when you type a URL: a connection to a remote socket, bytes flowing both ways, then a clean close. It is the foundation skill for network programming in Python, Java, C, and every other language.

Key Concepts

• Socket: a communication endpoint; the combination IP + port identifies one application on one host.
• Port: a 16-bit number (0–65535); 0–1023 are well-known (80 HTTP, 443 HTTPS); clients use ephemeral ports (49152–65535).
• TCP socket (SOCK_STREAM): reliable, ordered byte stream. UDP socket (SOCK_DGRAM): unreliable datagrams.
• Server calls: socket → bind (claim an address/port) → listen (wait) → accept (take one client, returning a new socket for that connection).
• Client calls: socket → connect (to the server's address/port) → send/recv.
• Network byte order: multi-byte numbers travel big-endian on the wire; functions like htons() convert host order to network order.
• Blocking: by default, recv() waits until data arrives.

How It Works

1. A server creates a TCP socket, binds it to 0.0.0.0:8080 (all its network interfaces, port 8080), and listens.
2. A client creates its own socket and connects to the server's IP and port; the OS picks the client an ephemeral port and performs TCP's three-way handshake behind the scenes.
3. Accept on the server returns a dedicated socket for that client, so the listening socket stays free for the next one.
4. Both sides now call send() and recv() as if writing to a file — TCP guarantees the bytes arrive in order. When done, either side closes, and the OS runs TCP's shutdown handshake.
5. With UDP the dance is shorter: no listen/accept/connect — just bind, then sendto() and recvfrom() with an address on every datagram.

Worked Example

A browser at 192.168.1.10 opens https://93.184.216.34 (port 443).

1. The client socket gets an ephemeral port, say 49152. The connection is fully identified by the 4-tuple (192.168.1.10, 49152, 93.184.216.34, 443) — which is why one server port can serve thousands of clients at once.
2. The port number 443 travels in network byte order (big-endian). 443 ÷ 256 = 1 remainder 187, so the two bytes on the wire are 0x01, 0xBB (check: 1 × 256 + 187 = 443).
3. On a little-endian laptop, htons(443) swaps the bytes so they leave in that order; the server's ntohs() swaps them back.
4. Data flows — the browser sends the HTTP request bytes, the server replies, and either side's close() ends it.

Four numbers identified the conversation, two bytes carried the port, and the app never saw a single packet.

Common Misconceptions

• "One port serves one client." The listening port accepts unlimited connections; each gets its own socket distinguished by the client's address and port.
• "send() guarantees the other side received it." send() only hands bytes to the OS; with TCP, acknowledgments confirm arrival — with UDP, nothing does.
• "Sockets are only for the internet." The same API connects programs on one machine (localhost), and Unix domain sockets skip networking entirely.

Real-World Applications

• Web servers and browsers, chat and game servers, REST APIs.
• Database clients connecting to Postgres or MySQL.
• IoT devices reporting sensor data to the cloud.

A socket is an IP-plus-port endpoint; servers bind, listen, and accept while clients connect, then both sides just read and write bytes. The 4-tuple and byte-order math show how thousands of conversations share one port correctly. Master this, and network programming in any language follows the same script.