Sockets and connection state

## What connect() is really waiting for A TCP client that calls `connect()` sends one packet — a SYN — and then waits. Everything the caller eventually sees is a consequence of what comes back, or of nothing coming back. The two failure modes candidates conflate, "connection refused" and "connection timed out", are exactly the answered case and the unanswered case. ## The refused case: an RST from the kernel When a SYN arrives on a Linux host, the kernel looks for a listening socket matching the destination address and port. This lookup is done by the kernel, not by any application: there is no process to consult, because by definition nothing has that port open. If no listening socket matches, the kernel replies with a TCP segment carrying the RST flag. The client's kernel receives the RST, aborts the pending connection attempt, and `connect()` returns `-1` with `errno` set to `ECONNREFUSED`, which the C library renders as "Connection refused". This happens in one round trip — on a LAN, sub-millisecond. The speed itself is diagnostic: an instant refusal proves the network path works in both directions and that the remote host's IP stack is alive and answering. A subtle and very common variant is a listener bound to the wrong address. A process that binds `127.0.0.1:8080` has a socket for the loopback address only. A SYN arriving on the machine's LAN address for port 8080 matches no socket, so the kernel refuses it exactly as if nothing were running. The service is up; it is just not listening where the client is knocking. Binding `0.0.0.0` (or `::`) is what makes a listener match every local address. ## The hanging case: silence and retransmission If the SYN is discarded rather than answered, the client learns nothing. TCP treats an unanswered SYN as a lost packet and retransmits, doubling the interval each time: roughly 1s, 2s, 4s, 8s, 16s, 32s, then a final wait. `net.ipv4.tcp_syn_retries` sets how many retransmissions are attempted; the default of 6 gives about 127 seconds in total before the kernel gives up and `connect()` fails with `ETIMEDOUT`. ``` sysctl net.ipv4.tcp_syn_retries net.ipv4.tcp_syn_retries = 6 ``` The usual causes of silence are a packet filter configured to DROP rather than reject, a security group or cloud firewall that discards non-permitted traffic by policy, a route that leads nowhere, or a host that is powered off. Note that a *drop of the reply* produces the same symptom: the server may have answered with a SYN-ACK that never made it home, for example because of asymmetric routing or a stateful middlebox. From the client's side these are indistinguishable, which is why the hang is a weaker signal than the refusal. ## Reject versus drop is a deliberate choice Firewalls can behave either way, and that is a policy decision. A rule that rejects sends something back — on Linux, netfilter's REJECT target defaults to an ICMP port-unreachable message, and can be told to send a TCP RST instead — so the client fails fast. A rule that drops sends nothing, so the client hangs for the full retry budget. Rejecting is friendlier to legitimate clients and to your own debugging; dropping is preferred on internet-facing edges because it gives a scanner no confirmation that the host exists at all. When you see one of your own services timing out where you expected a refusal, an intermediate DROP rule is the first hypothesis. ## Why this matters in practice The distinction turns "it does not connect" into a directed investigation: - **Refused** — the host and its IP stack are reachable. Stop looking at the network. Look at whether the process is running, which address and port it bound, and whether you are talking to the right host or the right port. - **Timed out** — packets are being lost in one direction or the other. Look at firewalls, security groups, routing and whether the host is up at all. The application is very likely blameless. A third outcome worth recognising is a connection that *is* established but then produces no data. That is not a handshake failure at all: the three-way handshake completed, so the port is open and something accepted you. That points at the application or at queueing behind the listener, not at reachability. ## The timeout is a client-side budget One last point candidates miss: the ~127-second hang is the *kernel's* default budget, not a law of TCP. Applications routinely impose a much shorter connect timeout of their own by using a non-blocking socket and giving up early, which is why the same unreachable host may fail in 2 seconds from one client and 127 seconds from another. The kernel's ceiling is the worst case, not the observed case.