BS 3

Netzwerkanwendungen laufen auf getrennten Endsystemen, den sogenannten Hosts. Die Endsysteme sind über Kommunikationsleitungen verbunden, sie besitzen ja keinen gemeinsamen Speicher, über den sie direkt lesen oder schreiben könnten. Die prozessübergreifende Kommunikation wird in verteilten (Netzwerk-)Anwendungen daher durch Nachrichtenaustausch über das Netzwerk realisiert.

Das Internet ist ein Verbund aus privaten und öffentlichen Netzwerken. Deshalb wird es auch als Netzwerk aus Netzwerken bezeichnet. Diese bilden zusammen ein „logisches Netzwerk“, das „Internet“. Das Internet ist ein paketvermitteltes Netz. Die Paketvermittlung erlaubt hier die gleichzeitige Nutzung mehrerer alternativer Wege (Routen oder auch Pfade) von A nach B; im einem zentralen oder in einem leitungsvermittelnden Netzwerk hingegen muß eine „Route“ immer gewisse vorgegebene Stellen durchlaufen. Das Internet ist paketvermittelnd und nicht leitungsvermittelnd. Da dieses die Mehrfach-nutzung von Leitungen und die Nutzung alternative Wege gestattet, ist es ausfallsicherer (es entstammt dem ARPANET). Hingegen würde „leitungsvermittelnd“ eine konstante Bandbreite auf Kosten der Ausfallsicherheit während der Verbindung garantieren. Die Internet-Standards sind in den RFCs (Request for Comments) durch die IETF (Internet Engineering Task Force) niedergeschrieben.

Laufen miteinander kommunizierende Anwendungen auf verschiedenen Rechnern, z.B. ein E-Mail-Client/UserAgent (MUA) auf einem PC und ein E-Mail-Serverprogramm auf einem Server, dann spricht man auch von verteilten Anwendungen oder Netzwerkanwendungen. Während bei der zentralen Datenverarbeitung die Verarbeitung der Daten auf einem zentralen Rechner geschieht, werden bei der verteilten Datenverarbeitung die Daten auf mehreren Rechnern arbeitsteilig verarbeitet. Ein klassisches Anwendungsbeispiel der Datenfernverarbeitung sind Flugbuchungssysteme.

Anwendungen für Rechnernetze: Datenverbund (data sharing), Betriebsmittel/Funktions-verbund (ressource sharing), Last/Leistungs/Wartungsverbund, als Kommunikationsmedium zwischen menschlichen Benutzern: WWW, E-Mail, Videokonferenzen, Gruppenarbeit (Computer Supported Cooperative Work).

Lokale Netzwerke (Local Area Network, LAN) wenige km, Stadtnetze/Regionale Netze (MetropolitanArea Network, MAN ca.100km), Weitverkehrsnetze (Wide Area Network, WAN).

Prozesse bzw. ausgeführte Netzwerkanwendungen auf zwei unterschiedlichen Endsystemen kommunizieren miteinander durch den Austausch von Nachrichten über ein Computer-netzwerk. Die Regeln und Konventionen, auf denen die nachrichtenbasierte Netzwerk-Kommunikation aufsetzt, werden Protokolle genannt bzw. durch Protokolle definiert. Ein Protokoll ist eine Vereinbarung zwischen kommunizierenden Parteien über den Ablauf der Kommunikation. Ein Protokoll definiert die Nachrichtentypen (z.B. Anforderungen und Antworten), ihre Syntax (Format/Felder), Semantik (Bedeutung des Inhalts), und die Regeln (wann, wie, in welcher Reihenfolge gesendet/reagiert wird). Protokolle implementieren bzw. realisieren bzw. erbringen Dienste. Bzgl. Schichtenmodell: Ein Protokoll ist eine Menge von Regeln, welche Format und Bedeutung der innerhalb eines Schicht-Dienstes ausgetauschten Nachrichten festlegen. Ein Protokoll dient der Erbringung eines gewünschten Dienstes auf der Basis der Nutzung der untergeordneten vorhandenen Dienste (z.B. bietet die Internet-Transportschicht verteilten Anwendungen auf den Endsystemen zwei Dienste, realisiert durch die Protokolle UDP und TCP an. „TCP“ und „UDP“ benutzen dazu wiederum das Protokoll „IP“ der tiefer gelegenen Vermittlungsschicht).

Die Architektur beschreibt: 1. welche Komponenten das System hat, 2. wie diese im System platziert werden bzw. organisiert sind und 3. wie sie miteinander kommunizieren (wechselwirken).

Das Schichtenmodell ist ein immer wiederkehrendes Muster in der Informatik. Es wird verwendet um die Systemkomplexität und die Implementierung(en) überschaubar zu halten (Transparenz/Verantwortlichkeits-Kapselung). Die Komponenten in Rechnernetzen sind modulare Einheiten wie z.B. Schichten und Protokolle, die Schnittstellen bereitstellen, die wohl definiert und erforderlich sind. Die Protokolle werden verschiedenen Schichten zugeordnet; bei einer geschichteten Protokollarchitektur gehört jedes Proto-koll zu einer bestimmten Schicht. Ein Protokoll der Schicht n definiert also genau die Regeln, mit denen zwei Endsysteme Nachrichten auf der Schicht n (unter Nutzung eines n-1-Schicht-Dienstes) austauschen. Zum Austausch der Nachrichten wird die direkt darunter liegende (untergeordnete) Schicht verwendet. Nur in der untersten „physikalischen“ Schicht findet die eigentliche Kommunikation; d.h. die Nachrichtenübertragung (im physikalischen Raum) statt.

In einem Schichtenmodell stellen höhere Schichten zusätzliche Funktionen zur Verfügung,  wie z.B. Fehlerkorrektur, Weiterleitung oder sichere Verbindungen. Dabei tauschen jeweils zwei Dienste einer Schicht Nachrichten untereinander aus. Tatsächlich werden die entsprechenden Daten nicht direkt physisch von Schicht n eines Rechners zu Schicht n eines anderen übertragen. Vielmehr nutzt eine Schicht dazu den Dienst bzw. einen Dienst der direkt untergeordneten Schicht, den es über einen Dienstzugangspunkt erreicht, welcher auch als Schnittstelle (Interface) bezeichnet wird. Nur in der untersten Schicht findet die eigentliche physische Kommunikation, also die physische Nachrichtenübertragung, statt. Jede Schicht bietet der direkt übergeordneten Schicht Dienste in Form einer Menge von Operationen (oder Programmen) an, dieses Konzept nennt man auch Dienstmodell. Ein Dienst sagt aber nichts darüber, wie diese Operationen implementiert (realisiert) oder ausgeführt werden. Die Definition eines Dienstes sagt nur, was die Schicht leistet (wie sie das tut, braucht den Klient nicht zu interessieren) und die Schnittstelle, wie die direkt darüber liegende Schicht auf den Dienst zugreift.

1. Jede Schicht (oberhalb der Übertragungs-Schicht 1) benutzt Dienste der direkt unter-      geordneten Schicht, den sie jeweils über den Dienstzugangspunkt (= Schnittstelle,      Interface) erreicht, um den von ihr angebotenen Dienst zu erbringen. Eine Schicht      darf die zu sendenden Daten, die am Dienstzugangspunkt eintreffen, mit (normierten)      Headern und Trailern versehen (sozusagen umklammern); d.h. die Daten bzw.      Nachrichten werden somit für die folgende untergeordnete Schicht durch das      Hinzufügen eines (n-)Headers „aufbereitet“, ohne dabei die ursprünglichen Daten zu      verändern.

2. Eine Änderung des Protokolls bzw. der Protokolle einer Schicht hat keinen Einfluß auf die      anderen Schichten, solange die Schnittstellen unverändert bleiben (Transparenz). Ein      Protokoll einer Schicht implementiert bzw. realisiert einen Dienst der Schicht.

3. Die oberste Schicht bildet die Schnittstelle für den Zugang von außen (der Anwendung).

Ein Dienst ist eine Menge von im Dienstmodell implementierungsunabhängig definierten Operationen, die einer übergeordneten Schicht zur Verfügung gestellt werden. Er kann als abstrakter Datentyp (Datenstruktur mit Operationen) angesehen werden. Die Definition des Dienstes sagt nur aus, was er leistet und nicht wie er das erreicht, dazu dient die Definition des Protokolls.

Die Schnittstelle bzw. der Dienstzugangspunkt legt fest, welche der Operationen wie verwendet werden müssen, um auf Dienste zugreifen zu können. Ein Aufruf eines Diensts kann nur durch die Benutzung der syntaktisch korrekten Operationen der Schnittstelle erfolgen. Eine Nachricht bzw. PDU enthält nicht nur die Nutzdaten, sondern auch Kontrollinformationen im Header über sie, wie z.B. den Ziel-Knoten. Die Informationen können vordefinierte Aktionen auslösen und sie müssen ein fest definiertes Format und eine Bedeutung haben:

Ein Protokoll legt die Kommunikationsregeln und die Nachrichtenformate fest. Es definiert eine Menge von Regeln wie z.B. Format, Bedeutung, Aktionen, Reihenfolge für die auszutauschenden Nachrichten. Ein Protokoll dient der Erbringung eines gewünsch-ten Dienstes auf der Basis der Nutzung der vorhandenen untergeordneten Dienste. Ein Protokoll legt fest, wie Dienste zu implementieren sind. Um den Dienst zu erbringen, müssen die Methoden implementiert werden. Die Methoden-Aufrufe bilden genau die Schnittstelle (Interface). Protokolle erbringen bzw. realisieren bzw. implementieren Dienste innerhalb einer Schicht.

Ein Protokoll der Schicht n wird auf Netzwerkeinheiten verteilt, welche wir „Quell-Host“ und „Ziel-Host“ nennen. Die Netzwerkanwendungen, die auf dem Quell-Host und Ziel-Host laufen, kommunizieren miteinander durch Austausch von Schicht-n-Nachrichten (n-PDUs) unter Nutzung der jeweils direkt untergeordnete Schicht (Die Kommunikation auf der Schicht 1 erfolgt dabei physisch, auf den übergeordneten Schichten jedoch „logisch“). Eine Protokoll-dateneinheit, Protocol Data Unit (PDU), ist eine aus Header (ggf. auch Trailer) und Payload bestehende Schicht-n-Nachricht welche der (logischen bzw. physischen) Kommunikation zwischen gleichen Protokollschichten (je nach Schicht nennt man sie: bit stream, frame, packet, datagram, segment oder message) dient; deshalb kann man PDUs auch als Schicht-n-Nachrichten (n-PDU) ansehen, deren Inhalt und Format durch das jeweils entsprechende Schicht-n-Protokoll definiert werden. Hierbei wird senderseitig beim Durchlaufen der Schichten des Protokollstapels (protocol stack) von jeder untergeordneten Schicht der n-PDU ein zusätzlicher n-Header vorangestellt bzw. hinzugefügt (Aufbereitung) und beim Empfang in umgekehrter Reihenfolge wieder entfernt (PDU-Schicht 4: „Segment“, Schicht 3: „Datagramm“, Schicht 2: „Rahmen“). Während der Übertragung können Nachrichten aus Optimierungsgründen auch innerhalb einer Schicht (sozusagen horizontal) aufgeteilt und zusammenfügt (ggf. auch erst verkettet und dann wieder getrennt) werden.

In einem größeren Computernetzwerk sind die Endsysteme nicht direkt miteinander verbunden; z.B. ist das Internet ein Verbund aus privaten und öffentlichen Netzwerken. Deshalb wird es auch als Netzwerk aus Netzwerken bezeichnet. Diese bilden zusammen ein „logisches Netzwerk“, das „Internet“. Zwischen den Endsystemen (Hosts) liegen also im allgemeinen weitere Netzwerke, welche durch sogenannte Transitsysteme (z.B. Router oder Gateways) verbunden sind. Dabei wird bei Verwendung des Internets das Zugangsnetzwerk für ein Endsystem durch den Internet-Service-Provider bereitgestellt. Lokale ISPs sind ihrerseits mit regionalen ISPs verbunden, die wiederum mit nationalen und internationalen ISPs verbunden sind. Die Internet-Standards werden in den RFCs (Request for Comments) durch die IETF (Internet Engineering Task Force) festgelegt.

Das Internet-Protokoll (Internet protocol, IP) ist das grundlegenden Protokoll auf der Vermittlungsschicht und ebenso grundlegend für das gesamte Internet; es spezifiziert das Format, in dem im Internet Informationen (Datagramme) zwischen Routern und Endsystemen (aber auch direkt zwischen z.B. zwei Endsystemen) auf der Vermittlungsebene ausgetauscht werden. Der Weg, den die Datagramme durch das Rechnernetz von einem Endgerät über verschiedene Transitsysteme zum anderen Endgerät nehmen, bezeichnet man als Route oder Pfad. (Datagramme werden auch als „IP-Pakete“ bezeichnet; Datagramme können ggf. während des Weiterleitens/Vermittelns im Pakete zerlegt werden, wobei auch nicht zerlegte Datagramme im Kontext des Vermittelns als Pakete bezeichnet werden.)

Das Internet ist paketvermittelnd. Eine Nachricht soll auch in einem gestörten System einen Weg zum Ziel finden können. Dafür werden Verbindungsnetzwerke mittels Routern (Router werden auch als Transitsysteme bezeichnet) aufgebaut. Dabei leitet jeder Router eine Nachricht so gut wie möglich (best effort) weiter. Ein Verbindungsnetz besteht aus Routern und Leitungen zwischen ihnen. Die Vermittlung in den Verbindungsnetzwerken macht es möglich keinen festen Übertragungsweg reservieren zu müssen (fester Übertragungsweg = Leitungsvermittlung); d.h. verschiedene Pakete können verschiedene Wege nehmen, auch dann wenn sie „semantisch/logisch“ zur selben Nachricht bzw. zum selben Datagramm gehören.

