Frage zu TCP IP

Message

Felix2000 · #1 Post by **Felix2000** » 06. Oct 2008 14:43

Hallo !

Ich bin neu in eurem Forum und hoffe, ihr könnt mir eine Frage zu dem TCP/IP Model erläutern.

Also ich habe folgende Szenarien und möchte gerne wissen, ob ich mit meinen Vermutungen richtig liege.

1. Ich fordere von einem Server die http-Dienst auf Port 80 an, aber dieser ist dort nicht verfügbar. Ich vermute, dass ich über das ICMP Protokoll der IP Schicht eine Fehlermeldung auf meinem Browser ausgegeben bekomme. Es liegt dann an mir nochmal den Dienst aufzurufen. Der Browser tut das nicht automatisch.

2. Ich möchte mir auf einem bestimmten Rechner eine Datei via ftp-Dienst herunterladen. Der Rechner, auf dem die datei liegt bietet auf den FTP Dienst an, allerdings kommt nicht jedes einzelne TCP Fragment auf der virtuellen Punkt zu Punkt Verbindung durch, weil irgendwo ein oder mehrere Router überlastet und vielleicht gar nicht funktionieren. Ich vermute das ich keine Meldung auf meinem Browser ausgegeben bekomme und nicht über die vielleicht fehlenden Pakete informiert werde, sondern zum Schluß eine datei auf meinem PC liegen habe, die nicht einwandfrei oder vielleicht sogar gar nicht funktioniert.

3. Fast ein ähnliches Szenario wie der 2te Fall, allerdings ist die gewünschte Datei nicht auf dem Rechner verfügbar und kann über ftp nicht heruntergeladen werden. Hier bekomme ich über ICMP eine Fehlermeldung auf meinem Browser ausgegben und es liegt wieder bei mir, den Dienst manuell aufzurufen, das es nicht automatisch passiert.

Wäre super wenn ihr mir ein Feedback geben könntet.

MFG und danke

Janka · #2 Post by **Janka** » 06. Oct 2008 15:04

Felix2000 wrote: 1. Ich fordere von einem Server die http-Dienst auf Port 80 an, aber dieser ist dort nicht verfügbar. Ich vermute, dass ich über das ICMP Protokoll der IP Schicht eine Fehlermeldung auf meinem Browser ausgegeben bekomme.

HTTP funktioniert per TCP. Horcht an einem TCP-Port kein Server-Socket und wird an diesen Port eine Verbindungsaufforderung geschickt, ist das Resultat ein ICMP Type 3, Code 3 (Port unreachable)

Es liegt dann an mir nochmal den Dienst aufzurufen. Der Browser tut das nicht automatisch.

Kommt drauf an. Downloadmanager probieren es beispielsweise später noch einmal.

Antwortet der HTTP-Server z.B. mit einer Fehlermeldung (z.B. 301 Moved Permanently), so war der Datenaustausch auf TCP-Ebene ja erfolgreich. Der Browser soll die angeforderte Datei also von einer anderen URI laden. Standardkonforme Browser tun das dann auch gleich.

2. Ich möchte mir auf einem bestimmten Rechner eine Datei via ftp-Dienst herunterladen. Der Rechner, auf dem die datei liegt bietet auf den FTP Dienst an, allerdings kommt nicht jedes einzelne TCP Fragment auf der virtuellen Punkt zu Punkt Verbindung durch, weil irgendwo ein oder mehrere Router überlastet und vielleicht gar nicht funktionieren. Ich vermute das ich keine Meldung auf meinem Browser ausgegeben bekomme und nicht über die vielleicht fehlenden Pakete informiert werde, sondern zum Schluß eine datei auf meinem PC liegen habe, die nicht einwandfrei oder vielleicht sogar gar nicht funktioniert.

Nein. FTP beruht auf TCP und TCP stellt die Integritaet der übertragenden Daten sicher. Es funktioniert wie ein Rohr, und falls das Rohr bricht, erhält man auch eine Fehlermeldung. Es können keine Pakete unbemerkt "fehlen", weil sie durchnummeriert sind und es einen Endemarker (TCP FIN) gibt.

