Telematik 2

Application Layer Protocols definieren die Art der ausgetauschten Nachrichten, die Syntax der Nachrichten, die Semantik der Felder und Regeln für die Prozesse.

Beispiele:

• HTTP/HTTPS
• FTP
• SMTP
• ...

TCP:

• Verbindungsorientiertes Transportprotokoll: Es wird zunächst eine Verbindung zwischen den Rechnern hergestellt, bevor die Daten über diese Verbindung verschickt werden.
• Zuverlässiges Transportprotokoll: Es wird sichergestellt, dass die Datenübertragung ohne Verluste erfolgt
• Flow Control: Kontinuierliche Datenübermittlung wird sichergestellt
• Congestion Control: Der Sender reduziert ggf. die Anzahl der Datenpakete, wenn das Netzwerk überlastet ist

=> TCP stellt keine Garantie für eine minimale Bandbreite oder für die benötigte Zeit sicher!

UDP (User Datagram Protocol):

• Verbindungsloses Transportprotokoll: Die Datenpakete werden ins "Blaue" verschickt, ohne vorher eine Verbindung aufzubauen
• Kein Verbindungsaufbau
• Keine Zuverlässigkeit
• Kein Flow / Congestion Control

=> UDP für Anwendungen geeignet, die die Zuverlässigkeit von TCP nicht benötigen (i.d.R. Multimedia Streaming etc.)

Der 3-Wege-Handshake ist ein mehrstufiges Verfahren zur wechselseitigen Authentifizierung zwischen zwei Instanzen. Hierbei baut der 3-Wege-Handshake in drei Schritten eine verlustfreie Datenübertragung zwischen zwei Instanzen, beispielsweise einem Client und einem Server, auf. Konkret funktioniert der Handshake wie folgt:

1. Host A sendet ein Datenpaket mit einem Synchronisations-Flag (SYN) an Host B
2. Host B empfängt die Syn-Anfrage von Host A und bestätigt diese mit einem SYN-ACK, einem Synchronisations-Flag (SYN) und einem Bestätigungs-Flag (ACK)
3. Host A bestätigt seinerseits den Empfang der SYN-ACK-Flags mit einem Bestätigungs-Flag (ACK)
4. Host B empfängt das Bestätigungs-Flag von Host A und etabliert eine Socket-Verbindung

HTTP ist ein zustandsloses Protokoll, wobei die Kommunikation zwischen Client und Server über Nachrichten erfolgt (HTTP-Request und HTTP-Response). Jede Nachricht besteht aus einem Nachrichtenkopf und einem Nachrichtenkörper. Der Nachrichtenkopf enthält Informationen über den Nachrichtenkörper, wie etwa die verwendete Kodierung oder den Inhaltstyp, damit der Empfänger die Nachricht korrekt interpretieren kann. Der Nachrichtenkörper enthält schließlich die Nutzdaten.

Wenn auf einer Webseite beispielsweise der Link zur URL http://example.de/info.html aktiviert wird, so wird an den Computer mit dem Hostnamen example.de die Anfrage gesendet, die Datei mit dem Namen info.html zurück zu schicken. Der Hostname wird dabei zunächst über das DNS-Protokoll in eine gültige IP-Adresse aufgelöst. Zur Übertragung wird über TCP auf den Standard-Port 80 des HTTP-Servers eine HTTP-GET-Anforderung gesendet. Sobald der Header mit zwei aufeinanderfolgenden Leerzeichen abgeschlossen wird, sendet der Computer, der einen Web-Server an Port 80 betreibt, seinerseits ein HTTP-Response zurück. Diese besteht aus den Header-Informationen des Servers, einer Leerzeile und dem tatsächlichen Inhalt der Nachricht, also dem Dateiinhalt von info.html.

Bei HTTP/1.0 wird vor jeder Anfrage eine TCP-Verbindung aufgebaut und nach Übertragung der Antwort standardmäßig wieder geschlossen. Enthält ein Dokument beispielsweise 10 Bilder, so werden zur Übertragung der Bilder 10 TCP-Verbindungen benötigt (nichtpersistente HTTP).

