Laden...

Netzwerk-Traffic aufzeichnen und wieder abspielen

Erstellt von live2 vor 9 Jahren Letzter Beitrag vor 9 Jahren 6.074 Views
L
live2 Themenstarter:in
34 Beiträge seit 2005
vor 9 Jahren
Netzwerk-Traffic aufzeichnen und wieder abspielen

Hallo Zusammen

Ich programmiere derzeit an einem UDP-Server in meiner Test Umgebung läuft alles einwandfrei sobald er aber im Live Betrieb läuft gibt er nach 50 bis 80 Millionen Request seinen dienst auf. Nun möchte ich mir den Traffic aufzeichnen damit ich ihn dann im Debug Modus analysieren kann.

Kennt jemand ein einfaches Tool dafür?

Bin bisher erst über wireshark und ostinato gestoßen. Wireshark scheint mir zu überdimensioniert für meinen Fall. Ostinato muss ich mir noch im Detail ansehen.

Vielen Dank
live2

16.807 Beiträge seit 2008
vor 9 Jahren

WireShark ist DAS Tool fuer die Netzwerk-Analyse..

L
live2 Themenstarter:in
34 Beiträge seit 2005
vor 9 Jahren

Hallo Abt

Hast du denn schon mal Traffic aufgezeichnet und diesen dann mit Wireshark wieder abgespielt? Gibt es hier ein gutes HowTo?

Danke

16.807 Beiträge seit 2008
vor 9 Jahren

Hast du denn schon mal Traffic aufgezeichnet und diesen dann mit Wireshark wieder abgespielt?

Ja.

Gibt es hier ein gutes HowTo?

Bestimmt. Google-Suche nach wireshark tutorial

L
live2 Themenstarter:in
34 Beiträge seit 2005
vor 9 Jahren

Hallo Abt

Danke für den netten Google Link. Ich poste hier im Forum um mit Menschen zu kommunizieren die schon vor der gleichen Herausforderung standen. Und einen besseren und vielleicht einfacheren Weg gefunden haben. Ich habe mich ja auch schon mit der Thematik auseinandergesetzt und mit Wireshark 2 Wochen den Traffic aufzunehmen und wieder abzuspielen scheint für mich nicht der optimale Weg zu sein.

Also wenn du wirklich helfen möchtest dann würde ich dich bitten Antworten zu verfassen die Hilfreich sind. Ansonsten kann ich gleich Google benutzen. Ich denke aber das Forum hier soll eine alternative zu Google darstellen.

Danke

C
1.214 Beiträge seit 2006
vor 9 Jahren

Naja, zumindest wenn du nach einem guten HowTo fragst, ist ein Google Link als Antwort nicht verkehrt 😉 Ich meine, ein HowTo kannst du sicher auch selber finden, und wenn du konkretere/andere Antworten haben willst, solltest du auch konkretere/andere Fragen stellen. Zumindest was diesen einen Satz und die Antwort darauf betrifft.

Solche Netzwerkprobleme können ziemlich kompliziert zu finden sein. Ich schreibe auch nebenbei an einer Serversoftware (nebenbei, weil die Serverkomponente eigentlich nur einen ganz kleinen Teil der Gesamtsoftware ausmacht) und wir hatten über die Jahre schon alle möglichen komischen Probleme damit. z.B. wurden die Verbindungen irgendwann nicht mehr zugemacht und das hat den Server nach einer Weile gekillt. Da mussten wir auch eine ganze Weile suchen, warum das Zumachen der Verbindungen von heut auf morgen nicht mehr ging, an der Software wurde nichts geändert, der Server wurde nur auf eine frische VM umgezogen. Selbe Windows Version, eigentlich alles gleich. Wir haben auch tatsächlich nicht rausfinden können, was der Unterschied war, aber irgendwann dann doch einen Bug in unserer Software gefunden. Oder irgendwann wars auch von wieder heut auf morgen viel langsamer usw...
Was ich sagen will, riesige network captures aufzuzeichnen und wieder durchlaufen zu lassen ist nicht unbedingt der richtige Weg, das Problem zu finden, oder zumindest nicht gleich. Kannst du das Problem schon eingrenzen? Wir haben über die Jahre wie gesagt viele Probleme untersuchen müssen und die hatten auch alle möglichen unterschiedlichen Ursachen. Kann sein, dass es auf die Menge ankommt, oder auf die zeitlichen Abstände, oder auf die Intervalle, oder auf ganz bestimmte Pakete zu einem bestimmten Zeitpunkt... Hatten wir alles schon. Kann sein, dass du den capture wieder abspielst und das Problem dabei nicht auftritt.

Wegen Wireshark. Ich habs länger nicht mehr so intensiv benutzt, aber so weit ich mich erinnern kann, hatte das früher Stabilitätsprobleme bei großen Captures. Also zumindest tshark verwenden und nicht die GUI. Aber ich meine, das hat auch so seine Probleme. Im Wireshark Blog (Wireshark Blog) steht, dass sie da was verbessert haben und beim rotieren der Dumpfiles auch der Speicher aufgeräumt wird, aber ob das jetzt auch wirklich released wurde und wie gut das funktioniert, weiß ich nicht.

L
live2 Themenstarter:in
34 Beiträge seit 2005
vor 9 Jahren

Ich setze bei meinem Projekt für die untere Schicht auf ein bewährtes Socket Framework. Dieses verwende ich auch schon bei einem anderem Projekt. Dort läuft über Monate ohne Fehler. Der einzige unterschied im ersten Projekt verwende ich TCP beim neuen benötige ich UDP. Das Betriebssystem schließe ich aus, da nach einem Service Neustart alles wieder einwandfrei funktioniert.

