Network throughput and retransmits on Linux: ss -ti, nstat, and iperf3

Goal

Tell whether a slow network path is actually losing and retransmitting packets, versus simply carrying less traffic than expected, using counters already on the host before reaching for a packet capture.

Prerequisites

iproute2 for ss and nstat (normally preinstalled); iperf3 on two hosts for an active throughput test; awareness that an active test consumes real bandwidth on a real link.

Steps

1. Check one connection's own view: ss -ti dst <ip> (narrow further with sport/dport). ss's manual documents -i/--info as showing internal TCP information; the output includes smoothed round-trip time (rtt:), congestion window (cwnd:) and, once any occurred, retrans:<in flight>/<total> for that specific socket.
2. Check host-wide counters: nstat. Its manual describes nstat as a tool to monitor kernel snmp counters and network interface statistics; by default it prints increments since its previous run (-a prints absolute values since boot, -z includes zero counters). Look for retransmission-related counters growing between two runs.
3. Understand what those counters mean before acting: the kernel's networking documentation defines extended TCP statistics such as TcpExtTCPRetransFail — a retransmission attempt that failed at a lower layer — among the counters exposed this way, alongside the plainer SNMP-defined retransmitted-segment count, TcpRetransSegs.
4. Set a baseline before reproducing a slow transfer: nstat -n updates the stored history without printing, so the next nstat reports only the change since then.
5. If retransmits are low but throughput still disappoints, measure achievable throughput directly: iperf3 -s -1 on one host (-1 serves a single test, then exits; TCP port 5201 must be reachable), iperf3 -c <server> -t 10 on the other, adding -R to test the reverse direction. The iperf3 documentation describes it as a tool for active measurements of the maximum achievable bandwidth on IP networks. Bound the duration (-t) and run it in a maintenance window on a production link, since in its default TCP mode it uses as much bandwidth as it can for that time.
6. If the server was started without -1, stop it once the test completes; it otherwise keeps listening.

Expected result

Either a specific connection's or a host-wide retransmission count that grows during the slow period, pointing at loss on the path, or a clean throughput test that matches expectations, pointing at the application or a rate limit instead.

Limits and test basis

ss -ti shows only currently open sockets; a closed connection is gone from its output, though nstat's cumulative counters still reflect it. iperf3 measures the path between the two test hosts, which may differ from a real client's path. None of these tools attribute retransmits to a cause (congestion, a flaky link, a middlebox); that still needs a packet capture.