Calling socket() creates a TCP-capable endpoint and returns a file descriptor; it does not, by itself, connect to another machine. A client normally starts a connection with connect(). A server prepares a listening socket with bind() and listen(), then gets a separate connected socket for each client through accept().
That distinction is the key to understanding the Linux socket lifecycle: the API calls create and manage endpoints, while TCP connection establishment involves protocol state at both ends and, in ordinary operation, a SYN, SYN-ACK, and ACK exchange.
As an Amazon Associate I earn from qualifying purchases.
What does socket() do?
A process might request an IPv4 TCP stream socket with:
int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);On success, Linux returns a file descriptor the process can use with socket system calls. The call creates the socket endpoint, but the new socket has no peer and is not yet a connected TCP session. As the Linux tcp(7) documentation puts it, “The newly created socket is not in the listening state.”
The descriptor is the application’s handle for subsequent operations. It does not mean a connection has been established, nor does the call alone send a TCP SYN.
How does a client connect?
1. Create the endpoint
The client first calls socket(), usually specifying an address family such as AF_INET or AF_INET6, a stream type, and TCP. It can explicitly bind a local address with bind(), but ordinary clients often let the kernel select local endpoint details.
2. Call connect()
The client supplies the remote address to connect(). This initiates the outgoing connection attempt and associates it with local and remote endpoint information. The chosen local port and route depend on the host and network; they are not fixed values.
With a blocking socket, connect() normally returns when the attempt succeeds or fails. With a nonblocking socket, establishment may still be pending when the call returns. The exact result and follow-up handling depend on the error and socket mode; a pending nonblocking connection is not yet equivalent to a completed session. See Linux’s connect(2) documentation for the API’s return and error behavior.
3. TCP establishes the connection
For ordinary TCP setup, the useful packet-level model is:
- The client sends a SYN.
- The server replies with a SYN-ACK.
- The client sends an ACK.
This is a conceptual sequence, not a claim that the system call itself is one packet or that every Linux kernel follows one identical internal call path. TCP Fast Open is a Linux-supported exception that can allow data to accompany connection setup, subject to support and configuration; it does not change the distinction between creating a socket and initiating a connection. The tcp(7) page describes TCP’s behavior and relevant Linux options.
Rank #3
4. Exchange stream data
Once connected, the application can read and write data. TCP provides a reliable, ordered, full-duplex byte stream: it handles delivery and ordering, but it does not preserve application write boundaries. A read may return fewer bytes than requested, and one write can be observed across multiple reads. If the application needs messages or records, its protocol must define framing, for example with lengths, delimiters, or fixed-size records.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
If connect() fails
Linux documents the state of a socket after a failed connect() as unspecified. The recommended recovery is to close that socket and create a new one before retrying, rather than assuming the original can be reused. A connection attempt can also take a long time to fail when the network or remote host does not respond.
How does a server receive connections?
A typical TCP server follows this sequence:
socket()creates a socket.bind()associates it with a local address and port.listen()marks it as a passive socket prepared to receive connections.accept()retrieves a pending connection and returns a new connected file descriptor.
The original descriptor remains the listener. Each successful accept() returns a separate socket for communicating with that client, so the server can continue accepting other connections. If the listener is blocking and no connection is pending, accept() waits. The Linux accept(2) documentation explains the returned descriptor and listener behavior.
Rank #4
What does listen(backlog) limit?
On Linux, the backlog argument to listen() limits the queue of fully established connections waiting for the application to accept them. It is not a single limit covering every stage of TCP setup.
Incomplete connection requests have a separate control: net.ipv4.tcp_max_syn_backlog. The requested listen() backlog is also capped by net.core.somaxconn. The Linux listen(2) documentation says the documented default for somaxconn has been 4096 since Linux 5.4; earlier kernels documented 128. These are versioned defaults, not a guarantee about a particular machine, whose kernel and runtime configuration may differ.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →What happens inside the Linux kernel?
At a high level, the application calls the socket API using a file descriptor, while Linux maintains socket and TCP protocol state and connects that state to IP and the networking device path. For an outgoing connection, the observable division is clear: socket() creates the endpoint, and connect() initiates the connection.
Best Value
There is no single kernel call path that can be described as invariant across Linux versions and configurations. The precise allocation steps, routing decisions, packet-filter traversal, interrupt behavior, driver operations, and other implementation details depend on the kernel release, address family, configuration, namespace, and environment. Those details should not be inferred from the user-space API sequence alone.
Keep the lifecycle distinctions straight
| Concept | What it means |
|---|---|
| Socket creation | socket() creates an endpoint handle; it does not establish a peer connection. |
| Active open | A client normally uses connect() to initiate an outgoing connection. |
| Passive open | A server uses bind() and listen() to prepare a listener, then accept() to obtain connected sockets. |
| Listener and accepted socket | The listener remains available for new connections; each accepted descriptor represents a distinct client connection. |
| TCP data | TCP delivers ordered bytes, not application messages; applications must supply record framing when needed. |
These API descriptions are from Linux man-pages 6.19, whose cited pages are dated February 2026. They describe documented Linux behavior, not the kernel version or runtime settings of every reader’s system.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
