Frage zu TCP IP

[Janka]

1. Welchen Abschnitt extrahiert der Browser aus der URL zur Bestimmung der IP Adresse des Rechners, auf dem der Webserver läuft?

Meine Antwort: www.themenbearbeitung.de

Ja. Alles hinter dem // (oder ab dem ersten @, falls vorhanden) bis zum ersten : oder / oder Ende.

2. Wozu dient der Abschnitt "http" in der URL

Meine Antwort: Zur Identifikation des zu verwendenden Protokolls. Damit TCP weiß, an welche Anwendungsschicht der Request beim Server weitergegeben werden muss.

Ja. Und mit dem Protokoll wird auch der Port festgelegt. Es sei denn, man hat im Server-Feld der URL einen : und danach eine gültige Portnummer angegeben, dann wird der angegebene Port verwendet.

3. Wozu dienen die aus 1 und 2 gewonnenen Informationen?

Meine Antwort: Mit IP und Portnummer kann nun ein Socket erzeugt werden, die Daten werden in einem TCP Paket verpackt und auf die Reise geschickt.

Lokal wird ein Socket erzeugt, dieser wird mit einem TCP-Socket verbunden, der am angegebenen Port auf dem angegebenen Rechner auf eingehende Verbindungen horcht.

Nachdem die Verbindung aufgebaut ist, wird ein HTTP-Request auf dieser Verbindung als Daten geschickt. Daraufhin sendet der Webserver auf derselben Verbindung einen HTTP-Response zurück. Danach wird die Verbindung wieder geschlossen (Ausnahme: Persistente Verbindungen für mehrere folgende, aber trotzdem weiterhin unabhängige HTTP-Requests/Responses; dies dient zur Geschwindigkeitssteigerung)

4.Woher weiß der Webserver, dass eine Seite zu laden und an den Browser zu senden ist? Wie identifiziert er die Seite?

Meine Antwort: Er erkennt dieses an der vom Client übergebenen Portnummer und den Rest der URL. Er identifiziert die Seite an seiner Endung, also bspw. html oder pdf

Nur im einfachsten Fall. Ein Webserver kann auch komplett datenbankbasiert sein, dann wird der zu einem Dokument gehörige Content-Type häufig ebenfalls in der Datenbank gespeichert. Oder man macht das verzeichnisabhängig. Alles eine Einstellungssache.

5. Weiß der Browser, ob es sich bei der angeforderten Seite um eine statische oder dynamische Seite handelt?

Meine Antwort: Nein das weiß er nicht !

Wissen kann er es nicht, aber ahnen. Dynamisch generierte Seiten enthalten aus naheliegenden Gründen das Headerfeld "pragma: no-cache" oder ähnliche. Siehe
http://www.w3.org/Protocols/rfc2616/rfc ... ml#sec14.9

Janka

[Felix2000]

Ja. Alles hinter dem // (oder ab dem ersten @, falls vorhanden) bis zum ersten : oder / oder Ende.

Also meinst Du damit den kompletten URL String "http://www.themenbearbeitung.de/veroeff ... iten/2008/" und nicht nur "www.themenbearbeitung.de"


4.Woher weiß der Webserver, dass eine Seite zu laden und an den Browser zu senden ist? Wie identifiziert er die Seite?

Du hast von "Verzeichnisabhängigkeit" gesprochen, was genau meinst du damit. Mit "Content-Type" kann ungefähr ahnen, was du meinst, aber 100%ig sicher bin ich mir auch nicht. Falls diese Dinge nicht zu komplex zu erklären sind, wäre ich dir sehr dankbar, wenn du nochmal kurz darauf eingehen könntest.


Ich würde auch gerne soviel über das Thema wissen, wie es bei Dir der Fall ist. Hast Du Dir Dein ganzes Wissen aus Büchern angeeignet?

MFG

[Janka]

Ja. Alles hinter dem // (oder ab dem ersten @, falls vorhanden) bis zum ersten : oder / oder Ende.

Also meinst Du damit den kompletten URL String "http://www.themenbearbeitung.de/veroeff ... iten/2008/" und nicht nur "www.themenbearbeitung.de"

Nein. Ich meine URLs der Form
http://felix@meinedomain.net:8080/irgend/ein/Pfad.
Hier wird meinedomain.net als Servername verwendet.

4.Woher weiß der Webserver, dass eine Seite zu laden und an den Browser zu senden ist? Wie identifiziert er die Seite?

Du hast von "Verzeichnisabhängigkeit" gesprochen, was genau meinst du damit. Mit "Content-Type" kann ungefähr ahnen, was du meinst, aber 100%ig sicher bin ich mir auch nicht. Falls diese Dinge nicht zu komplex zu erklären sind, wäre ich dir sehr dankbar, wenn du nochmal kurz darauf eingehen könntest.