3. Fast ein ähnliches Szenario wie der 2te Fall, allerdings ist die gewünschte Datei nicht auf dem Rechner verfügbar und kann über ftp nicht heruntergeladen werden. Hier bekomme ich über ICMP eine Fehlermeldung auf meinem Browser ausgegben und es liegt wieder bei mir, den Dienst manuell aufzurufen, das es nicht automatisch passiert.

Nein. ICMP gibt nur eine Meldung zurück, wenn auf der anderen Seite ein Server auf diesem Port nicht läuft. Ist eine Datei nicht vorhanden, wird dies vom FTP-Server ganz regulär über die TCP-Kontrollverbindung von FTP (FTP ist ein kompliziertes Protokoll!) mitgeteilt.

Ein Downloadmanager würde auch hier wieder später einen zweiten Versuch starten.

Janka

Felix2000 · #3 Post by **Felix2000** » 06. Oct 2008 15:57

Janka wrote:
Felix2000 wrote: 1. Ich fordere von einem Server die http-Dienst auf Port 80 an, aber dieser ist dort nicht verfügbar. Ich vermute, dass ich über das ICMP Protokoll der IP Schicht eine Fehlermeldung auf meinem Browser ausgegeben bekomme.
HTTP funktioniert per TCP. Horcht an einem TCP-Port kein Server-Socket und wird an diesen Port eine Verbindungsaufforderung geschickt, ist das Resultat ein ICMP Type 3, Code 3 (Port unreachable)

Ok aber diese Meldung bekomme ich im Web-Browser angezeigt? das war die eigentliche Frage.

Es liegt dann an mir nochmal den Dienst aufzurufen. Der Browser tut das nicht automatisch.
Kommt drauf an. Downloadmanager probieren es beispielsweise später noch einmal.

Antwortet der HTTP-Server z.B. mit einer Fehlermeldung (z.B. 301 Moved Permanently), so war der Datenaustausch auf TCP-Ebene ja erfolgreich. Der Browser soll die angeforderte Datei also von einer anderen URI laden. Standardkonforme Browser tun das dann auch gleich.

2. Ich möchte mir auf einem bestimmten Rechner eine Datei via ftp-Dienst herunterladen. Der Rechner, auf dem die datei liegt bietet auf den FTP Dienst an, allerdings kommt nicht jedes einzelne TCP Fragment auf der virtuellen Punkt zu Punkt Verbindung durch, weil irgendwo ein oder mehrere Router überlastet und vielleicht gar nicht funktionieren. Ich vermute das ich keine Meldung auf meinem Browser ausgegeben bekomme und nicht über die vielleicht fehlenden Pakete informiert werde, sondern zum Schluß eine datei auf meinem PC liegen habe, die nicht einwandfrei oder vielleicht sogar gar nicht funktioniert.
Nein. FTP beruht auf TCP und TCP stellt die Integritaet der übertragenden Daten sicher. Es funktioniert wie ein Rohr, und falls das Rohr bricht, erhält man auch eine Fehlermeldung. Es können keine Pakete unbemerkt "fehlen", weil sie durchnummeriert sind und es einen Endemarker (TCP FIN) gibt.

Ok auch hier nochmal explizit die Frage. Bekomme ich in meinem Browser eine Fehlermeldung angezeigt?

3. Fast ein ähnliches Szenario wie der 2te Fall, allerdings ist die gewünschte Datei nicht auf dem Rechner verfügbar und kann über ftp nicht heruntergeladen werden. Hier bekomme ich über ICMP eine Fehlermeldung auf meinem Browser ausgegben und es liegt wieder bei mir, den Dienst manuell aufzurufen, das es nicht automatisch passiert.
Nein. ICMP gibt nur eine Meldung zurück, das auf der anderen Seite ein Server auf diesem Port nicht läuft. Ist eine Datei nicht vorhanden, wird dies vom FTP-Server ganz regulär über die TCP-Kontrollverbindung von FTP (FTP ist ein kompliziertes Protokoll!) mitgeteilt.

Ein Downloadmanager würde auch hier wieder später einen zweiten Versuch starten.

