What Is a Socket?

Right now, dozens of programs on your computer are using the network. Your browser has multiple tabs open. Email syncs in the background. A video streams. The operating system checks for updates.

But your computer has one network connection.

When a packet arrives, how does it know which program it belongs to? The browser tab showing YouTube, or the one loading your bank? The email client or the system updater?

A socket is an endpoint—a specific destination inside your computer where one program's network conversation happens. Every networked program creates at least one socket, and that socket has an address that makes it unique across the entire Internet.

The Socket Address

A socket is identified by three things:

• IP address — which computer on the network
• Port number — which program on that computer (0–65535)
• Protocol — TCP or UDP

Together, these form a socket address. Your browser might create a socket at 192.168.1.50:52431/TCP. The web server has a socket at 93.184.216.34:443/TCP. Packets traveling between them carry both addresses.

The IP address is which building. The port is which apartment. That's it.

Why Port Numbers Exist

Your computer can maintain thousands of connections simultaneously because each one has a unique combination of IP addresses and port numbers.

When your browser connects to a web server, it picks an unused port—say, 52431—for its end of the conversation. The server listens on port 443 (the standard HTTPS port). Every packet carries both the source and destination socket addresses, so they always reach the right place.

The operating system reads the destination port on each incoming packet and delivers it to the socket that owns that port. Different conversations, different ports, no collisions.

Stream Sockets vs. Datagram Sockets

Sockets come in two types, matching the two transport protocols.

Stream sockets use TCP. They establish a connection—a dedicated channel that guarantees data arrives in order, intact, exactly once. You connect, exchange data, disconnect. Like a phone call.

Web browsing, email, and file transfers use stream sockets. The cost is overhead: TCP must handshake, track acknowledgments, and retransmit lost packets.

Datagram sockets use UDP. No connection, no guarantees. You send a packet; it either arrives or doesn't. You send another; it might arrive first. Like mailing postcards.

Video streaming, online gaming, and DNS lookups use datagram sockets. If a video frame disappears, keep playing—pausing to request retransmission would be worse. Speed matters more than perfection.

The Socket Lifecycle

Stream sockets have a lifecycle because TCP connections do.

A server socket calls listen() to start accepting connections. A client socket calls connect() to reach out. Once TCP's three-way handshake completes, both sockets enter the established state—where data flows.

Closing is more complex. TCP needs both sides to agree the conversation is over. The initiating side goes through FIN-WAIT-1, FIN-WAIT-2, and TIME-WAIT. The other side goes through CLOSE-WAIT and LAST-ACK.

TIME-WAIT looks strange at first. After closing, the socket lingers for 60 seconds (on Linux; other systems vary) before fully disappearing. Why quarantine a closed socket?

Because packets take strange paths through the Internet. An old packet might wander in like a ghost from a previous conversation. If the system immediately reused that socket address for a new connection, the ghost packet could corrupt it. TIME-WAIT ensures any lingering packets have died before the address is reused.

Datagram sockets skip all this. No connection means no connection state.

The Programming Interface

The socket API originated in 1980s BSD Unix and became the universal standard. C, Python, Go, JavaScript—all use the same model.

Creating a socket: socket() returns a handle to a new socket.

For servers: bind() claims a port, listen() starts accepting connections, accept() waits for clients. Each accepted connection creates a new socket for that conversation.

For clients: connect() with the server's address. Once connected, the socket is ready.

For everyone: send() and recv() move data. The operating system handles segmentation, checksums, retransmission, reassembly. You write bytes in, read bytes out.

This abstraction is why network programming is possible. You don't construct TCP headers or calculate checksums. You tell the socket what to send; it handles the protocols.

Socket Options

Sockets can be tuned.

SO_REUSEADDR lets you bind to a port still in TIME-WAIT. Without it, restarting a server means waiting for old connections to clear—annoying in development, unacceptable in production.

SO_KEEPALIVE sends periodic probes on idle connections to detect if the other end has vanished.

Buffer sizes control how much data the OS queues. Larger buffers improve throughput on high-latency links; smaller buffers reduce memory and latency.

Timeouts prevent operations from blocking forever when networks misbehave.

The Foundation

Every networked application is built on sockets. They're the boundary where your program ends and the network begins.

You don't think about packets, routes, or retransmissions. You open a socket, send data, receive data, close the socket. The entire complexity of the Internet's protocols happens beneath that interface.

Sockets are the fundamental unit of network communication. HTTP, WebSockets, database connections, APIs—all of it rests on this foundation.