Ich habe schon in einem Test 200 Millionen Request produziert und der Server lief einwandfrei. Ich gehe davon aus das korrupte UDP Pakete für den Fehler verwantwortlich sind. Ich muss aber diese Korrupten UDP Pakete zuerst identifizieren und möchte diese dann dem Entwickler zukommen lassen.

C
1.214 Beiträge seit 2006
vor 9 Jahren

Wir haben die Sockets natürlich auch nicht selber implementiert 😉 Nur, damit es hier keine Missverständnisse gibt.
Kannst du die ganze Zeit einen Debugger mitlaufen lassen? Breakpoints an den wichtigen Stellen setzen, wo sich das Programm beenden könnte, und natürlich Exceptions aktivieren.
Ansonsten kannst du schon versuchen, mit tshark den Traffic aufzuzeichnen und dann nochmal abzuspielen. Da du schreibst, dass du das schon probiert hast, was genau hat dann nicht geklappt?

C
2.121 Beiträge seit 2010
vor 9 Jahren

Kannst du wirklich das System ausschließen? Serviceneustart bedeutet der Service wird komplett abgeräumt, also auch Sockets die das Betriebssystem verbockt hat und die zum Absturz führen. Da muss nicht erst ein Reboot helfen um das System verantwortlich zu machen.

Wie könnte so ein Paket korrupt sein? Wenn es um den Inhalt geht, den kannst du ohne Tool direkt im Dienst aufzeichnen.
Logge neben den Daten auch verschiedene Ablaufschritte während der Verarbeitung um zu sehen wo genau die Verarbeitung abbricht. Da dann noch weiter verfeinern.
Regelmäßig den freien Speicher protokollieren, den Plattenplatz, die Anzah Threads... offene Sockets (gibts die bei UDP überhaupt in der Form?)
Ist um alles ein try-catch? Lieber testweise noch ein paar einbauen.

Ist der Dienst gegen falsche Inhalte gesichert oder kanns sein dass man ihn mit etwas unerwartetem abschießen kann? Vielleicht kommt ein Broadcast rein der eigentlich für was anderes gedacht ist und bringt den durcheinander.
Zähle die Verbindungen mit und sieh dir an ob da irgendwelche Lecks auftreten, etwas nicht geschlossen wird oder so.

Gibt es relevante Unterschiede zwischen Test und live System? Anderes Betriebssystem, anderer Updatestand, andere Netzwerkkarte....
Lass den Test auf dem Livesystem laufen und baller ihn voll, sofern das möglich ist.

So ein Link ist übrigens doch eine nette Sache. In solchen Tutorials wird (wenn sie gut sind) viel ausführlicher etwas erklärt als es jemand hier tun könnte und wollte.

W
872 Beiträge seit 2005
vor 9 Jahren

Die Alternative wäre für Dich Windump zu nehmen - das ist der Port von tcpdump für Windows. Das ist ein Kommandozeilentool.
Ansonsten sind die Unterschiede zwischen TCP und UDP groß. Das Problem wirst Du kaum auf ein einziges Paket zurückführen können. Bei UDP musst Du vor allem schnell genug sein, so daß keine Pakete verloren gehen. TCP wird in dem Fall nur langsam, weil die Pakte nochmal geschickt werden, UDP wirft sie weg. TCP garantiert, das die Reihenfolge beim Empfang dem Versand entspricht, UDP macht das nicht.

L
live2 Themenstarter:in
34 Beiträge seit 2005
vor 9 Jahren

@Coder007 Ich habe beim letzten Versuch mit Wireshark und der GUI gearbeitet. Die GUI war nach einem Tag nicht mehr ansprechbar. Es hat aber weiterhin die Pakete aufgezeichnet. Nur beim abspielen meldete er dann das ein Problem mit dem File vorliegt.

@Chilic Ich habe den Service auf 2 Verschiedenen Servern installiert. Auch wenn ich den Socket Layer stoppe und wieder starte ohne den ganzen Prozess zu beenden dann läuft es auch wieder für eine Zeit weiter, verhängt sich dann aber schneller wieder als wenn ich den Prozess komplett beende.

@Weismat Ich werde es mal mit windump versuchen. Danke für den Tipp. Mal schauen ob ich hier bessere Files erzeugen kann.
Habe den Prozess nun an gestartet "WinDump.exe -C 200 -w traffic.pcap -s 0 -n port 53"

Generell noch ein mehr Informationen zum Projekt. Ich baue derzeit an einem Dns Server der auf TCP und UDP Anfragen antwortet. Das System läuft grundlegend schon sehr gut. Wie schon oben beschrieben fällt meistens der Nameserver1 nach einer bestimmten Zeit aus. Die Pakete habe ich auch schon ein wenig analysiert und teilweise kommen update Pakete die eigentlich nicht daher kommen sollten. Daher gehe ich schwer davon aus das eh mit korrupten Paketen zusammenhängt. Das Problem was ich dann aus den Logfiles entnehmen kann liegt mit dem senden der Antworten zusammen, da stellt es ihn irgendwo auf. Evtl. fälscht jemand die IP das möchte ich eben über ein Traffic Logfile herausfinden.

Grundsätzlich läuft der Dienst weiter kann aber keine Antworten mehr versenden. Ich habe einen Zähler eingebaut beim Senden der Antwort und dieser zählt dann ins unendliche hoch wenn der Fehler auftritt.

Testweise habe ich nun einen der beiden Services auf .NET 4.5 umgestellt. Der zweite läuft auf dem .NET 4.0 Framework.