Gut wie genau sieht denn eine solche Fehlermeldung aus?

Janka

Danke für dein posting

PDA · #4 Post by **PDA** » 06. Oct 2008 21:09

Wie ein Browser auf Fehler reagiert hängt ja vom verwendeten Browser ab.
Der empfängt die Status Codes und verarbeitet diese entsprechend (seiner Programmierung).
Das gilt auch für jedes andere Programm wie FTP-Klient, Downloadmanager oder andere.

Zu der FTP Fehlermeldung. Es kommt ja darauf an warum die Datei nicht (oder nicht mehr) verfügbar ist.
Dafür gibt es die FTP Status Codes

Felix2000 · #5 Post by **Felix2000** » 07. Oct 2008 9:01

Also zugegebener Maßen bin ich auf diesem Gebiet neu ein ziemlicher Laie, habe lediglich etwas bei wikipedia und aus einem Anfängerbuch aufgeschnappt.

"HTTP funktioniert per TCP. Horcht an einem TCP-Port kein Server-Socket und wird an diesen Port eine Verbindungsaufforderung geschickt, ist das Resultat ein ICMP Type 3, Code 3 (Port unreachable) "

Meinst Du hier mit Server Socket die Anwendung auf dem Server, welche automatisch auf einem bestimmten Port und IP-Adresse auf einen Kommunikation wartet?

Und nochmal kurz zu dem ICMP Protokoll. Wie genau sieht eigentlich eine solche ICMP fehlermeldung aus?

Gibt es eigentlich eine Software, mit der ich mich etwas mit der Thematik beschäftigen könnte?

Janka · #6 Post by **Janka** » 07. Oct 2008 12:06

Felix2000 wrote:
Janka wrote: HTTP funktioniert per TCP. Horcht an einem TCP-Port kein Server-Socket und wird an diesen Port eine Verbindungsaufforderung geschickt, ist das Resultat ein ICMP Type 3, Code 3 (Port unreachable)
Meinst Du hier mit Server Socket die Anwendung auf dem Server, welche automatisch auf einem bestimmten Port und IP-Adresse auf einen Kommunikation wartet?

"Sockets" sind die Unix-Typischen Verwaltungseinheiten für bidirektionale Verbindungen. Linux nutzt Sockets für Netzwerkverbindungen, aber auch als Pipe-Ersatz und für bestimmte Sonderdienste.

Es gibt bei TCP zwei Arten von Sockets. Solche, die auf eine eingehende Verbindung warten, das sind die Server Sockets. Dann noch Sockets, über die dann die eigentliche Kommunikation läuft.

Und nochmal kurz zu dem ICMP Protokoll. Wie genau sieht eigentlich eine solche ICMP fehlermeldung aus?

Der Client-Prozess, der ebenfalls einen TCP-Socket geöffnet hat, bekommt eine Fehlermeldung (der Systemaufruf schlägt fehl), wenn dieser nicht mit dem angeforderten Server-Socket verbunden werden kann. Von ICMP sieht er nichts. Auf der Netzwerkebene sind ICMP-Pakete Pakete wie andere auch. In jedem Datenpaket steht im Kopf das Protokoll, in dem dieses Paket kodiert ist.

Gibt es eigentlich eine Software, mit der ich mich etwas mit der Thematik beschäftigen könnte?

Lies ein gutes Buch, z.B. Advanced Programming in the Unix Environment von W. Richard Stevens. Da sind auch 'ne Menge Beispiele drin. Uni-Bibliotheken haben dieses Buch meist sogar vorrätig.

Software: tcpdump, wireshark

Janka

PDA · #7 Post by **PDA** » 07. Oct 2008 18:31

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

FI Netzwerk Grundlagen

Felix2000 · #8 Post by **Felix2000** » 07. Oct 2008 20:03

Ok danke erstmal bis hierhin. Das was ihr bisher geschrieben habt, hat mir schon sehr weitergeholfen. Eine Frage habe ich noch:

Ich gehe jetzt mal davon aus, dass irgendwo auf einem Server eine Datei liegt und ich plane diese herunterzuladen.

