Troubleshooting Slow Performance: Using 'netstat' and 'ss' Effectively

When diagnosing slow application performance or unexpected connection behavior on a Linux system, the network stack is often the first place to look. Understanding established, listening, and transient connections is crucial for identifying bottlenecks, rogue processes, or security anomalies. Historically, administrators relied heavily on the netstat utility. However, modern Linux distributions favor the faster, more feature-rich ss (socket statistics) utility.

This guide will provide a comprehensive comparison of netstat and ss, detailing how to use both tools effectively to monitor TCP and UDP sockets, analyze connection states, and pinpoint performance issues on your system.

---

Why Monitor Network Sockets?

Network latency and sluggishness are frequently tied to connection issues rather than CPU or memory exhaustion. Monitoring sockets helps administrators answer critical questions such as:

• Which ports are actively listening for connections?
• Are there too many connections stuck in the SYN_RECV or TIME_WAIT states?
• Which process (PID) is using a specific port?
• Are there unexpected outbound connections occurring?

By examining socket statistics, you can quickly rule out network configuration problems or identify resource contention related to connection handling.

The Legacy Tool: netstat

netstat has been the standard utility for displaying network connections, routing tables, interface statistics, and masquerade connections for decades. While deprecated in favor of ss on many modern systems, it remains widely available and often familiar to long-time administrators.

Common netstat Examples

The most common flags used with netstat provide a comprehensive overview:

Flag	Description
-a	Shows all sockets (listening and non-listening)
-n	Shows numerical addresses instead of trying to resolve hostnames and service names (speeds up output)
-t	Shows TCP connections
-u	Shows UDP connections
-l	Shows only listening sockets
-p	Shows the PID/Program name associated with the socket (requires root privileges)

Example: Viewing all active TCP connections numerically

sudo netstat -ant

Example: Finding what is listening on port 80 (HTTP)

sudo netstat -antlp | grep ':80'

Understanding Connection States (netstat)

The output of netstat often includes a State column. Key states to watch for include:

• LISTEN: Waiting for incoming connections.
• ESTABLISHED: An active, open connection.
• TIME_WAIT: A socket waiting for a short period after closing to ensure delayed packets are handled.
• SYN_RECV: Waiting for the final acknowledgement of a three-way handshake (can indicate a SYN flood attack if excessive).

Warning on netstat: netstat often relies on parsing /proc/net/* files, which can be slow, especially on systems with a very high volume of active connections (thousands). This is the primary reason ss was developed.

The Modern Replacement: ss (Socket Statistics)

The ss utility is significantly faster than netstat because it retrieves socket information directly from the kernel space using Netlink sockets, bypassing slower file system lookups.

Common ss Examples

The flag structure for ss is very similar to netstat, promoting easy transition:

Flag	Description
-a	Shows all sockets
-n	Shows numerical addresses
-t	Shows TCP sockets
-u	Shows UDP sockets
-l	Shows listening sockets
-p	Shows process information (PID/Program)

Example: Viewing all active TCP connections numerically (Equivalent to netstat -ant)

ss -ant

Example: Finding what is listening on port 443 (HTTPS)

sudo ss -antlp | grep ':443'

Advanced Filtering with ss

One of the biggest advantages of ss is its ability to perform direct filtering on connection states, which is much more efficient than piping netstat output to grep.

Filtering by Connection State

You can use the state option directly within the ss command. This is extremely useful for diagnosing connection buildup.

Finding all sockets currently in the TIME-WAIT state:

ss -s state time-wait

Finding all sockets in the SYN-SENT state (client side waiting for server response):

ss -s state syn-sent

Filtering by Port or Address

Filtering by destination or source address/port is straightforward:

Show established connections destined for port 22 (SSH):

ss -tn state established '( dport = :22 or sport = :22 )'

Show connections related to a specific local IP address:

ss -ant '( daddr = 192.168.1.100 or saddr = 192.168.1.100 )'

Performance Analysis: netstat vs. ss Comparison

When troubleshooting, the choice between the tools often comes down to speed and detail.

Feature	netstat	ss
Speed	Slower (Reads files)	Much Faster (Uses Netlink sockets)
Syntax	Mature, highly documented	Similar flags, newer specific options
Filtering	Requires piping to grep	Native state and address filtering support
Information Depth	Good for basics	More detail on socket buffer sizes (TCP Info)
Availability	Nearly universal	Standard on modern Linux distributions

Diagnosing Slow Connection Establishment

If clients report slow connections, check for sockets stuck waiting for handshakes. Using ss is the fastest way to determine this:

1. Check for high SYN-RECV counts: This suggests the server is receiving connection requests but not completing the handshake, often due to resource exhaustion or high traffic load.
   bash ss -s | grep syn-rec
2. Check for high SYN-SENT counts: If the server itself is initiating many connections (e.g., acting as a client to databases or other APIs), this shows it is waiting for responses.
   bash ss -s | grep syn-sent

If you see exceptionally high numbers in either category, the application initiating those connections is likely facing network latency or firewall issues.

Best Practices for Network Troubleshooting

1. Always Use -n: When troubleshooting performance or scripting, use the numerical flag (-n) to avoid DNS resolution delays, which can make diagnostics sluggish.
2. Prioritize ss: Adopt ss as your default tool. Reserve netstat only for legacy systems where ss is unavailable.
3. Run as Root for PID: To see which program is using a port, you generally need sudo or root privileges when using the -p flag with both utilities.
4. Check Interface Stats: Don't forget interface counters. Use ip -s link show <interface_name> to check for dropped packets or errors, which might indicate a physical layer issue rather than a socket issue.

By mastering the modern capabilities of ss and understanding the foundational context provided by netstat, system administrators gain powerful insight into the network state of any Linux host, significantly speeding up performance diagnostics.