Messen von Handshake-Zeiten mithilfe von TCP-Analysen
Wie Sie mit der TCP-Analyse vom Allegro Network Multimeter die Handshake-Zeiten ermitteln
Wie viel Zeit benötigen Ihre Handshakes?
In der Abbildung 1 sehen Sie in den TCP-Statistiken des Allegro Network Multimeter die Client-Handshake-Zeiten der letzten 10 Minuten. Hier können Sie mit einen Blick erkennen, dass es verlängerte Antwortzeiten im angegebenen Zeitraum gegeben hat. Doch aus welchem Grund? Steht der Server im Internet zu weit weg? Oder ist vielleicht das WLAN zu schwach? Solche Fragen gehören mit dem Allegro Network Multimeter rasch der Vergangenheit an. Denn mit diesem können Sie einfach und schnell herausfinden, an welcher Stelle die Antwortzeiten zu lange sind und welche Ursache dahintersteckt.
Gründe für verlängerte Handshake-Zeiten
In der Tabelle auf Abbildung 2 werden alle Daten in tabellarischer Form angezeigt. Hier haben Sie die Möglichkeit, nach verschiedenen Parametern auf- und absteigend zu sortieren und können somit schnell erkennen, welcher Server bzw. Client durchschnittlich die längste Handshake-Zeit hat.
Dies ist möglich, da der Allegro Network Multimeter die Handshake-Zeiten permanent aufzeichnet und analysiert. Der Vorteil daran? Sie sehen auf einen Blick, ob es Latenzprobleme oder vielleicht sogar Qualitätsprobleme mit der virtuellen Maschine gibt. Gerade bei virtuellen Maschinen ist dies häufig der Fall, denn diese funktionieren nach dem Prinzip des „Best Efforts“.
Best Effort meint, dass hier genauso viel Rechenleistung verteilt wird, wie gerade verfügbar ist.
Das mag für den ein oder anderen Dienst, wie beispielsweise beim Backup, in Ordnung sein, da es hier keine Rolle spielt, wie groß oder klein die Zeitscheiben sind. Bei Diensten wie einem ERP-System sieht das wiederum anders aus. Das ERP-System sendet viele kleine Anfragen, für das es sofort Rechenleistung benötigt.
Auch hierfür ist es gut, einen schnellen Blick auf die Handshake-Zeiten werfen zu können. Wir hatten einmal den Fall, dass die Handshake-Zeiten regelmäßig zu bestimmten Uhrzeiten stark nach oben ausgerissen sind. Daran konnten wir sehr schnell erkennen, dass etwas an der virtuellen Maschine nicht stimmte. Wir erkannten, dass der Host nicht genug Rechenzeit der virtuellen Maschine zugeteilt hat. Somit gab es größere Pausen, in denen die Maschine quasi stillstand und keine Anfragen beantwortete.
Wie Sie die Antwortzeiten einer bestimmten IP-Adresse messen
Eine weitere nützliche Funktion der TCP-Statistiken ist, dass Sie in der Tabelle nach einer beliebigen IP-Adresse suchen können und so deren mittlere sowie minimale und maximale Antwortzeit sehen.
Mit Antwortzeit ist die Zeit gemeint, die die Gegenseite benötigt, um den Eingang der von uns ausgesendeten TCP-Daten zu bestätigen. Nicht selten kommt es dazu, dass die Gegenseite mit ihrer Antwort ein wenig wartet, um Pakete zu sparen. Dies ist zum Beispiel beim Linxus-Betriebssystem so. Das Linux-Betriebssystem wartet standardmäßig 40 Millisekunden, bis es antwortet. Grund dafür ist, dass es hofft, ein paar Pakete zu sparen, wenn der Server schneller antwortet. So kann es das Acknowledgement direkt mitschicken.
Was ist, wenn die Handshake-Zeiten deutlich über 40 Millisekunden hinaus gehen?
Hier sollten Sie aufmerksam werden. In so einem Fall bedeutet das meistens, dass die Datenpakete zum Server gekommen sind, der Server aber entweder unter sehr hoher Last steht oder die Verbindung zu langsam ist. Das Gleiche gilt auch in Client-Richtung. Wenn der Client die Daten, die er bekommt, nur zögerlich bestätigt, kann es sein, dass der Client oder die Strecke überlastet ist.
TCP-Retransmissions
Mit dem Allegro Network Multimeter haben Sie die Möglichkeit, jederzeit in die TCP-Statistik reinzusehen. Dadurch können Sie eingrenzen, auf welcher Seite das Problem liegt. Dies ist analog auch für TCP-Retransmissions möglich.
Wie auf Abbildung 3 zu sehen ist, ist können Sie unter dem Menüpunkt TCP-Retransmission alle Datenpakete und nochmals (= retransmit) übertragene Daten einer Verbindung sehen. Dadurch können Sie sofort erkennen, wie viel Prozent der Daten doppelt ist und wie viele Daten insgesamt übertragen wurden.
Wann erscheinen Daten doppelt?
Wenn Daten an einer Stelle doppelt erscheinen, bedeutet das, dass die Gegenstelle die Daten nicht bekommen hat. In dem Fall ist eine Überlast zwischen Gerät und Empfangssystem erfolgt, welche dafür gesorgt hat, dass die Daten im Allegro Network Multimeter verloren gegangen sind.
Typischer Anwendungsfall aus der Praxis:
Es gibt die Beschwerde, dass das Netzwerk zu langsam ist. Nun können Sie mithilfe des Allegro Network Multimeter direkt an dem Server messen, um die aktuelle Antwortzeit von diesem zu sehen. Umgekehrt sieht man aber auch, in welcher Zeit die Daten rausgeschickt werden.
Wenn hier keine Retransmissions angezeigt werden, können Sie davon ausgehen, dass das kein Netzwerk-Bandbreiten-Problem ist. Zusätzlich dazu können Sie sich noch die Antwortzeiten ansehen. Wenn diese gering sind, können Sie das Netzwerk als Problemverursacher gänzlich ausschließen. Das Problem ist somit eine der anderen Seiten, irgendwas im Server oder direkt im Client, der lange für die Verarbeitung der Daten braucht.
Wie finden Sie ungültige Verbindungen?
Auf Abbildung 4 können Sie unter den TCP-Statistiken beim Reiter "TCP-Server mit ungültige Verbindungen" solche mit einem Blick identifizieren. Somit wissen Sie immer sofort, welche IP-Adresse die ungültige Anfrage abschickt und können bei Bedarf Maßnahmen einleiten.
Um eine ungültige Verbindung handelt es sich, wenn eine TCP-Anfrage versendet wurde, aber keinerlei Daten anzeigt werden. Eine Ursache hierfür könnte ein Angriff von außerhalb sein. Es könnte aber auch sein, dass jemand Verbindungen sendet, diese aber gar nicht übertragen möchte und etwas bei der Client-Server-Kommunikation gestört ist.
In der Tabelle sehen Sie gegebenenfalls auch, dass manche Verbindungen den Status „nicht valide“ beinhalten. Das kann der Fall sein, wenn nur ein paar Bytes übertragen wurden und der Handshake zwar da ist, aber die Verbindungen seit 20 Stunden offen sind und nie sauber geschlossen wurden. Auch hier sollten Sie aufmerksam sein, da es sich um einen Angriff handeln könnte. Bitte beachten Sie, dass es sich hierbei nicht um ein Security-Feature handelt, sondern dass Sie dieses eher als eine Art Früh-Warn-System verstehen können.
Funktionen der TCP Flag Auswertung
Durch diese können Sie einfach und schnell sehen, wie viele Flags zu welcher Zeit genutzt wurden.
Dies kann ein Indikator dafür sein, dass etwas im Netzwerk nicht in Ordnung ist, z.B. wenn plötzlich die Reset-Rate sehr stark ansteigt. In so einem Fall können Sie in der Tabelle nach der IP sortieren, die die meisten Resets sendet bzw. empfängt, um den Übeltäter zu finden.
Wann kommt es zu einem Zero Window?
Ein Zero Window kommt immer dann vor, wenn die Daten beim Server angekommen sind, aber die Anwendung die Daten nicht schnell genug abholt. Das hängt mit dem Puffer im Kern vom Betriebssystem zusammen. Immer wenn Daten zu schnell im Betriebssystem ankommen, wird der Puffer kleiner. Sobald der Puffer aufgebraucht ist, sendet das TCP die Nachricht „Puffer ist 0“, ein Zero Window. Das hat den Vorteil, dass das Netzwerk als Problem ausgeschlossen werden kann. Denn das Netzwerk zwischen den beiden Geräten ist schnell genug, der Server kommt nur nicht nach.
Hierfür gibt es zwei mögliche Ursachen:
- Das Fenster ist zu klein, in dem die Daten geschickt werden dürfen
- Oder die Anwendung ist zu langsam, um die Daten anzunehmen
Unter dem auf Abbildung 5 zu sehenden Menüpunkt „TCP Zero Window“ können Sie sich jederzeit ansehen, welche Zero Windows vorhanden sind und auch nachvollziehen, wie viele gesendet und empfangen wurden. Gleichzeitig können Sie sehen, wie groß die Datenmenge sein darf, die das Betriebssystem zwischenspeichert, die sogenannte Fenstergröße bzw. Window Size. Diese wird am Anfang der TCP-Verbindung über den Windows-Scaling-Faktor ausgehandelt. Den Windows-Scaling-Faktor legt die maximale Größe fest und kann nicht zur Laufzeit einer Verbindung geändert werden.
Generell sind das alles gute Indikatoren dafür, dass die physische Verkabelung, die Switches, die Router, die Firewalls etc. nicht das Problem sind. Hier liegt das Problem eindeutig beim Endgerät und dessen Performance. Sie sehen also, dass die TCP-Analyse Ihnen dabei hilft, mögliche Problemverursacher schnell auszuschließen und sich dem eigentlichen Problem zu nähern. Der große Vorteil an TCP ist, dass es auch mit einer großen Menge an Protokollen, insbesondere mit voll verschlüsseltem Verkehr wie SSL funktioniert, weil auch hier TCP genutzt wird.
Ein Anwendungsfall aus dem Leipziger Office:
Mit dem Allegro Network Multimeter können Sie ganz einfach nach der Anwendung sortieren, die die meisten TCP Zero Windows sendet. Bei uns sind es viele aus dem Back-up-System. Wir konnten bei genauerer Betrachtung der Zeiten feststellen, dass 500 Zero Window Pakete pro Sekunde versendet wurden. Gleichzeitig ist die Antwortzeit sehr langsam. Was war der Grund dafür?
Unter dem Punkt „Peers“ sahen wir, dass es einen großen Transfer von 66 GB von unserer Diskstation gab. Das hatte in diesem Fall den Grund, dass einmal pro Nacht von unserem zentralen NAS ein Backup auf unser altes NAS gemacht wird. Jetzt ist das neue NAS schneller als das alte und kann die Daten schneller senden.
Ausschließen von Verkehr mithilfe von Filtern
Oft gibt es Installationen, bei denen man entweder einen großen Mirror-Port bekommt oder von einem Paket Broker sehr viele Daten hat. Damit Sie diesen analysieren können, haben wir einen Netzwerkfilter eingebaut. Mit diesem können Sie bestimmten Verkehr, den Sie nicht aufzeichnen oder analysieren möchten, ganz einfach ignorieren.
Solche Verbindungen können zusätzlich auch als Black- oder Whitelist definiert werden. Vielleicht haben Sie bestimmte IP- oder MAC-Filter, die für Ihre Messungen relevant sind. Vielleicht ist auch das Gegenteil der Fall und Sie möchten bestimmte Rechner ausschließen, die auf keinen Fall analysiert werden sollen. Auch dies ist mit dem Allegro Network Multimeter kein Problem. Beachten Sie bitte, dass, auch wenn die einzelnen Pakete ausgeschlossen wurden, diese dennoch in den Interface-Statistiken zu sehen sind. Das liegt daran, dass die Pakete vorhanden waren und registriert wurden. Bevor es zur Verarbeitung kommt, werden diese allerdings weggefiltert und intern verworfen. Damit Sie hier den Überblick behalten können, haben wir die Rubrik „gefilterter Datenverkehr“ ins Dashboard installiert.
Wie auf Abbildung 6 zu sehen ist, finden Sie hier die Filterfunktion für folgende Bereiche: IP-Adressen, Subnetze, IP-Paare, MAC-Adressen, VLANs, Ports, Netzwerk-Interfaces-Filter
Die Verknüpfung beim Filtern ist Oder-basiert, was bedeutet, dass jeder Filter für sich allein und separat angewendet wird. Wird zum Beispiel ein MAC- und ein IP-Filter gleichzeitig eingesetzt, dann wird die Adresse, sobald sie auf diesen Verkehr trifft, herausgefiltert. Im umgekehrten Fall, wenn Sie viele IP-Adressen hinzugefügt haben, werden diese dann Oder-verknüpft und der Filter wird angewendet, sobald eine IP-Adresse getroffen wird.
Fazit
Durch die Funktion der TCP-Analyse und der Handshake-Zeiten Messung im Allegro Network Multimeter lassen sich Fehler schnell analysieren und mögliche Angriffe erkennen. Wir empfehlen Ihnen zu diesem Thema das Video von unserem Geschäftsführer Klaus Degner und die Anleitung im Produkt-Wiki.