Seit HTTP/1.1 kann der Client den Wunsch äußern, die Verbindung aufrecht zu erhalten, um die Verbindung erneut nutzen zu können (persistente HTTP). Die Unterstützung auf Serverseite ist jedoch optional und kann insbesondere bei Verwendung eines Proxys Probleme bereiten. Daher können seit HTTP/1.1 auch mehrere Anfragen und Antworten mittels HTTP-Pipelining über eine TCP-Verbindung gesendet werden.

Cookies sind kleine Textdateien im Web-Brwoser, die der Web-Server als Reaktion auf Anforderung des Clients sendet. In Cookies wird das Verhalten des Nutzers registriert (z.B. Passwörter, persönliche Daten des Nutzer, welche Seiten er zuletzt besucht etc.). Diese Dateien werden zunächst im Hauptspeicher zwischengespeichert und beim Schließen des Browsers in einer Textdatei abgelegt. Beim nächsten Aufruf des Servers werden die Daten wieder aufgefrufen, um die letzte Sitzung wieder herzustellen. Dies erleichtert Login-Prozeduren, kann aber auch benutzt werden, um Nutzungsgewohnheiten eines Besuchers zu protokollieren.

Für Cookies müssen folgende Komponenten zusammen spielen:

1. Cookie Header im HTTP Response
2. Cookie Header im HTTP Request
3. Gespeichertes Cookie auf Client-Rechner sowie Cookie-Manager im Browser
4. Datenbank an der Webseite

SMTP:

SMTP ist ein Protokoll der Internetprotokollfamilie, das zum Versenden von E-Mails dient. Das Protokoll benutzt eine persistentente TCP-Verbindung auf Port 25, um E-Mails vom Client auf den Server zu transferieren. Die Kommunikation erfolgt dabei in drei Phasen:

1. Verbindungsaufbau (Handshake)
2. Transfer der Nachrichten über Port 25
3. Schließen der TCP-Verbindung

POP3:

Das POP3-Protokoll ist ein Übertragungsprotokoll, über das ein Client E-Mails von einem Mail-Server abholen kann. Die Funktionalität ist sehr beschränkt und erlaubt nur das Auflisten, Abholen und Löschen von E-Mails am E-Mail-Server.

IMAP:

IMAP ist ein Übertragunsprotokoll, das dazu dient, Abhängigkeiten von Client-Rechnern aufzulösen. Zu diesem Zweck erweitert IMAP das POP3-Protokoll so, dass Benutzer ihre Mails, Ordnerstrukturen und Einstellungen auf den auf sem Server speichern und belassen können. Die Clients greifen direkt online auf die Informationen des Servers zu und müssen allenfalls Kopien davon beherbergen.

Der Benutzer kann in seinem Browser einen sog. Proxy Server einstellen. Dieser dient dann als Web Cache, d.h. der Browser sendet zunächst alle HTTP-Anfragen an den Cache. Ist das benötigte Objekt bereits im Cache, so wird das Objekt vom Cache geladen und an den Browser zurück geschickt. Andernfalls wird die HTTP-Anfrage an den Original-Web-Server weiter geleitet und seine Antwort im Cache gespeichert.

Vorteile:

• Reduzierung der Antwortzeit durch Cache
• Reduzierung des Traffics einer Institution
• Überprüfung der HTTP-Responses auf unerwünschte Inhalte

Bei einem Condiditonal-GET ist die Anforderung von Daten an bestimmte Bedingungen geknpüpft. Die genauen Bedingungen sind dabei im Header-Feld "Condiditonal" hinterlegt. Häufig zu finden sind zum Beispiel If-Modified-Since, If-Unmodified-Since oder If-Match. Mit Hilfe dieser Bedingungen kann die Netzwerkbelastung signifikant reduziert werden, da somit nur die wirklich benötigt Daten übertragen werden. In der Praxis nutzen zum Beispiel Proxyserver diese Funktion, um die mehrfache Übertragung von Daten, die sich bereits im Cache befinden, zu verhindern.

1. Process Model