Also wenn eine TCP Verbindung über den 3 Wege Handshake mit einem Server-Socket bzw. dem Anwendungsprozeß aufgebaut wurde, wird während des "eigentlichen" Datenaustausches eigentlich immer noch jedes TCP Paket quittiert oder kann ich einstellen, dass nicht jedes Paket innerhalb dieser Verbindung quittiert wird (hätte ja evtl. Geschwindigkeitsvorteile) oder wird vielleicht gar kein Paket quittiert. Wie ist die Voreinstellung?

Oder ist das bei TCP Quatsch und nur bei UDP noch Bedeutung?

PDA · #9 Post by **PDA** » 07. Oct 2008 20:58

Wie stellt man das denn ein?
Mit dem Protokoll komme ich doch nicht in Berührung.
Siehe bitte den Link, da siehst du das Schichten Modell.
TCP regelt das alles selbst, das kann man zwar nicht als "Voreinstellung" bezeichnen, da gibt es nichts einzustellen (zumindest nicht so wie du dir das vorstellst), das ist so weil es so implementiert ist.

Diese Grundlagen werden dort aber erklärt.

Janka · #10 Post by **Janka** » 07. Oct 2008 22:18

Felix2000 wrote: Also wenn eine TCP Verbindung über den 3 Wege Handshake mit einem Server-Socket bzw. dem Anwendungsprozeß aufgebaut wurde, wird während des "eigentlichen" Datenaustausches eigentlich immer noch jedes TCP Paket quittiert oder kann ich einstellen, dass nicht jedes Paket innerhalb dieser Verbindung quittiert wird (hätte ja evtl. Geschwindigkeitsvorteile) oder wird vielleicht gar kein Paket quittiert. Wie ist die Voreinstellung?

Jedes Paket wird quittiert, allerdings schickt der Sender schon weitere Pakete los, bevor er eine Quittung für das jeweils letzte Paket erhalten hat. Jeder der beiden TCP-Teilnehmer muss also eine Liste der noch nicht quittierten Pakete führen. Es bringt nichts, die Quittierung auszuhebeln, deshalb ist das auch nicht abschaltbar.

Wenn man an solchen Dingen herumspielen will, ist TCP einfach nicht die richtige Wahl. TCP ist ein funktionierendes Fertigrohr. Wenn man selber ein Protokoll basteln will, nimmt man lieber UDP als Grundlage oder gleich IP.

Oder ist das bei TCP Quatsch und nur bei UDP noch Bedeutung?

Bei UDP gibt es keinen 3-Way-Handshake und auch keine Quittierung. Es gibt übrigens noch viele andere Protokolle, zum Beispiel RDP. Guck in /etc/protocols und dann in die dort angemerkten RFCs, um mehr zu erfahren.

Janka

Felix2000 · #11 Post by **Felix2000** » 08. Oct 2008 12:34

@PDA

Danke für Deinen Post, leider sehe ich den Link nicht, auf den Du Dich beziehst. Könntest Du den bitte nochmal nachträglichen posten? Besten Dank !

@Janka

Auch Dir erstmal recht herzlichen Dank für die Antworten. Leider nutze ich WinXP, somit wird das wohl unter etc/protocolls mit dem reinschauen nicht klappen.

Nochmal kurz eine andere Frage an Dich: Könntest Du mir vielleicht nochmal 2 beispiele nennen, in denen ich eine Fehlermeldung durch das Protokoll ICMP der IP-Schicht erhalte? Du hattest schon einmal ein Bsp. genannt, nämlich das mit dem srevers Socket ganz zu Beginn meines Themas hier. Ich glaube zwei weitere Beispiel würden mir helfen, die Sache noch deutlicher abzugrenzen.

Besten Dank !

Janka · #12 Post by **Janka** » 08. Oct 2008 18:21

Der Link von PDA befindet sich einen Post darüber...

Felix2000 wrote: Leider nutze ich WinXP,

Dann wird es höchste Zeit, dies zu ändern. Damit das "Leider" aus deinem Gesicht verschwindet... Ist ja nicht so, dass du mit MS-Windows verheiratet wärst oder so...