Ein Router muß das Ziel eines Pakets kennen und soll nur fehlerfreie Pakete weiterleiten. Daher muß er ein ganzes Paket zuerst komplett empfangen, bevor er damit beginnen kann, das Paket über eine ausgehende Leitung weiterzugeben (Speichervermittlung/Store-and-Forward-Übertragungstechnik/“switching method“ im Gegensatz zu „cut through switching“). Würde eine Nachricht immer nur als ein einziges Paket über z.B. n hintereinander liegende Router übertragen („Nachrichtenvermittlung“ als ineffizienter Spezialfall der Paket- und Speichervermittlung), so würde die Nachricht wegen der Store-and-Forward-Übertragungs-technik auch die n-fache Gesamtübertragungszeit benötigen. Zerlegt man hingegen die Nachricht in viele kleine Pakete, so können die Pakete mehrere hintereinander liegende Router gleichzeitig und jeweils mit kürzerer Verzögerung (Latenzzeit) durchlaufen; d.h. der effektive Durchsatz vergrößert sich. Die Gesamt-Verzögerung kann sich dabei fast soweit verringern, als ob insgesamt nur ein Router durchlaufen werden würde. Im Fehlerfall wird ggf. auch nur das fehlerhafte Paket wiederholt. Eine Nachricht sollte deshalb beim Sender in kleine Pakete (Protocol Data Units, PDUs) zerlegt und beim Empfänger wieder zusammengesetzt werden. Allerdings resultiert bei kleineren Paketen dadurch auch ein größerer Header-Overhead (Verwaltungsmehraufwand).

Paketvermittelte Netze werden in zwei Klassen unterteilt: Datagramm-Netzwerke und VC-Netzwerke (Virtual Channels, virtuelle Kanäle). Sie unterscheiden sich dadurch, daß sie Pakete entweder anhand von Host-Zieladressen oder anhand von virtuellen Kanal-nummern weiterleiten. Das Internet ist ein Datagramm-Netzwerk, da das IP die Pakete anhand von Zieladressen weiterleitet. (ATM Asynchronous Transfer Mode ist z.B. ein VC-Netzwerk)

1. Verarbeitungsverzögerung: die Zeit, die ein Router braucht, um festzustellen wohin ein     Paket geht und ob es Bit-Fehler enthält. Fehlerhafte Pakete werden nicht weitergeleitet.

2. Warteschlangenverzögerung: die Zeit, die ein Paket in den Warteschlangen bei Router     verbringt, bevor es verarbeitet und gesendet wird.

3. Übertragungszeit: die Zeit, die ein Router benötigt, um alle Bits eines Pakets auf die     Leitung zu bringen. (Übertragungsrate bzw. Bandbreite in bps  mal die  Anz. Paketbits).

    Einheiten-Präfixe werden hierbei dezimal interpretiert: 1 Kbps = 1000 bps)

4. Ausbreitungsverzögerung: die Zeit, die ein Signal von Router A nach B braucht.

5. Gesamtverzögerung des Routers (1.bis 4.) und

6. die komplette Ende-zu-Ende-Verzögerung.

OSI-Modell: Open System Interconnection Model, ISO: International Organization for Standardization. Das OSI/ISO-Modell (ISO/IS 7498, 1977-1983, Überarbeitung 1995) definiert ein Rahmenwerk zur Implementierung von Protokollen, um die Kommunikation zwischen Computersystemen zu standardisieren. Es basiert auf den Schichten-Modell-Konzepten: Dienst, Schnittstelle und Protokoll und somit auch auf Kapselung bzw. Geheimnisprinzip, der Abstraktion durch eine Schicht und der Transparenz bzw. „Durchsichtigkeit“ der untergeordneten Schichten (Transparenz: Nachrichteninhalte werden nicht verändert und der Übertragungsdienst wird vollbracht ohne daß der Klient wissen muß wie der Dienst vollbracht wird).

1. Dienst: gibt an, was die Schicht allgemein macht, nicht wie die darüber liegende Schicht     drauf zugreift.

2. Schnittstelle: definiert, wie auf den Dienst zugegriffen werden kann.

3. Protokoll: implementiert/realisiert/erbringt einen Dienst. Solange die Schnittstelle unver-     ändert bleibt, kann ein Protokoll (fast) auswirkungsfrei abgeändert werden (Transparenz).

Die Dienste der unteren drei Schichten ermöglichen den Transport von Daten zwischen Endsystemen, während die Dienste der oberen vier Schichten für einen reibungslosen Verlauf des Dialogs zwischen den Anwendungsprozessen zuständig sind.

(Es existiert keine praxisrelevante OSI/ISO-Modell-Implementierung. Das Modell hat nur noch historische bzw. akademische Bedeutung).

Die sieben Schichten des OSI-Modells lassen sich wie folgt charakterisieren:

Schicht 1: Bit-Übertragungsschicht (physical layer): stellt physikalische Übertragungskanäle                    zur Verfügung, die es gestatten, beliebige Bit-Folgen zu übertragen.

Schicht 2: Sicherungsschicht (data link layer): stellt weitgehend sichere Übertragungskanäle                    für die Übertragung von Datenblöcken zur Verfügung. Hierzu werden                    Verfahren zur Fehlererkennung und Fehlerkorrektur eingesetzt. Die von der                    Schicht 2 dieses Modells zur Verfügung gestellte Funktionalität ist also die                    Fehlerkorrektur. (Der Bedarf für eine „Bus-Arbitrierung“, „logical link“ und „media                      access control“ auf einem lokalen Ethernet-Bus auf Schicht 2 (link layer) wurde von der                    OSI ursprünglich nicht vorgesehen und muß daher ggf. von höheren OSI-Schichten                    übernommen werden.)

 Schicht 3: Vermittlungsschicht (network layer): stellt logische Übertragungskanäle                    zwischen Endsystemen zur Verfügung. Schicht 3 stellt somit das Weiterleiten                    und das Routing als Funktionalität zur Verfügung. Ein lebendes Beispiel ist das                    IP als anwenderseitiges Protokoll auf der Vermittlungsschicht im Internet.

 Schicht 4: Transportschicht (transport layer): stellt logische Übertragungskanäle zwischen                    den auf den Endsystemen aktiven, miteinander kommunizierenden Prozessen                     zur Verfügung (lebende Beispiele sind die Protokolle TCP und UDP des                    Internet-Protocol-Stacks).

Schicht 5: Kommunikationssteuerungsschicht oder auch Sitzungsschicht (session layer):                    stellt Dienste zur Verfügung, die es den miteinander kommunizierenden                    Anwendungen erlauben, ihren Dialog zu kontrollieren und zu synchronisieren.

 Schicht 6: Darstellungsschicht (presentation layer): stellt Dienste zur Verfügung, die die                    Darstellung von Daten in unterschiedlichen Repräsentationen (z.B. zwischen                    verschiedenen Zeichencodierungen) umwandeln.

 Schicht 7: Anwendungsschicht (application layer): implementiert die eigentliche Anwen-                    dungsfunktionalität. (Das dem Anwender zur Verfügung stellen einer „IP-                     Adresse“ oder eines „Dienst-Ports“ wäre im gekapselten OSI/ISO-Schichtenmodell                     Architektur-Rahmenwerk nicht vorgesehen gewesen).

1. horizontale Richtung: Eine Schicht bietet einen oder mehrere logische Übertragungs-kanäle bzw. Kommunikationsdienste zwischen zwei Kommunikationspartnern (z.B. Anwendungen, Prozessen, Hosts) an. Diese werden durch Protokolle realisiert bzw. implementiert. Nur in der untersten Schicht findet die eigentliche physische Kommunikation; d.h. die Nachrichtenübertragung über physikalische Medien statt.

2. vertikale Richtung: Die Dienste einer Schicht (oberhalb der Übertragungs-Schicht 1)  benutzen die Dienste der jeweils untergeordneten Schicht, welche sie jeweils über den entsprechenden Dienstzugangspunkt (= Schnittstelle, Interface) erreichen, um die von ihnen angebotenen Dienste zu erbringen. Eine Schicht darf die zu sendenden Daten bzw. PDUs, die an der Schnittstelle eintreffen, mit Kontrollinformationen in Form eines Schicht-n-Headers versehen bzw. „aufbereiten“.

Top-Down-Reihenfolge:

Die Anwendungsschicht regelt den anwendungsspezifischen Teil der Kommunikation zwischen Netzwerkanwendungen. Sie beinhaltet viele „höhere Protokolle“ bzw. Anwendungs-Protokolle: darunter HTTP für das Web, SMTP für E-Mail und FTP für den Filetransfer. In der Internet-Terminologie wird sie auch als Verarbeitungsschicht bezeichnet. Mit dem Kommunikationspartner "Anwendung" ist hier eher die Art der Anwendung gemeint. Es kann aber mit „Anwendung“ je nach Kontext z.B. auch eine konkrete Server-Anwendung gemeint sein, deren Prozess-Threads z.B. über mehrere Sockel-Schnittstellen gleichzeitig über die Transportschicht mit mehreren Clients kommuni-zieren.

Die Transportschicht stellt „einen Kommunikationsdienst zwischen zwei Anwendungs-prozessen“ (oder alternativ auch Anwendungs-Threads) bereit und ermöglicht so eine Endpunkt-zu-Endpunkt-Kommunikation zwischen zwei Prozessen (via Slot-Interfaces). Es gibt hier zwei Übertragungsprotokolle: TCP und UDP. TCP bietet einen zuverlässigen, verbindungs-orientierten Dienst, über den ein Bytestrom von einem Rechner im Internet fehlerfrei einem anderen Rechner zugestellt wird. UDP bietet einen unzuverlässigen, verbindungs-losen, flexiblen „paketorientierten“ Dienst. Sowohl TCP als auch UDP erweitern die Host-zu-Host-Übertragung der Vermittlungsschicht um die Prozess-zu-Prozess-Kommunikation. Ferner enthalten sowohl UDP-Segmente/Datagramme als auch TCP-Segmente eine Prüfsumme über den Header und die Payload, also über das gesamte Daten-Segment, da IP nicht garantiert, daß Datensegmente unverfälscht ankommen.

Auch die Vermittlungsschicht bietet einen Endpunkt-zu-Endpunkt-Kommunikationsdienst (es gibt hier und bei UDP aber auch Broadcasts). Sie transportiert IP-Datagramme von einem Quell-Host zu einem Ziel-Host. Die Vermittlungsschicht des Internets besteht aus zwei Hauptkomponenten: dem anwenderseitigen IP und vielen Routing-Protokollen. Das IP definiert das Format eines IP-Datagramms und es wird als das grundlegende Protokoll für das Internet angesehen. Im Kontext des Weiterleitens werden zerlegte und auch nicht zerlegte Datagramme auch als Pakete bezeichnet. Die Routing-Protokolle bestimmen idealerweise im Vorfeld des Weiterleitens, welche Pfade die Pakete zwischen Quelle und Ziel in etwa nehmen. Innerhalb eines Netzwerks kann der Netzwerkadministrator jedes beliebige Routing-Protokoll benutzen. Die Vermittlungsschicht, die das IP und viele Routing-Protokolle enthält, wird auch als IP-Schicht oder Internet-Schicht bezeichnet.

Die Sicherungsschicht ist für die Beförderung ganzer Rahmen von einem Netzwerk-Knoten (Host, Router, Gateway, Bridge oder Paket-Switch) zu einem benachbarten Knoten zuständig, die physikalisch über einen Übertragungskanal, z.B. ein Kabel, eine Telefonleitung oder einer Punkt-zu-Punkt-Funkverbindung, miteinander verbunden sind. Der auf der Sicherungsschicht bereitgestellte Dienst hängt von dem spezifischen Sicherungs-schichtprotokoll ab. Ethernet und PPP (Point-to-Point Protocol) sind Beispiele für Sicherungsschicht-Protokolle. Garantiert vollumfänglich mit Prüfsummen versehen werden die Payload-Daten eigentlich erst in der Internet-Transportschicht durch TCP und UDP.

Demgegenüber überträgt die Bitübertragungsschicht die einzelnen Bits der 1-PDU von einem Knoten zum nächsten. Die Protokolle dieser Schicht hängen wesentlich vom Über-tragungsmedium der Verbindungsleitung ab. Ethernet benutzt z.B. viele Protokolle für die

Bitübertragungsschicht: eines für Twisted-Pair Kabel, eines für Koaxialkabel, eines für Glasfaser usw. Je nach Medium wird ein Bit nachrichtentechnisch unterschiedlich auf der Verbindungsleitung oder per Funk übertragen. Der Begriff Netzwerkschnittstellenschicht (Network Interface Layer) fasst die Bitübertagungsschicht und die Sicherungsschicht zusammen. Diese Schicht wird auch als Host-an-Netz-Schicht (Host-to-Net Layer) bezeichnet.

Im Vergleich zu den sieben ISO/OSI-Modell-Schichten besteht das Internet-Modell nur aus fünf (eigentlich vier) Schichten. Die Dienste und Funk-tionalitäten der Schichten 5 und höher des ISO/OSI-Modells sind bereits sehr anwendungsspezifisch, so daß sich die Anwendungsschicht der Internet-Architektur hierfür als praxisgerechtes Äquivalent erwiesen hat. Im Internet-Modell gibt es auch keine so strikte Trennung der Schichten. In der Internet-Anwendungsschicht sind z.B. sowohl die Port-Nummern aus der Transportschicht als auch die IP-Interface-Adressen aus der Vermittlungsschicht sichtbar; dadurch haben Änderungen in Schicht 3 und 4 ggf. Auswirkung auf Schicht 5. Einige Routing-Protokolle für die Vermitt-lungsschicht liegen aus OSI-Sicht auf zu hohen Schichten: z.B. DNS (Anwendungsschicht); das liegt daran, daß im Internet-Modell die Komplexität der Internet-Architektur aus Flexibilitäts- und Wachstumsmöglichkeitsgründen möglichst auf die Ränder des Netzwerks und in die Anwendungsschicht verlagert wird. Das Internet-Modell ist daher mehr praxisorientiert und hat sich auch in der Praxis durchgesetzt.

(Die Architektur von Rechnernetzen wird akademisch idealerweise durch das ISO/OSI-Referenzmodell beschrieben (Schichtenmodell-Rahmenwerk als Architektur von Rechnernetzen). Die Architektur des Internet wird durch das Internet-Schichtenmodell und dessen existierenden Protokolle (z.B. TCP/IP) festgelegt. Es gab auch bereits Vorgänger-Protokolle vor dem Internet-Modell (ARPANET). Im ISO/OSI-Modell sind die Verantwortlichkeiten strenger gekapselt und es bildet eher ein theoretisches Rahmenwerk zur Implementierung von Protokollen. Es existiert jedoch keine praxisrelevante ISO/OSI-Modell-Implementierung. Dadurch, daß im Internet-Modell  nur die Auswahl zwischen Stream (TCP) und Paket (UDP) besteht, wird auch das Wissen um die Flusskontrolle etwas in die Applikation hinein gedrängt, wobei fraglich ist ob es überhaupt möglich ist auf dieses in der Anwenderebene komplett zu verzichten.)