• Ein HTTP-Request wird in einem Prozess ausgeführt
• Wenn der HTTP-Request ausgeführt wurde, kann eine neue Verbindung aufgebaut werden
• Typischerweise werden hierfür mehrere Prozesse benötigt (Beispiel: Apache Web-Server)

Vorteile:

• Schutz zwischen Prozessen bei einem Crash

Nachteile:

• Schlechte Performance, da context switching overhead
• Performance-Optimierungen können schlecht durchgeführt werden

2. Thread Model:

• Anfragen werden in eigenen Threads (statt in eigenen Prozessen) ausgeführt
• Beispiele: IIS, Apache (Windows)

Vorteile:

• Performance besser als bei Process Model

Nachteile:

• Betriebssystemunterstützung notwendig, um Threads auf dem Prozessor zu starten
• Anzahl der Threads kann das per-process-limit erschöpfen

3. Kernel Model:

Der gesamte Server liegt im Kernel, d.h. Vermeidung von Kopiervorgängen zwischen Kernel und User-Space

Vorteile:

• Sehr schnell

Nachteile:

• Fehler können sehr schwerwiegend sein
• Schwer zu debuggen
• Betriebssystemunterstützung notwendig

4. Event-driven Model:

Ein einzelner ereignisgesteuerter Prozess, der sich um die Abarbeitung konkurrierender Requests kümmert, wird verwendet.

Vorteile:

• Sehr schnell
• keine context-switches notwendig
• komplette Kontrolle über Scheduling
• keine Betriebssystemunterstützung notwendig

Nachteile:

• Per-process Ressourcen Limits
• OS muss volles asynchrones I/O haben

FTP ist ein Netzwerkprotokoll zur Übertragung von Dateien über Computernetzwerke. Hierbei erfolgt der eigentlich Datenaustausch über eine TCP-Verbindung über Port 20 und ein Verbindungsaufbau auf Port 21.

Das Domain Name System ist einer der wichtigsten Dienste in der Netzwerkkommunikation. Seine Hauptaufgabe ist die Beantwortung von Anfragen zur Namensauflösung:

• Übersetzung Hostname zu IP-Adresse
• Aliasing (Namen auf anderen Namen auflösen)
• Load distribution (Verteilung eines Namens auf mehrere IP-Adressen)

Die DNS-Einträge werden in einer Datenbank auf einem DNS-Server im RR-Format gespeichert.

Recursive Query

=> Server holt die Daten von einem anderen Nameserver

Iterative Query

=> Server antwortet mit einem oder mehreren Verweisen oder mit einem Ressource Record auf andere Nameserver

Der Begriff Multimedia bezeichnet Inhalte und Werke, die aus mehreren (meist digitalen) Medien bestehen (primär Audio & Video, also kontinuierliche Medien).

Multimediaanwendungen sind typischerweise sensitiv gegenüber Delays, aber tolerant gegenüber Datenverlust.

1. Streaming Anwendungen:

=> Client fordert Audio- bzw. Videodaten vom Server an und stellt sie noch während der Datenübertragung dar

=> Streaming-Anwendungen sind interaktiv, d.h. der Nutzer kann das Abspielverhalten kontrollieren (Pausieren, Vorspulen, Zurückspulen etc.)

2. Unidirektionale Echtzeit Multimediaanwendungen

=> Echtzeit-Streaming (ähnlich wie bei Radio / TV)

=> Nicht-interaktiv

3. Interaktive Echtzeit-Anwendungen:

=> Höhere Anforderungen an Delayzeiten, da Echtzeit

=> Beispiel: Telefon- oder Videokonferenzen

Sämliche Internetprotokolle (TCP, UDP) sind "best-effort services", d.h. sie geben keine Garantie für ein bestimmtes Delay oder für den Datenverlust. Multimediaanwendungen benutzen deshalb Techniken auf Applikationsebene, um diese Probleme zu beheben bzw. zu verringern:

• Puffern, um Schwankungen in der Ankunftsrate auszugleichen
• UDP statt TCP, um die TCP-Rate-Control zu umgehen
• Kompressionsrate für die verfügbare Bandbreite

Ansätze im IP-Netzwerk:

