What Is a Network Socket?

A Socket Is an Endpoint, Not a Connection

The word "socket" gets used loosely, so it is worth being precise. A socket is one end of a communication channel. It is defined by three things: a transport protocol (TCP or UDP), an IP address, and a port number. Written out, a socket looks like 192.0.2.10:443 — an address and a port joined by a colon.

A connection is then a pairing of two sockets: one on the client, one on the server. Data written into the client's socket comes out of the server's socket, and vice versa. The connection is the pipe; each socket is a mouth of that pipe.

To the program, a socket behaves like a file handle. It calls an operation to write bytes and another to read them; the operating system's network stack takes care of wrapping those bytes into segments and packets, attaching the right headers, and putting them on the wire. This "treat the network like a file" abstraction is what made sockets the universal programming interface for networking across virtually every operating system.

The Lifecycle: Bind, Listen, Accept, Connect

Servers and clients use sockets differently. A server follows a fixed sequence:

1. Create a socket of the right type (TCP or UDP).
2. Bind it to an IP address and port — for example, "listen on port 443 on all interfaces."
3. Listen, marking the socket as passive and ready to accept incoming connections.
4. Accept each arriving connection, which spawns a brand-new connected socket dedicated to that one client.

A client is simpler: it creates a socket and connects it to the server's address and port, which triggers the TCP three-way handshake for a TCP socket.

The key insight is in step 4. The listening socket never carries application data — it only manufactures new connected sockets. So a busy web server has exactly one listening socket on port 443 but potentially thousands of connected sockets, every one of them also "on" port 443. That seems contradictory until you see how connections are actually distinguished.

The 5-Tuple: How Thousands of Connections Share One Port

The operating system does not identify a connection by a single socket. It identifies it by the 5-tuple — five values that together are unique across the whole machine:

As long as any one of those five values differs, the connection is distinct. Two browsers on the same home network connecting to the same web server share the same destination IP and port — but their source IPs and source ports differ, so the server keeps the two streams perfectly separate. Even a single computer opening several connections to the same server gets a different ephemeral source port for each, which is what keeps them from being confused.

This is the real answer to "how can one port serve so many users at once": the port number is only one-fifth of the connection's identity.

Port vs Socket: The Distinction That Trips People Up

A port is just a 16-bit number — a label. A socket is a full endpoint (address + port + protocol), and a connected socket is bound to a complete 5-tuple. Saying "port 443 is busy" usually means a listening socket is already bound to that port; it does not mean only one connection can use it. The confusion comes from collapsing the label (the port) and the endpoint (the socket) into one idea.

One more wrinkle: TCP and UDP have entirely separate port spaces, so a TCP socket on port 53 and a UDP socket on port 53 are unrelated. DNS famously uses both.

Reading Socket State With ss and netstat

Every active socket on a machine sits in a state you can inspect with tools like ss (Linux) or netstat. The common TCP states map directly onto the connection lifecycle:

A pile-up of TIME_WAIT sockets on a busy server is normal, not a bug — it is the stack being careful that a delayed packet from a finished connection cannot be mistaken for data on a new one that happens to reuse the same address and port.

TCP Sockets vs UDP Sockets

The socket abstraction covers both transport protocols, but they behave differently. A TCP socket is connection-oriented: you connect once, then read and write a continuous, ordered byte stream, and the kernel handles retransmission and ordering for you. A UDP socket is connectionless: there is no handshake and no guaranteed delivery — the program sends and receives discrete datagrams, each addressed independently, and is responsible for handling any loss itself. This is why latency-sensitive workloads like VoIP, gaming, and DNS lookups lean on UDP, while anything that must arrive intact — web pages, file transfers, email — uses TCP. The trade-offs are covered in depth in TCP vs UDP.

Frequently Asked Questions

What is a network socket?

A socket is one endpoint of a network connection: an IP address combined with a port number and a transport protocol (TCP or UDP). Programs read from and write to sockets much like files, and the operating system turns those operations into packets.

What is the difference between a port and a socket?

A port is a 16-bit number; a socket is the full endpoint (IP + port + protocol). Many connections can share one port because each is identified by a complete 5-tuple, not by the port alone.

What is the 5-tuple?

The five values that uniquely identify a connection: protocol, source IP, source port, destination IP, and destination port. If any one differs, it is a separate connection — which is how one server port handles many clients at once.

What is a listening socket?

A server-side socket bound to an address and port, waiting for incoming connections. Accepting a connection creates a new connected socket for that client while the listening socket stays open for the next one.

What does TIME_WAIT mean?

A state the closing side enters after its final acknowledgement, held briefly so that delayed packets from the old connection are not mistaken for a new connection reusing the same address and port. A backlog of TIME_WAIT sockets on a busy server is expected behaviour.