Socket Statistics: ss & netstat

ss -tulnp vs netstat, TCP socket state machine, TIME_WAIT, and CLOSE_WAIT diagnosis.

Overview

Overview ss (socket statistics) is the modern replacement for netstat. It reads socket information directly from the kernel via netlink socket rather than parsing /proc/net/tcp, making it significantly faster on systems with many connections.

ss -tulnp decoded: - t: TCP sockets - u: UDP sockets - l: listening sockets only (omit to see established connections too) - n: numeric — show IP addresses and port numbers instead of resolving to hostnames and service names (much faster) - p: show process name and PID

Reading ss output: Netid (tcp/udp/unix), State, Recv-Q (bytes received but not read by application — high value means app can't keep up), Send-Q (bytes in send buffer not yet acknowledged by remote), Local Address:Port, Peer Address:Port, Process.

TCP state machine: The full TCP handshake and teardown creates distinct connection states. LISTEN (server waiting), SYN_SENT (client sent SYN, waiting for SYN-ACK), SYN_RECV (server received SYN, sent SYN-ACK), ESTABLISHED (connected), FIN_WAIT_1/2 (initiator closing), TIME_WAIT (initiator waiting for delayed packets), CLOSE_WAIT (receiver's side acknowledged FIN, application hasn't called close()), LAST_ACK, CLOSED.

TIME_WAIT: After TCP connection closes, the initiating side enters TIME_WAIT for 2×MSL (Maximum Segment Lifetime, typically 30-60 seconds, so TIME_WAIT lasts 60-120 seconds). Purpose: ensure delayed/duplicate packets from the old connection don't corrupt a new connection with the same 4-tuple. Thousands of TIME_WAIT connections are normal on a busy server — the kernel manages them automatically.

CLOSE_WAIT: The remote sent FIN (wants to close) and the local acknowledged it, but the local application hasn't called close() yet. CLOSE_WAIT connections accumulate when there's an application bug (not calling close() on HTTP keep-alive connections, unclosed sockets in code). This is almost always an application bug, not a kernel issue.

Key concepts

ss vs netstat speed
ss reads from kernel netlink socket directly. netstat parses /proc/net/tcp (reads entire file). On systems with 100k+ connections, netstat is ~100x slower than ss.
-tulnp flags
t=TCP, u=UDP, l=listening only, n=numeric (no DNS), p=show process. ss -tulnp is the standard "what's listening" command. Add -a to also show established.
TIME_WAIT 2MSL
Normal after TCP close. Duration 60-120s. Prevents old duplicate packets corrupting new connections. High count on busy servers is expected. Tune net.ipv4.tcp_tw_reuse if needed.
CLOSE_WAIT as app bug
CLOSE_WAIT means remote sent FIN but local app hasn't called close(). Unlike TIME_WAIT (kernel-managed), CLOSE_WAIT grows until the app is fixed or restarted. Check with: ss -tnp state close-wait.

When to use it

  • Checking what ports are listening on a server
  • Diagnosing "address already in use" errors
  • Investigating connection leaks (CLOSE_WAIT buildup)
  • Monitoring connection counts and queue depths under load

Interview questions

  • You see thousands of TIME_WAIT connections on a server. Is this a problem? How do you tune it?
  • What does CLOSE_WAIT mean in the TCP state machine? What usually causes it?

Sign up free to read the full topic

More Linux topics

Start free on Cariara · Coding problems · System design studio