Aufgrund des Bestrebens einen großen Teil der Komplexität der Internet-Architektur auf die Ränder des Netzwerks zu legen, implementieren die Endsysteme wie z.B. Hosts alle fünf Schichten, während die Transitsysteme wie z.B. Router, Gateways, Bridges und Switches keine Transportprotokolle implementieren (zumindest nicht für das eigentliche Weiterlei-ten). Router und Gateways implementieren die Schichten 1 bis 3 (kennen also IP-Adressen), Bridges, Switches (beide sind Paket-Switches) und auch die Hubs imple-mentieren nur die Schichten 1 und 2 (kennen also z.B. nur Ethernet-MAC-Adressen). Bridges verbinden Netzte unterschiedlicher Techno-logie. Gateways oder Gateway-Router verbinden verschiedene „autonome Systeme“, also Netzwerke mit unterschiedlichen Routing-Protokollen. Sowohl Endsysteme als auch die Transitsysteme sind die wichtigsten Netzwerkein-heiten im Internet.

Das Internet bietet verteilten Anwendungen auf den Endsystemen über die Transportschicht bzw. deren Sockel-Schnittstelle (socket API) zwei Endpunkt-zu-Endpunkt-Kommunika-tionsdienste an: UDP und TCP (wobei UDP auch Broadcasts unterstützt, diese Segmente sind dann aber nicht routebar). Auf der Transportschicht kommunizieren Prozesse (technisch die Sockel) miteinander, wobei eine Anwendung auch mehrere Kommunikations-Threads gleichzeitig aktiviert haben/halten kann. Die Kommunikationsdienste auf der Transportschicht werden durch zwei Übertragungsprotokolle realisiert: UDP (User Datagram Protocol) und TCP (Transmission Control Protocol). UDP bietet einen bzgl. Verlust und der Reihenfolge eintreffender Telegramme unzuverlässigen, verbindungslosen Dienst (vergleichbar eher mit dem Postkartenversand als mit einem Stream bzw. als mit klassischer Telefonie). TCP bietet einen zuverlässigen, verbindungsorientierten Dienst, über den ein „unbegrenzter“ Bytestrom (Stream) von einem Host-Prozess im Internet fehlerfrei zu einem anderen Host-Prozess (bidirektional) transferiert wird (TCP bietet somit die Illusion eines typischen leitungsvermittelnden Dienstes wie z.B. die klassische Telefonie). Dienst-merkmale von UDP: zeitsensitive, bandbreitensensitive aber verlusttolerante Anwen-dungen, flexible Anwendbarkeit (z.B. Subnet-Broadcasts). Dienstmerkmale von TCP: zuverlässige aber zeitlich elastische Anwendungen. Auf der Transportschicht kommunizieren jeweils zwei Prozesse unter Ausnutzung der Dienste tiefergelegener Schichten (dem IP) logisch miteinander. Adressiert werden auf dieser Schicht Segmente empfangende Prozesse (bzw. Sockel) über Port-Nummern. Die Transportschicht teilt die Sendedaten der Anwendung ggf. in viele Segmente auf bzw. setzt die Segmente beim Empfang wieder zusammen und entfernt jeweils die Header. Die Weiterleitung der empfangenen Daten an den richtigen Prozess (bzw. and den von ihm belegten Sockel) beim Empfang anhand von Port-Nummern (und ggf. auch von Host-IPs) nennt man Demultiplexen. Das Multiplexen und Demultiplexen muß jedes Transportprotokoll leisten, da Transportprotokolle gerade die Host-zu-Host-Übertragung der Vermittlungsschicht um die Prozess-zu-Prozess-Kommunikation erweitern. Allerdings benötigt das Demultiplexen auf Schicht 4 zur eindeutigen Partnerprozess-Identifikation ggf. noch die Quell-Host-IP-Adresse aus Schicht 3 (z.B. falls mehrere eintreffende Segmente anfragender Clients zufällig den selben Quell-Port aufweisen; siehe dazu auch die Frage zum Demultiplexing) bzw. es benötigt die Quell-Port-Nummer (z.B. falls die eintreffenden Segmente vom selben Quell-Host stammen). Sowohl UDP-Segmente als auch TCP-Segmente enthalten eine Prüfsumme über den Header und die Payload, also über das gesamte Daten-Segment, da IP nicht garantiert, daß Datensegmente unverfälscht ankommen.

UDP verwendet keinen Verbindungsaufbau und ist somit für kurze zustandslose, kontext-freie Dienst-Anfragen, welche sowieso in ein Segment bzw. in eine Standard-PDU-Pay-load-Länge passen und auch für Echtzeit-Streaming-Dienste, bei denen schon mal ein Segment auswirkungsfrei verlorengehen darf, gut geeignet. UDP ist also gut geeignet für einfache, zeitsensitive, bandbreitensensitive aber verlusttolerante Anwendungs-Kommuni-kation.

Ein Segment ist die PDU der Transportschicht auf der die Protokolle UDP und TCP auf-setzen. Ein Segment (4-PDU) besteht aus der Header-Information und den Nutzdaten (payload). Es enthält im Header im wesentlichen die Quell-Port- und Ziel-Port-Nummer welche in der Transportschicht für das Multiplexen beim Versenden und für das Demultiplexen beim Empfang zwecks Zuordnung eines empfangenen Segments zu den kommunizierenden Prozessen (bzw. zu deren verwendeten Sockel) verwendet wird. (Bei gleichzeitiger Verwendung mehrerer TCP-Verbindungen durch einen Server Dienst, muß zur eindeutigen Identifikation des Client-Sockels bzw. des Client-Prozesses noch die Quell-Host-IP-Adresse (zur genaueren Identifikation des Client-Prozesses) aus dem Schicht-3-Header des empfangenen Segments bzw. Datagramms referenziert werden und auch die Quell-Port-Nummer (falls mehrere Clients des selben Typs (z.B. mehrere Firefox-Instanzen) auf dem selben „Quell-Host“-PC laufen).)

Die Vermittlungsschicht bietet einen (logischen) Endpunkt-zu-Endpunkt-Kommunika-tionsdienst zwischen zwei Hosts. Auf Schicht 3 kommunizieren jeweils zwei (Ausnahme: UDP-Broadcasts) Netzwerk-Knoten über eines der Schichtprotokolle (anwenderseitiges IP„-Protokoll“ oder ein „hintergründig laufendes“ Routing-Protokoll) miteinander (IP-Data-gramme weiterzuleiten ist nicht Routing). Adressiert werden auf dieser Schicht Hosts über Host-Interface-IP-Adressen. Sie transportiert Datagramme logisch vom Quell-Host zum Ziel-Host (kennt daher nur IP-Adressen und keine Ports). Die Vermittlungsschicht des Internets bietet folgende Haupt-Dienstmerkmale: Host-IP-Adressierung, Paketübertra-gung bzw. Übermittlung und die Pfadermittlung, bzw. besteht aus zwei Hauptkom-ponenten: dem anwenderseitigen IP und vielen Routing-Protokollen. Das IP definiert das Format eines IP-Datagramms und ist somit das grundlegende Transferprotokoll im Internet. Die idealerweise im Vorfeld des Paket-Transfers abgearbeiteten Routing-Protokolle bestimmen, welche Pfade die IP-Datagramme bzw. Pakete zwischen Quelle und Ziel nehmen (werden). Innerhalb eines Netzwerks kann der Netzwerkadministrator jedes beliebige Routing-Protokoll benutzen. Die Vermittlungsschicht, die das IP und viele Routing-Protokolle enthält, wird auch als IP-Schicht oder Internet-Schicht bezeichnet. Die Vermittlungsschicht bietet nur einen unzuverlässigen, verbindungslosen Kommunikations-dienst, d.h. Pakete können verlorengehen. Pakete können auch unvorhersehbar in einer anderen Reihenfolge empfangen werden, als sie gesendet wurden (paketzerlegte IP-Datagramme werden aber schon in der richtigen inhaltlichen Reihenfolge vom IP wieder hergestellt). Das Dienstmodell auf der Vermittlungsschicht beschreibt die hier erwähnten Eigenschaften, die der Kommuni-kationsdienst der Vermittlungsschicht der nutzenden Schicht (Transportschicht) bietet. Die Vermittlungsschicht hält das Internet grundlegend zusammen.

Das Internet-Protokoll (Internet Protocol, IP) spezifiziert das Datagramm-Format, mit dem im Internet Anwenderdaten zwischen Routern und Endsystemen (aber auch direkt zwischen z.B. zwei Endsystemen: Host-zu-Host-Übertragung) auf der Vermittlungsebene transferiert werden. Der Weg, den die Information durch das Rechnernetz von einem Endgerät über verschiedene Transitsysteme zum anderen Endgerät nimmt, bezeichnet man als Route oder Pfad. Die „Payload“ eines IPv4-Datagramms kann 64k-Byte (-1) minus 20 Header-Bytes betragen. (Während das IP zur Weiterleitung von Informationen zwischen Endsystemen (und Routern) dient (Host-zu-Host-Übertragung), leisten TCP oder UDP die Weiterleitung von Informationen zwischen den „Pro-zessen“, die auf den Endsystemen verteilte Netzanwendungen ausführen. TCP und UDP benutzen dazu das IP.)

Rechnernetze dienen zur Realisierung verteilter Anwendungen, welche durch den Austausch von Nachrichten über das Computernetzwerk miteinander kommunizieren. Die Protokolle auf der Anwendungsschicht legen das Format und die Reihenfolge der ausgetauschten Nachrichten fest und definieren die aus der Übertragung oder dem Empfang einer Nachricht resultierenden Aktionen. Bei verteilten Anwendungen muß man die eigentlichen Netzwerkanwendungen von den verwen-deten Anwendungsprotokollen unterscheiden:

Innerhalb der Netzwerkanwendung „World Wide Web (WWW)“ nutzen z.B. Web Browser und Web-Server das HTTP (HyperText Transfer Protocol), E-Mail Clients/User Agents nutzen das SMTP (Simple Mail Transfer Protocol) bzw. IMAP (Internet Message Access Protocol), File-Transfer-Applikationen nutzten FTP, Remote Login nutzt Telnet und SSH, die Internet-Telephonie nutzt SIP, u.s.w…

Die Anwendungsschicht (Verarbeitungsschicht) ist zuständig für die Bereitstellung von Netzwerkanwendungen. Anwendungen bzw. Programme sind die Schnittstelle zwischen dem Benutzer und dem Internet. Ein Benutzer interagiert mit einer Anwendung, um einen Dienst zu erhalten. Dabei kommunizieren zwei Anwen-dungen auf der Anwendungsschicht. Sie beinhaltet viele Protokolle: Mit dem spezifischen Dienst bzw. mit dem spezifischen Anwendungsschichtprotokoll ist eine (häufig öffentlich) festgelegte Port-Nummer assoziiert; d.h. der Dienst(-Typ) wird über seine Port-Nummer identifiziert.                                                                      Benutzer-Interaktion

Client und Server sind beides Netzwerkanwendungen. Dabei ist der Client der Nutzer eines Dienstes und der Server der Anbieter eines Dienstes. Um diesen Dienst in Anspruch zu nehmen, sendet der Client initiativ eine Anfrage zum Server und bekommt idealerweise eine Antwort zurück, womit der Dienst vollbracht ist; der Server wird in diesem Modell nie von selbst initiativ oder aktiv.

Im Peer-to-Peer-Modell (z.B. Filesharing) hingegen tauschen zwei Peers (Gleichgestellte, Kollegen) Host-Anwendungen in gleichen Rollen direkt Daten untereinander aus ohne dafür über eine Server-Anwendung zu gehen. Jeder Peer kann einen Dienst anbieten oder nutzen.

Ein applikativer Dienst bzw. eine Server-Netzanwendung wird durch eine eindeutige Portnummer (16 Bit breit) innerhalb des Server-Hosts identifiziert (Eine „offizielle“ Server-Anwendung wird zumindest als Typ bereits durch die öffentlich assoziierte Port-Nummer identifiziert, dennoch muß man natürlich auch hier bei der Inanspruchnahme noch den konkreten Server-Host benennen, es könnte ja z.B. sein, daß der Dienst auf einem konkreten Host gar nicht angeboten wird). Ein dienstanbietender Prozess (gemeint ist hier ein Sockel der Anwendung als Kommunikations-Knoten der Schicht 4 und nicht der Server-Dienst als Typ) auf dem Server-Host wird jedoch noch nicht bereits durch die Port-Nummer des Anwendungsprotokolls bzw. des Dienstes, den dieser Server-Prozess ausführt und die IP-Adresse des Server-Hosts allein schon eindeutig identifiziert; letzteres liegt daran, daß speziell bei Verwendung von TCP/IP ein Dienstprozess mehrere Threads bzw. Sockel bzw. zustandsbehaftete Verbindungen gleichzeitig besitzen kann; somit müssen diese auch noch anhand der aktuell verbundenen Clients (quasi-zufälliger Quell-Port, Quell-IP-Adr.) unterschieden werden. Bzgl. TCP gilt dasselbe dann entsprechend auch für die Identifikation des Client-Prozesses. Gäbe es nur zustandslose UDP-Kommunikation würde theoretisch schon die Host-IP und die Port-Nummer für die Adressierung eines Kommunikationspartner-„Prozesses“ ausreichen. Allgemein gilt: Eine Kommunikation bzw. Verbindung zwischen zwei Anwendungen (und somit auch der eine konkrete Anfrage bearbeitende Dienst-Thread bzw. Prozess) wird erst eindeutig durch folgendes 4-Tupel identifiziert und adressiert: IP-Adresse des Server-Hosts, IP-Adresse des Client-Hosts, Port-Nummer des Servers, Port-Nummer des Clients (siehe dazu auch die Frage zum Demultiplexing). Dieses 4-Tupel definiert eine Ende-zu-Ende-Kommunikation zwischen zwei Anwendungen im Internet („Kommunikation“, weil der Begriff „Verbindung“ bereits für TCP reserviert ist). „Ende-zu-Ende-Kommunikation“ sagt nichts aus über die überlagerte Verwendung von Peer-to-Peer oder Client-Server. Auch bei einer UDP-Kommunikation muß z.B. ein Server wissen, an welchen Client bzw. Kommunikationspartner die aktuelle Antwort zurückgesendet werden soll.

