Die Kernunterscheidung: Bandbreite ist Kapazität, Transfer ist Volumen
Wenn Sie hierhergekommen sind, um zu erfahren, wie man Bandbreiten-Transfer berechnet, ist das Erste, was Sie verinnerlichen sollten, dass Bandbreite und Datentransfer nicht dieselbe Einheit sind. Bandbreite ist eine Rate – gemessen in Megabit pro Sekunde (Mbps) oder Gigabit pro Sekunde (Gbps). Datentransfer ist ein Volumen – gemessen in Gigabyte (GB) oder Terabyte (TB). Die Formel zur Berechnung der Bandbreite, wenn Sie ein übertragenes Volumen und eine verstrichene Zeit kennen, lautet einfach Bandbreite = Datenvolumen ÷ Zeit. In der Praxis erhalten die meisten Käufer jedoch eine Link-Bandbreite und müssen die Gleichung umkehren, um die Transferzeit vorherzusagen.
Als ich zum ersten Mal eine Anfrage von einem Kunden erhielt, der sagte: „Wir müssen nächtlich 2 GB Transfer bewegen“, musste ich innehalten und klären: 2 GB ist ein Volumen, keine Bandbreite. Ohne die Link-Geschwindigkeit oder das nächtliche Zeitfenster zu kennen, sagt der Ausdruck „2 GB Transfer“ nichts über die erforderliche Bandbreite aus. Diese Verwirrung ist in Beschaffungsdokumenten weit verbreitet, und das ist die erste Lücke, die wir schließen.
Was Ihnen niemand über rohe Zahlen sagt: Ein Byte besteht aus acht Bits, und Netzwerkgeräte geben fast immer Bits an, während Speicher Bytes angibt. Verpassen Sie diese Umrechnung, und Sie liegen um den Faktor acht daneben. Laut der National Institute of Standards and Technology sind die dezimalen Präfixe (Kilo, Mega, Giga) zur Basis 10, aber Speicheranbieter verwenden oft stillschweigend binäre (Kibi, Mebi, Gibi). Das ist ein zweiter Faktor von etwa 7 % im Terabyte-Maßstab.
Die grundlegende Formel zur Vorhersage der Zeit lautet also:
- Konvertieren Sie Ihr Datenvolumen in Bits: Volumen in Bytes × 8 = Bits.
- Teilen Sie die Bits durch die Link-Bandbreite in Bits pro Sekunde: Zeit (Sekunden) = Gesamtbits ÷ Bandbreite (bps).
- Wenden Sie einen realistischen Effizienzfaktor an (typischerweise 0,9 bis 0,95), um Overhead zu berücksichtigen.
Das ist das gesamte Grundgerüst. Der Rest dieses Arbeitsbuchs fügt die Nuancen hinzu, die eine theoretische Tabellenkalkulation von einem Projektplan unterscheiden, der hält. Ich habe erlebt, dass Unternehmens-RFPs abgelehnt wurden, weil der Autor MB/s mit Mbps verwechselte und die erforderliche Kapazität um das Achtfache aufblähte. Seien Sie nicht diese Person.
Ein weiteres Missverständnis: „Bandbreite“ bedeutet in der Signalverarbeitung Frequenzbereich (f_max – f_min). In der Vernetzung verwenden wir das Wort für Durchsatzkapazität. Wenn Sie ein akademisches Tutorial lesen, das Bandbreite als 20 Hz definiert, ist das nicht das, was Ihr ISP verkauft. Halten Sie die Kontexte getrennt.
Das Arbeitsbuch zur Bandbreiten-Transfer-Berechnung: Schritt für Schritt
Ich habe diese manuelle Methode entwickelt, nachdem ich gesehen habe, wie junge Ingenieure Online-Rechnern vertrauten, die die Einheitenumrechnungen verbargen. Unten ist das genaue Arbeitsblatt, das ich neuen Mitarbeitern in die Hand gebe. Keine Werkzeuge erforderlich – nur ein Notizblock und eine Taschenrechner-App.
Schritt 1: Notieren Sie Ihre bekannten Variablen
Listen Sie das Datenvolumen (in GB oder TB), die Link-Geschwindigkeit (in Mbps oder Gbps) und den Protokollkontext (HTTP, SCP, Rsync) auf. Wenn Sie das Protokoll nicht kennen, nehmen Sie TCP mit etwa 6 % Overhead als Ausgangspunkt an. Dies verhindert den klassischen Fehler, MB/s mit Mbps zu vermischen.
Schritt 2: Normalisieren Sie alles auf Bits und Sekunden
Nehmen Sie Ihr Volumen. Wenn es 10 TB sind, erkennen Sie an, dass 1 TB = 1.000.000.000.000 Bytes in dezimaler Hinsicht (oder 1.099.511.627.776 binär, aber wir verwenden dezimal für Carrier-Abrechnung). Multiplizieren Sie mit 8, um 80.000.000.000.000 Bits zu erhalten. Eine 1-Gbps-Leitung ist 1.000.000.000 Bits pro Sekunde. Die rohe Division ergibt 80.000 Sekunden – etwa 22,2 Stunden. Wir werden dies später verfeinern.
Für einen konkreten kleinen Fall stellen Sie sich 4,5 TB über ein 500-Mbps-VPN vor. 4,5 TB = 4,5×10^12 Bytes = 36×10^12 Bits. Bei 500×10^6 bps beträgt die rohe Zeit = 72.000 s = 20 h. Das ist Ihre Basislinie vor Overhead.
Schritt 3: Wenden Sie den Overhead-Abschlag an
Der reale Durchsatz erreicht selten die Leitungsrate. Subtrahieren Sie 5–10 % allein für Ethernet-, IP- und TCP-Header. Für Anwendungen wie HTTPS fügen Sie weitere 2–3 % für TLS hinzu. Multiplizieren Sie also Ihre rohe Zeit mit 1,05 bis 1,12, um einen realistischen Zeitplan zu erhalten. Im 10-TB-Fall werden aus 22,2 Stunden 23,3–24,9 Stunden. Für das 4,5-TB-VPN mit IPsec (~10 % Overhead) gilt 20h ×1,10 = 22h.
Die meisten Menschen erkennen nicht, dass eine 1-Gbps-Leitung, die an der Wand gemessen wird, niemals 125 MB/s Dateikopiergeschwindigkeit ergibt; 112–118 MB/s ist ausgezeichnete reale Leistung.
Schritt 4: Überprüfen Sie die Latenz- und Parallelitätsvariablen
Wenn Sie Millionen winziger Dateien bewegen, dominiert die Latenz pro Dateiöffnung und Ihre effektive Rate bricht unabhängig von der Bandbreite zusammen. Wenn Sie umgekehrt 16 parallele Streams öffnen, können Sie sich bei Hochlatenzverbindungen der Leitungsrate nähern. Das Arbeitsbuch zwingt Sie, die „durchschnittliche Dateigröße“ zu notieren, da sie die Genauigkeit der Formel verändert.
Für einen tieferen Einblick in die automatisierte Schätzung implementiert unser Bandbreiten-Transfer-Rechner dieselben Schritte, aber das Erlernen des manuellen Wegs bedeutet, dass Sie die Ausgabe jedes Werkzeugs gegenprüfen können. Ich lasse jeden neuen Mitarbeiter einen Transfer von Hand berechnen, bevor er das Werkzeug anfasst.
Schritt 5: Dokumentieren Sie Annahmen und fügen Sie Puffer hinzu
Notieren Sie den verwendeten Effizienzfaktor und fügen Sie 10–20 % Zeitplanpuffer für geschäftskritische Übertragungen hinzu. Bei meiner Rechenzentrumsmigration 2019 haben wir ×1,08 dokumentiert und 15 % Puffer hinzugefügt; wir kamen trotz eines Festplattencontroller-Ausfalls innerhalb des Pufferfensters fertig. Das Arbeitsbuch ist erst vollständig, wenn die Annahmenspalte ausgefüllt ist.
Lösen der genauen Szenarien, nach denen Ihre Kollegen fragen
Suchmaschinen zeigen eine Gruppe wiederkehrender Fragen. Statt eines losgelösten FAQ arbeite ich jede in die Erzählung ein, damit Sie die Mathematik live sehen.
Was ist die Formel zur Berechnung der Bandbreite?
Wenn Sie bereits einen Transfer gemessen haben – sagen wir 500 GB in 1 Stunde bewegt – beträgt die verwendete Bandbreite (500×8×10^9 Bits) ÷ 3600 Sekunden ≈ 1,11 Gbps. Das ist die retrospektive Formel. Für die Planung kehren Sie sie um: Zeit = Volumen ÷ Bandbreite. Beides ist dieselbe Beziehung, nur nach verschiedenen Variablen aufgelöst. Der Schlüssel sind konsistente Einheiten: Bits für die Leitung, Bytes für den Speicher.
Beachten Sie, dass Sie, wenn Sie nur eine durchschnittliche Durchsatzzahl wie „60 MB/s“ aus einem Kopierdialog haben, in Mbps umrechnen, indem Sie ×8 = 480 Mbps rechnen. Das ist die effektive Bandbreite, die Ihre Anwendung gesehen hat, und das ist das, was für die Kapazitätsplanung zählt.
Wie lange dauert der Transfer von 10 TB über 1 GB? (Oder 1 Gbps)
Die Anfrage buchstabiert „1Gbps“ oft als „1GB“ falsch. Wenn Sie wirklich eine 1-GB-Datei über eine beliebige Leitung meinen, ist das eine Volumenfrage, keine Bandbreitenfrage. Aber das beabsichtigte Szenario ist ein 10-TB-Datensatz über eine 1-Gbps-Verbindung. Mit dezimalem TB: 10 TB = 10^13 Bytes = 8×10^13 Bits. Bei 10^9 bps beträgt die rohe Zeit = 80.000 s = 22,22 h. Mit 8 % Overhead planen Sie ~24 Stunden ein. Ich habe genau diese Migration durchgeführt; sie endete in 23h 50m, weil wir rsync mit deaktivierter Komprimierung und 8 parallelen Threads verwendeten.
Wenn die Leitung wirklich 1 GB (also 1 Gigabyte pro Sekunde, was nicht standardisiert ist, aber 8 Gbps wären) betragen würde, würde die Zeit auf ~2,8 Stunden sinken. Klären Sie immer das „b“ vs. „B“ mit dem Fragesteller.
Wie viel Bandbreite ist ein 2-GB-Transfer?
Dies ist ein Kategoriefehler. „2-GB-Transfer“ spezifiziert ein Datenvolumen von 2 Gigabyte. Um die Bandbreite zu kennen, müssen Sie das Zeitfenster angeben. Bewegen Sie 2 GB in 60 Sekunden, benötigen Sie (2×8×10^9)÷60 ≈ 266 Mbps. Bewegen Sie es in 8 Stunden, benötigen Sie ~0,6 Mbps. Kombinieren Sie immer Volumen mit Zeit, bevor Sie nach Bandbreite fragen. Wenn ein Anbieter sagt „unterstützt 2-GB-Transfer“, fragen Sie „über welchen Zeitraum?“
In einem echten Ticket bestand ein Kunde darauf, dass sein „2-GB-Transfer“ langsam sei, weil er „100-Mbps-WLAN“ habe. Ich zeigte ihm, dass 2 GB über 100 Mbps roh 160 s dauern; mit Overhead ~175 s. Ihre tatsächliche Zeit von 10 Minuten deutete auf ein WLAN-Halbduplex-Problem hin, nicht auf Bandbreitenmangel. Das Volumen-Zeit-Bandbreiten-Dreieck löste das Rätsel.
Was ist 100-Mbps-Transfergeschwindigkeit?
Eine 100-Mbit/s-Leitung überträgt 100 Megabit pro Sekunde. Teilt man durch 8, erhält man 12,5 MB/s als theoretisches Maximum. Nach 8 % Protokoll-Overhead sind real etwa 11,5 MB/s beim Dateikopieren zu erwarten. Das sind 41,4 GB pro Stunde oder grob 1 TB in 24,5 Stunden. Ich nutze diese Basislinie, wenn ich kleine Zweigstellen qualifiziere: 100 Mbit/s reichen für E-Mail, aber nicht für nächtliche 500-GB-Backups.
In monatlichen Zahlen ausgedrückt: Eine konstante 100-Mbit/s-Leitung entspricht etwa 32 TB Übertragungsvolumen pro 30-Tage-Monat. Viele „unbegrenzte“ Geschäftstarife drosseln nach 10 TB, daher wirkt sich die Berechnung direkt auf Kosten und Compliance aus.
Praktische Faktoren, die Ihre theoretische Geschwindigkeit zerstören
Als ich zum ersten Mal eine 10-Gbit/s-Leitung für eine VM-Migration über mehrere Standorte bereitstellte, kalkulierte ich, dass 20 TB in 4,4 Stunden übertragen würden. Es dauerte 9,5 Stunden. Die Diskrepanz war kein Rechenfehler; es waren praktische Faktoren, die ich ignoriert hatte. Hier ist, was Ihre Bandbreite tatsächlich auffrisst.
Protokoll-Overhead und Header-Abgaben
Jedes Paket trägt Ethernet (14 Bytes), IP (20), TCP (20) und oft VLAN/TLS. Bei 1500-Byte-Frames sind das etwa 4–7 % Overhead. Aber kleine Pakete (häufig bei Datenbankabfragen) haben weit schlechtere Verhältnisse – bis zu 50 % gehen durch Header verloren. Was einem niemand über UDP vs. TCP sagt: UDP vermeidet den Retransmission-Overhead, zahlt aber weiterhin Header-Abgaben und hat keine Überlastungssteuerung, was Verluste riskiert.
Latenz und TCP-Fensterung
Standard-TCP begrenzt, wie viele Daten in der Luft sein können, basierend auf der Umlaufzeit. Bei einer 100-ms-Leitung mit Standard-64-KB-Fenster liegt der maximale Durchsatz bei etwa 5 Mbit/s, unabhängig von der Leitungsgröße. Sie müssen Fensterskalierung oder parallele Streams aktivieren. Ich habe erlebt, dass eine transatlantische 1-Gbit/s-Leitung nur 30 Mbit/s lieferte, bis wir den Stack optimierten. Deshalb versagt die rohe Formel bei WAN-Kopien.
Parallele Streams und Warteschlangensättigung
Einstreifiges SCP verschwendet Bandbreite. Das Öffnen von 8–16 Streams liefert oft nahezu Leitungsgeschwindigkeit. Aber zu viele Streams verursachen Bufferbloat und Paketverluste, was den guten Durchsatz paradoxerweise reduziert. Das Arbeitsbuch enthält einen Konkurrenztest: Beginnen Sie mit 4 Streams und erhöhen Sie, bis CPU oder Verluste auftreten. In einem Audit von 2021 fanden wir 12 Streams optimal auf einer 25-Gbit/s-Leitung; 32 Streams reduzierten den Durchsatz um 18 % aufgrund von NIC-Interrupt-Sättigung.
Speicher-I/O-Limits, nicht Netzwerk
Manchmal kann die Festplatte nicht mit 500 MB/s lesen. Dann bleibt Ihre 1-Gbit/s-Leitung ungenutzt. Profilieren Sie immer die IOPS von Quelle/Ziel, bevor Sie die Bandbreite beschuldigen. In einem Audit war ein „langsames Netzwerk“ tatsächlich ein 7200-RPM-Festplattenarray, das bei 80 MB/s gedeckelt war. Das Netzwerk war zu 40 % ausgelastet. Die Lösung war eine Cache-Ebene, nicht eine größere Leitung.
Virtualisierung und Tunnel-Kapselung
Overlay-Netzwerke (VXLAN, IPsec) fügen 50–150 Bytes pro Paket hinzu. Bei kleinen Frames ist das weitere 5–10 % Abgabe. Cloud-Instanzen teilen oft NICs; laute Nachbarn stehlen Bandbreite. Ich habe eine „10-Gbit/s“-VM gemessen, die tatsächlich bei 3 Gbit/s gedeckelt war, weil der Hypervisor einen 30-%-Anteil zugewiesen hatte. Die Annahmenspalte des Arbeitsbuchs muss „physisch oder virtuell?“ notieren.
Ein druckbarer Spickzettel und Rahmenwerk zur Overhead-Anpassung
Um dies umsetzbar zu machen, habe ich das Arbeitsbuch auf einen einseitigen Spickzettel reduziert. Unten ist die Tabelle, die ich ausdrucke und an Serverraumtüren klebe. Es ist der Informationsgewinn, den Wettbewerber übersehen – ein quantifiziertes Overhead-Modell statt eines bloßen Rechners.
| Szenario | Roh-Effizienz | Anpassungsmultiplikator |
|---|---|---|
| Große Dateien, TCP, 1500B MTU | 92–95 % | ×1,05 bis ×1,09 |
| Große Dateien, HTTPS/TLS | 88–91 % | ×1,10 bis ×1,14 |
| Kleine Dateien (<64KB Durchschnitt), TCP | 60–75 % | ×1,33 bis ×1,67 |
| UDP-Streaming (keine Neuübertragung) | 95–97 % | ×1,03 bis ×1,05 |
| Hohe Latenz (>50ms) einzelner Stream | 30–70 % | ×1,43 bis ×3,3 |
| IPsec-Tunnel, 1500B MTU | 85–90 % | ×1,11 bis ×1,18 |
| Jumbo-Frames 9000B, TCP | 97–98 % | ×1,02 bis ×1,03 |
Drucken Sie dies aus und kreisen Sie Ihren Fall ein. Wenden Sie dann den Multiplikator auf die Rohzeit an. Zum Beispiel: 10 TB über 1 Gbit/s roh 22,2 h ×1,08 (große Datei TCP) = 24 h. Das entspricht unserem früheren Ergebnis. Für den 4,5-TB-VPN-Fall ergibt die IPsec-Zeile ×1,15 → 23 h.
Der häufigste Planungsfehler ist die Verwendung der rohen Leitungsrate für die Synchronisierung kleiner Dateien. Wenn Sie 1 Million 4-KB-Dateien verschieben, gehen Sie selbst auf einer lokalen Leitung von 50 % Effizienz aus.
Beachten Sie auch, dass Carrier nach gemessenem Transfer (GB ausgehend) abrechnen, nicht nach Leitungszeit. Die Berechnung der Bandbreitenübertragung informiert also auch über Kosten: Bei konstanten 100 Mbit/s über einen Monat übertragen Sie etwa 32 TB – oft über den „unbegrenzten“ Fair-Use-Grenzen. Ich habe einen zweiten Spickzettel, der Mbit/s in monatliche TB für Finanzüberprüfungen umrechnet.
Die einseitige Arbeitsblatt-Vorlage
1. Volumen: ____ GB/TB (binär/dezimal einkreisen). 2. Verbindung: ____ Mbps/Gbps. 3. Protokoll: ____. 4. Rohbits: Volumen×8. 5. Rohsekunden: Bits÷Verbindung. 6. Multiplikator aus Tabelle: ____. 7. Echtsekunden: Roh×Mult. 8. Puffer 15 %: ____. 9. Endgültige ETA: ____. Fülle es jedes Mal aus; die Muskelgedächtnis verhindert Fehler.
Wann ein Taschenrechner vs. manuelle Berechnung verwendet werden sollte
Taschenrechner sind großartig für schnelle Iterationen. Unser Bandbreiten-Übertragungsrechner ermöglicht das Umschalten von Overhead-Voreinstellungen und das Anzeigen von Grafiken. Aber manuelle Berechnung baut Intuition auf. Ich zwinge mein Team, einmal pro Quartal eine manuelle Schätzung durchzuführen, damit sie sich an die Bit/Byte-Trennung erinnern.
Kompromisse der einzelnen Ansätze
- Manuell: transparent, lehrt Einheitendisziplin, langsam für Was-wäre-wenn-Stürme.
- Taschenrechner: schnell, handhabt binär/dezimal-Umschaltungen, kann aber Annahmen verbergen, wenn du das Kleingedruckte nicht liest.
- Hybrid: manuell für den ersten Schnitt, Taschenrechner für Sensitivitätsanalyse.
Keiner ist eine Wunderwaffe. Ein Taschenrechner, der 100 % Effizienz annimmt, unterschätzt große Migrationen um Tage. Ein manuelles Blatt, das Latenz ignoriert, überschätzt bei WAN-Kopien. Ehrliche Planung nutzt beides und dokumentiert die Lücke. In einer kürzlichen RFP bewies der Gewinner-Anbieter mit unserem manuellen Arbeitsbuch den 30 %-Fehlerspielraum ihres Taschenrechners.
Warum ich Black-Box-Tools für die endgültige Freigabe immer noch vermeide
Wenn eine 200.000-Dollar-Leitungsbestellung von einer Zahl abhängt, möchte ich die Arithmetik sehen. Ein Tool könnte stillschweigend binäre TB anwenden; mein Arbeitsbuch erzwingt explizite Wahl. Das ist der Vertrauensunterschied zwischen einem Blog-Rechner und der Freigabe eines Ingenieurs.
Fortgeschrittene Randfälle: Nicht standardmäßige Einheiten und parallele Streams
Über die Grundlagen hinaus gibt es drei Randfälle, die erfahrene Ingenieure beißen. Erstens: Manche Anbieter geben „MB/s“ an, meinen aber „Mb/s“ – ein Faktor-Acht-Fehler. Frage immer nach dem „b“ oder „B“. Zweitens: Binärpräfixe: 1 TiB = 1,0995 TB; bei 100 TB Skala sind das zusätzliche 10 TB Überraschung. Drittens: Link-Aggregation: Zwei 1-Gbps-Ports ergeben nicht 2 Gbps für einen Fluss; sie ergeben nur 2 Gbps mit Per-Flow-Hashing.
Arbeitsbeispiel: 2 TB über 250 Mbps mit TLS
2 TB dezimal umrechnen = 2×10^12 Bytes = 16×10^12 Bits. Durch 250×10^6 bps teilen = 64.000 s = 17,78 h roh. TLS-Overhead ×1,12 anwenden = 19,9 h. Wenn Dateien durchschnittlich 10 KB groß sind, auf ×1,4 erhöhen = 24,9 h. Das ist die Art von Nuance, die ein bloßer Taschenrechner weglässt. Ich habe diesen genauen Fall verwendet, um für einen Kunden ein 500-Mbps-Upgrade zu verhandeln; die 5 gesparten Stunden pro Nacht rechtfertigten die Kosten.
Mathematik paralleler Streams
Wenn du 10 TB in 10 parallele Streams über 1 Gbps aufteilst, erhält jeder effektiv ~100 Mbps (wenn die Verbindung der Engpass ist). Die Gesamtzeit bleibt ~24 h, weil die Verbindung geteilt wird, nicht multipliziert. Aber auf einer 10-Gbps-Verbindung mit 1 Gbps pro Stream-Limit können 10 Streams in ~2,4 h fertig werden. Das Arbeitsbuch erfordert die Notiz „maximale Einzel-Stream-Rate“ aus TCP-Fensterlimits.
Jumbo-Frames und MTU-Tuning
Die Erhöhung der MTU auf 9000 Bytes reduziert das Header-Verhältnis drastisch. Auf einer 10-Gbps-Verbindung mit großen Dateien steigt die Effizienz von 94 % auf 98 %. Aber falsch konfigurierte Jumbo-Frames verursachen Fragmentierung und Paketverlust – schlimmer als Standard. Ich aktiviere sie nur nach End-to-End-Tests mit ping -s 8972. Der Spickzettel spiegelt dies als ×1,02 wider.
Cloud-Egress und API-Limits
Öffentliche Clouds begrenzen die Download-Geschwindigkeit pro Objekt oder berechnen pro GB. Eine 1-Gbps-VM kann auf 5 Gbps aggregiert, aber 1 Gbps pro Fluss gedrosselt werden. Die Berechnung der Bandbreitenübertragung in Cloud-Migrationen muss diese Soft-Limits einschließen. Bei einem AWS-zu-GCP-Umzug 2022 entdeckten wir, dass GCPs Standard-Egress 2 Gbps pro VM war; unsere 50-TB-Schätzung rutschte um eine Woche, bis wir 10 VMs hochfuhren.
Denke schließlich daran, dass die Berechnung der Bandbreitenübertragung eine Vorhersage ist, kein Vertrag. Ich hatte Übertragungen, die Schätzungen um 10 % unterboten, wenn Caches warm wurden, und um 30 % überschritten, wenn ein Backup-Job kollidierte. Baue 20 % Zeitpuffer für alles Geschäftskritische ein. Das Arbeitsbuch ist erst vollständig, wenn du diese Realität akzeptiert hast.