written by Timur Özcan - Created: 22. June 2017

 

They tell the truth unless they have been captured incorrectly. In those cases, packets can tell bold-faced lies.

When digging through trace files, we can come upon symptoms in the packets that may raise an eyebrow. These are events that look strange on the surface and may even divert our troubleshooting focus for a time. In fact, some of these issues have misdirected engineers for hours, if not days, causing them to chase down issues and events that simply did not exist on the wire.

Most of these examples can be avoided simply by capturing the packets from a network test access point (TAP) rather than on the machine generating the traffic. (Come on, you know you have needed a TAP for a while! Just spring for one and capture correctly next time.)

 

Very Large Packets

1

For the most part, packets should not be larger than the Ethernet maximum of 1518 bytes, or whatever the link MTU is set to. That is unless we are using 802.1Q tags or are in a jumbo frame environment.

How is it possible to have packets that are larger than the Ethernet maximum? Simply put, we are capturing them before they are broken up by the NIC. Many TCP/IP stacks these days use TCP Segmentation Offloading, which delegates the burden of segmenting the packets to the NIC. The WinPcap or Libpcap driver captures the packets before this process happens, so some of the packets can look far too big to be legal. If the same activity was captured on the wire, the large frames would have been broken into several smaller ones for transport.

 

2

 

Zero Delta Times


3

Zero delta times mean that there is no measured time between packets. When these packets entered the capture device, they were timestamped the same as the most recent one with a measureable delta time. The ingress timestamping on the capture device could not keep up with the packet load. If these packets were captured with a TAP external to the server, we would likely see correct timestamping.

 

Previous Packet Not Captured

This warning is shown because Wireshark interpreted a gap in the TCP stream. It can determine from the sequenced numbers that a packet went missing. Sometimes this is legitimately due to upstream packet loss. However, it can also be a symptom that the analyzer or SPAN dropped the packet because it couldn’t keep up with the load.

4Tip – after this warning, look for a series of duplicate ACK packets, then an Out-Of-Order packet. This indicates that a packet was indeed lost and needed to be retransmitted. If you don’t see a retransmission or out-of-order packet, then the analyzer or SPAN probably could not keep up with the data stream. The packet was there on the wire, but we didn’t see it.

TCP ACKed Unseen Segment

In this case, we see an acknowledgement for a data packet that was not captured. The data packet could have taken a different path, or the capture device simply did not pick it up.

Recently, I have seen these events from trace files that have been captured from switches, routers, and firewalls. Since capturing traffic is a lower priority than forwarding (thank goodness!) the device simply missed some of the frames in the stream. Since we saw the acknowledgement, we know that the packet did make it to its destination.

For the most part, packets tell the truth. They can lead us to the root cause of our network and application problems. Since they present such clear and detailed data, it is very important that we capture them as close to the wire as possible. This means capturing them in transit and not on the server itself. This will help us avoid wasting time on the false negatives.

 

https://www.garlandtechnology.com/tap_vs_span_lp

 

Geschrieben von Timur Özcan - Erstellt: 02. März 2017

 

Was kann bei einem TCP-Handshake schief gehen?

Hier ist der erster Artikel einer Serie, die alle Informationen enthält, die Sie zur Behebung von Leistungsproblemen von Anwendungen benötigen, welche auf dem TCP-Protokoll basieren.

Schauen wir uns an, wie TCP-Sessions aufgebaut werden ... und was schief gehen kann!

Das TCP-Protokoll ist ein verbindungsorientiertes Protokoll, was bedeutet, dass eine Verbindung aufgebaut und aufrechterhalten wird, bis die Anwendungsprogramme an jedem Ende den Austausch von Nachrichten abgeschlossen haben. TCP arbeitet mit dem Internet Protocol (IP).