Bei einen Push-Protokoll sendet ein Client (auch wenn die Anwendung hauptsächlich die Rolle eines Servers haben sollte) mit seiner „Request-Anfrage“ eigeninitiativ Nutzdaten zum Server. Zum Beispiel ist SMTP ein Push-Protokoll, d.h. der sendende „Mail-Server“ schiebt als Client die E-Mail(s) unaufgefordert auf den empfangenden Mail-Server. Bei einem Pull-Protokoll wie z.B. HTTP fragt der Client ganz klassisch Nutzdaten beim (Web-)Server an.

Die Prozess-ID ist nur innerhalb eines Host-Rechners gültig und eindeutig und hat nur temporären Charakter. Die Port-Nummer hat mit 16 Bit zumindest ein eindeutiges Format.

Ein „Uniform Resource Locator“ ist ein spezieller Typ eines „Uniform Resource Identifier”, (ein URL ist also immer auch ein URI) speziell für den Gebrauch in verteilten Netzan-wendungen, um eine Ressource wie z.B. eine Web-Seite oder Server-Datei eindeutig symbolisch in menschenlesbarer Form zu identifizieren und zu lokalisieren. Eine URL besteht aus den drei Teilen:

1. Name des Protokolls: wie zugegriffen wird.

2. Name des Servers (Domain-Name): worauf sich die Ressource befindet (DNS-Name od. IP-Adresse).

3. lokaler Name der Ressource: wie die Ressource heißt (lokaler Pfad der Datei auf dem Server).

http://<IP adresse>/<lokaler Pfad>

Dabei wird der Aufbau des „Domain-Name“ durch das Domain Name System (DNS) definiert. Eine Server-Anwendung (aber nicht der bearbeitende Thread oder die Verbindung) wird im Internet durch die Host-IP und die Port-Nummer identifiziert. Die Port-Nummer erscheint innerhalb einer URL indirekt in Form der Protokollbezeichnung. Alternativ kann man in der URL auch explizit die Port-Nummer mittels Doppelpunkt hinter die Host-IP anfügen: wie z.B. „www.google.de:443“. Die Web-Browser benutzen/assoziieren allerdings automatisch den richtigen Port mit dem angegebenen Protokoll.

Das Domain Name System (DNS) des Internets übernimmt die Aufgabe, die mnemonischen Host-Namen auf IP-Adressen abzubilden, da Router nur IP-Adressen verarbeiten können. Das Domain Name System (DNS) bildet also einen symbolischen Domänen-Namen, welcher ein Teil der URL ist, auf eine numerische IP-Adresse ab. Dabei kann ein symbolischer Name mehrere Adressen haben; z.B. liefert „www.google.com“ via ping mehrere IP-Adressen (wg. Skalierbarkeit). Umgekehrt kann eine IP-Adresse auch mehreren DNS-Namen zugeordnet sein. Bevor ein Zugriff auf eine Ressource stattfindet, muß ein Name in eine Adresse („transparent“: ohne daß der Benutzer die reale IP-Adresse sieht) ggf.

mittels mehrerer DNS-Name-Server-Requests, welche sowohl per UDP als auch TCP auf Port 53 ablaufen können, aufgelöst werden.

Das DNS realisiert eine verteilte Datenbank, die als eine Hierarchie von Name-Servern implementiert ist. Auf der untersten Stufe stehen die lokalen Namens-Server, die vom ISP betrieben und den Hosts im lokalen Netz jeweils beim Internet-Zugang zugewiesenen werden. Lokale „Name-Server“ versuchen, DNS-Anfragen für den anfragenden Host zu erledigen und die endgültige Antwort an ihn zurück zu liefern. Jede Institution, die eine Second-Level-Domain wie www.fernuni-hagen.de betreibt, stellt auch mindestens einen zuständigen autoritativen Name-Server zur Verfügung, der alle Anfragen zu dieser Domain beantworten kann. Viele Namens-Server fungieren gleichzeitig als lokale und autoritative Name-Server. Darüber stehen die Top-Level-Name-Server, für die Domains wie „.de“ zuständig sind und insbesondere den jeweils richtigen autoritativen Name-Server einer untergeordneten Institution kennen. Ganz oben in der Hierarchie des Internets gibt es etwa ein dutzend Root-Name-Server, die mindestens alle Top-Level-Name-Server kennen. Alle Name-Server arbeiten mit einem Cache, der die Anfragen und Antworten der letzten Zeit speichert, so daß die darüber liegenden Server entlastet werden. So wird der lokale Name-Server fast nie die Root-Name-Server konsultieren, und auch die Top-Level-Server nur dann, wenn nach einer bisher nicht bekannten Subdomain gefragt wird. Der lokale Name-Server arbeitet nach dem Prinzip der rekursiven Namens-Auflösung: er übernimmt die Anfrage eines Hosts, erledigt alles Notwendige zur Beantwortung und liefert, falls möglich, die endgültige komplette Antwort zurück, ansonsten aber eine explizite Negativmeldung. Die Arbeitsweise der Name-Server auf den höheren Stufen nennen wir dagegen iterative Namens-Auflösung: Sie antworten nur mit dem Verweis auf einen anderen (untergeordneten) Server, der die Frage weiterbearbeiten kann. An diesen ist dann dieselbe Anfrage noch einmal zu richten. Das iterative Prinzip ist für die viel beschäftigten Name-Server vorteilhaft, weil sie so ohne jede Verzögerung die Anfragen endgültig erledigen können. Eine 3rd-level Subdomäne, wie z.B. „www.“ wird ggf. erst in einem späteren Folge-Request iterativ aufgelöst. Ein Host-Name darf höchstens 255 Bytes lang sein.

Eine Socket-API (application programming interface) ist die Schnittstelle bzw. ist ein Dienstzugangspunkt zwischen Anwendungsschicht und Transportschicht, sie bietet Sockel bzw. ein Socket-Interface an. Die folgenden Sockel-Schnittstellenoperation sind üblich:

Erzeugen eines Sockels: (create newSocket),

client-seitige TCP-Verbindungs-Anfrage(connect),

server-seitiges Akzeptieren einer TCP-Verbindungs-Anfrage (listen, accept)

Lesen aus einem Socket (getInputStream, recv, recvfrom)

Schreiben in einen Socket (getOutputStream, send, sendto)

Schließen eines Sockets server-socket.close(), client-socket.close()

Ein Sockel wird durch seinen Handle, den er durch „newSocket()“ erhält, identifiziert.

Das World Wide Web ist nicht das Internet. WWW ist nur eine verteilte Anwendung bzw. Netzwerk-Anwendung von vielen im Internet (so wie z.B. auch E-Mail). Es kann auch auf einem anderen Netzwerk als dem Internet betrieben werden. WWW besteht aus mehreren Komponenten: Web-Browser-Anwendungen als Benutzerschnittstelle, Web-Servern zur Bereitstellung von Dokumenten, Protokollen: z.B. HTTP (HyperText Transfer Protocol) und Standards: z.B. HTML (HyperText Markup Language) ein Dokumentenformat-Standard. HTTP definiert die Nachrichtentypen und die Art der Weiterleitung von Nachrichten zwischen Web-Browsern und Web-Server. Es ist der Grund warum Browser und Server sich weltweit verstehen.

Das File Transfer Protokoll ist zustandsbehaftet (schon wegen der benutzerspezifischen Verzeichnisse über die der Server Buch führen muß). Die Datei-Daten werden in eigenen von den Anfragen getrennten Verbindungen übertragen (out-of-band protocol) (Bei HTTP hingegen werden Steuerinformationen mit den Nutzdaten zusammen versendet (in-band)).

HTTP (HyperText Transfer Protocol) ist ein TCP/IP basiertes zustandsloses Client-Server-Protokoll welches auf menschenlesbaren ASCII-Anfragen beruht (s. RFC 1945 und 2616). Es gibt zwei Nachrichtentypen: Die Anfrage vom Client enthält z.B. eine GET-Methode mit einer WWW-Objekt-Referenz um ein Objekt (z.B. HTML-Datei oder Grafik-Datei) vom Server zu erfragen. Die Antwort-Nachricht des Web-Servers enthält dann die angeforderten Daten im MIME-Format. Ab HTTP-Version 1.1 werden persistente Verbindungen unterstützt, welche es gestatten mehrere Objekte nacheinander von demselben Server zu laden, ohne für jedes Objekt immer eine neue Verbindung aufbauen zu müssen. Da HTML zustandslos arbeitet, besteht auch bei persistenten Abfragen auf Anwenderebene keine Auswirkung einer vorangegangenen Abfrage auf die folgende Abfrage. Persistente Verbindungen werden zudem entweder mit oder ohne Pipelining verwendet. Bei einer persistenten Verbindung mit Pipelining kann der Client, sobald er auf eine Referenz eines Objekts stößt, Anfragen an einen Server senden, ohne auf die vorherige Antworten warten zu müssen. Laufen die HTML-Anfragen z.B. über einen lokalen Proxy-Server spricht man von einem Web-Cache. Diese fungieren nach innen als Web-Server und nach außen als Client. Sie erhöhen effektiv die Reaktionszeit, reduzieren die benötigte Bandbreite ins öffentliche Netz und anonymisieren den internen Client vor der Außenwelt.

In obiger Anfragenachricht wünscht der Client durch die Angabe in der dritten Zeile connection: close ausdrücklich eine nicht persistente Verbindung, obwohl HTTP-Version 1.1 persistente Verbindungen unterstützt. Die vierte Zeile gibt den Browser-Typ an, in diesem Fall das Mozilla/4.0, ein Netscape-Browser. Dieses kann nützlich sein, da manche Server unterschiedliche Versionen eines Objektes für unterschiedliche Browser bereithalten. Alle diese Versionen werden aber nur mit einem URL bezeichnet. Wird dem Server kein Browsertyp mitgeteilt, liefert er die auf ihm konfigurierte Default-Version des angefragten Objektes.

Eine mögliche Antwort auf diese Anfrage könnte wie folgt aussehen: Die erste Zeile, die Statuszeile, umfasst immer drei Felder: Version (hier HTTP-Version 1.1), Statuscode (200 bedeutet, daß alles in Ordnung ist), und Phrase (hier OK: die Anfrage wurde gemäß den Anforderungen abgearbeitet). Danach folgen wieder Header-Zeilen, die dem Web-Browser Details über die Lieferung geben: Zeile 3 enthält das Lieferdatum, d.h. wann die Antwortnachricht generiert wurde, Zeile 4 den Server und die Zeilen 5 bis 7 beschreiben das gelieferte Objekt selbst. Schließlich folgen im sogenannten Entity Body die eigentlichen Daten.

Anwendungen: Der Mail User Agent ist die Anwendung auf der Benutzer-Seite, d.h. das laufende E-Mail-Programm, mit dem ein Benutzer interagiert, z.B. zum Verfassen, Lesen, Bearbeiten von E-Mails. Der Message Transfer Agent (MTA) ist die Server-Anwendung, die darauf wartet, daß neue E-Mails ankommen, und sie dann zustellt.

Protokolle: Mit SMTP (Simple Mail Transfer Protocol) werden E-Mails übertragen. Mit POP3 oder IMAP werden E-Mails von der Mailbox abgeholt.

Prinzip von POP3: download and delete (bzw. auch keep), einfach.

Prinzip von IMAP: synchronize, speichern der Zustände auf allen Seiten. Die Mails verbleiben auf dem Server und werden im Client nur dargestellt.

Alle MUAs müssen den Kodierungsstandard „Muitipurpose Internet Mail Extension“ unterstützen, welcher Texte und Grafiken „verlustlos“ mittels 7-Bit-ASCII-Zeichen kodiert.

Eine E-Mail-Adresse bestimmt eine Mailbox und hat das Format mailbox@Domain-Name

Ein Beispiel: alice.schmidt@studium.fernuni-hagen.de

E-Mail-Anwendungen: (Mail User Agent MUA) für Benutzer sind E-Mail-Programme wie Thunderbird oder Outlook verfügbar.

Es sind Anwenderprotokolle die relativ langsam ablaufen können (zuverlässige aber elastische Anwendungen) und ggf. die weitverbreitete SSL-Verschlüsselung benutzen.

Verteilte Anwendungen bieten ihre spezifischen Kommunikationsdienste auf Schicht 5 an. Die Anwendungen brauchen sich dabei jeweils nur für einen eher paketorientierten (UDP) oder einen verbindungsorientierten (TCP) Dienst der Transportschicht zu entscheiden und brauchen dann nur die Daten über Sockel-Schnittstellen der Transportschicht zu übergeben und von diesen abzuholen. Die Transportschicht (Schicht 4) realisiert bzw. bietet eine zwei Dienste umfassende logische Ende-zu-Ende-Kommunikation zwischen zwei Prozessen an (also nicht direkt zwischen Anwendungen als Kommunikationspartner auf dieser Ebene, sondern zwecks Verwendung durch übergeordnete Anwendungen die z.B. gleichzeitig jeweils mehrere Threads bzw. mehrere Sockel bzw. mehrere zustandsbehaftete Verbindungen als Kommunikationsknoten „Prozesse“ geöffnet halten können). Eine Ende-zu-Ende-Kommunikation wird im Internet durch die zwei Port-Nummern beider an einer Verbindung/Kommunikation beteiligter Prozesse und die zwei IP-Adressen beider Hosts eindeutig identifiziert. Die Weiterleitung empfangener Daten an den richtigen Prozess(-Sockel) in Schicht 4 (ggf. unter Referenzierung von Host-Adressen aus Schicht 3) wird als Demultiplexen bezeichnet (siehe dazu auch die Frage zum Demultiplexing). Die Transportschicht teilt zu sendende Daten der Anwendung bei Bedarf in kleinere Stücke auf, in jedes Stück wird ein Header der Transportschicht eingefügt, daraus ergeben sich mehrere Segmente. Transportprotokolle nutzen die Dienste der Vermittlungsschicht (Schicht 3) zur Realisierung logischer Schicht-4-Kommunikation zwischen zwei Prozessen bzw. zwischen zwei Sockel-Schnittstellen. Auf den Sockel-Schnittstellen können dann die Anwendungen der Schicht 5 aufsetzen.

