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.