What Is a Network Socket? Socket vs. Port Explained

Sockets and ports get confused constantly -- here's the difference, built up step by step.

  1. What a socket actually is

    A socket is the combination of an IP address, a port number, and a protocol (TCP or UDP) -- together they form one endpoint of a network connection. Using a phone analogy: the IP address is a building's street address, the port number is an extension inside that building, and the socket is the specific line that's actually connected for a call.

  2. How a port differs from a socket

    A port number is just a single number (0-65535) indicating which service to reach. A socket is more specific: it combines that port number with an actual IP address and protocol to form one concrete connection. The same port 80 produces a different socket for every client IP that connects, which is exactly how a web server can serve many people at once on the same port.

  3. Socket pairs identify each connection

    A single TCP connection is uniquely identified by a socket pair -- the combination of your own IP:port and the remote IP:port. That's how a server can accept thousands of simultaneous connections on the same port 80 and still know exactly which incoming data belongs to which client.

  4. TCP sockets vs UDP sockets

    A TCP socket establishes a connection first (a three-way handshake, like placing a phone call) and guarantees data arrives in order, while a UDP socket sends data immediately without setting up a connection first, more like dropping a postcard in the mail. Applications where accuracy matters, like loading a website, tend to use TCP; applications where speed matters more, like live gaming or video calls, often use UDP.

  5. Well-known ports vs. ephemeral ports

    Ports like 80 (HTTP) and 443 (HTTPS) are "well-known ports" that servers use by convention so clients know where to connect. The port your own device uses when connecting out to a server, by contrast, is an ephemeral port automatically assigned by the operating system (typically in the 49152-65535 range) -- not something you need to manage yourself.

  6. How a socket address is written

    A socket address is commonly written as "IP address:port number." For example, 192.168.0.10:8080 refers to port 8080 on the device at 192.168.0.10. You'll see this notation often in server configuration files and developer tools.

  7. Listening sockets vs. established sockets

    A server program waiting for new connections on a given port holds a listening socket, while a socket that has an active, ongoing exchange of data with a client is an established socket. Network diagnostic tools like netstat let you see directly which sockets are currently listening and which are established.

  8. What a firewall actually controls is sockets

    When a firewall rule "blocks a port," what it's really doing is preventing new socket connections from being made on that port. Once you understand sockets, concepts like port forwarding, firewall rules, and proxy configuration all click into place as variations on the same underlying idea.

  9. The three port ranges

    IANA divides port numbers into well-known ports (0-1023), registered ports (1024-49151), and dynamic or private ports (49152-65535). Well-known ports are assigned to core services such as 22 for SSH, 25 for mail transfer, 53 for DNS, and 80 and 443 for the web. Operating systems pick ephemeral client ports from a dynamic range, and Linux by default uses 32768-60999 instead of the IANA range.

  10. Life of a TCP server socket

    A typical server creates a socket, binds it to an address and port, calls listen to start accepting connections, and then calls accept for each incoming client, which returns a new socket dedicated to that conversation. The original listening socket keeps waiting. When the exchange is finished, each side closes its socket, and the connection passes through closing states before it disappears.

  11. The client side in order

    A client creates a socket, optionally binds it, and calls connect with the server's address and port. For TCP this triggers the three-way handshake. The operating system picks the source port if none was chosen. After that, both sides can send and receive until one closes. For UDP, a client can skip connect and just send datagrams to an address, with no handshake.

  12. TIME_WAIT and why closed sockets linger

    After a TCP connection closes, the side that closed first keeps the socket in a TIME_WAIT state for a while, to make sure stray late packets from the old connection are not mistaken for a new one. Busy systems can accumulate many such sockets. The wait is a safety feature; shortening it carelessly can cause confusing errors.

  13. Local sockets on the same machine

    Not every socket uses an IP address. Unix domain sockets connect programs on the same computer through a file-system path instead of a network address, skipping much of the network stack, so databases and web servers often use them for local communication. Windows has comparable local mechanisms. The programming interface looks similar, which is why the same ideas carry over.

  14. Where the socket API came from

    The socket programming interface was introduced in the Berkeley Unix family in the early 1980s and spread to nearly every operating system. Because of that, the function names (socket, bind, listen, accept, connect, send, recv) are almost the same in C, Python, and many other languages, and Windows adopted a compatible version called Winsock.

WebSocket is a different thing, despite the similar name

Despite the name, "WebSocket" isn't the operating-system-level socket described on this page -- it's a separate application-layer protocol built specifically so a browser and a server can hold open a persistent, two-way connection, commonly used for chat apps and live updates. A WebSocket connection is actually built on top of an ordinary TCP socket underneath.

Sockets, firewalls, and port forwarding are the same idea from different angles

A firewall rule that blocks a port is really preventing new sockets from forming on that port, and port forwarding works by redirecting incoming socket connections on a router to a specific device inside the network. Once the socket concept clicks, these related networking topics stop feeling like separate rules to memorize.

Reading netstat or ss output

Run netstat -an on Windows or ss -tan on Linux and you will see a list of sockets with local address, remote address, and state. A line with state LISTEN is a listening socket, showing the address a server waits on; an address of 0.0.0.0 or [::] means all interfaces, while 127.0.0.1 means only the local machine. ESTABLISHED lines are active conversations, and each is a unique pair of local and remote endpoints. TIME_WAIT and CLOSE_WAIT lines show connections ending. A large number of CLOSE_WAIT sockets owned by one program often means the program is not closing connections properly, a common bug in server code. Knowing these states makes it much easier to tell whether a service is listening at all, which is the first question to answer when something will not connect.

Common mistakes when working with sockets

Beginners often confuse a failed connection with a closed port: a refused connection means a machine answered and nothing was listening, while a timeout usually means a firewall dropped the packets or the host is unreachable. Another trap is binding a server to 127.0.0.1 and then wondering why other machines cannot reach it. Forgetting that TCP is a byte stream, not a message stream, leads to bugs where a single send arrives as two reads, or two sends arrive as one. Finally, a port already in use error usually means another program, or an earlier run still in TIME_WAIT, holds the address.

Frequently Asked Questions

Do I ever need to choose my own socket number?

No. A server's well-known ports (like 80 or 443) are set by the program or an administrator, but the temporary port your device uses as a client is assigned automatically by the operating system, so there's nothing for you to configure.

Can a server run out of sockets?

Yes -- a server that opens and closes a very large number of connections in a short time can temporarily run out of available ephemeral ports, a condition sometimes called socket exhaustion. This is often mitigated by tuning connection reuse (keep-alive) settings on the server.

How many ports does a device have?

There are 65,536 port numbers (0 to 65535) for each protocol, TCP and UDP separately. Port 0 is reserved and not used for normal communication. A device does not use them all; most are idle at any moment.

Can two programs listen on the same port?

Normally not on the same address and protocol; the second program receives an address-in-use error. There are options for sharing, such as letting several processes accept on the same port for load distribution, but they must be enabled explicitly. TCP and UDP use separate port spaces, so one program can use TCP 53 and another UDP 53.

Is a socket the same as a connection?

Close, but not identical. A socket is one endpoint held by a program, while a connection is the pairing of two endpoints. A listening socket has no connection at all until a client arrives.