Die Vermittlungsschicht bietet den Datagrammaustausch zwischen zwei Hosts an: Die Aufgabe der Vermittlungsschicht („network layer“ OSI/Schicht 3 jedoch „internet layer“ im Internet-Modell/Schicht 3. Verwechslungsgefahr: der „network layer“ im Internet-Modell umfasst die Schichten 1 und 2) ist die Erbringung eines verbindungslosen, paketvermittelten, unzuver-lässigen Best-Effort-Dienstes bzw. Datagramm-Transports zwischen zwei Hosts mittels des „anwenderseitigen“ Internet-Protokolls (IP) bzw. ist die Datagramm-Vermittlung (Forwarding) und das Routing innerhalb eines (ggf. autonomen) Verbin-dungsnetzwerkes unter „hintergründiger/transparenter“ Verwendung eines Routing-Protokolls zwecks Erstellung von Routing/Verbindungs-Tabellen, angewandt idealer-weise im Vorfeld der eigentlichen IP-Datagramm-Weiterleitung. Die Hosts sind in der Regel nicht direkt, sondern über eine Menge von dazwischen liegenden Routern und Kommunikations-verbindungen miteinander verbunden. Die Router dienen lediglich zum Transport von Paketen zwischen den Hosts. Sie implementieren die Schichten 1 bis 3 (kennen also IP-Adressen, aber keine DNS-Namen und keine Ports).

Aus Sicht der übergeordneten Transportschicht ist die Aufgabe der transparenten Vermittlungsschicht der logische Endpunkt-zu-Endpunkt-Transport von Transportschicht-Nachrichten (Segmenten) von Host zu Host. Adressiert werden auf der Vermittlungsschicht die Hosts über Host/Interface-IP-Adressen (ebenfalls keine Ports und auch keine DNS-Namen). Die Vermittlungsschicht des Internets bietet somit zwei Haupt-Dienstmerkmale:

Die Host-zu-Host adressierte Paketvermittlung (bei bekannten Pfaden) und die Pfader-mittlung (Netztopologiebestimmung) bzw. besteht aus zwei Hauptkomponenten: dem IP und vielen Routing-Protokollen. Während IP zur Weiterleitung von Anwender-Informa-tionen zwischen Endsystemen (und Routern) dient (Host-zu-Host-Übertragung), leisten TCP oder UDP die Weiterleitung von Anwender-Informationen zwischen den „Prozessen“ (technisch: den Threads bzw. den Sockeln), die auf den Endsystemen von den verteilten Netzanwendungen ausgeführt werden. TCP und UDP benutzen dazu das IP.

Rechnernetze bzw. Computernetzwerke dienen zur Realisierung verteilter Anwendungen, welche durch den Austausch von Nachrichten (über das Netzwerk) miteinander kommuni-zieren. Ein Rechnernetz oder Computernetzwerk ist ein System bestehend aus mindes-tens zwei miteinander über Kommunikationsleitungen (z.B. ein Local Area Network) verbun-denen Rechnern (Endsysteme, Hosts (speziell Server), ggf. auch Transitsysteme: Router, Gateways, Switches, Bridges). Auf den Rechnern/Endsystemen laufen die Netzwerk-anwendungen. Das Modell eines Netzwerks ist ein Graph, wobei Knoten die Rechner und Peripheriegeräte und Kanten die Kommunikationsleitungen sind. (Ein „System“ besteht aus verbundenen Komponenten mit einem erwarteten Verhalten und es wechselwirkt über Schnittstellen mit der Umgebung.)

Mit dem Kommunikationspartner "Anwendung" ist häufig eher der Typ der Anwendung gemeint. Es kann aber mit „Anwendung“ je nach Kontext auch z.B. ein konkreter Server-Anwendungsprozess gemeint sein, der z.B. über mehrere Sockel-Schnittstellen und ggf. entsprechenden Threads gleichzeitig über die Transportschicht mit mehreren Clients ggf. zustandsbasiert kommuniziert oder es können z.B. auch mehrere Instanzen einer Client-Anwendung wie z.B. der „Firefox“-Browser gleichzeitig jeweils mehrere Verbindungen zu unterschiedlichen Servern oder auch dem gleichen Server geöffnet halten, die dann für jede dieser Verbindungen einen eigenen Sockel als Schnittstelle zur Transportschicht besitzen. Deshalb muß auf Schicht 4 nicht zwischen Anwendungen sondern zwischen Verbindungen (TCP) bzw. zwischen Kommunikationen (UDP) unterschieden werden (gemäß Skript werden hier „Prozesse“ adressiert). Die entsprechenden Verbindungs-Endknoten, also die „Kommunikationspartner“ der Schicht 4 sind technisch eigentlich die Kommunikations-Sockel, welche eine verteilte Anwendung zu einem Zeitpunkt gleichzeitig geöffnet hat. Diese werden im Schichtenmodell als „Prozesse“ referenziert. Mit der „Identität“ bzw. „Adressierung des Prozesses“ ist im Schichtenmodell also nicht die Identität der Anwendung gemeint, sondern die Identität einer ihrer gerade verwendeten Schicht-4-Knoten-Schnittstellen (Sockel). Jedoch wird in Kap. 3.3.4 „Adressierung von Prozessen“ wiederum die ID eines einen Port dauerhaft besitzenden diensterbringenden Anwendungsprozesses eben mit seiner Port-Nummer assoziiert. Man muß also zwischen Schicht-5 (Anwendungsprozess) und Schicht 4 (Prozess-Threads bzw. Prozess-Sockel) kontextbezogen unterscheiden: Die Ziel-Port-Nummer eines eintreffenden Segments identifiziert zwar abstrakt den Dienst auf Schicht 5 bzw. den Horch-Sockel (welcomeSocket) besitzenden Haupt-Anwendungsprozess; die konkrete(n) aktive(n) Verbindung(en) des Dienstes bzw. seiner instanziierten Threads werden aber erst durch das 4-Tupel bestehend aus IP-Adresse des Server-Hosts, IP-Adresse des Client-Hosts, Port-Nummer des Servers, Port-Nummer des Clients eindeutig identifiziert (siehe dazu auch die Frage zum Demultiplexing). Die entsprechenden Verbindungs-Endknoten werden durch die Sockel bzw. korrespondierend durch die „Prozesse“ identifiziert. Ferner wird in Schicht 4 wird auch kein anwendungsspezifisches Wissen, also 5-PDU Nachrichteninhalte, verwendet oder verändert (Transparenz).

Ein UDP-Server holt sich immer nur eine empfangene Client-Anfrage nach der anderen vom einen an einen UDP-Dienst-Port gebundenen Sockel ab und kann dann über den selben Sockel antworten, merkt sich also i.a. keine Zustände von einer Anfrage zur nächsten.

Ein TCP-Server hält auf seinem TCP-Dienst-Port ständig einen an diesen Protokoll-Port gebundenen Horch-Sockel (welcomeSocket) aktiviert. Für jede tatsächlich aufgebaute Client-Verbindung existiert jedoch ein zusätzlicher eigener verbindungsspezifischer Daten-Transfer-Sockel der den Zustand bzw. Kontext der jeweiligen geöffneten Verbindung kennt. Daß ein TCP-Server gleichzeitig mehrere Verbindungen zu verschiedenen Clients geöffnet halten kann, ist auch der Grund warum die Ziel-Port-Nummer eines empfangen Segments den Server-Prozess (gemeint ist damit einer seiner Verbindungs-Sockel) nicht eindeutig adressiert: es müssen noch die Clients (anhand ihrer Quell-Host-IP-Adressen und quasi-zufälligen/temporären Quell-Ports) unterschieden und somit auch berücksichtigt werden.

Der Server muß bereits laufen bevor die ersten Client-Anfragen eintreffen.

Transportprotokolle nutzen die Host-zu-Host-Kommunikationsdienste der Vermittlungs-schicht zur Realisierung logischer Kommunikation zwischen „Prozessen“ in der Transport-schicht. In der Regel laufen auf einem Host mehrere verteilte Netzwerk-Anwendungs-prozesse, die über das Rechnernetz kommunizieren wollen. Da auf der Vermittlungsschicht (Schicht 3) nur die logische Kommunikation zwischen Hosts unterstützt wird; d.h. zwischen „Prozessen“ hier also nicht unterschieden werden kann, fügt die Transportschicht vor der Übergabe eines zu sendenden Segments (4-PDU) an die Schicht 3 dem Segment noch den Source-Port zur Identifizierung des das Segment sendenden Quell-Prozesses hinzu und auch den Destination-Port zwecks Identifizierung des empfangenden Ziel-Prozesses auf dem Ziel-Host. Das Hinzufügen der Port-Nummern des Quellprozesses und des Zielprozesses in der Transportschicht beim Senden ist der Schicht-4 Teil des Multiplexens (Multiplexing). Das Segment wird dann an die Vermittlungsschicht zum Versenden an den Ziel-Host weitergegeben. Die Vermittlungs-schicht fügt dann noch einen Header (H3) vor das Segment welcher entsprechend die Source-Host-IP und den Quell-Host-IP enthält. Das Hinzufügen der Host-IP-Interface-Adressen des Quell-Hosts und des Ziel-Hosts in der Vermittlungsschicht beim Senden ist der Schicht-3 Teil des Multiplexens (Multiplexing), auch wenn man vom Multiplexen eigentlich immer nur in Schicht 4 spricht. Berücksichtigt man, daß z.B. ein Server-Prozess unter Verwendung seiner Dienst-Port-Nummer mehrere zustandsbehaftete TCP-IP-Verbindungen, also mehrere Sockel unter ein und derselben Port-Nummer, zu je einem Client gleichzeitig geöffnet haben kann, so erreicht man je nach Szenario erst eine eindeutige Adressierung der Verbindungs-Sockel dieses Server-Prozesses, falls man das komplette 4-Tupel (IP-Adresse des Server-Hosts, IP-Adresse des Client-Hosts, Port-Nummer des Servers, Port-Nummer des Clients) beim Empfang eines Client-Datagramms auswertet: Bsp.-Szenario 1: zwei Clients von unterschiedlichen Hosts haben zufälligerweise denselben Source-Port; d.h. die Source-Host-IP wird zur Unterschei-dung von Segmenten der beiden benötigt. Szenario 2: zwei Clients von gleichen Host müssen anhand ihres Quell-Source-Ports unterschieden werden (mehrere parallele Verbindungen von einer Client-Anwendung auf einem Host zu einer Server-Anwendung sind möglich). Daß die quasi-zufälligen, temporären Source-Ports ausgehender Segmente zweier Client-Sockel innerhalb eines Hosts sich unterscheiden, dafür sorgt der Internet-Stack des Host-BS automatisch.

Die Auswahl des passenden Empfangsprozesses in der Ziel-Host-Transportschicht anhand des Destination-Ports und auch anhand des Source-Ports (ist nötig bei mehreren geöffneten TCP-Verbindungen vom selben Quell-Host) eines von der Vermittlungsschicht empfangenen Segments nennt man Demultiplexen. Das empfangene Segment kann dann dem passenden TCP-Sockel zugewiesen werden. (Für UDP allein würde auch der Destination-Port für die Auswahl des Sockels/Prozesses ausreichen, da UDP nur einen Sockel pro Empfangs-bzw. Ziel-Port-Nummer nutzt und es dadurch keine „parallelen Verbindungen“ auf derselben Ziel-Port-Nummer gibt.)

Kurzform:

Da auf Schicht 3 nur die Kommunikation zwischen Hosts unterstützt wird, muß ein Transportprotokoll Nachrichten verschiedener Prozesse i.a. unter Verwendung derselben Host-IP senden und empfangen. Hierzu muß das Transportprotokoll den Nachrichtenstrom, den es von der Vermittlungsschicht erhält, auf die verschiedenen Empfängerprozesse (bzw. auf die von ihnen belegten Sockel) verteilen. Dies nennt man Demultiplexen.

Damit das Demultiplexen funktioniert, muß das sendende Transportprotokoll geeignete Kontrollinformationen zwecks Prozessidentifikation zu den Nachrichten, die es vom „Prozess“ erhält, zum Segment(4-PDU)-Header hinzufügen, bevor es sie an die Vermittlungsschicht zum Versenden übergibt. Dieses nennt man Multiplexen.

1. Zuverlässigkeit (keine Datenverluste,Datenintegrität/Reihenfolge) versus Verlusttoleranz

2. bandbreiten-sensitive versus elastische Anwendungen

3. zeitsensitive Anwendungen

Der UDP-Header besteht aus den vier 16Bit-Feldern Quell(Source-)-Port, Ziel(Destinati-on)-Port und Segment-Länge inklusive Hea-der und Prüfsumme. Danach folgen nur noch die Anwendungsdaten (pay-load). Die eingetra-gene Datenlänge beträgt mindestens 8 Bytes (entspricht der 8 Byte-Header-Länge). Die Anwendungsdaten können höchstens 65535 - 8(UDP-Header) - 20(IPv4) Bytes umfassen. Die Prüfsumme wird als Einer-Komplement (invertiert) über einen Pseudo-Header (er enthält auch Teile des IP-Headers) und der Payload berechnet. Ist die Datenlänge ungerade, so wird eine „virtuelle“ Null am Ende der Daten vor der Prüfsummenberechnung eingefügt.

Auf der Vermittlungsschicht findet mittels IP Host-zu-Host-Kommunikation statt, sie kennt keine adressierten Prozesse als Kommunikationsknoten. Die Transportschicht bietet aber mit UDP eine Prozess-zu-Prozess-Kommunikation an. Beim Multiplexen und Demultiplexen werden Prozesse mittels Port-Nummern adressiert. UDP führt dieses Multiplexen und das Demultiplexen aus.

Anwendungen von UDP:

1. Für eine einmalige, zustandslose und kurze (in ein UDP-Segment passende) Anfrage wie     z.B. iterative (evtl. auch für rekursive) DNS-Anfragen; so kann z.B. ein DNS-Server jede     hereinkommende Anfrage gleich beantworten und sofort wieder vergessen.

2. Für Anwendungen, bei denen die Schnelligkeit der Übertragung wichtiger ist als die     Verfügbarkeit, z.B. die Übertragung von Audio- und Video-Streaming, bei welcher auf eine     Fluss- und Überlaufkontrolle bewußt verzichtet wird.

UDP-Segmente können bis zu 65535 - 8 - 20 Byte Nutzsdaten enthalten. Eine Webseite passt u.U. dort hinein, aber ein http-Server erwartet TCP/IP; d.h. er möchte eine TCP/IP-Verbindung mit dem Web-Client aufbauen, bevor er dessen HTTP-Anfragen beantwortet.

