Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Netzwerkgrundlagen

Website-Aufruf mit Wireshark analysieren

Testen Sie unsere 2016 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Das Programm Wireshark dient der Analyse der Kommunikation innerhalb eines Netzwerks. Dieses Video zeigt den schrittweisen Ablauf eines Website-Aufrufs mit Hilfe des Programms.

Transkript

Ja, wie wir ja hier sehen, habe ich gerade eine Webseite im Intranet abgerufen, und wie dieser Abruf im Wireshark aussieht, das wollen wir uns in diesem Video ansehen. Wie gesagt, Abruf Intranetseite, und so sieht das Ganze hier im Wireshark aus, ich hab's eben gerade aufgezeichnet, und wir wollen uns diesen Aufruf, oder diesen Abruf jetzt mal Schritt für Schritt anschauen. Ja, was passiert denn als erstes? Beim Paket mit der Nummer 1 haben wir zunächst mal das ARP-Protokoll, er hat also ausgerechnet, dass sein DNS-Server im lokalen Netzwerk liegt, und zwar sucht er jetzt den Domänen-Controller hier, da liegt hier im Übungsnetzwerk auch der DNS-Server drauf, und er versucht jetzt erstmal, für eine gegebene IP die MAC-Adresse zu kriegen. Das wäre also hier die 192.168.100.1, und er möchte dazu die MAC und bittet dann um eine Antwort, an seine eigene IP. Der Domänen-Controller im Paket 2, der antwortet dann auch gleich und sagt nun ja, die 192.168.100.1 liegt an dieser MAC-Adresse. Wie geht es dann weiter, im dritten Paket sucht er dann den entsprechenden Namen des Webservers, den ich aufgerufen habe. Mein Webserver liegt hier an "srv1.train.lernschmiede.de". Und dieses Protokoll, das wollen wir uns jetzt mal kurz genauer anschauen. Wir haben hier unten also den Ethernet-Frame, wir haben das Internetprotokoll und wir haben hier unten das Transportprotokoll auf Schicht 4. Wir können auf Schicht 4 in zwei verschiedenen Varianten arbeiten, einmal verbindungslos und einmal verbindungsorientiert. Und das DNS-Protokoll für die Namensauflösung, das arbeitet verbindungslos, standardmäßig, tatsächlich, und zwar mit dem Protokoll "User Datagram Protocol", das ist das UDP-Protokoll. Gucken wir uns das doch hier mal ein bisschen genauer an. Wir haben hier ziemlich wenige Einstellungen bei so einer verbindungs- losen Kommunikation, und zwar haben wir hier Quellport, Zielport, Länge und eine Prüfsumme, das wars. Es sind also überhaupt keine Mechanismen da, um festzustellen, ob das Paket erfolgreich angekommen ist und dergleichen, das kann ich mit dem UDP-Protokoll überhaupt nicht bestimmen. Vielleicht noch ein Wort, was ist überhaupt ein Port? Ein Port ist im Grunde genommen nichts weiter als eine 16-Bit lange Zahl, das kann man hier unten bei 6 ganz gut erkennen, und 2 hoch 16 ergibt dann rund 65.000 verschiedene Nummern, und diese Nummern, die repräsentieren also jeweils einen Zugangspunkt auf Layer 4. Und was ist der Sinn und Zweck des Ganzen? Ich möchte mit Hilfe von Ports eine bestimmte Applikation adressieren. Sagen wir mal, wir haben eine IP und ganz viele unterschiedliche Netzwerkapplikationen, die wir ansprechen wollen, dann muss es ja irgendeinen Mechanismus geben, um eine bestimmte Applikation anzusprechen. Und genau dieser Mechanismus ist hier der Port. Also, ich habe hier einen Quellport, und ich habe einen Zielport, auf dem ich eine bestimmte Anwendung adressiere. An den Quellport wird dann natürlich die Antwort geschickt. Der Zielport von DNS ist Port 53, wir haben insgesamt wie gesagt über 65.000. Davon sind die ersten 1023, also bis 1023 sind die Ports standardisiert, von der IANA, das heißt zum Beispiel Port 53 ist DNS, Port 80 ist HTTP, Port 443 ist HTTPS, aber letzten Endes geht es immer nur darum, welchen Port spreche ich an und auf welchem Port lauscht eine entsprechende Applikation im Netzwerk, und wenn sich die beiden Kommunikations- teilnehmer über die Ports einig sind, dann muss ich auch nicht mit standardisierten Ports arbeiten, oder ich müsste es nicht, aber sinnvoll ist das Ganze natürlich schon. Dann haben wir hier wie gesagt noch eine Längenangabe und eine Prüfsumme, und das wars auch schon beim UDP-Protokoll, und anschließend kommt dann gleich das Applikationsprotokoll, das Anwendungsprotokoll mit den verschiedenen Einstellungen, die dann der DNS-Abruf beherbergt. Kommen wir wieder zurück zum Paket Nummer 4, also der DNS-Server antwortet dann dem Client: "Pass mal auf, das was du suchst, das liegt an der 192.168.100.5. Da liegt der Server 1, da liegt dein (...)Server." Dann kommen wir hier zum nächsten Paket, und zwar zu einer TCP-Verbindung. HTTP, das ich dann ein Stückchen später aufrufen will, basiert auf TCP. TCP ist jetzt ein verbindungs- orientiertes Protokoll, und das bedeutet, es werden also Mechanismen bereit gestellt, die eine Verbindung strukturiert aufbauen, die Verbindung erhalten und im besten Fall auch wieder strukturiert abbauen. Und den strukturierten Aufbau, den sehen wir jetzt gleich hier, also im Vergleich jetzt zu UDP, hier oben bei DNS, ist es hier so, dass zunächst mal ein so genannter "3-Wege-Handshake" durchgeführt wird. Damit sagen sich die Clients: "Pass mal auf, ich würde gerne mit dir kommunizieren." Dann sagt der andere: "Ja, alles klar, wunderbar!", und der dritte bestätigt nochmal: "Alles klar, ich hab' dein Ja gehört." Und das passiert hier, beim 3-Wege-Handshake werden hier noch überhaupt keine Daten angehangen, sondern es wird zunächst mal ein TCP-Paket geschickt mit einem gesetzten SYN-Flag. Das SYN-Flag, das können wir auch hier unten beobachten, sagen wir mal: "Das TCP-Protokoll erweitern", da haben wir hier unten die so genannten Flags, das sind also Bits die ich setzen kann im Protokoll, oder nicht, und eins davon ist eben das SYN-Flag an einer bestimmten Position, und wenn ich dort das Bit auf "1" setze, dann ist das Flag sozusagen gesetzt. Ja, und was bedeutet das jetzt? Er sagt also: "Ich würde gerne mit dir synchronisieren, lieber Server", und das ganze passiert jetzt hier nicht nur mit dem gesetzten SYN-Flag, sondern auch noch einer so genannten Sequenznummer, und diese Sequenznummer, das wär jetzt die "0", und auf die bezieht sich dann nachher die Antwort. Danach sieht man hier ganz gut: Der Server hat die Anfrage bekommen, und er hat ganz offensichtlich die MAC-Adresse meines Clients noch nicht abgespeichert, deswegen fragt er erstmal ins Netz: "Moment mal, ich benötige erstmal die MAC-Adresse! Von der 153 bitte an mich, ich selber von meinem Client aus gebe ihm dann hier mit Hilfe eines ARP-Replys die MAC-Adresse." Danach geht's weiter im TCP-3-Wege-Handshake. Im zweiten Abschnitt schickt der Server an den Client ein gesetztes ACK-Flag. Dieses "Acknowledge-", also Bestätigungs-Flag, das bezieht sich auf das vorher gesendete SYN-Flag. Außerdem gibt es eine Nummer, und zwar die so genannte "Acknowledgment Number". Das ist die Nummer, die vorher "0" war, plus 1. Also, wenn wir das mal abstrakt betrachten, wenn die Sequenznummer in der Anfrage ein "x" war, dann ist die Acknowledge-Nummer "x + 1". Und das wäre hier tatsächlich auch die "1". Außerdem setzt er ein eigenes SYN-Flag, das kann man hier unten gut beobachten, indem er seinerseits eine Synchronisierung aufbaut, und für diese SYN-Flag gibt's dann auch wieder eine eigene Sequenznummer. Die setzt er hier auch auf "0". Das ist der zweite Abschnitt im 3-Wege-Hangshake, und der dritte Abschnitt, der geht dann hier weiter mit einem letzten ACK-Paket, das wiederum der Client dem Server schickt. Also, er schickt jetzt keine neue SYN mehr sondern er bestätigt das ACK-Paket und schickt einerseits eine Sequenznummer, die die vorherige Sequenznummer in Schritt 2 bestätigt. Das war ja auch eine "0", also zählt er einen Wert drauf und schickt die relative Sequenznummer "1" wieder zurück, und er bestätigt auch nochmal die Acknowledge-Nummer, und zwar genau gleich, wie er sie vorher bekommen hat, und deswegen bleibt das hier eine "1", wird keine "2", das ist dann ein so genanntes "ACK-Forwarding". Er bestätigt also einfach nochmal die in Schritt 2 erhaltene Nummer, indem er sie hier nochmal zurück schickt. Ja, und das ist auch schon der TCP-3-Wege-Handshake, und anschließend geht es los mit einem Abruf von dieser HTTP-Seite, das ist also hier ein HTTP-GET-Request, und wie wir sehen, haben wir auch hier Source-Ports, Destination-Ports, diese ganzen Sequenznummern, haben wir extrem viele Header-Daten, die alle dafür da sind, den Datenfluss bei TCP zu erhalten und gegebenenfalls bei Fehlern wieder aufzunehmen. Wie funktioniert das Ganze aus der Vogelperspektive? Nach dem 3-Wege-Handshake werden also Pakete geschickt, dazu gibt's einen Puffer, und innerhalb dieses Puffers werden die Pakete abgespeichert, das ist das so genannte "Sliding Window". Das Sliding Window, das wird hier auch gleich mit angegeben, welche Größe also das Sliding Window im Augenblick hat, darüber sprechen sich die beteiligten Kommunikationspartner ab, und dann werden die Pakete eben los geschickt, aber parallel dazu im Pufferspeicher gehalten. Und erst wenn eine Bestätigungsmeldung vom entsprechenden Gegenüber kommt, dass das Paket auch angekommen ist, erst dann werden die nächsten Pakete in den Pufferspeicher rein geladen. Es gibt hier noch wirklich sehr viele Optionen, sehr viele Einstellungsmöglichkeiten, TCP-betreffend, das sprengt so ein Video-Training auf allen Ebenen, daher belassen wir das an der Stelle dabei. Danach geht also die HTTP-Datenverbindung los, ich könnte sie jetzt hier auch noch beobachten, er setzt sie mir hier zusammen in dem TCP-Datenstrom, ich sehe also den kompletten Quelltext, den ich mir hier runterlade, inklusive dem Bild, das hier aufgeschlüsselt ist, PNG-Bild. Wenn ich sehen möchte, welche Verbindungen TCP-seitig gerade geöffnet sind, dann kann ich folgenden Befehl verwenden. Dazu gehe ich mal ganz kurz hier nochmal rein, in den "Internet Information Server" und öffne ihn und verbinde mich kurz auf den Server 1 und gebe ein: "netstat -n" Es gibt ganz viele Befehle, wie man sieht, sind hier unterschiedliche Sockets, also IP-Adresse + Ports geöffnet, und es sind auch Verbindungen hergestellt, zum Beispiel hier auf Port 80 und 3389, das ist meine Remote-Desktop-Verbindung, und andere Ports, die warten im Augenblick auf Verbindung, das heißt, wenn eine Applikation auf einen bestimmten Port hört, dann sagt man auch: Der Port ist offen. Das war der Ablauf von so einer HTTP-Verbindung aus der Vogelperspektive und anhand von Wireshark.

Netzwerkgrundlagen

Lassen Sie sich die grundlegenden Netzwerktechniken erklären und erfahren Sie anhand vieler Beispiele, wie Netzwerke in der Praxis aufgebaut werden und wie sie funktionieren.

6 Std. 38 min (63 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!