TCP bietet eine zuverlässige, geordnete und fehlerfreie Übertragung. Um dies zu tun, besitzt TCP einige Funktionen, wie zum Beispiel Handshake, Reset, Fin, Ack, Push-Pakete und andere Arten von Flags, um die Verbindung aufrechtzuerhalten und keine Informationen zu verlieren.

TCP wird mit vielen funktionellen Protokollen verwendet, wie beispielsweise HTTP. Daher ist es wichtig zu wissen, wie TCP-Probleme diagnostiziert werden können. In dieser Artikelserie werden wir diese TCP-Metainformationen erläutern und erklären, warum sie für eine Fehlerbehebung wichtig sind und wie sie mit PerformanceVision (PV) ganz leicht gemessen werden können.

Wie wird eine Session gestartet? TCP-Handshake und Verbindungszeit

Eine TCP-Verbindung, die auch als 3-Wege-Handshake bezeichnet wird, erfolgt über SYN, SYN + ACK und ACK-Pakete. Aus diesem Handshake können wir eine Leistungsmetrik mit dem Namen Connection Time (CT) ermitteln, die zusammenfasst, wie schnelle eine Session zwischen einem Client und einem Server über ein Netzwerk aufgebaut werden kann. Weitere Informationen finden Sie in diesem hervorragendem Artikel auf Wikipedia.

 

Standard TCP Handshake

Abb.1 - Wie TCP Handshakes analysiert werden

 

Die drei Schritte eines TCP-Handshakes sind:

1. Das 'SYN' ist das erste Paket, das von einem Client an einen Server gesendet wird, es verlangt buchstäblich von einem Server, eine Verbindung mit ihm aufzubauen.

2. Wenn es möglich ist, antwortet der Server mit einem "SYN + ACK", was bedeutet, "Ich haben Ihre 'SYN' erhalten und ich bin damit EINVERSTANDEN"

3. Schließlich sendet der Client ein 'ACK', um die Verbindung zu bestätigen.

Wie TCP-Verbindungsfehler diagnostiziert werden

1 - SYN ohne Verbindungen

Die erste Sache, die Sie mit PV leicht diagnostizieren können, lautet: "Können meine Clients eine Verbindung zu meinen Servern herstellen?" Gehen Sie im PV-Menü zu Applikation - → Clients, wählen die Registerkarte TCP und setzen den Filter mit dem Namen “Nur einseitigen Fluss". Dadurch sehen wir nur den Verkehr vom Client zum Server und keine Antwort vom Server.

 

Performance Vision FilterAbb.2 - Nur auf einseitige Flows filtern

 

Dies bedeutet, dass Sie nur die Top-Client-IPs mit nur einem Fluss vom Client und ohne Antwort sehen möchten.

Für fortgeschrittene Benutzer von PerformanceVision

Wir haben den Filter so festgelegt, dass nur einseitige Flows zu sehen sind, wodurch größtenteils 'SYN' Probleme angezeigt werden, aber Sie könnten auch andere Arten von Flows erhalten. Um lediglich die 'SYN' ohne Verbindungen zu ermitteln, werden Sie einenbenutzerdefinierten Filter verwenden müssen:

syn.count > 0 and ct.count = 0

 

SYN TabelleAbb.3 - PV hat einseitige Flows gefunden und diese sortiert

 

 Wie Sie auf den obigen Ergebnissen sehen können, gibt es mehrere IPs, die eine Verbindung zu einem Server (SYN> 0) fordern, aber keine Verbindung zu ihnen herstellen können (Connections = 0).

Hier sind häufige Fehlerfälle:

  •   Eine Firewall verweigert diese Verbindungen - Sie können dieselbe Anfrage auf Client Zones (im selben Menü) anwenden, um festzustellen, ob sich die IPs in derselben Zone befinden.
  •   Der Server existiert nicht mehr oder ist nicht verfügbar - dies geschieht häufig, wenn eine Server-IP geändert wird, aber einige Clients auch weiterhin die alte IP anfragen.



2 - Schlechte Verbindungsraten