Wenn man z.B. ein Webradio mit UDP realisiert, was kann es da mit den Paketen für Probleme geben? Warum können Pakete sich überholen?

Pakete können aufgrund des paketvermittelnden Routings alternative Wege durchlaufen, auch dann wenn sie nur Millisekunden hintereinander geschickt werden. Daher können Pakete sich überholen und grundsätzlich auch verlorengehen.

Z.B. durch eine Durchnummerierung der Pakete bzw. Nachrichten mittels einer art von Sequenznummer auf applikativer Ebene (in der Anwendungsschicht, Schicht 5).

Transportprotokolle nutzen zur Datenübertragung die Dienste der Vermittlungsschicht, also das IP-Protokoll. IP ist ein unzuverlässiger Dienst; d.h. IP-Datagramme bzw. einzelne Pakete können verlorengehen. Gründe für den Verlust eines IP-Datagramms sind z.B. eine in einem Router anhand der Checksumme erkannte Verfälschung des Datagramms oder eine Überflutung des Routers, die dazu führt, daß das ankommende Datagramm nicht im Empfangspuffer des Routers gespeichert werden kann. Beides führt dazu, daß der Router das Datagramm nicht weitersenden kann. Da auch UDP ein unzuverlässiger Dienst ist, d.h. das Ankommen eines UDP-Datagramms beim Empfänger nicht garantiert ist, werden die bei einer Überlastung durch Pufferüberlauf verlorengegangenen Datagramme nicht durch UDP automatisch noch einmal gesendet. Hieraus resultiert dann ein Datenverlust. IP garantiert nicht die Lieferung empfangener IP-Datagramme in der richtigen Reihenfolge, wohl aber die korrekte Reihenfolge innerhalb der Datagramme, jedoch wiederum nicht die Integrität der Daten.

1. Die Daten sollen unverfälscht beim „Empfängerprozess“ abgeliefert werden (Bitfehler).

2. Daten sollen vollständig beim „Empfängerprozess“ abgeliefert werden (Nachrichtenverlust).

3. Die Daten sollen in unveränderter Reihenfolge abgeliefert werden (Paket-Überholung).

4. Eine Überflutung des Empfängers soll vermieden werden.

Dieses kann z.B. durch zusätzliche Kontrollinformationen (Redundanz, Prüfsummen, Bestä-tigung (ACK/NACK), Quittierung, Wiederholung, Paket-Nummerierung, Sequenznummern, Timeout, Hop-Count, (kumulative) Bestätigung) und einer damit verbundenen Flusskontrolle erreicht werden und ggf. zusätzlich durch eine Netz-Überlastkontrolle (Congestion Contr.).

Das zuverlässige Datentransferprotokoll verschickt die Daten mittels der darunter liegenden unzuver-lässigen Netzwerkschicht an das auf der Empfänger-seite laufende zuverlässige Datentransferprotokoll. Zusätzliche bilaterale Kommunikation von Daten und Kontrollinformation  zwischen der Senderseite und der Empfängerseite des zuverlässigen Datenüber-tragungsprotokolls ist notwendig, um eventuelle Feh-ler zu beheben. Das Protokoll selbst kann über einen Zustandsautomaten modelliert werden.  rdt steht für „reliable data transfer“, udt steht für „unreliable data transfer“

erstes Fehler-Modell: verlustfreier Übertragungskanal mit garantierter Reihenfolge aber mit Bitfehlern:

1. Möglichkeit zur zuverlässigen Datenübertragung: Bitfehlerbehebung mittels Redundanz.

2. Möglichkeit: Stop-and-Wait-Protokoll: Die nächste Übertragung erfolgt erst nach positiver Bestätigung (ACK), sonst (NACK oder Timeout) altes Paket wiederholen. Nachteil: fehlerhafte Bestätigung: Kommt ein NACK des Empfängers beim Sender als ACK an, so sendet er fälschlicherweise das nächste Paket.

Abhilfe: Stop-and-Wait mit Sequenznummer:

Damit der Empfänger beide Fälle unterscheiden kann, enthalten die abgesendeten Pakete eine Sequenznummer (Der Empfänger kann ja nicht anhand seines letzten ACK oder NACK unterscheiden, ob ein empfangenes Paket eine Wiederholung ist, da ACK bzw. NACK ja selbst verfälscht werden können (fehlerhafte Bestätigung)). Auch die Quittungs-Pakete (ACK oder NACK) werden vom Empfänger mit der Sequenznummer des zuletzt integer empfangenen Pakets im Bestätigungsfeld versehen. In der Literatur heißen zuverlässige Datenübertragungsprotokolle, die auf Wiederholungen basieren, auch ARQ-Protokolle (Automatic Repeat reQuest). Grundsätzlich werden in einem ARQ-Protokoll drei Fähigkeiten benötigt, um Bitfehler zu behandeln: Fehlererkennung (Redundanz), ACK-, NACK-Rückmeldung vom Empfänger für jedes empfangene Paket und wiederholtes Senden bei NACK. Paketfehler können also mittels Prüfsummen, Wiederholungen aufgrund von Bestätigungsnachrichten und Sequenznummern behandelt werden.

zweites Modell: Übertragungskanal mit garantierter Reihenfolge aber verlustbehaftetet und mit Bitfehlern: Alternating-Bit-Protokoll (Der Name kommt daher, daß die Sequenznummern des Protokolls immer zwischen Null und Eins alternieren).

1. Die Behandlung von erkannten Paketverlusten: kann ebenfalls mittels Techniken wie  Prüfsumme, Sequenznummern, Bestätigungsnachrichten und ggf. Wiederholungen erreicht werden.

2. Erkennung von Paketverlusten: wird senderseitig gelöst, indem ein Countwdown-Timer beim Senden einer Nachricht gestartet, beim Empfang einer positiven Quittung ACK angehalten und bei Timeout die Nachricht erneut gesendet wird (jedoch noch nicht beim Empfang eines fehlerhaften Pakets).

Ein zu knapp bemessenes Timeout-Intervall oder verzögerte Tele-gramme führen zu unnötigen Zweitsendungen und den dazuge-hörigen Bestätigungen. Der Sender darf den Empfang veralteter n-1 Quittungen (auch dann wenn sie nicht als solche erkennbar sind) auf keinen Fall zum Anlass nehmen vor Ablauf des Timeouts erneut n-Telegramme zu versenden, da er dadurch entsprechend viele n-ACKs erhalten wird, wenn er bereits auf das n+1 te NACK wartet, u.s.w.

Auch das Alternating-Bit-Protokoll ist ein Stop-and-Wait-Protokoll. Die nächste Nachricht wird also immer erst nach der erfolgreichen Bestä-tigung der vorangegangenen Nach- richt versendet. Der Empfänger hat keine große Einflußmöglichkeit.   Zeitdiagramme

Bei einem Fenster-Protokoll darf der Sender eine Folge von durchnummerierten Paketen senden, bevor zum Weitersenden eine Bestätigung des Empfängers eintreffen muß. Die Sendefenstergröße legt fest, wie viele Pakete ohne Rückbestätigung gesendet werden dürfen. Der Sender besitzt daher einen Puffer als Sendefenster, in dem die Segmente gespeichert werden, für die er entweder noch keine Bestätigung erhalten hat oder die noch gar nicht gesendet wurden. Das Empfangsfenster ent-hält sämtliche Paketnummern die der Empfänger aktuell empfangen darf. Der Empfänger bestätigt in der Regel nicht den Empfang jedes einzelnen Paketes sondern den Em-pfang einer korrekt empfangene Paketfolge (kumulative Bestäti-gung) mittels der Nummer des zuletzt korrekt empfangenen Pakets. Die sen-derseitige Zeitüberwachung erfolgt hier individuell für jedes Paket (S.151) oder nur für jedes „anfänglich“ gesendete Paket (S.162) oder bei erfolgreichen Bestätigungen (S.162). Der Empfänger hat hier zwei aktive Eingriffsmöglichkeiten: „go-back-n“ bzw. das „Sliding-Window-Protokoll“ fordert den Sender auf, einen Block von n Pakete erneut zu senden und zweitens „selective-reject/repeat“; d.h. nur ein fehlerhaftes Paket wird erneut angefordert. Das Alternating-Bit-Protokoll kann man als Fenster-Protokoll mit der Fenstergröße 1 ansehen (bzgl. Nachteile eines Alternating-Bit Protokolls).

Das Stop-and-Wait-Protokoll und das Sliding-Window-Protokoll (Schiebefenster-Protokoll) sind zwei Methoden zur Steuerung der Flusskontrolle bei der Netzwerkdatenübertragung. Stop-and-Wait-Protokolle verwenden das Konzept der Bestätigung eines Pakets, bevor ein weiteres Pakete gesendet werden darf. Umgekehrt erlaubt das Schiebefensterprotokoll das Senden mehrerer Pakete vor dem Senden einer Bestätigung. Unter den beiden Protokollen ist das Schiebefenster-Protokoll effizienter als ein Stop-and-Wait-Protokoll. Die „Stop-and-Wait-Protokolle“ sind auch nicht tolerant gegenüber Paketverlusten.

Durch eine geschickte Wahl der Flusskontrolle bei der Netzwerkdatenübertragung lässt sich ein „logischer“ verbindungsorientierter verlustloser Endpunkt-zu-Endpunkt-Kommunikationsdienst auf der Transportschicht konstruieren. Das Behandeln von Paketverlusten kann mittel Techniken wie Prüfsumme, Sequenznummern, Bestä-tigungsnachrichten und wiederholtes Senden erreicht werden. Verluste können mittels Timer-Intervalle erkannt werden. Die Paket/Segment-Sequenznummer dient auch für Fensterprotokolle und zur die Wiederherstellung der korrekten Reihenfolge. Eine „Netz-Überlastung“ wird zusätzlich durch die Überlastkontrolle (Congestion Control) abgefangen.

Es wird keine Verbindung aufgebaut. (Es kann im Gegensatz zum verbindungsorientierten Dienst TCP auch ohne vorherigen Verbindungsaufbau kommuniziert werden; UDP verwendet auch nur einen Sockel pro Port und nur die einfachen Funktionen recvfrom() und sendto()). Es werden einzelne Nachrichten (und kein Byte-Strom wie bei TCP) vermittelt. Die Segmente einer Nachricht werden nicht automatisch in Schicht 4 nummeriert (transaction IDs höchstens auf applikativer Ebene) und sie werden unabhängig voneinander gesendet (zustandslos). Nachrichten bzw. Segmente können verloren gehen (Paketverlust). Die Segmente können auch in einer anderen Reihenfolge beim Empfänger ankommen, als sie gesendet wurden. Es gibt keine Fluss- oder Staukontrolle, d.h. die Segmente werden abgesendet, ohne zu prüfen, ob der Empfänger auch die Daten empfangen kann. Der Sender wird auch nicht darüber benachrichtigt, ob die Daten überhaupt angekommen sind.

Das Transportprotokoll TCP (Transmission Control Protocol) bietet einen verbindungs-orientierten logischen Punkt-zu-Punkt Vollduplex-Kommunikationsdienst an. TCP bietet/vermittelt also einen Vollduplex-Bytestrom-Dienst zwischen genau einem Sender und einem Empfänger. Daten können im Extremfall byte-weise/granular in beiden Richtungen gesendet und empfangen werden. Natürlich können in den Byte-Strom auch klassische Nachrichten wie bei UDP z.B. mittels Trennzeichen einkodiert werden (diese kommen aber beim Empfänger-Sockel nicht unbedingt immer sofort atomar an).

 TCP bietet einen zuverlässigen Dienst an:

1. Die Daten kommen korrekt an

2. Die Daten kommen vollständig und

3. in der richtigen Reihenfolge (wie gesendet beim Empfänger) an.

4. Es gibt einen Flusskontrollmechanismus für jeden der beiden Byteströme zwischen Sender und Empfänger, damit der Sender den Empfangspuffer beim Empfänger nicht überschwemmt. Es wird eine Überlastungskontrolle eingesetzt, die die Sendegeschwin-digkeit drosseln kann, um eine Überlastung des Netzwerks zu verhindern (z.B. mittels der dynamischen Empfangsfenstergröße im „Fenstergrößen-Feld“ des TCP-Headers oder auch mittels der Netz-Überlastkontrolle „Congestion Control“). TCP trägt auch manchmal den Namen „verbindungsorientiertes Protokoll“ bzw. „verbindungsorientierter Dienst“.

Beim Aufbau einer TCP-Verbindung zwischen einem Client und einem Server wird ein Drei-Wege-Handschlag durchgeführt, d.h. drei Segmente werden ausgetauscht, wobei auch die initialen Sequenznummern festgelegt werden:

Das Client-TCP sendet ein sogenanntes SYN-Segment (synchronize sequence num-bers) an das Server-TCP. Dieses Segment enthält keine Anwendungsdaten, aber es hat ein spezielles Header-Feld, das SYN-Bit, auf 1 gesetzt. Zusätzlich enthält das Sequenz-nummer-Feld des SYN-Segments eine initi-ale Sequenznummer, die das Client-TCP gewählt hat.

Sobald das SYN-Segment beim Server-TCP ankommt, erzeugt es eine neue Verbindung und weist ihr entsprechende Puffer-Ress-ourcen zu. Dann schickt das Server-TCP ein SYNACK-Segment an das Client-TCP zurück. Dieses Segment enthält noch keine Anwendungsdaten, aber es enthält drei wichtige Informationen im Segment-Header: das SYN-Bit ist auf 1 gesetzt, das Acknowledgement-Feld ist auf die gerade empfangene Sequenznummer (um 1 inkrementiert) gesetzt und das Sequenznummer-Feld ist auf eine initiale Sequenznummer des Servers gesetzt, die das Server-TCP gewählt hat. Dieses SYNACK-Segment bestätigt dem Client-TCP, daß das Server-TCP die Verbindung mit der initialen Sequenznummer client_isn des Client-TCP akzeptiert hat und daß die initiale Sequenznummer des Servers server_isn ist.

