Netzwerk-Durchsatz mit iperf3 messen
Auf einen Blick
| Gilt für | iperf3 3.x (aktuell 3.22) unter Debian 12/13, Ubuntu 24.04/26.04, RHEL 9/10 und Windows; iperf 2.x |
|---|---|
| Bereich | Netzwerk-Software |
| Dauer | ca. 15 Minuten |
| Rechte | normaler Benutzer für die Messung; root bzw. sudo für Installation und Firewall-Freigabe |
| Stand | Oktober 2026 |
Den Netzwerk-Durchsatz mit iperf3 messen ist der zuverlässigste Weg, die tatsächliche Übertragungsrate zwischen zwei Rechnern zu ermitteln – unabhängig von Festplatten, Dateifreigaben oder Browsern. Mit TCP-Messungen prüfen Sie, ob eine Leitung, ein Switch-Port oder ein VPN die erwartete Bandbreite liefert; mit UDP-Messungen ermitteln Sie Paketverluste und Jitter, etwa bei Problemen mit der Sprachqualität. Diese Anleitung zeigt Installation, Messung, Auswertung und die typischen Fehlerquellen.
So funktioniert die Durchsatzmessung mit iperf3
iperf3 arbeitet nach dem Client-Server-Prinzip: Auf einem Endpunkt läuft iperf3 als Server, auf dem anderen als Client. Der Client erzeugt künstlichen Datenverkehr und beide Seiten messen, wie viel davon in welcher Zeit ankommt. Gemessen wird damit die Strecke dazwischen – Kabel, Switches, Router, Firewall, WLAN oder VPN.
- Port: iperf3 verwendet standardmäßig TCP und UDP 5201 (iperf 2: 5001).
- Richtung: Standardmäßig sendet der Client zum Server (Upload aus Sicht des Clients).
- Ein Test zur Zeit: Ein iperf3-Server bedient immer nur eine Messung gleichzeitig; ein zweiter Client erhält „the server is busy running a test“.
iperf3 installieren
# Debian / Ubuntu (die Frage nach dem automatischen Start als Dienst mit „Nein“ beantworten)
sudo apt install iperf3
# RHEL / Rocky / Alma / Fedora
sudo dnf install iperf3
Auf dem Server den Port in der lokalen Firewall freigeben:
# Ubuntu mit ufw
sudo ufw allow 5201/tcp && sudo ufw allow 5201/udp
# RHEL mit firewalld (nur bis zum nächsten Neustart)
sudo firewall-cmd --add-port=5201/tcp --add-port=5201/udp
Für Windows stellt das iperf3-Projekt (ESnet) keine eigenen Programmpakete bereit; es gibt aber verbreitete, aktuelle Builds von Drittanbietern. Laden Sie diese nur aus vertrauenswürdiger Quelle und prüfen Sie die Prüfsumme. Messungen aus dem WSL heraus sind wegen der zusätzlichen Virtualisierungsschicht ungenau. Die früher verbreitete Java-Oberfläche jperf basiert auf dem alten iperf 2 und wird nicht mehr gepflegt.
TCP-Durchsatz messen
Server starten:
iperf3 -s
Auf dem Client die Messung starten (30 Sekunden, Ausgabe je Sekunde):
iperf3 -c 10.12.11.100 -t 30
Beispielausgabe (gekürzt) einer Gigabit-Verbindung:
Connecting to host 10.12.11.100, port 5201
[ 5] local 10.12.10.100 port 45088 connected to 10.12.11.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 0 395 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 395 KBytes
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-30.00 sec 3.29 GBytes 941 Mbits/sec 0 sender
[ 5] 0.00-30.00 sec 3.29 GBytes 939 Mbits/sec receiver
- Bitrate der Zeile receiver ist der tatsächlich angekommene Durchsatz.
- Retr (Retransmits) zählt erneut gesendete TCP-Segmente. Werte nahe 0 sind gut; viele Retransmits deuten auf Paketverluste, Überlast oder Duplex-Probleme hin.
- Cwnd ist das aktuelle TCP-Staufenster des Senders.
Wichtige Optionen:
| Option | Wirkung | Wann sinnvoll |
|---|---|---|
-R |
Server sendet zum Client (umgekehrte Richtung) | Download prüfen, ohne die Rollen zu tauschen |
--bidir |
gleichzeitig in beide Richtungen | Vollduplex-Verhalten, asymmetrische Leitungen |
-P 4 |
4 parallele Streams | 10 GbE und mehr, Leitungen mit hoher Latenz; ab iperf3 3.16 laufen die Streams in eigenen Threads |
-w 4M |
TCP-Fenstergröße festlegen | einzelner Stream über WAN/VPN mit hoher Latenz |
-t 60 / -O 3 |
Messdauer / erste Sekunden nicht werten | stabile Mittelwerte, TCP-Anlaufphase ausblenden |
--json |
Ausgabe als JSON | automatisierte Messungen, Monitoring |
UDP-Durchsatz, Jitter und Paketverlust messen
Bei UDP gibt der Client die Senderate vor – ohne -b sendet iperf3 nur 1 Mbit/s. Der Server misst, wie viele Pakete ankommen, in welcher Reihenfolge und mit welchen Laufzeitschwankungen (Jitter):
iperf3 -c 10.12.11.100 -u -b 900M -t 30
Die entscheidende Zusammenfassung (gekürzt):
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 3.14 GBytes 900 Mbits/sec 0.000 ms 0/2329170 (0%) sender
[ 5] 0.00-30.00 sec 3.07 GBytes 880 Mbits/sec 0.021 ms 48912/2329170 (2.1%) receiver
Von 2.329.170 gesendeten Paketen gingen hier 48.912 verloren – 2,1 %. Ein solcher Wert erklärt bereits hörbare Aussetzer bei Telefonie oder Videokonferenzen.
VoIP-Verkehr nachbilden: Ein Sprachkanal mit G.711 sendet 50 kleine Pakete pro Sekunde. Dieses Muster prüft, ob kleine Pakete verloren gehen oder schwanken – unabhängig von der verfügbaren Bandbreite:
iperf3 -c 10.12.11.100 -u -b 64K -l 160 -t 60
Ergebnisse richtig bewerten
| Verbindung | realistischer TCP-Durchsatz (MTU 1500) |
|---|---|
| Fast Ethernet (100 Mbit/s) | ca. 94 Mbit/s |
| Gigabit Ethernet | ca. 940 Mbit/s |
| 2,5 GbE | ca. 2,35 Gbit/s |
| 10 GbE | ca. 9,4 Gbit/s (meist nur mit mehreren Streams) |
Die Differenz zur Nennrate ist kein Fehler: Ethernet-, IP- und TCP-Header kosten rund 6 %. Für UDP-Sprachverkehr gelten als Richtwerte: Paketverlust unter 1 %, Jitter unter 30 ms.
Typische Ursachen für zu geringen Durchsatz:
- Hohe Latenz bei einem einzelnen TCP-Stream: Der Durchsatz ist durch Fenstergröße ÷ Laufzeit begrenzt. Für 100 Mbit/s bei 40 ms Latenz muss das Fenster mindestens 100 Mbit/s × 0,04 s = 500 KB groß sein. Abhilfe:
-Poder-wund TCP-Tuning der Systeme. - CPU-Limit: Messungen auf Firewalls, Routern oder kleinen NAS sind durch deren CPU begrenzt – immer durch das Gerät hindurch messen, zwischen zwei leistungsfähigen Endpunkten.
- Duplex- oder Kabelfehler: viele Retransmits, Fehlerzähler am Switch-Port (
ip -s link,ethtool -S). - MTU-Probleme bei VPN oder Jumbo Frames: Fragmentierung oder verworfene Pakete, siehe MTU.
- WLAN: Ergebnisse schwanken stark; immer zusätzlich eine kabelgebundene Referenzmessung durchführen.
iperf 2 und die Messung aus der Praxis
Das ältere iperf 2 (aktuell 2.2.x) wird parallel weiterentwickelt und ist nicht mit iperf3 kompatibel – beide Seiten müssen dieselbe Variante verwenden. Die Befehle unterscheiden sich leicht:
# TCP – Server als Hintergrunddienst, Client mit 512 KB Fenster und Ausgabe je Sekunde
iperf -s -D -w 512k
iperf -i1 -w 512k -c <ServerIP>
# UDP mit 1000 Mbit/s
iperf -u -s -D
iperf -u -i1 -c <ServerIP> -b 1000m
Eine reale Messung über eine Gigabit-Strecke zeigte mit iperf 2 per TCP 900 Mbit/s, per UDP jedoch nur 795 Mbit/s bei einem Verlust von 14.801 von 691.023 Paketen (2,1 %) – die Ursache für die schlechte Sprachqualität am Standort.
Hinweise
- Einen iperf3-Server nie dauerhaft offen ins Internet stellen; nach der Messung beenden oder mit
iperf3 -s -1nur eine einzige Messung annehmen. - Für Messungen über Internetanschlüsse einen eigenen Gegenpunkt (z. B. einen Server im Rechenzentrum) verwenden – öffentliche iperf3-Server sind oft überlastet.
- Regelmäßige Messungen lassen sich mit
--jsonautomatisieren und im Monitoring auswerten.
Unterstützung von m.a.x. it
Bei Netzwerkanalysen, Performance-Engpässen und dem Betrieb von Linux-Systemen unterstützt Sie das Linux-Consulting von m.a.x. it – von der Messung über die Ursachenanalyse bis zur Optimierung von Servern und Netzwerkpfaden.
Siehe auch
Links und Quellen
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