In einer perfekten Welt sollten Sie 1 'SYN' pro TCP-Verbindung erhalten. PV stellt eine Metrik zur Verfügung, um diese Verbindungseffizienz zu sehen, was durch eine 'SYN' pro Verbindungsrate (dies entspricht der Anzahl der SYN-Pakete, die mit der Anzahl der TCP-Sitzungen verglichen werden, die eingerichtet wurden) dargestellt wird. Diese Metrik befindet sich in den "Details" Tabellen und kann über die Registerkarte "TCP" geöffnet werden. Sie können auch die zeitliche Entwicklung über Anwendung → benutzerdefinierte Diagramme grafisch darstellen.

 

 

 

SYN VerbindungenAbb.4 - PV benutzerdefinierte SYN/Conn Tabellen

 

Eine schlechte "SYN"-Effizienz kann manchmal auch durch ein Netzwerkproblem ausgelöst werden. Somit wird die Fehlverbindung durch einen Paketverlust oder Kontingenz verursacht. Sie können diese Vermutung überprüfen, indem Sie die Verbindungszeit betrachten. Wenn diese niedrig bleibt und sich auf mehrere Hosts auswirkt, dann ist es wahrscheinlich ein Netzwerkproblem.

Wenn hingegen die Verbindungszeit hoch ist, aber das Problem beim Server liegt, ist dieser überlastet und kann nicht auf alle Clientanfragen antworten. Wenn schließlich die 'SYN'-Rate sehr groß ist, dann könnten Sie Sicherheitsprobleme haben, wie zum Beispiel einen DDOS-Angriff.

Fortgeschrittene Funktionen von PerformanceVision

Die Netzwerklatenz - RTT (Round Trip Time) - dies kann Ihnen einen weiteren Hinweis dafür geben, dass das Problem auf der Netzwerkseite liegt. PV stellt das RTT in der Metrik der Netzwerkleistung zur Verfügung.

 

SYN Fehlerdiagnose von VerbindungenAbb.5 - Eine Fehlerdiagnose von Verbindungen durch Verbindungszeiten und SYN-Raten

 

Fazit

In diesem ersten Artikel sahen wir eine kurze Darstellung der TCP-Leistungsmetriken und wie das TCP-Protokoll die Verbindungen mit SYN/SYN + ACK/ACK-Paketen verarbeitet. Wir sehen auch einige häufige Fehlerfälle, die leicht mit PerformanceVision diagnostiziert werden können.

Um diese Art von Problemen zu beheben, verwendeten wir die Page Top Clients, Top Client Zones und Custom Charts. Um einen Schritt weiter zu gehen, haben wir "Advanced Filter: Unilateral Flows" verwendet, um Flows ohne Antworten zu filtern.Wir haben zudem mehrere Metriken vorgestellt: die Anzahl der 'SYN' und 'Handshakes' (Verbindungen), die SYN-Effizienz und die Verbindungszeit. In nächsten Artikel werden wir einen Blick darauf werfen, wie Sie eine Verbindung mit Reset- und Fin-Paketen beenden können.

In der Zwischenzeit; falls Sie es ausprobieren möchten, können Sie einfach unsere Evaluation Virtual Appliance herunterladen:

Geschrieben von Timur Özcan - Erstellt: 17. November 2016

 

Ein Microburst ist eine lokale und plötzlich auftretende Fallbö (Downdraft) innerhalb eines Gewitters, die in der Regel einen Durchmesser von 4 km besitzt, was meistens jedoch viel geringer ist. Mikrobrüche können zu erheblichen Schäden an der Oberfläche führen und in einigen Fällen sogar lebensbedrohlich sein.