Bei einer Zwei-Wege-Handshake/Handschlag-Lösung würden ggf. vorhanden Duplikate der Client-Aufbau-Nachricht zu mehrfachen Verbindungsaufbauten auf Server-Seite und in Folge auch auf dem Client führen. Im schlimmsten Fall könnte dann die gleiche Datenübertragung (z.B. eine Banküberweisung) nochmals stattfinden. Auch deshalb werden die initialen Sequenznummern zufällig gewählt um die Wahrscheinlichkeit zu verringern, daß ein verzögertes TCP-Segment aus einer anderen kurz vorher abgebauten Verbindung oder auch aus einem vorangegangenen Verbindungsaufbau-Versuch in das aktuelle Fenster bzw. zur initialen Sequenznummer passt. Des weiteren sind die beiden initialen Sequenznummern beim Aufbau der TCP-Verbindung erforderlich um eine innerhalb der Verbindung eindeutige Nummerierung der Segmente zwecks Wiederherstellung der richtigen Reihenfolge für die Anwendung erreichen zu können. Diese initiale Nummer muß beim Aufbau einer TCP-Verbindung vereinbart werden.

Der Abbau der Verbindung erfolgt über ein FIN-Segment, dann von der Gegenseite ACK und später FIN, dann von der ursprünglichen Seite abschließend ein ACK-Segment.

Ein TCP-Segment besteht aus einem 20-Byte-Header-Feld, einem Optionsfeld und Anwendungsdaten. Der TCP-Header ist mindes-tens 20 Byte groß. Die Sequenznummer und die Bestätigungsnummer sind 32 Bit breit. Die 16-Bit-Fenstergröße gibt die aktuelle Größe des eigenen Empfangspuffers bekannt (nicht zu ver-wechseln mit dem „congestion control window“). Auffällig ist das Fehlen einer Längenangabe für das Segment. Theoretisch könnte ein TCP-Segment z.B. gemäß dem „Empfänger-Fenstergröße“-Feld bis zu 64k Byte Anwendungsdaten enthalten und über einen „scaling factor“ sogar bis zu 1 Gigabyte.  Allerdings wird die Länge  durch die „maximum segment size“ MSS (z.B. 1460B Ethernet, 536B, 512B Router, 64kB - 1 - 20 - 20 Byte IPv4) der darunterliegenden Schichten (3 & 2) weiter eingeschränkt, da eine weitere Zerteilung (Fragmentierung) der TCP-Segmente in jeweils mehrere IP-Datagramme auf der Vermittlungsschicht die TCP-Fluss-Effizienz  beeinträchtigen würde. Würde ferner TCP ein Segment auf z.B. zwei IP-Datagramme  aufteilen, so wäre auch die Daten-Reihenfolge innerhalb des Segments beim Empfang nicht weiter gewährleistet. Das ACK-Bit zeigt, daß die Bestätigungsnummer gültig ist. Das SYN-Bit zeigt, daß das Segment zum Verbindungsaufbau ist. Das FIN-Bit zeigt, daß der Sender signalisiert, daß von ihm keine Daten mehr gesendet werden.

Die Segmentgröße wird, wie bereits erwähnt, durch zwei Faktoren begrenzt:

1. jedes Segment muß in das Nutzdatenfeld des IP-Protokolls passen (65.515 Byte bei IPv4) 2. jedes Netz hat eine maximale Transfereinheit (MTU - Maximum Transfer Unit), in die das Segment ebenfalls passen sollte. In der Regel ist die MTU einige hundert Byte groß (bei-spielsweise Ethernet: 1500 Bytes). Die maximale TCP-Segment-Größe wäre somit MTU-Größe minus 20 Byte TCP-Header minus 20 Byte IPv4-Header (z.B. 576-20-20=536B). Läuft ein Segment durch eine Anzahl von Netzen und trifft dabei auf ein Netz mit einer kleineren MTU, so muß das Segment vom Router in kleinere Segmente aufgeteilt werden. Segmente ohne Daten sind zulässig und dienen der Übermittlung von Bestätigungen und Steuernachrichten.

TCP realisiert aus Anwender(-sockel)sicht einen Datenstrom von Bytes zwischen Sender und Empfänger. Jedes Byte in diesem Byte-Strom wird nummeriert, diese Nummer nennen wir die Byte-Stromnummer. Die Sequenznummer eines Segments ist definiert als die Byte-Stromnummer des ersten Bytes im Segment. Betrachten wir das Beispiel eines Anwendungsprozesses, der über eine TCP-Verbindung eine Datei von 10000 Byte an den Empfängerprozess verschicken will, wobei die maximale Segmentgröße MSS (Maximum Segment Size) 1000 Byte Anwendungsdaten betragen soll. Der Anwendungsprozess schreibt dann die 10000 Byte in den Socket, der mit der Verbindung assoziiert ist. Das Client-TCP konstruiert dann 10 Segmente und befüllt deren Datenfelder mit den Anwendungsdaten. Wenn das erste Byte mit i nummeriert wird (i = client_isn + 1), enthält das erste Segment die Bytes i bis i + 999, das zweite Segment die Bytes i + 1000 bis i + 1999 usw. Damit erhält das erste Segment die Sequenznummer i, das zweite Segment die Sequenznummer i + 1000 usw., die im Header des entsprechenden TCP-Segments eingetragen werden. TCP verwendet Bestätigungsnummern (Acknowledgements), um zu signalisieren, welches Byte als nächstes vom Sender erwartet wird. Wenn also das Server-TCP die ersten beiden Segmente korrekt empfangen hat und das dritte anfordern möchte, dann erwartet es als nächstes Byte dasjenige mit der Byte-Stromnummer i + 2000. Deshalb gibt das Server-TCP die Nummer i + 2000 als Bestätigungsnummer im nächsten Segment an, welches das Server-TCP an das Client-TCP verschickt. Falls das Server-TCP Segmente empfängt, die Daten enthalten, die erst später im Datenstrom kommen (z.B. passiert dies, wenn ein vorheriges Segment verlorengegangen ist oder später ankommen wird), dann verschickt das Server-TCP als Bestätigungsnummer trotzdem nur die Nummer des nächsten noch fehlenden Bytes im Byte-Strom. TCP wendet also die kumulative Bestätigung von bis dahin korrekt empfangenen Bytes an. Was passiert jedoch mit den Daten der Segmente, die erst nach der Lücke kommen? Implementierungsabhängig kann das Server-TCP diese Daten puffern und darauf warten, daß die fehlenden Daten ankommen, und dann bis zum dann fehlenden nächsten Byte bestätigen, oder aber verwerfen und damit das Client-TCP später zur Wiederholung zwingen.

Die Sequenznummer ist die erste Byte-Stromnummer der Anwendungsdaten des Segments. Zum Beispiel gäbe es drei Segmente 1, 2 und 3. Die initiale Sequenznummmer sei hier der Einfachheit halber 0. Die Sequenznummer eines Segments ist die Sequenznummer des vorherigen Segments plus die Anzahl der Datenbytes im vorherigen Segment. Die Bestätigungsnummer ist die Byte-Stromnummer des nächsten Bytes, das der Empfänger vom Sender erwartet. Die Bestätigungsnummer ist somit die Sequenznummer des nächsten Segments, auf das der Empfänger wartet. Die Bestätigung eines Segments ist auch eine Anforderung an den Sender, daß er das nächste Segment senden soll.

Wenn ein verspätetes Paket keine Anforderung zum Aufbau einer Verbindung ist, sondern irgendein anderes, das während einer Verbindung auftreten kann, dann wird es einfach verworfen, denn es kann keiner existierenden Verbindung zugeordnet werden. Es sei denn, es existiert schon wieder eine neue Verbindung mit denselben IP-Nummern und zufällig denselben Port-Nummern, und die verwendete Bestätigungsnummer fällt in das aktuelle Fenster, was aber sehr unwahrscheinlich ist. Wenn aber eine verspätete Anforderung (connection request) zum Aufbau einer Verbindung mit einer initialen Sequenznummer beim Empfänger ankommt, dann bestätigt er zunächst mit derselben initialen Sequenznummer und seiner eigenen initialen Sequenznummer für den Rückweg (connection granted). Die (scheinbar) gewünschte Verbindung wird aber nicht zustande kommen, weil sie norma-lerweise auf der Absenderseite keinem Verbindungsversuch zuzuordnen ist. Es sei denn, daß es zeitnah einen erneuten Versuch zum Verbindungsaufbau mit denselben IP-Adressen, denselben Port-Nummern und zufällig derselben initialen Sequenznummer gegeben hat, für den die Bestätigung noch aussteht, was wiederum extrem unwahrscheinlich ist.

1. Der Sendeprozess bekommt Daten vom Anwendungsprozess, verpackt diese in Segmente und übergibt sie zur Übertragung an die Vermittlungsschicht. Der Timer wird gestartet, falls er momentan nicht aktiv ist. Dies kann der Fall sein, wenn beispielsweise alle bisher gesendeten Segmente schon bestätigt wurden.

2. Wenn der Timer abläuft und die Bestätigung noch nicht angekommen ist, dann wiederholt der Senderprozess die Übertragung des unbestätigten Segments mit der kleinsten Sequenz-nummer.

3. Wenn ein Segment beim Empfänger ankommt, schickt dieser ein ACK-Segment zum Sender zurück. Darin steht die Bestätigungsnummer, die gleich der nächsten erwarteten Sequenznummer ist.

4. Wenn ein Segment mit Bestätigungsnummer N im ACK-Feld ankommt, dann prüft der Sender zuerst, ob es sich um eine Bestätigung für ein bis jetzt noch nicht bestätigtes Segment handelt. Dies ist genau dann der Fall, wenn N größer ist als die Sequenznummer des letzten vom Empfänger bestätigt Byte. Der Sender weiß dann, daß der Empfänger alle Daten korrekt empfangen hat, die vor der Sequenznummer N liegen. Deshalb kann der Sender seine Zustandsvariable (sendbase), welche die Sequenznummer des letzten vom Empfänger noch nicht bestätigten Bytes enthält, auf den neuen Wert N setzen und falls noch nicht alles gesendet wurde, den Timer erneut starten. Falls aber vorher schon einmal eine Bestätigung mit demselben Wert N im ACK-Feld empfangen wurde (d.h. N ≤ sendbase), dann handelt es sich um ein sogenanntes Duplicate ACK. In diesem Fall ignoriert der Sender die Bestätigung, falls N < sendbase ist. Falls N = sendbase, kann der Sender vermuten, daß der Empfänger das Segment mit der Sequenznummer N nicht korrekt empfangen hat. Der Sender erhöht deshalb einen Zähler für die Anzahl der Duplicate ACK für das betroffene Segment. Ein Duplicate ACK entspricht einer negativen Bestätigung. Wenn der Sender drei Duplicate ACKs mit dem Wert N = sendbase erhalten hat, dann weiß er, daß das Segment mit Sequenznummer N verloren gegangen ist und überträgt es erneut, auch wenn der Timer noch nicht abgelaufen sein sollte. Der Zähler für die Anzahl der Duplicate ACKs für das wieder übertragene Segment wird auf Null zurückgesetzt. Man spricht deshalb auch von einem Fast Retransmit.

Fall das Timeout (dynamisch adaptiv) abgelaufen ist oder vorzeitig (Fast Retransmission), falls insgesamt vier gleiche ACKs (bzw. drei Duplicate ACKs) empfangen wurden.

Fast Retransmit: Der Sender sendet ein Segment erst nochmal, wenn er drei Duplikate der Bestätigung für diese bekommen hat (schon vor dem Ablauf des Timeouts) oder wenn der Retransmit-Timer denn abgelaufen ist. Beispiel: Die Segmente mit Sequenznummer 0 und 330 sind beim Empfänger angekommen. Das Segment mit Sequenznummer 250 ist nicht beim Empfänger angekommen. Der Empfänger bestätigt Nummer 250, der Sender hat das Segment mit Nummer 250 aber längst abgeschickt. Der Empfänger bestätigt noch einmal Nummer 250, aber der Sender sendet das Segment immer noch nicht zum zweiten Mal, er spekuliert, daß das Segment mit Sequenznummer 250 in der Zwischenzeit noch beim Empfänger ankommen wird. Der Sender wiederholt das Senden des Segments erst dann, wenn er drei Duplikate der Bestätigung (Wiederanforderung) erhalten hat. Wenn der Sender das erste ACK erhält, weiß er, daß die Segmente bis 250 − 1 korrekt beim Empfänger angekommen sind und dieser das Segment mit der Sequenznummer 250 erwartet. Wenn der Sender das zweite ACK bekommt weiß er, daß der Empfänger entweder das Segment 250 nicht korrekt oder mindestens ein Segment mit der Sequenznummer größer als 250 empfangen hat. Jetzt wiederholt der Sender das Senden des Segments 250 noch nicht und wartet noch etwas in der Hoffnung, daß der Empfänger nach dem Absenden des zweiten ACKs das verspätete Segment N=250 noch erhält. Wenn der Sender aber das dritte ACK empfangen hat, ist ihm klar, daß das Segment N=250 noch nicht beim Empfänger angekommen ist und der Empfänger mindestens noch ein anderes Segment mit einer Sequenznummer größer als N=250 erhalten haben muß. Nun wiederholt der Sender die Übertragung des Segments N=250. Drei Duplicate-ACKs stellen einen Kompromiss zwischen der Ausführung des Fast-Retransmit und dem Warten auf die Ankunft verspäteter Segmente dar. Einerseits will der Sender schnell die fehlenden Segmente wieder senden und andererseits versuchen, die Übertragung nicht zu oft zu wiederholen, um das Netz nicht unnötig zu belasten. Ein Retransmit-Timer kann bei TCP implementierungsabhängig für das aktuelle Segment am Anfang der Sende-Queue oder segment-individuell getriggert werden.