Man kann bei Apache z.B. auch einstellen, dass alle Dateien in einem Verzeichnis html-Dateien sein sollen, egal wie der Dateiname lautet. Das Headerfeld wäre dann "Content-Type: text/html"

Ich würde auch gerne soviel über das Thema wissen, wie es bei Dir der Fall ist. Hast Du Dir Dein ganzes Wissen aus Büchern angeeignet?

Lesen hilft, allerdings gibt es nur wenige wirklich gute Bücher. "Advanced Programming in the Unix Environment" von W.- Richard Stevens gehört dazu. Dann noch die "...in a Nutshell"-Bücher von O'Reilly.

Details liest man am besten in den RFCs nach. Dort ist so ziemlich alles standardisiert, was mit Netzwerken zu tun hat.

Janka

[Felix2000]

Hallo Janka !

Könntest Du Dir vielleicht nochmal ein paar Fragen anschauen, zu denen ich Lösungen ausgearbeitet habe? Ich danke dir vielmals für deine Hilfe !!!!

1. Die Verfahren zur Kollisionserkennung bei CSMA/CD erzwingen eine minimale Rahmengröße, vermute aber, dass diese abhängig vom gewählten Netzwerkprotokoll (also bspw. Ethernet, EEEOP, X.25 usw.) und der Netzwerkhardware ist.

Meine Antwort: Ja das tun sie, allerdings kenne ich die Rahmengröße nicht.


2. IP stellt einen verbindungslosen, unzuverlässigen Datengrammdienst bereit. Damit hat der Transportdienst, die TCP Schicht, keine Möglichkeit, den Verlust und Duplikate eines TCP Segments, das gekapselt in einem IP-datengramm durch das Netz transportiert wird, zu erkennen.

Meine Antwort: Ja das stimmt !


3. Überlastungen in einem Paketvermittlungsnetz könennd urch Flusssteuerung (mittels Schiebefenstertechnik) auf der Sicherungsschicht vermieden werden.

Meine Antwort: Weiß ich leider nicht !


4. Endlose kreisende (und damit nicht zustellbare) IP-Datagramme werden von Routern verworfen.

Meine Antwort: Ja das stimmt (das TTL-Feld im IP Header läuft dann langsam gegen 0 zu) und der Sender wird über ICMP darüber informiert, dass das Paket inkl. Rahmen verworfen wurde. Ich vermute, dass der Sender dann nochmal sendet, eben weil der Empfänger nicht quittieren konnte. Wie lange der Sender nochmals den Sendevorgang wiederholt, kann ich vermutlich in den RFC´s nachlesen!?

[Janka]

1. Die Verfahren zur Kollisionserkennung bei CSMA/CD erzwingen eine minimale Rahmengröße, vermute aber, dass diese abhängig vom gewählten Netzwerkprotokoll (also bspw. Ethernet, EEEOP, X.25 usw.) und der Netzwerkhardware ist.

Ethernet ist kein Netzwerkprotokoll, sondern eine Netzwerkhardware. X.25 enthält auch eine Beschreibung der Hardware, aber das verwendet eh kaum noch jemand. Ausnahme ist Packet Radio.

Meine Antwort: Ja das tun sie, allerdings kenne ich die Rahmengröße nicht.

Der Sender muss den anderen Teilnehmern signalisieren können, dass er den Bus belegt hat. Also muss er mindestens so lange senden, bis das erste Bit seiner Sendung alle anderen Teilnehmer erreicht hat. Eine Arbitrierungsfehler, weil ein anderer Teilnehmer seinerseits kurz vor dem Ankommen des ersten Bits mit dem Senden begonnen hätte würde er dann spätestens innerhalb der doppelten Zeit bemerken.

Die minimale Rahmengröße bei Ethernet hängt also von der Ausdehnung des Netzwerkes ab.

Aber es verwendet heutzutage ohnehin niemand mehr (außer mir) 10Base5, 10Base2 oder TP-Hubs. Heutzutage hat man nur noch Punkt-Zu-Punkt-Verbindungen zwischen Switches und Hosts. CSMA-CD ist dabei überflüssig, weil es kein gemeinsames Medium mehr gibt.

2. IP stellt einen verbindungslosen, unzuverlässigen Datengrammdienst bereit. Damit hat der Transportdienst, die TCP Schicht, keine Möglichkeit, den Verlust und Duplikate eines TCP Segments, das gekapselt in einem IP-datengramm durch das Netz transportiert wird, zu erkennen.