In Computernetzwerken wird ein Microburst als kurzzeitiger Andrang von Daten definiert, der typischerweise nur Millisekunden dauert, was jedoch die Verbindung überlastet (Ethernet, Gigabit, 10 Gigabit usw.). Ein Mikroburst ist ein ernsthaftes Bedenken für jedes Netzwerk, denn auch eine kurzfristige Überlastung des Netzwerks bedeutet, dass einige Benutzer keinen Zugriff auf das Netzwerk haben werden. Da der Industriestandard für die Messung der Netzwerknutzung in Bit pro Sekunde (bps) angezeigt wird, bleiben Mikrobursts oft unentdeckt, weil sie im Verlauf der Messung ausgeglichen werden. In den meisten Fällen melden herkömmliche Netzwerküberwachungssysteme eine solche Überlastung nicht, weil diese nicht mehr als eine volle Sekunde vorhanden sind. Die Erfahrung des Endbenutzers kann deutlich eingeschränkt werden, wenn zu viel Netzwerkverkehr aufkommt oder Leistungsengpässe entstehen, die durch einen langsamen Datendurchlauf oder Verbindungsausfall verursacht wurden.

Um einen Microburst zu identifizieren, ist eine genaue Messung des Netzwerkverkehrs auf einem Link mit einer Mikrosekunden-Granularität sowie eine Visualisierung in Millisekunden erforderlich. Hier ist ein praktisches Beispiel für die Identifizierung eines Microbursts.

In diesem Beispiel befindet sich der Messpunkt auf einem TAP, der in einen 10-Gbit/s Link einer Rechenzentrumsverbindung eingefügt wird. Wir haben 45 Sekunden des Netzwerkverkehrs mit einem Savvius Omnipliance TL gemessen. Das Expertensystem von Omnipeek alarmiert sofort auf Unregelmäßigkeiten auf den OSI-Schichten 2 bis 7. Diese Warnungen können auf der Basis einer der verfügbaren Spalten sortiert werden, z. B. durch Anzahl, Schichten usw. In diesem Fall sortieren wir nach Anzahl und sind dadurch in der Lage TCP-Wiederübertragungen, "Nicht reagierende" Peer Alerts, langsame Bestätigungen usw.

 

abbildung1.jpg

 Abbildung 1: Omnipeek Expertensystem mit Strömungen, kategorisiert nach Protokollen/Anwendungen und Expertenereignissen, die nach Anzahl der Vorkommen sortiert wurden.

 


abbildung2.jpg

Abbildung 2: Eine Grafik der Gesamtauslastung mit sekundengenauer Auflösung zusammen mit den meistgenutzten Anwendungen.

 

Wenn die Netzwerkauslastung unter Verwendung der typischen bps dargestellt wird, wie dies in Bild 2 der Fall ist, dann beträgt die maximale Vollduplex Spitze 2,54 Gbit/s, was bei einer Verbindung mit 10-Gbit/s und einer Vollduplexkapazität von 20 Gbps als nicht besorgniserregend gilt (senden und empfangen - 10 Gbit/s in jede Richtung).

Eine Sache, die wir in der Zusammenfassung des Compass Expert Events bemerkt haben, ist, dass es eine ziemlich große Anzahl von Ereignissen gibt, die mit langsamen Netzwerkproblemen in Verbindung stehen, insbesondere bei einer Messung von 45 Sekunden. Compass kann das Auftreten von Expert Events grafisch darstellen, wodurch deutlich wird, dass es eine Gemeinsamkeit in dem Neigungsverhältnis zwischen Expert Events und der gesamten Netzwerkauslastung gibt:

 

abbildung3.jpg

 Abbildung 3: Die Compass-Funktion von Omnipeek kann das Vorkommen von Expert Events darstellen.

 

Da die Anzahl von langsamen Netzwerkereignissen recht umfangreich ist, lassen Sie uns zurück zum Nutzungsdiagramm gehen, um die Spitzen etwas näher zu untersuchen. Wir können eine tiefer gehende Analyse durchführen, um dadurch eine Detailgenauigkeit in Millisekunden zu sehen, wobei wir mehrere Spitzen mit bis zu 9.845 Mbit pro Millisekunde feststellen konnten. Umgerechnet auf Sekunden (einfach multipliziert mit 1000), wäre dies 9.845 Gbps, und sollte dies in eine Richtung verlaufen, dann wird dies unseren 10 Gig Link vollständig auslasten.



