When ss Shows Normal Connections but Your Network Interface is Saturated: Investigating Bandwidth Without Connection Counts

The Deceptive Network Problem

You're staring at a server that's responding sluggishly to web requests. The first instinct is to check connection counts with ss -tuln or the old faithful netstat. Everything looks normal. Maybe 200 active connections on your web server, well within reasonable limits. But something's wrong.

Then you fire up iftop and watch your 1Gbps interface pushing 950Mbps of sustained traffic. Your network interface is drowning, but the connection-based tools suggest everything's fine.

This disconnect happens more often than you'd think, especially on modern servers handling large file transfers, video streaming, or backup operations.

Why Connection Count Tools Miss the Real Story

Tools like ss and netstat excel at showing you connection states and counts. They'll tell you how many sockets are in ESTABLISHED, TIME_WAIT, or LISTEN states. What they won't tell you is how much data each connection is actually pushing.

A single connection downloading a 5GB database backup can saturate your network interface just as effectively as 10,000 small HTTP requests. But ss treats both scenarios identically from a connection counting perspective.

The key insight is that network performance problems often stem from bandwidth saturation rather than connection limits. Your server might handle the connection setup perfectly but struggle to push the actual data.

Finding the Bandwidth Hogs

iftop is excellent for real-time interface monitoring, but it only shows aggregate traffic. To identify which processes are consuming bandwidth, you need to dig deeper.

Start with nethogs, which shows network usage per process:

nethogs eth0

This reveals which specific processes are consuming bandwidth. You might discover that your backup script is running during peak hours, or a user is downloading massive files.

For historical analysis, combine sar -n DEV with process monitoring. The -n DEV flag shows network interface statistics over time, helping you correlate bandwidth spikes with specific events.

The TCP Window Scaling Factor

Another common culprit is TCP window scaling issues. Even with normal connection counts, individual connections might be underperforming due to poor window scaling negotiation.

Check your current TCP window settings:

cat /proc/sys/net/ipv4/tcp_window_scaling
cat /proc/sys/net/core/rmem_max
cat /proc/sys/net/core/wmem_max

If window scaling is disabled (showing 0), large data transfers will be artificially limited, forcing more connections to achieve the same throughput.

Monitoring the Right Metrics

The lesson here is that effective network monitoring requires multiple perspectives. Connection counts matter, but bandwidth utilisation and per-process network usage often provide better insights into performance problems.

Server Scout's monitoring approach captures both connection-level metrics and interface bandwidth usage, giving you the complete picture when network performance issues arise. Rather than guessing whether the problem is too many connections or simply too much data, you can see both metrics side by side.

If you're tired of network troubleshooting blind spots, Server Scout's free trial includes comprehensive network monitoring that goes beyond simple connection counting.