Beispiele

 

Im LAN tritt eine geringe Übertragungsverzögerung (delay) von 2 ms Round-Trip-Time auf. Der Sender erwartet zudem alle 64 KByte (TcpWindowSize, im Unix-Sprachgebrauch RWIN) eine Empfangsbestätigung vom Empfänger.

Die Leitung hat eine Bandbreite von 10 Mbit.

 

Somit ergibt sich folgende durch TCP-bedingte Datenübertragungsrate:

 

Zeit:

 

64 kByte Nutzdaten, Übergabezeit an die Leitung

+         5%* Protokollheader, Übergabezeit an die Leitung

+         Datenübertragungszeit auf dem Medium/Leitung**

+         TCP-Bestätigungspaket (TCP-Ack), Übergabe an die Leitung

+         5% Protokollheader, Übergabezeit an die Leitung

+         Datenübertragungszeit auf der Leitung

 

ergibt:

 

1/10000000 s x 512.000 Bit*** = 0,0512 s Übergabezeit der Nutzdaten an die Leitung

+         0,00256 Sekunden Übergabezeit des Headers an die Leitung

+         1 ms**** = 0,001 Sekunden Datenübertragungszeit

+         1/10000000 s x 480 Bit = 0,000048 Sekunden TCP-Ack Übergabezeit an die Leitung

+         0,0000024 Sekunden Übergabezeit TCP-Ack – Header an die Leitung

+         1 ms = 0,001 Sekunden Datenübertragungszeit

=         0,0558104 Sekunden Übertragungszeit je 64 KByte Nutzdaten

bzw. 512.000 Bit

=         9.173.917 Bits Nutzdaten pro Sekunde,

entspricht 1.146.739 Bytes

=         1.09 Mbyte (leicht gerundet)

 

(* Der Wert ist gerundet. Mit IPv4 kann man von min. 78 Bytes, bei IPv6 von min. 98 Bytes Protokollheader ausgehen.

** Die Datenübertragungszeit ist unabhängig von der Paketgröße, da das letzte Bit die gleiche Datenübertragungszeit wie das erste Bit hat. Daher ist es ausreichend, die Datenübertragungszeit pro Wegstrecke nur einmal zu berücksichtigen.

*** In der Rechnung wird mit „Bit“ gerechnet, 1 Byte = 8 Bit.

**** Die Zeit ist die halbe RTT, da in diesem Rechenschritt nur eine Richtung berücksichtigt wurde)

(-> Zum ersten Verständnis ist diese Rechnung gut, zum schnellen Ermitteln Ihrer Bandbreite können Sie aicalc nutzen, dort werden alle notwendigen Parameter berücksichtigt.)

 

⇒  Die durch TCP bedingten Verzögerungen in der Datenübertragung sind bei einer Round-Trip-Time von 2 ms und einer TCP-WinSize von 64 KByte gering.

 

Anders sieht es jedoch bei WAN-Strecken aus, wobei ein Round-Trip-Time von 80–120 ms durchaus üblich ist:

 

Nun erfolgt die gleiche Rechnung wie oben, jedoch mit einer RTT von 80 ms:

 

1/10000000 s x 512.000 Bit = 0,0512 Sekunden Übergabezeit an die Leitung

 

+         0,00256 Sekunden Übergabezeit des Headers an die Leitung

+         40 ms = 0,04 Sekunden Datenübertragungszeit

+         1/10000000 s x 480 Bit = 0,000048 Sekunden TCP-Ack Übergabezeit an die Leitung

+         0,0000024 Sekunden Übergabezeit des TCP-Ack – Header an die Leitung

+         40 ms = 0,04 Sekunden Datenübertragungszeit

=         0,1338104 Sekunden Übertragungszeit je 64 KByte Nutzdaten

bzw. 512.000 Bit

=         3.826.309 Bits Nutzdaten pro Sekunde, entspricht 478.288 Bytes

=         0.45 Mbyte (gerundet)

 

Die Nutzbandbreite unter Berücksichtigung der TCP-Eigenschaft würde eine Übertragungsrate von ca. 3.826.309 Bits pro Sekunde bzw. 0,44 Mbyte ermöglichen.

 

Unter Berücksichtigung all dieser Parameter können Sie mit aicalc die theoretisch maximal zu erwartende Übertragungsrate für eine TCP-Session in Ihrem Netzwerk schnell und zuverlässig errechnen.

 

Fazit:

 

In Zukunft wird es wohl Aktualisierungen oder zumindest Erweiterungen für das betagte Transportprotokoll TCP geben. So arbeitet Google an einem vorausschauenden Verhalten durch die “TCP Fast Open”. Ebenso gibt es erste Versuche mit der Bündelung von mehreren TCP-Sessions zwischen zwei Endpunkten, das so genannte Multipath-TCP.

Konkret ist QUIC und http/3 in der heißen Phase. QUIC setzt übrigens auf UDP als Transportprotokoll auf. 

 

Abhängig von der Markdurchdringung der Hersteller wird sich zukünftig entscheiden, welche dieser Möglichkeiten unsere Datenübertragung beschleunigen wird. Zumindest bei der http-basierten Webseitenübertragung wurden Protokollerweiterungen wie das durch Google geförderte „SPDY“ bereits implementiert.

​

Bis dahin bleibt das Messen der WAN-Strecken, das Definieren von Schwellwerten und das Emulieren von WAN-Strecken, um das Applikationsverhalten zu testen. 

​

​

PS.: Ändert IPv6 irgendwas an der Performance? 

​

Diesen Mythos gilt es zu klären:

IPv6 ist ein Layer 3 Protokoll und hat in diesem Zusammenhang keinen Einfluss auf die Datenübertragungsgeschwindigkeit.
Lediglich die unterschiedlich großen IP-Header sorgen für ein verändertes Verhältnis zwischen Header und Nutzlast.
Richtig ist, dass ein IPv4-Header in der Praxis meistens 20 Byte groß ist (maximal 60 Byte) und ein IPv6-Header ohne Extension Headers bereits 40 Byte groß ist. 
Damit gehen einmal 1,3 % (20 Byte von 1.500 Byte) von einem IPv4-Paket und bei IPv6 2,6 % (40 Byte von 1.500 Byte) für den Header "verloren". In der Praxis ist dieser Unterschied zu der Datenübertragungsmenge von 1,4 % zu vernachlässigen.

​

​