TCP/IP

TCP (Transmission Control Protocol) übernimmt dabei eine gewisse Fehlerkontrollfunktion. Es versieht jedes Paket mit einem so genannten Header (vorstellbar als Checksumme mit zusätzlichen Daten) und kümmert sich darum, dass sozusagen jedes "Bit" korrekt ankommt. Stellt "TCP" am Zielrechner fest, dass die Daten Fehler beinhalten oder auch Datenpakete einfach nicht in einer bestimmten Zeit angekommen sind, werden die Daten automatisch erneut angefordert. Anwendungen, die auf vollständige und korrekte Übertragung angewiesen sind, greifen auf das TCP Protokoll zurück.

Um während des Sendens nicht jedes Paket bei erfolgreicher Übertragung einzeln zu bestätigen (wie beim IPX-Protokolk), wird die "sliding-window" Technik eingesetzt. Daten werden zu einem so genannten Fenster (window) zusammengefasst und gesendet. Der Empfänger stellt ebenfalls ein solches Fenster bereit, in dem die Pakete richtig zusammengesetzt werden. So lassen sich gleich mehrere Pakete auf einmal bestätigen. Ist ein "window" bestätigt, verschiebt sich das Fenster (sliding) und das nächste Fenster wird gesendet/abgearbeitet.

TCP arbeitet verbindungsorientiert, d.h. es wird zwischen Sender und Empfänger eine logische Punkt-zu-Punkt (point to point) Verbindung aufgebaut. Dazu wird vor dem Senden der eigentlichen Daten ein so genannter 3-Way-Handshake ausgeführt:

  1. Der Sender sendet an die Zielstation eine Aufforderung (SYN-Flag) samt einer "Initial Sequenznumber" (einer Art Kontrollnummer).
  2. Der Zielhost - wenn empfangsbereit - erhöht die Sequenznummer um 1 und bestätigt den Erhalt durch Setzen des ACK-Flags und schickt seinerseits eine Sequenznummer und ein SYN-Flag zurück.
  3. Der Sender erhält die Bestätigung (ACKnowledgement) der Zielstation (die um 1 erhöhte Kontrollnummer) und bestätigt wiederum, durch Setzen des ACK-Flags und Erhöhen der erhaltenen Sequenznummer des Zielhosts, die Daten und seine Sendebereitschaft.

Danach fängt die Datenübertragung an.

Das UDP Protokoll (User Datagram Protokoll, Layer 4 des ISO/OSI-Modells - Transportservice) funktioniert ähnlich zum TCP Protokoll, ist jedoch verbindungslos, benutzt keine Fehlerkontrolle und sorgt sich auch nicht darum, ob das Paket überhaupt ankommt bzw. in welcher Reihenfolge (also verbindungslos, transaktionorientiert ).

D.h. wiederum, dass sich die höheren Netzwerkschichten um dies kümmern müssen (Beispiel: siehe DHCP discovery packet). In einem UDP-Paket werden unter anderem der Source-Port und Destination-Port angegeben, mithilfe dieses Mechanismus lassen sich Netzwerksdienste zuordnen.
(z.B. Live-Streaming setzt auf UDP, da meist verlorengegangene Packete auch nicht mehr angefordert werden können, bzw. das eventuell gar keinen Sinn machen würde).

Beim Transport über die TCP/IP-Schichten (Layers) wird auch das verwendete Protokoll und eine Portnummer mitgespeichert. Sind die Daten letztendlich beim Zielhost angekommen, entscheidet der Zielhost auf Grund der Protokollnummer und der Portnummer welcher Anwendungen er die Daten weiterreicht.

Protokoll 6 steht dabei z.B. für TCP und 17 für UDP: Liste (IANA)

Erst durch Portnummer und Protokollnummer sind die Daten eindeutig eine Anwendung zuordenbar.

Protokoll 6 und Port 80 wäre eine Standardverbindung zu einem Webserver (http). Protokoll 6 und Port 23 zu einem Telnetserver und Protokoll 6 und Port 21 zu einem FTP Server. Die Server müssen aber nicht unbedingt auf den Standardports (well know ports) laufen.

Die Kombination aus IP-Adresse und Port wird allgemein als Socket bezeichnet. Bei der Kommunikation über TCP/IP, die ja verbindungsorientiert ist, kommt eine Verbindung durch einen Socket am Zielrechner und einem zugehörigen Socket am Quellrechner zustande. Vorstellen lässt sich das als Kanal zwischen den beiden Einheiten.