Meine Antwort: Ja das stimmt !

Nein. Denke nochmal über diese Aussage nach. Diese fehlenden Funktionen von IP werden über TCP nachgerüstet.

Stell dir vor, du schickst in unregelmäßigen Abständen Postkarten mit ein paar Buchstaben drauf an einen Bekannten. Die Buchstaben ergeben in der richtigen Reihenfolge einen Satz.

Der Bekannte hat keine Möglichkeit festzustellen, ob eine Postkarte fehlt (oder doppelt ist, ok, das ist hier unwahscheinlich). Außerdem weiß dein Bekannter nicht, in welcher Reihenfolge er die Karten hintereinanderlegen muss. Er kann das nur anhand der Ankunftszeit erraten. Das ist das, was IP macht.

Mit TCP würdest du nun einfach zusätzlich eine Nummer auf die Karte schreiben. Nun ist es egal, in welcher Reihenfolge der Bekannte die Karten erhält. Er kann auch feststellen, ob eine fehlt und nochmal anfordern.

Die Nummer wird also eingekapselt in die Karte durch das Posttransportnetz befördert. Genauso mit TCP über IP.

3. Überlastungen in einem Paketvermittlungsnetz könennd urch Flusssteuerung (mittels Schiebefenstertechnik) auf der Sicherungsschicht vermieden werden.

Meine Antwort: Weiß ich leider nicht !

Schiebefenstertechnik? Oh Graus. Wer hat das den zwanghaft eindeutscht? "Congestion Window" heißt der Begriff. Such mal danach

Gemeint ist folgendes: Die Flussteuerung erfolgt nicht wie z.B. bei RS232 mittels zweier Nachrichten "STOP" und "Weiter" vom Empfänger aus. Diese würden den Sender vermutlich nicht rechtzeitig erreichen und es würde sich ein Stop+Go-Staubetrieb ergeben.

Stattdessen kontrolliert der Sender selbst, wie viele Empfangsbestätigungen für gesendete Pakete noch ausstehen. Danach bestimmt er, wann er wieder das nächste Paket losschickt.

4. Endlose kreisende (und damit nicht zustellbare) IP-Datagramme werden von Routern verworfen.

Meine Antwort: Ja das stimmt (das TTL-Feld im IP Header läuft dann langsam gegen 0 zu) und der Sender wird über ICMP darüber informiert, dass das Paket inkl. Rahmen verworfen wurde. Ich vermute, dass der Sender dann nochmal sendet, eben weil der Empfänger nicht quittieren konnte. Wie lange der Sender nochmals den Sendevorgang wiederholt, kann ich vermutlich in den RFC´s nachlesen!?

Die Aussage mit der TTL ist richtig, das ist der Sinn dieses Zählers. IP-Datagramme werden jedoch (zumindest von der IP-Schicht ausgehend) niemals wiederholt. TCP bekommt die TTL-Probleme WIMRE ebenfalls mit und wiederholt auch nicht.

Janka

[Felix2000]

1. Die Verfahren zur Kollisionserkennung bei CSMA/CD erzwingen eine minimale Rahmengröße

3. Überlastungen in einem Paketvermittlungsnetz könennd urch Flusssteuerung (mittels Schiebefenstertechnik) auf der Sicherungsschicht vermieden werden.

Hallo Janka ! Vielen Dank für Deine Antworten ! Trotz deiner ausführlichen Erklärung muss ich hier als Laie nochmal nachhaken. Also Frage 1 und 3 stimmen nicht? Das kann ich Newbie auf diesem Gebiet leider nur schwer aus deinen Antworten herauslesen...Danke Dir

[Janka]

Frage 1 hast du teilweise falsch beantwortet, weil du Informationen eingebaut hast, die so nicht richtig waren, die aber auch nicht gefragt waren. Würde bei einer schriftlichen Prüfung vermutlich einfach weggestrichen werden (je nach Modus), bei einer mündlichen Prüfung ist sowas üblicherweise ein "Falsch".

Frage 3 hast du doch gar nicht beantwortet? Für die Eindeutschung von "Congestion Window" sollte der Prüfer auf jeden Fall was hinter die Löffel bekommen.

Janka

[Felix2000]

also ist Antwort 1 korrekt und Antwort 3 nicht ! Bei Antwort 3 hatte ich gar nicht beantwortet. Stimmt. Hab eben nochmal deine Erklärung durchgelesen, anhand deiner Erklärung lese ich nun heraus, das die Frage falsch ist.

[candykane]

Vielleicht hilft dir das erst einmal weiter, zumal es auch noch kostenlos ist.

FI Netzwerk Grundlagen

Link ist leider nicht mehr aktuell