abbildung4.jpg

 Abbildung 4: Netzauslastung in Millisekunden-Granularität mit mehreren Spitzen von bis zu 10 Mbit pro Millisekunde

 

Interessanterweise wurde in Abbildung 4 das obere Protokoll in CIFS umgewandelt. Was ist also passiert?

 

abbildung5.jpg

Abbildung 5: Die übliche Ausnutzung durch TCP-Verkehr ist in Lila dargestellt, wohingegen die CIFS-Spitzen braun gekennzeichnet wurden.

 

Bei einer normalen Ausnutzung von bis zu 6 Mbit pro Millisekunde an TCP-Verkehr, können CIFS-Spitzen von bis zu 6 Mbit pro Millisekunde die Ausnutzung sogar auf 12 Mbit pro Millisekunde steigern, was die Kapazität eines 10 Gbit/s Links in eine Richtung gänzlich übersteigt. In einer solchen Situation sind die Switches nicht mehr in der Lage den Datenverkehr zu puffern, bis die Bursts verschwunden sind, was dazu führt, dass Pakete verloren gehen und letztendlich TCP-Neuübertragungen verursacht werden, was die Expert Events eindeutig darlegen. Savvius Omnipeek bietet eine sehr intuitive und kostengünstige Möglichkeit, um zu überprüfen, ob tatsächlich Mikrobursts in Ihrem Netzwerk auftreten, aber auch wann, wo und wie sehr die Netzwerkleistung darunter leidet. Wenn Sie noch heute eine kostenlose und 30-tägige Testversion von Omnipeek ausprobieren möchten, dann besuchen Sie einfach unsere Webseite.

Geschrieben von Timur Özcan - Erstellt: 12. August 2016

 

Im Moment gibt es wohl kein heißeres Modewort in der Technologiebranche als Virtualisierung - und das aus gutem Grund. Organisationen wenden sich in Scharen der Virtualisierung zu, um Kapazitäts- und Energiekosten, die mit dem Betrieb eines herkömmlichen Hardwarenetzwerks einhergehen, zu reduzieren.

Dennoch haben fast 60 Prozent der Unternehmen nach einem Bericht von Nemertes Research eine Verlangsamung in ihren Virtualisierungsbemühungen erkennen können. Auch wenn Organisationen und Unternehmen einige der Vorteile der virtualisierten Netzwerke nutzen, schöpfen viele von ihnen wahrscheinlich nicht das Optimum ab.

Netzwerkingenieure wissen nur allzu gut, dass eine virtuelle Topologie sich von Architekturen aus der Vergangenheit grundlegend unterscheiden. In einem virtuellen Netzwerk kommt der Datenverkehr niemals mit dem physischen Netzwerk in Berührung, wo er leichter zu erfassen und zu analysieren ist. Mit anderen Worten: Netzwerküberwachung ist in einer virtuellen Umgebung ein vollständig anderes „Tier“, das den Einsatz ganz anderer Werkzeuge und Hilfsmittel erfordert.

Eine gute Netzwerküberwachung für virtuelle Umgebungen muss kritische Anwendungen überwachen können, die in virtuellen Umgebungen laufen und sollte die Fähigkeit haben, das IT-Personal schnellstmöglich zu benachrichtigen, wenn Probleme auftreten. Savvius 'OmniEngine arbeitet zum Beispiel als Anwendung auf einem virtuellen Netzwerk und kann den Datenverkehr, der zwischen einem physikalischen Host und virtuellen Maschinen fließt, analysieren. Auf diese Weise bleibt "unsichtbarer Datenverkehr" auch latent.