Um eine Überlastung des Empfängers zu vermeiden, bietet TCP einen Flusskontrolldienst (Flow Control Service). Mit diesem Dienst kann der Empfänger die Senderate des Senders so verringern, daß der Empfangspuffer nicht überläuft. Dazu hat jeder TCP-Prozess eine Variable, die man Empfangsfenster (receive window) nennt. Dieses Empfangsfenster zeigt an, wie viel freier Pufferplatz noch beim Empfänger vorhanden ist. Wann immer der Sender Daten sendet, zieht er den zur Speicherung notwendigen Platz vom Empfangsfenster ab. Falls kein Patz mehr da ist, sendet der Sender keine weiteren Daten. Damit dies funktioniert, teilt der Empfänger dem Sender in jedem Segment, das er an den Sender schickt, im 16-Bit-Feld „Fenstergröße“ (WINDOW-Feld) des TCP-Headers mit, wieviel freien Platz er aktuell noch im Empfangspuffer hat. Nun kann der Sender jeweils maximal so viele Daten senden, wie noch Empfangs-pufferplatz übrig ist. Wenn der Empfängerpuffer voll ist, wartet der Sender, bis er vom Empfänger ein Segment erhält, in dem wieder neuer freier Platz gemeldet wird. Damit dies auch dann funktioniert, wenn der Empfänger gerade keine Anwendungsdaten an den Sender zu schicken hat, muß der Empfänger in diesem Fall ein leeres Segment ohne Dateninhalt an den Sender schicken, in dem er den freien Empfangspufferplatz mitteilt. Sonst wäre der Sender blockiert, und könnte trotz freien Empfangspuffers keine Daten mehr senden. Es gibt noch einen weiteren Fall, in dem die Verringerung der Senderate des Senders sinnvoll ist. Falls das Netzwerk überlastet ist, macht es Sinn, die Senderate zu verringern. Dies nennt man auch Überlastungskontrolle (Congestion Control, Congestion Window) (Vergleich: „Sliding Window“ mit „Congestion Window“).

Die Roundtrip-Zeit (Round-Trip Time, RTT) zwischen A und B ist die Zeit, die benötigt wird, um eine Nachricht von A zu B und die zugehörige Bestätigung zurück zu übermitteln. Das Empfangsfenster muß mindestens die Daten von A aufnehmen, die im Zeitintervall [t – RTT/2, t + RTT/2] unterwegs sind. Es muß also mindestens so groß sein, daß es noch die Daten aufnehmen kann, die innerhalb einer Roundtrip-Zeit übertragen werden.

Würde ein UDP- oder TCP-Segment (oder ein Segment eines fiktiven Schicht 4-Protokolls) an die IP-Schicht zum Senden übergeben werden und dann von der IP-Schicht in mehrere IP-Datagramme aufgeteilt werden, so könnte das diese IP-Datagramme empfangende IP die empfangenen IP-Datagramme nicht mehr in der richtigen Reihenfolge zum ursprünglichen Segment zusammenfügen (innerhalb jeweils eines IP-Datagramms kann das IP die Daten-Reihenfolge jedoch sehr wohl garantieren). Daraus und auch weil Segmente in der Transportschicht die atomaren header-tragenden PDU-Einheiten sind folgt, daß jedes Segment genau von einem IP-Datagramm transportiert werden muß (ein IP-Datagramm darf dabei problemlos in mehrere Pakete aufgeteilt werden) und auch in dieses hineinpassen muß (UDP:65535 - 8 - 20, TCP: 65535 - 20 - 20). Allein aus der Länge eines empfangenen IP-Datagramms läßt sich somit, sowohl für UDP als auch TCP die Länge des enthaltenen Segments empfängerseitig berechnen. Zumindest bei Verwendung des zugrundeliegenden IPv4 ist das Feld „Segment-Länge“ also nicht unbedingt nötig. Es kann jedoch neben der Prüfsumme dazu verwendet werden, speziell die Länge zu verifizieren und es macht auch deutlich, daß UDP im Gegensatz zu TCP nachrichten-paket-basiert und nicht stream-basiert ist. Das Segment-Längen-Feld wird also nur akademisch/konzeptionell zur Anwenderschicht hin verwendet. Zur Vermittlungsschicht hin wird die Länge der Segmente bzw. der korres-pondierenden IP-Datagramme implizit verwendet.

Kumulative Bestätigung: Der Empfänger bestätigt den Empfang einer korrekt empfangenen Folge von Segmenten. Im Beispiel hat der Empfänger zwei Segmente mit Sequenznummern 0 und 250 mit insgesamt 330 Byte korrekt empfangen, dann sendet er ein Segment mit der Bestätigungsnummer 330. Der Empfänger weiß dann trotz des nicht explizit empfangenen ACK=250, daß bis 330 alles nahtlos empfangen wurde.

Go-Back-n-Protokoll: Der Empfänger bestätigt nur die bisher lückenlos korrekt empfangenen Segmente. Der Sender muß die Segmente nach einer gewissen Zeit nochmal senden, wenn sie nicht bestätigt sind. Beispiel: Gesendet werden drei Segmente mit den Sequenznummern 0, 250 und 330. Korrekt empfangen werden die beiden Segmente mit Sequenznummern 0 und 330. Bestätigt wird das Segment mit der Sequenznummer 0 durch die Bestätigungsnummer 250. Vom Empfänger wird das Segment mit Sequenznummer 330 hier nicht gespeichert. Der Sender muß die Segmente mit Sequenznummern 250 und 330 nochmals senden.

TCP benutzt zur Übertragung seiner Segmente den unzuverlässigen Übertragungsdienst des IP-Protokolls. Insbesondere garantiert IP nicht, daß IP-Datensegmente unverfälscht ankommen. Deshalb fügt TCP eine eigene Prüfsumme zu jedem Segment hinzu.

Prüfsumme: Das gesamte Segment ohne das Feld Prüfsumme wird als Folge von 16-Bit-Wörtern (je 2 Byte) aufgefasst. Alle 16-Bit-Wörter werden mit Hilfe der Einer-Komplement-Arithmetik zu einer Summe addiert, der Überlauf links wird niederwertig dazu addiert. Das Einer-Komplement dieser Summe wird gebildet, indem alle Bits der Summe invertiert werden, das ist die angehängte Prüfsumme. Sie ist genau das Einer-Komplement der Einer-Komplement-Summe aller 16-Bit-Wörter des Segments. Der Empfänger berechnet (idealerweise) dieselbe Summe und addiert dabei zusätzlich die übertragene (invertierte) Prüfsumme, was in Summe zu „0xFFFF“ führt. Allerdings ist dieses Ergebnis nicht wirklich ein Beweis dafür, daß die Daten korrekt angekommen sind, sondern nur dafür, daß es zumindest keinen einzelnen Bitfehler gegeben hat. Für die Erzeugung der TCP-Prüfsumme werden auch Teile des IP-Headers in einen sogenannten „Pseudo-Header“ übernommen. Er dient nur zur Erzeugung der Prüfsumme und wird nicht übertragen. (Aufgrund der Doppelkodierung der Null in der Einer-Komplement-Darstellung muß man beim Addieren mit Überschreitung der Null eine Korrektur um Eins vorsehen. Dieses geschieht durch zusätzliches Addieren des beim Überschreiten entstehenden Übertrags.) 

TCP realisiert einen zuverlässigen Datenübertragungsdienst, d.h. Daten werden unver-ändert, vollständig und in der Reihenfolge beim Empfängerprozess abgeliefert, in der sie vom Senderprozess versendet wurden. Dabei werden folgende Mechanismen verwendet:

 1. Aufbau der TCP-Verbindung mittels Drei-Wege-Handshake. Eine zufällige initiale      Sequenznummer wird vereinbart.

2. Die Anwendungsdaten sind byteweise nummeriert, beginnend der initialen Sequenz-      nummer (+ 1).

3. Für die korrekte und vollständige Übertragung in der richtigen Reihenfolge brauchen       wir die Mechanismen Prüfsumme, Sequenznummer, Bestätigung und Timeout.

Die Prüfsumme wird über ein ganzes Segment gebildet. Durch die Prüfsumme wird die Korrektheit der empfangenen Bits in einem Segment festgestellt. Falls die Prüfung negativ ausgefällt, wird das Segment verworfen. Durch die Bestätigung weiß der Sender, ob die Daten angekommen sind, Durch ein Timeout kann ein Sender abschätzen, ob ein Segment verloren gegangen ist. Der Sender sendet ein Segment noch einmal, falls der Timer abgelaufen ist und die Bestätigung dafür noch nicht bei ihm angekommen ist oder vorzeitig, falls Bestätigungen sich wiederholen. Durch die Sequenznummern in den Segmenten kann der Empfänger die Daten in der richtigen Reihenfolge zusammensetzen. Die Sequenznummer ist die erste Byte-Nummer der Anwendungsdaten im Segment.

4. Für die Flusskontrolle gibt es im TCP-Header das Feld Empfänger-Fenstergröße, die     angibt, wie groß sein aktuelles Empfangsfenster ist; d.h. wieviele Daten der Empfänger     noch aufnehmen kann.

Die Transportschicht des Internet bietet mit UDP (User Datagram Protocol) und TCP (Transmission Control Protocol) zwei verschiedene Transportdienste an, die jeweils  „logische“ Endpunkt-zu-Endpunkt-Kommunikationsdienste zur Verwendung zwischen zwei (Anwendungs-)Prozessen zur Verfügung stellen. TCP bietet einen zuverlässigen Datenübertragungsservice, während UDP nur einen unzuverlässigen (verlustbehafteten) Datenübertragungsservice bietet. Wann sollte ein Anwendungsentwickler nun welches Protokoll benutzen?

UDP weist neben der eingeschränkten Zuverlässigkeit auch eine Reihe von Vorteilen auf: UDP ist ein verbindungsloses Protokoll und kommt daher ohne Verbindungsaufbau und Verbindungsabbau aus. UDP speichert keinen Verbindungszustand und kommt daher mit einer einfacheren Implementierung aus. Ein Serverprozess, der mit UDP arbeitet, kann daher deutlich mehr Clients bedienen; UDP kommt mit einem Header von nur 8 Byte aus. Dies verringert den administrativen Aufwand gegenüber TCP, das einen 20 Byte langen Header aufweist. Pro Segment kann UDP somit 12 Byte mehr übertragen; UDP erlaubt Anwendungen so viele Daten pro Zeiteinheit zu versenden, wie sie Daten generieren (abhängig von Algorithmus, CPU etc.) und über die Netzwerkkarte in das Internet einspeisen können. Dies bedeutet jedoch nicht, daß alle diese Daten auch beim Empfänger ankommen. Insbesondere kann es aufgrund von Überlast zu Nachrichtenverlusten kommen.

Aufgrund obiger Vorteile wird UDP z.B. von den folgenden Internetanwendungen benutzt: Remote file server (NFS: Network File System), Streaming Multimedia Anwendungen, die einen schnellen Datentransferbrauchen und mit Nachrichtenverlusten leben können (z.B. Video-Übertragungen), Internet Telephony Anwendungen, die bei Nachrichtenverlusten eine etwas schlechtere (aber oft noch verständliche) Sprachqualität liefern können. Network Management Anwendungen (SNMP: Simple Network Management Protocol) kontrollieren Netzwerke, die bei Überlastung des Netzes noch am ehesten UDP-Kommunikation durchführen können.  Das Domain Name System (DNS) übersetzt symbolische Namen in IP-Adressen. Bei Verlust einer Anfrage wird die kurze Anfrage erneut gestellt oder an einen anderen Server gerichtet.

TCP hingegen realisiert einen zuverlässigen bidirektionalen Datenübertragungsdienst mit Flusskontrolle. Deshalb entlastet TCP den Anwendungsprogrammierer von der expliziten Behandlung von Bit-Fehlern, Paketverlusten, Paketvertauschungen und Puffer-überläufen im Anwendungsprogramm. Mit diesen angenehmen Leistungen sind aber auch ein paar Nachteile verbunden: TCP ist ein verbindungsorientiertes Protokoll. Damit einher geht eine initiale Verzögerung bei der Datenübertragung (verursacht durch das 3-Wege-Handschlag-Verfahren beim Verbindungsaufbau). Dieses war eine der Hauptursachen für die Wartezeiten beim WWW, denn bei HTTP Version 1.0 wird für jede Anforderungsnachricht eine neue Verbindung aufgebaut. TCP speichert den Verbindungszustand in der TCP-Implementierung auf Sender- und Empfängerseite. Diese Informationen/Ressourcen (Puffer, Zustandsvariable) werden zur Verwaltung der Verbindung und zur Erbringung der Diensteigenschaften benötigt. Daher kann ein Server, der mit TCP arbeitet, weniger Clients bedienen als ein gleich ausgestatteter Server, der mit UDP arbeitet. Der TCP-Header ist 20 Byte lang gegenüber 8 Byte bei UDP. TCP verbraucht also mehr Bandbreite für Verwaltungsinformation als UDP. TCP bietet eine Flusskontrolle, die den Senderprozess am Verschicken zu vieler Nachrichten hindert. Dies ist dann ein Nachteil, wenn eine Echtzeitanwendung zwar Paketverluste tolerieren kann, aber immer eine minimale Senderate haben muß (zeitlich nicht elastische Anwendungen z.B. bei der Übertragung von Live Video). TCP wird z.B. von den folgenden Internetanwendungen benutzt: Electronic Mail (SMTP) Anwendungsgebiete von TCP: Remote Terminal Access (Telnet), WWW (HTTP), File Transfer (FTP), usw.

Mangels Fluss- und Überlaufkontrolle bremst sich UDP nicht selbst aus, wodurch eine minimale Daten-Bandbreite gewährleistet werden kann. UDP hat auch keinen 3-Wege-Handshake.

Der URL in der HTTP-Anfrage muß eventuell erst mittels einer DNS-Server-Anfrage zur IP-Adresse gewandelt werden (z.B. mittels der Sockel-Funktion gethostbyname()).

Datenaustausch via HTTP: Der Web-Browser öffnet eine TCP/IP-Stream-Sockel mit Angabe des Ziel-Ports(80/443) und der Ziel-Host-IP. Der Web-Browser baut die Anfrage im HTTP-Format zusammen und übergibt diese mitsamt dem Ziel-Port und der Ziel-IP and den Web-Sockel in die Transportschicht.

Der bearbeitende Prozess auf der Transportschicht baut (aufgrund eines applikativen connect()-Aufrufs) mittels des Drei-Wege-Handshake eine Verbindung zum Server auf. Die von der Transportschicht gemäß dem TCP-Protokoll generierten TCP-Segmente werden an die darunterliegenden Schichten weitergereicht und in jeder Schicht mit neuen PDU-Headern versehen (speziell: Multiplexing auf Schicht  4(Port) und 3(IP-Adresse)).

Der Server horcht auf eingehende Aufträge, akzeptiert die TCP-Verbindung, parst die empfangen Client Anfrage und versendet die Antwort-Nachricht unter Bezugnahme der bestehenden Verbindung über den verbindungsspezifischen Verbindungssockel.

Seitenaufbau im Webbrowser: Der Client empfängt das angefragte Objekt und zeigt es an.

Ggf. schließt der Client noch die Verbindung für diese Link-Anfrage.