• Mehr Bandbreite, Caching, Routing Policy ändern
• Zur Segmentierung einer Multimedia-Datei werden verschiedene Protokolle (Real Time Protocol, RTP) benutzt

1. RTP/RTCP => Transportprotokoll
2. RTSP => Session Layer für Streaming
3. SIP => Session Iniitation Protocol (Alternative zu H.323)

=> Alle diese Protokolle setzen auf TCP für den Steuerungsanteil bzw. UDP für den Datenverkehr auf

Als Jitter wird in der Datenübertragung die Phasenschwankungen und damit die zeitlichen Änderungen von Signalfrequenzen bezeichnet. Es handelt sich dabei um Schwankungen von fixierten Zeitpunkten, z.B. dem Zeitpunkt des Übergangs von einer Signalamplitude eines Signals auf eine andere. Dadurch können sich Bezugszeitpunkte verschieben, was zu einer Fehlinterpretation der Signale, zu Paketverlusten und damit zur Verschlechterung der Übertragunsqualität in Echtzeitanwendungen führt.

Ein Jitter kann man verhindern, indem die Daten in einem ausreichend großen Puffer zwischengespeichert werden. Je größer der Jitter, desto größer muss der Puffer sein!

Das Real-Time-Transport-Protokoll ist ein Protokoll zur kontinuierlichen Datenübertragung und dient dazu, Multimediadatenströme über ein Netzwerk zu transportieren, d.h. die Daten zu kodieren, zu paketieren und zu versenden. RTP ist ein paketbasiertes Protokoll und wird normalerweise mit UDP betrieben.

Das Real-Time-Control-Protokoll arbeitet eng mit RTP zusammen und dient zur Aushandlung von Quality-of-Service-Parametern.

RTP besteht aus folgenden Komponenten:

1. Synchronization Source (SSRC):
   => Datenquelle wird als Synchronization Source bezeichnet und durch einen 32-Bit-Identifikator im Header dargestellt
2. Translator:
   => Leitet eingehende RTP-Pakete weiter und lässt dabei den SSRC-Identifikator intakt (dienen zum Überwinden von Firewalls)
   => Können auch die Kodierung der übertragenen Daten verändern (Payload Type und Timestamp muss angepasst werden)
3. Mixer:
   => Kombinieren die Datenströme mehrerer Quellen zu einem neuen Datenstrom und leiten diesen weiter (dabei kann Kodierung verändert werden)
   => Da der Mixer mit den Quellen nicht synchronisiert sein muss, muss der Mixer ein eigenes Timing für den kombinierten Stream erzeugen (Mixer trägt seine eigen SSRC-ID in Header für ausgehende Pakete ein)
4. Empfänger:
   => Der Empfänger der RTP-Pakete sortiert diese anhand der Sequenznummer und stellt sie der Anwendung zur Verfügung
5. RTP-Paket:
   => Ein RTP-Paket besteht aus einem Header mit Versions- und Sequenznummern, Datenformat, SSRC, Zeitstempel, Nutzdaten
6.  

Variante 1: Dateien werden als HTTP-Objects übertragen (kein echtes Streaming, da Dateien herunterladen werden müssen)

Variante 2: Der Client (Browser) erhält ein Metafile, welches den zu erwartenden Datenstrom beschreibt, und reicht dieses an einen Player weiter. Optimalerweise zeigt die Beschreibung auf einen Streaming Server.

Über das Session Initialization Protokoll können Sitzungen mit zwei oder mehreren Teilnehmern aufgebaut, modifiert und beendet werden. SIP basiert auf HTTP und dient zur Übertragung von Echtzeitdaten in paketbasierten Netzen.

SIP ist funktional ähnlich zu H.323, basiert jedoch auf einem Transaktionsmodell statt einem Verbindungsmodell. Außerdem kann SIP SSL und TSL für die Sicherheit nutzen. Zum Aufbau der Teilnehmerverbindung wird eine eigene SIP-Adresse verwendet, da sich die IP-Adresse ändern kann. SIP-Informationen können entweder über TCP oder UDP ausgetauscht werden.