somit wird das wohl unter etc/protocolls mit dem reinschauen nicht klappen.

Oh doch, denn Microsoft hat das komplette TCP/IP-Subsystem von einer alten Unix-Version kopiert. Unter C:\windows\system32\drivers\etc liegt ein passendes /etc-Verzeichnis. Da sollte auch eine "protocols"-Datei drinstehen.

Nochmal kurz eine andere Frage an Dich: Könntest Du mir vielleicht nochmal 2 beispiele nennen, in denen ich eine Fehlermeldung durch das Protokoll ICMP der IP-Schicht erhalte? Du hattest schon einmal ein Bsp. genannt, nämlich das mit dem srevers Socket ganz zu Beginn meines Themas hier. Ich glaube zwei weitere Beispiel würden mir helfen, die Sache noch deutlicher abzugrenzen.

ICMP-Nachrichten aufgrund von Problemen mit TCP-Verbindungen oder UDP-Datagrammen gibt es eigentlich nur vom Typ 3, also wenn kein Kontakt zur Gegenseite aufgebaut werden kann. Mehr dazu hier:http://en.wikipedia.org/wiki/ICMP_Desti ... nreachable
UDP kennt gar keine anderen Fehlerfälle und TCP behandelt andere Fehler (zum Beispiel Abbruch der Verbindung) intern.

Janka

Felix2000 · #13 Post by **Felix2000** » 08. Oct 2008 19:37

Ich hoffe, dass ich nun alles richtig verstanden habe. Vielleicht nochmal ein selbst gewähltes Beispiel von mir:

1. Also ich fordere eine Webseite, z.B. www.pro-linux.de an. So aber hier findet mein Browser bzw. mein Browserprozeß keine Website oder auch keinen Server-Socket an Port 80.

Ich vermute das dann keine erfolgreiche TCP Verbindung aufgebaut werden konnte und evtl. auch ein Fehler der Kategorie 5xx an mich zurückgesendet wird.

2. Vertippe ich mich bspw. bei der folgenden Adresse www.we.de wurde keine erfolgreiche TCP Verbindung aufgebaut und auch keine IP Verbindung aufgebaut, weil der Zielrechner nciht gefunden werden konnte. Ich erhalte dann einen Fehler der Kategorie 4xx.

3. Gebe ich statt www.web.de ww.web.de erhalte ich ganz normal die Website, warum auch immer!? Ich kanns mir nicht erklären. Vielleicht weils standardmäßig im Browser so implementiert wurde.

4. Gebe ich www.testseite.de (aber die Domain ist umgezogen) ein und erhalte eine Meldung der Kategorie 3xx, so wurde eine erfolgreiche TCP Verbindung aufgebaut und an mich ein Hinweis versendet, dass die Seite vielleicht umgezogen ist.

5. Ich will eine datei auf Server XYZ herunterladen, aber diese datei ist nicht dort. Dann wurde trotzdem eine TCP Verbindung korrekt aufgebaut.

Janka · #14 Post by **Janka** » 08. Oct 2008 21:57

Felix2000 wrote:Ich hoffe, dass ich nun alles richtig verstanden habe. Vielleicht nochmal ein selbst gewähltes Beispiel von mir:

1. Also ich fordere eine Webseite, z.B. www.pro-linux.de an. So aber hier findet mein Browser bzw. mein Browserprozeß keine Website oder auch keinen Server-Socket an Port 80.

Ich vermute das dann keine erfolgreiche TCP Verbindung aufgebaut werden konnte und evtl. auch ein Fehler der Kategorie 5xx an mich zurückgesendet wird.

Nein. Fehler 5xx sind HTTP-Fehlercodes. Die bekommst du dann, wenn zwar eine TCP-Verbindung bestand, aber während des Verarbeitens des darin enthaltenen HTTP-Requests ein Fehler auftrat. Der Fehler wird über die korrekt funktionierende TCP-Verbindung ganz normal als TCP-Daten (aber eben als HTTP-Fehlermeldung) übertragen.