Da der Bandbreitenbedarf auch weiterhin steigt und Rechenzentren entsprechend dimensionieren, werden Virtualisierungen zunehmen. Neue Trends wie die Virtualisierung von Netzwerkfunktionen (NFV) und softwaredefiniertes Networking (SDN) gewinnen an Fahrt, wodurch die Überwachung unkonventioneller Netze noch dramatischer voranschreitet. Ein kürzlich veröffentlichter Bericht von Research & Markets zeigt auf, dass der NFV-, SDN- und Wireless-Networkinfrastrukturmarkt auf 21 Milliarden Dollar bis 2020 wachsen wird.

Die Wahrscheinlichkeit ist groß, dass Ihre EDV-Struktur entweder bereits mit einem virtuellen Netzwerk ausgeführt oder in naher Zukunft umgestaltet wird. Stellen Sie sicher, dass Sie das Optimum erhalten. Die OmniPeek Netzwerk-Analysesoftware ist Savvius preisgekrönte Lösung zur Überwachung, Analysierung und Fehlerbehebung von Netzwerken aller Art. Wie der Name schon sagt, wurde OmniPeek entwickelt, um umfassende Transparenz im Netzwerkverkehr zu gewährleisten: Lokal und remote, LAN und WLAN sowie für Netzwerke mit allen Geschwindigkeiten.

Geschrieben von Timur Özcan - Erstellt: 12. Juli 2016

 

Als Latenz (auch Latenzzeit) wird die Zeit bezeichnet, die benötigt wird, um ein Datenpaket über ein Netzwerk zu senden. 
Latenz kann auf unterschiedliche Weise gemessen werden: bidirektional (beide Richtungen), monodirektional (eine Richtung), usw. 
Die Latenzzeit kann von jedem Teilstück der Kommunikationsverbindung, über welche das Datenpaket gesendet wird, beeinflusst werden: den Arbeitsplatz, die WAN-Verbindungen, Router, lokale Netzwerke (LAN), Server … und letztendlich kann diese - für große Netzwerke - durch die Lichtgeschwindigkeit begrenzt sein.
Die Durchsatzrate ist definiert als gesendete/empfangene Datenmenge innerhalb einer definierten Zeiteinheit. Die UDP-Durchsatzrate wird von der Latenz nicht beeinflusst. 
UDP ist ein Protokoll, das verwendet wird, um Daten über ein IP-Netzwerk zu senden. Eines der Prinzipien von UDP ist, dass angenommen wird, dass die gesendeten Pakete vom Empfänger auch empfangen werden (oder eine entsprechende Steuerung findet auf einer anderen Schicht, beispielsweise einer Anwendung, statt). 
Theoretisch bzw. für bestimmte Protokolle (bei welchen auf keiner anderen Schicht eine Steuerung stattfindet – beispielsweise bei monodirektionalen Übertragungen) wird die Rate, zu der Datenpakete durch den Sender gesendet werden können, nicht von der Zeit, die zur Auslieferung an den Empfänger benötigt wird (=Latenz), beeinflusst., Der Sender wird unabhängig von dieser eine definierte Anzahl an Datenpaketen pro Sekunde senden, die wiederum von anderen Faktoren abhängt (Anwendung, Betriebssystem, Ressourcen, ...).

Warum wird TCP direkt von der Latenz beeinflusst:

  •   TCP dagegen ist ein komplexeres Protokoll, da es einen Mechanismen integriert, der prüft, ob sämtliche Datenpakete auch korrekt geliefert werden. Dieser Mechanismus wird Bestätigung (engl. acknowledgement) genannt: Er veranlasst den Empfänger, an den Sender ein spezifisches Paket oder Flag (ACK-Paket bzw. ACK-Flag) zu senden, das den korrekten Empfang des Datenpakets bestätigt. Der Effizienz wegen werden nicht alle Datenpakete einzeln bestätigt: Der Sender wartet entsprechend nicht auf eine Bestätigung nach jedem einzelnen Paket, um die nächsten Datenpakete zu senden. Tatsächlich wird die Anzahl der Datenpakete, die gesendet werden können, bevor ein korrespondierendes Bestätigungspaket erhalten werden muss, von einem Wert, der als TCP Sendefenster (engl. TCP Congestion Window) bezeichnet wird, gesteuert.

 