1. Pakete müssen markiert und dementsprechend priorisiert werden
2. Schutz/Isolation der Klassen voreinander (z.B. wenn Audio mit höherer Framerate sendet als erlaubt)
3. Ressourcen müssen so effizient wie möglich eingesetzt werden
4. Erlaubnis-Erteilung: Netzwerk kann einen Anruf blockieren, wenn dessen Belange (momentan) nicht erfüllt werden können

Beim Scheduling wird das Paket ausgewählt, welches als nächstes versendet werden soll. Beispielsweise können die Datenpakete in Ankunftsreihenfolge, also nach dem FIFO-Prinzip, verschickt werden. Bei allen Scheduling-Algorithmen sind Richtlinien notwendig, die bestimmen, welche Pakete verworfen werden sollen, wenn die Queue voll ist.

Scheduling-Richtlinien:

1. Priority Scheduling
2. Round-Robin-Scheduling
3. Weight Fair Queuing

Ziel: Limitieren des Traffics, so dass die deklarierten Paramter nicht überschritten werden:

1. Long Term Average Rate
2. Peak Rate
3. Max Burst Rate

Das Tocken Bucket ist eine Definition der Datentransferrate und besteht aus den drei Komonenten

• Größe des Bursts
• Mittlere Übertragunsrate
• Zeitintervall

Mit dem Token Bucket werden Geräte verwaltet, die den Datenfluss steuern. Token bucket und WFQ kombiniert garantieren eine Delay-Obergrenze, ergeben also eine QoS-Garantie.

IntServ (integrated services) ist ein Verfahren, das eine bestimmte Dienstgüte für Multimediaanwendungen garantiert. Mit IntServ können Echtzeit-Anwendungen effizienter und mit maximal möglicher Performance übertragen. Um dies zu erreichen, wird im IntServ-Modell von folgenden Annahmen ausgegangen:

1. Die zur Verfügung stehenden Ressourcen müssen explizit verwaltet werden
2. Dienstgarantien können nicht ohne Ressourcen-Reservierung erfolgen
3. P2P-Verzögerungen werden begrenzt

Bei IntServ frag der Host bei den Routern im Netzwerk zunächst an, ob die Ressourcen für einen Verkehrsfluss vom Sender zum Empfänger vorhanden sind. Danach stellen die Vermittlungssysteme (hierbei wird das Resource Reservation Protocol verwendet) die Verbindung in der gewünschten Qualität her und halten sie bis zum Übertragunsende aufrecht. Das Konzept sieht mehrere Prioritätsklassen vor, die unterschiedliche QoS-Klassen repräsentieren.

Das Resource Reservation Protocol (RSVP) ist ein Protokoll zur Reservierung von Bandbreite in IP-basierten Netzwerken. Dabei wird zuerst ein Pad über die Router aufgebaut, indem das Protokoll periodisch Pfad-Mitteilungen vom Sender zum Emfpänger schickt. Diese Pfad-Mitteilungen dienen der Erkundung, Festlegung und Reservierung der Route für RSVP-Nachrichten. Sie werden von RSVP-fähigen Routern ausgewertet und reservieren in den Routern die entsprechende Bandbreite für die spätere Übertragung. Der Empfänger bestätigt die Reservierungsroute und die Datenpakete mit den Nutzdaten können über diese reservierte Route übertragen werden.

Vorteile:

• Strikte QoS-Regelung

Nachteile:

• Apps können QoS-Anforderungen oftmals nicht speziifizieren, da sich diese über die Zeit ändern können oder beim Start einer Session unbekannt sind
• Schlechte Skalierbarkeit, da viel Signaling und Policying notwendig

DiffServ ist ein Verfahren zur Übertragung von Echtzeitanwendungen über IP-basierte Netzwerke. Bei DiffServ ist die Dienstgüte in weniger QoS-Klassen unterteilt als bei IntServ. Jeder Dienstklasse steht ein Satz von Regeln zur Verfügung, die sog. Per-Hob-Behavior (PHB). PHB legt dabei fest, welche Klasse welche Priorität besitzt. Hierfür gibt es zwei Strategien:

1.     Expedited Forward (EF)
2.     Assured Forward (AF)