2. Vertippe ich mich bspw. bei der folgenden Adresse www.we.de wurde keine erfolgreiche TCP Verbindung aufgebaut und auch keine IP Verbindung aufgebaut, weil der Zielrechner nciht gefunden werden konnte. Ich erhalte dann einen Fehler der Kategorie 4xx.

Nein, du bekommst dann keinen Fehler 4xx, denn auch dies ist ein HTTP-Fehler. Du bekommst eine Fehlermeldung von TCP, dass keine Verbindung aufgebaut werden konnte.

3. Gebe ich statt www.web.de ww.web.de erhalte ich ganz normal die Website, warum auch immer!? Ich kanns mir nicht erklären. Vielleicht weils standardmäßig im Browser so implementiert wurde.

Weil der Rechner ww.web.de existiert.

4. Gebe ich www.testseite.de (aber die Domain ist umgezogen) ein und erhalte eine Meldung der Kategorie 3xx, so wurde eine erfolgreiche TCP Verbindung aufgebaut und an mich ein Hinweis versendet, dass die Seite vielleicht umgezogen ist.

Genau. Das wäre dann eine HTTP-Fehlermeldung, die dem Browser einen Hinweis gibt, was er tun soll, um das Problem zu beseitigen.

5. Ich will eine datei auf Server XYZ herunterladen, aber diese datei ist nicht dort. Dann wurde trotzdem eine TCP Verbindung korrekt aufgebaut.

Richtig. Du bekommst bei HTTP eine Fehlermeldung "404 Datei nicht gefunden" innerhalb der TCP-Verbindung übertragen.

Jetzt kannst du natürlich noch die Frage stellen: Wie unterscheidet HTTP Fehlermeldungen und Daten? Dazu solltest du dir das RFC zu HTTP angucken.

Janka

Felix2000 · #15 Post by **Felix2000** » 09. Oct 2008 14:06

Sauber Janka, Du hilfst mir wikrlich sehr weiter mit Deinen ausführlichen Antworten. Ich hab mich zwar nun schon einige Male bedankt, tue es aber dennoch wieder.

Einmal muss nochmal nachhaken:

Ich habe geschrieben:

2. Vertippe ich mich bspw. bei der folgenden Adresse www.we.de wurde keine erfolgreiche TCP Verbindung aufgebaut und auch keine IP Verbindung aufgebaut, weil der Zielrechner nicht gefunden werden konnte. Ich erhalte dann einen Fehler der Kategorie 4xx.

Janka hat geschrieben:

Nein, du bekommst dann keinen Fehler 4xx, denn auch dies ist ein HTTP-Fehler. Du bekommst eine Fehlermeldung von TCP, dass keine Verbindung aufgebaut werden konnte.

Meine Nachfrage:

Da www.we.de nicht existiert kann doch das DNS Protokoll den String "www.we.de" gar nicht in eine reine IP Adresse umwandeln oder verstehe ich das falsch? Deswegen auch meine Vermutung, das die IP Schicht nicht korrekt arbeiten kann.

Ich habe geschrieben:

3. Gebe ich statt www.web.de ww.web.de erhalte ich ganz normal die Website, warum auch immer!? Ich kanns mir nicht erklären. Vielleicht weils standardmäßig im Browser so implementiert wurde.

Janka hat geschrieben:

Weil der Rechner ww.web.de existiert.

Meine Nachfrage:

Verstehe ich richtig, dass das www vor web.de eigentlich überflüssig ist und standardmäßig bei solchen fehlerhaften Eingaben immer Port 80, also http, angesprochen wird? Gebe ich wwww.web.de bekomme ich ebenfalls die korrekte Internetseite angezeigt.

Grundsätzlich:

Danke nochmal, dass du erklärt hast das die Fehler 404 usw. Fehlermessages im http-Protokoll sind. das war mir gar nicht so bewusst.

Anhand dieser ganzen Theorie kann man mal sehen, was das Internet für eine tolle und zuverlässige Erfindung ist. es ist schon toll mal hinter die Kulissen zu schauen, um zu verstehen, was man da eigentlich tagtäglich benutzt.

Pro-Linux

Frage zu TCP IP

Frage zu TCP IP

Re: Frage zu TCP IP