TCPThroughputVsLatency

 

Round trip latency

TCP Throughput

0ms

93.5 Mbps

30ms

16.2 Mbps

60ms

8.07 Mbps

90ms

5.32 Mbps

 

Nehmen wir hypothetisch an, dass kein Paket verloren geht:

  •  Der Sender wird ein erstes Kontingent an Datenpaketen gleichzeitig senden (entsprechend dem TCP Congestion Window). Erhält der Sender das Bestätigungspaket, wird das TCP Congestion Window vergrößert. Sukzessiv wird also die Anzahl an Paketen, die in einem bestimmten Zeitraum gleichzeitig gesendet werden können, steigen (Durchsatzrate). Die Verzögerung, mit welcher die Bestätigungspakete empfangen werden (=Latenz), hat einen Einfluss darauf, wie schnell das TCP Congestion Window vergrößert wird (entsprechend auch auf die Durchsatzrate).
    Ist die Latenz hoch, bedeutet dies, dass der Sender länger untätig ist (keine neuen Pakete sendet), was wiederum die Geschwindigkeit, mit welcher die Durchsatzrate steigt, reduziert.
    Die Testwerte (Quelle: http://smutz.us/techtips/NetworkLatency.html) sind sehr deutlich: Warum wird TCP durch wiederholte Paketsendungen (Retransmissions) und Datenverlust beeinflusst?
 

Der TCP Congestion Window Mechanismus geht folgendermaßen mit fehlenden Bestätigungspaketen um:

  •  Bleibt das Bestätigungspaket nach einer fest definierten Zeit (Timer) aus, wird das Paket als verloren eingestuft und das TCP Congestion Window, also die Anzahl der gleichzeitig gesendeten Pakete, wird halbiert (die Durchsatzrate entsprechend auch – dies korrespondiert mit der Wahrnehmung einer restringierten Kapazität irgendwo auf dem Verbindungsweg seitens des Senders); die Größe des TCP Windows kann wieder ansteigen, wenn die Bestätigungspakete korrekt empfangen werden.

Datenverlust hat zwei Effekte auf die Geschwindigkeit der Datenübertragung:

  •  Die Pakete müssen erneut gesendet werden (selbst wenn lediglich das Bestätigungspaket verloren gegangen ist, die Datenpakete aber empfangen wurden) und das TCP Congestion Window wird keine optimale Durchsatzrate zulassen: Dies gilt unabhängig vom Grund für den Verlust der Bestätigungspakete (Überlastung, Serverprobleme, Art der Paketschnürung, …) Ich hoffe, dies hilft Ihnen dabei, die Auswirkungen von Retransmissions/Datenverlusten auf die Effektivität Ihrer TCP-Anwendungen zu verstehen.

 

impactofpacketlossandlatencyonTCPthroughput

 

With 2% packetloss, the TCP throughput is between 6 and 25 lower than with no packet loss.

 

Round trip latency

TCP Throughput with no packet loss

TCP Throughput with 2% packet loss

0 ms

93.5 Mbps

3.72 Mbps

30 ms

16.2 Mbps

1.63 Mbps

60 ms

8.7 Mbps

1.33 Mbps

90 ms

5.32 Mbps

0.85 Mbps

 

We are happy to advise you and look forward to hearing from you!

NEOX - Location

Our partners

IT Security made in Germany TeleTrusT Quality Seal


Contact Details

NEOX NETWORKS GmbH
Otto-Hahn Strasse 8
63225 Langen / Frankfurt am Main
Tel: +49 6103 37 215 910
Fax: +49 6103 37 215 919
Email: info@neox-networks.com
Web: http://www.neox-networks.com
Your route to us >>