Updated 10 hours ago
Your computer has one network connection. But right now, dozens of programs are using the network—your browser has multiple tabs open, email is syncing in the background, a video is streaming, your operating system is checking for updates.
Here's the problem: when a packet arrives at your computer, 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?
Sockets solve this. 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 (a 16-bit number, 0–65535)
Protocol — TCP or UDP
Together, these form a socket address. Your web browser might create a socket at 192.168.1.50:52431/TCP. The web server it's connecting to has a socket at 93.184.216.34:443/TCP. When packets travel between them, these addresses ensure they arrive at the right place.
The IP address gets packets to your computer. The port number gets them to the right program. That's the whole trick.
Why Port Numbers Exist
Think of your computer as an apartment building. The IP address is the building's street address—it gets mail to the right building. But mail for apartment 443 shouldn't go to apartment 22.
Port numbers are apartment numbers. When your browser connects to a web server, it picks an unused port (say, 52431) for its end of the conversation. The server is listening on port 443 (the standard HTTPS port). Packets flowing in both directions carry both addresses, so they always reach the right socket.
This is why your computer can maintain thousands of connections simultaneously. Each one has a unique combination of IP addresses and port numbers. The operating system reads the destination port on each incoming packet and delivers it to the socket that owns that port.
Stream Sockets vs. Datagram Sockets
Sockets come in two main types, matching the two transport protocols.
Stream sockets use TCP. They establish a persistent connection between two endpoints—a dedicated channel that guarantees data arrives in order, intact, exactly once. You connect, exchange data back and forth, then disconnect. Like a phone call: you dial, talk, hang up.
Web browsing, email, file transfers, and anything requiring reliable delivery use stream sockets. The cost is overhead—TCP must handshake, track what's been received, and retransmit lost packets.
Datagram sockets use UDP. No connection, no guarantees. You send a packet to an address; it either arrives or it doesn't. You send another packet; it might arrive before the first one. Like mailing postcards: you address each one separately, and delivery is best-effort.
Video streaming, online gaming, DNS lookups, and real-time applications use datagram sockets. If a few video frames disappear, it's better to keep playing than to pause and request retransmission. Speed matters more than perfection.
The Socket Lifecycle
Stream sockets have a lifecycle because TCP connections have a lifecycle.
A new socket starts closed—it exists but isn't connected to anything. A server socket calls listen() to become listening, waiting for incoming connections. A client socket calls connect() to reach out to a server.
Once TCP's three-way handshake completes, both sockets enter the established state. This is where data actually flows. Most of a connection's life is spent here.
Closing is more complex. TCP needs both sides to agree the conversation is over. The side that initiates closing goes through a sequence of states—FIN-WAIT-1, FIN-WAIT-2, and finally TIME-WAIT—before returning to closed. The other side goes through CLOSE-WAIT and LAST-ACK.
The TIME-WAIT state looks strange at first. After a connection closes, the socket lingers for 30–120 seconds before fully disappearing. Why?
Because packets can take strange paths through the Internet. An old packet might arrive late. If the system immediately reused the same socket address for a new connection, that stray packet could be misinterpreted as part of the new conversation. TIME-WAIT quarantines the address until any lingering packets have certainly died.
Datagram sockets skip all this. No connection means no connection state. They're either open or closed.
The Programming Interface
The socket API originated in 1980s BSD Unix and became the universal standard. Whether you're programming in C, Python, Go, or JavaScript, you'll find the same conceptual model.
Creating a socket: Call socket() to get a handle—a reference to a new socket the operating system manages for you.
For servers: Call bind() to claim a specific port, listen() to start accepting connections, then accept() to wait for clients. Each accepted connection gives you a new socket for that specific conversation.
For clients: Call connect() with the server's address. Once connected, the socket is ready.
For everyone: Call send() and recv() to move data. The operating system handles segmentation, checksums, retransmission, and reassembly. You just write bytes in and read bytes out.
This abstraction is why network programming is tractable. You don't construct TCP headers or calculate checksums. You tell the socket what data to send; it handles the protocols.
Socket Options
Sockets can be tuned for specific needs.
SO_REUSEADDR lets you bind to a port that's still in TIME-WAIT. Without this, restarting a server requires waiting up to two minutes for old connections to fully clear—annoying during development, unacceptable in production.
SO_KEEPALIVE sends periodic probes on idle connections to detect if the other end has vanished. Useful for long-lived connections that might sit quiet for hours.
Buffer sizes control how much data the operating system queues for sending and receiving. Larger buffers improve throughput on high-latency connections; smaller buffers reduce memory usage and latency.
Timeouts prevent operations from blocking forever when networks misbehave.
What Sockets Make Possible
Every networked application you use—every website, every streaming service, every online game, every chat app—is built on sockets. They're the boundary where your application ends and the network begins.
The elegance is in what they hide. 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 simple interface.
When you understand sockets, you understand the fundamental unit of network communication. Everything else—HTTP, WebSockets, databases, APIs—is built on top of this foundation.
Frequently Asked Questions About Sockets
Was this page helpful?