DiffServ ist erheblich einfacher als IntServ, da nicht jeder Datenfluss verwaltet werden muss. Die Daten werden nur am Eingang des DiffServ-Netzes bearbeitet und die Dienstklassen festgelegt. Dazu wird das sog. DSCP-Feld im DiffServ-Header entsprechend markiert. Dieses Feld entspricht dem Typo-of-Service-Feld (ToS) im IPv4-Header und dient dazu, die einzelnen Datenströme eins Verkehrsbündels auseinander zu halten.

Sind in einer Diff-Serv-Verbindung mehrere ISPs eingebunden, so wird die Dienstklasse zwischen den einzelnen ISPs bei jedem neuen ISP-Netz verhandelt.

1. Sehr langsam, da bei jedem hop ein ein IP-Lookup notwendig
2. Keine Auswahl beim Pfad (muss immer der kürzeste sein)
3. Keine QoS-Garantien

Multi-Label Protocol Switching (MLPS) ist eine Technik mit der Netzwerkbetreiber höherwertigere Dienste im Kernnetzbereich implementieren. Hierbei werden die Services durch Tags in den Datenpaketen gekennzeichnet. Die Carrierer kennzeichnen mit diesen Tags bestimmte Service-Klassen, die vom Kernnetz unterstützt werden.

• Forwarding durch einfaches Suchen des Labels in Switching Table
• Switching Table wird a priori mit einzigartigem next-hop label geladen, sowie output port und queuing & scheduling rules

Terminologie:

• Label = Identifer einer festen Länge mit dem man eine FEC identifizieren kann
• FEC = Forward Equivalence Class repräsentiert eine Menge von Paketen, welche die gleichen Forwarding requirements aufweisen
• LSR = Label Switched Router
• LER = Label Edge Router
• NHLFE = Next Hop Label Forwarding Entry
• ILM = Incoming Label Map
• LSP = Label Switched Path

Kernkonzept:

• Trenne Kontrolle und Forwarding klar voneinander
• Forwarding = befasst sich damit, wie die Pakete zwischen IP-Routern ausgetauscht werden
• Kontrolle = richtet Pfade ein mit Labels und konvertiert diese in Forwarding Tables

Ingress LSR:

• Router, der den Übergang zu einem MPLS-Netz herstellt
• Ist für die Vergabe des ersten Labels verantwortlich
• Teil das Paket einer LSP und einer FEC zu

LSR in der MPLS-Domain

• In den LSR, die sich in der MPLS-Domain befinden, werden lediglich die den MPLS-Paketen vorgeschalteten Labels ausgewertet

Egress LSR

• Router, der den Ausgang eines MPLS-Netzes symbolisiert

1. Flexibilität
   • Router kann alle verfügbaren Informationen nutzen, um zu bestimmen, an welches Label ein Paket gesendet wird
   • Verteilung der Labels kann beliebig komplex sein
   • Ein Label repräsentiert somit einen aufgebauten Weg im Netzwerk, ohne diesen komplett angeben zu müssen
   • Multiprotocol: beliebige Netzwerkprotokolle einsetzbar
2. Hilf verbindungsähnliche QoS-Garantien zu unterstützen
   • Fixed capacity für spezifische Anwendung
   • Control latency/jitter
   • Ensure capacity for voice
   • MPLS führt ein verbindungsorientiertes Modell in IP-basierte Netze ein
3. Traffic Engineering wird unterstützt
4. VPN-Unterstützung
5. Multi Protocol Support

Unter Multicast versteht man eine Übertragungsart, bei der Datenpakete von einem oder mehreren Sender, zu einer definierten Gruppe von Empfängern geschickt wird. Der Vorteil des Multicasting liegt darin, dass gleichzeitig Nachrichten über eine Adresse an mehrere Teilnehmer oder geschlossene Benutzergruppen übertragen werden können, ohne dass die benötigte Bandbreite mit der Anzahl der Empfangseinrichtungen ansteigt.

Beispiele:

1. Video-/Telefonkonferenz
2. Telelearning
3. IP-TV, Video on Demand
4. Softwareverteilung
5. ...