Telematik 2

Telematik 2 (T2)
Vertiefungsrichtung	II
Vorlesung
Vorlesender	Schäfer
Abschluß
Art	k.A.

---

Prüfung

Klausur
Termin
Datum:	07.03.2012
Zeit:	11:00 - 12:30
Ort:	HuHs

Am Ende des Semester gibt es eine Klausur die über 90 Minuten geht.

Kurzzusammenfassung

Diese Zusammenfassung erhebt weder den Anspruch auf Korrektheit noch auf Vollständigkeit. Sie soll lediglich als Art Merkstütze verstanden werden. Darum sind Korrekturen/Ergänzungen/Verbesserungen jeglicher Art gern gesehen.

Internet Application Layer

HTTP

• HTTP ist stateless
• drei unterschiedliche Verfahren um Objekte zu übertragegen: persistentes HTTP oder nicht, mit pipelining oder ohne:

  • Nichtpersistentes HTTP

    • für jedes Objekt wird neue TCP-Verbindung geöffnet
    • braucht dadurch mind. 2 Roundtripzeiten pro Objekt
    • verbraucht dadurch ständiges öffnen von TCP-Verbindungen auch im Betriebssystem mehr Ressourcen

    Persistentes HTTP

    • Verbindung bleibt offen und es können mehrere Objekte über die gleiche TCP-Verbindung übertragen werden

      Persistentes HTTP ohne pipelining

      • Client fordert neues Objekt erst an, wenn das letzte fertig übertragen wurde
      • mind. 1 RTT pro Objekt

      Pers. HTTP mit pipelining

      • Client fordert neue Objekte an, sobald er merkt, dass er mehrere braucht. Also auch schon, solange das Alte Päckchen noch Unterwegs ist.
      • braucht also mind. eine RTT für alle Objekte (wenn sie hinreichend klein sind)
• Wie bekomm ich per HTTP Daten ins Netz?
  • Wenns wenige sind einfach in der URL mitschicken (z.B. bei Suchanfragen)
  • Bei mehr Daten mit eingener Post-Methode - Daten Hängen dann im Nachrichtenkörper

Caching

• Caching fetzt ;)
• kann Antwortzeiten der Anfragen verringern (sofern nicht bei jeder Anfrage am ursprünglichen System nachgefragt wird, ob Daten noch aktuell sind)
• Verringert Traffic "nach Außen"

FTP

• Datenübertragung(Port 20) (Oder Kontrollverbindung (Port21), wie man's sieht) ist out of Band
• Datenverbindung wird nach jeder übertragenen Datei wieder geschlossen
• FTP-Server merkt sich den aktuellen Status

SMTP

• zum versenden von Mails
• Port 25
• drei Phasen: Begrüßung, Datenübertragung, Schließen
• persistente Verbindung
• alles in 7bit ASCII
• Ende von Mails wird durch CRLF.CRLF gekennzeichet

POP3

• lesen von Mails
• Übersicht, abrufen und löschen sind separate Befehle

DNS

• sorgt für Namensauflösung

  angebotene Dienste (plus entsprechende Records)

  • Hostname zu IP-Adress Übersetzung (A - name=hostname - value=IPAdresse)
  • Aliase für Hostnamen (CNAME - name=alias - value=canonical name (realer Name))
  • Mailserveraliasing (MX name=domainname - value=name des mailservers Hier: name=tu-ilmenau.de value=piggy.rz.tu-ilmenau.de.)
  • Lastverteilung (mehrere IP-Adressen für einen kanonischen Namen)
• weils grad hier her passt der NS-Record mappt die IP-Adresse des authoritative name servers auf einen Domainnamen
• Hierarchische Aufteilung der DNS-Datenbanken: Root DNS Server -> TLD DNS Server -> DNS Server von Einrichtungen (Authoritative DNS Server) -> Lokale DNS Server (gehören eigentlich nicht dazu und sind mehr als DNS-Proxys zu verstehen)
• zwei möglichkeiten von DNS:
  • rekursive Anfragen
    • DNS-Server kümmert sich selbst um die Antwort und fragt beim nächsten DNS nach und dieser dann wieder beim nächsten usw.
    • Das Ergebniss läuft dann die Fragekette bis zum Ursprung zurück
  • iterative Anfragen
    • dir wird nur der nächste DNS gesagt und du musst dich selbst drum kümmern den zu belästigen
• DNS server cachen natürlich auch

P2P

• mehrere Desings mit mehr oder weniger starker Zentralisierung

Napster

• ein zentraler Server, der verwaltet, wer was wo hat
• Wenn ich was will frag ich den Server wer's hat
• er sagt's mir und ich lads dann bei demjenigen runter

Gnutella

• komplett dezentralisiert

  Beitreten

  • muss erstmal einen finden, der schon im Netz ist
  • über den verschick ich dann Ping nachrichten
  • der leitets weiter und alle Empfänger antworten mit Pong
  • zu denen kann ich dann auch Verbindungen aufbauen

  Anfragen

  • Anfrage(nach Dateien) wird geflutet
  • Antwort gelagt über den umgekehrten Weg zurück
  • Filetransfer findet über HTTP statt
• insgesamt wird virtuelles Netz über vorhandenes Netz gelegt
• jeder Client idR mit <10 anderen verbunden

Kazaa

• so'n bissl Hierarchisch
• gibt groupleader, die untereinander verbunden sind
  • sind in der Regel Rechner die'n bissl länger im Netz hängen, können aber theoritsch alle Clients sein
• Groupleader weiß, was seine Kinders alles an Daten haben

  Anfragen

  • Anfrage an Groupleader
  • der Antwortet, wenn er was hat
  • kann Anfragen auch an andere Groupleader weiterleiten, dann antworten die halt
  • Antwort besteht aus: IP-Adresse, hash und Metadaten
• Client läd wieder per HTTP (wählt Datei anhand des hashwerts aus)

Multimedia

• Am Anfang geht's um verschiedene Multimediainhalte, und was die Vorraussetztungen dafür sind
• Der Rest dreht sich praktisch ausschließlich um Streaming
• Bei Streaming ziemlich blöd Daten erneut anzufordern, wenn was verloren gegangen ist - Deswegen:

Forward Error Correction

• einfachste Form: alles einfach mehrfach schicken
• besser: einfacher XOR Code
  • mehrere Pakete werden XORt und das Ergebnis in zusätzliches Paket geschrieben
  • eins der Pakete kann aus den andern wieder hergestellt werden (durch xor mit den andern ganzen Paketen)
• noch besser: Reed-Solomon Codes
  • es gibt n Datenpaket und k Reparaturpakete
  • Die Reperaturpakete sind Linearkombinationen der Datenpakete
  • bis zu k Pakete können verloren gehen (egal welche)
  • Der Rest kann einfach aus den andern Paketen wiederhergestellt werden (ist auch nur ein Gleichungssystem mit n Gleichungen und n Unbekannten)
• ganz anderer Ansatz: Mitschicken von geringerwertigen Kopien schon gesendeter Pakete in späteren Paketen
  • geht nur bei bestimmten Inhalten.
  • z.B. Videos - Wenn ein Bild nicht ankommt - wird's durch ein späteres Paket nachgeliefert
  • Dann isses zwar kurz matschig aber besser als ganz weg

Protokolle (nicht Prüfungsrelevant?)

RTP

• Real time transfer protocoll
• landet auf einem geraden Port (um es von RTCP zu unterscheiden)
• nur Sender (von Daten) verschicken RTP-Pakete
• setzt auf UDP auf
• bietet keinerlei Staukontrolle oder QOS
• im Header finden Payloadtype, Sequenznummer, Zeitstempel, Synchronisation Source Identifier (SSid), blah statt

RTCP

• real time transfer control protocol
• verwaltet RTP (dient u.a. zum Anpassen der Quelle an die Empfänger)
• geht an ungerade Ports
• jeder (Sender und Empfänger) sendet regelmäßig Daten über verlorene Pakete, Jitter, Nutzerdaten...
• sowohl RTP als auch RTCP gehen an die gleiche Multicastadresse - deswegen die unterschiedlichen Portnummern
• umso mehr Teilnehmer in einer Sitzung sind umso seltener schickt jeder einzelne RTCP-Pakete (RTCP soll max. 5% des zugehörigen RTP ausmachen)
• 75% des Traffics gehen an Sender 25% an die restlichen Teilnehmer

RTSP

• Real time streaming protocol
• kontrolliert Abspielvorgänge von Streams (pause, vorwärts, play...)
• out of band (Eine Verbindung für Kontrollnachrichten, eine für eigentliche Daten)
• kann sowohl mit udp als auch mit tcp

SIP

• Session Initiation Protocoll
• dient der Namensübersetzung, "klingeln", Einigung auf Codecs, "auflegen", alles, was man so für IP-Telefonie braucht
• eigentliche Daten werden über andere Protokolle übertragen z.B. RTP/UDP
• SIP Nachrichten sind Http ähnlich
• Damit das ganze funzt braucht man SIP-Registrare und SIP-Proxys
• am Registrar meld ich mich an, und teil ihm u.a. meine IP-Adresse mit
• SiP-Proxy routet Sip-Nachrichten zum Angerufenen, da ich mir nich für jede Person merken kann, an welchem Registrar er sich anmeldet (kann man mit lokalem DNS-Server vergleichen)

QOS

• vier Prinzipien benötigt um Servicegarantien einzuhalten:

1. Pakete müssen für Router markiert werden, damit sie die Pakete entsprechend der Richtilinien behandeln können
2. Einzelne Transportklassen müssen vor andern geschützt (isoliert) werden
3. Trotz Isolierung sollten Resourcen so effizient wie möglich genutzt werden
4. Call Admission: Wenn das Netzwerk die Wünsche eines neuen flows nicht mehr unterstützen kann wird er abgewiesen

Scheduling Policies

Priority Scheduling

• wer die höchste Priorität hat kommt zu erst

Round Robin

• durch die Klassen abwechseln

Weighted Fair Queing

• Round Robin mit Gewichten
• Jede Klasse bekommt pro Zyklus mehr oder weniger Menge an Service zugeteilt

Policing Mechanismen

Token Bucket

• Bucket wird mit konstanter Rate mit Tokens befüllt (bis zu max. Füllstand)
• Immer wenn Paket verschickt wird muss Token aus bucket entfernt werden

Technologien

Int-Serv

• Framework, welches mit Resourcenreservierung arbeitet
• Kanal ähnlich Virtuellem Circuit wird aufgebaut, dem vorher festgelegte Resourcen zugesichert sind
• Reservierung der Resourcen mit RSVP (Resource Reservation Protocol)
• Dabei werden R-Spec (QOS Anforderungen siehe Seite 24) und T-Spec (Traffic Charakteristik Seite 23) festgelegt, bzw. bekanntgegeben
• zwei Service Models (Klassen)
  • Guaranteed QOS (strikte Grenzen für harte real-time Anwendungen)
  • Controlled Load (Annäherung an Möglichkeiten eines unbelasteten Netztes)
• Sehr viel Status muss in allen Routern gemerkt werden
• Ein Ansatz um etwas Status zu sparen ist den Status von mehreren flows zusammenzufügen
  • entweder aufsummieren (wird angenommen, dass alle flows gleichzeitig aktiv sind)
  • oder zusammenfügen (wird angenommen, dass nur einer(wenige) gleichzeitig aktiv sind)
• INT-Serv ist nur das Framework - eigentliche Protokoll um den ganzen Mist zu koordinieren ist RSVP
  • bietet Unterstützungs fürs mergen von flows
    • ungefiltert: jeder Sender kann gesicherte Resourcen nutzen
    • statischer Filter: nur bestimmte Sender können reservierte Res. nutzen
    • dynamischer Filter: auch nur bestimmte Sender, aber die können auch mal wechseln
• Propleme an Int-Serv/RSVP:
  • für Anwendungen schwer zu sagen, wie viele Resourcen sie benötigt
  • Verdammt viel Status muss gehalten werden
  • Viel zu viel kommunikation, was benötigt wird
  • skaliert einfach nicht

Diff-Serv

• Ansatz ist das komplizierte an den Rand des Netzes zu verlagern und die Corerouter weiterhin nur einfache Aufgaben machen zu lassen
• Edge Router managen per flow und markieren Pakete
• Edge Router können Traffic auch Formen, wenn einer gegen Prinzipien seiner gezahlten Klasse verstößt etc.
• Muss Traffic-Klasse nur am Edgerouter anmelden und der packt mich dann in eine der vordefinierten Klassen im Kernnetz
• Core Router managen den Traffic nach Klassen und anhand der Markierungen, die am Rand getroffen wurden
• Diff-Serv kann keine sehr starken Garantien verteilen
• hat zwei Forwarding Strategien (per Hop)
  • Expedited Forwarding
    • Abgangsrate der Pakete einer Klasse >= vorgegebener Rate
    • Pakete landen alle in gleicher Que aber sobald Que länger als Klassengrenze ist werden für diese Klasse keine Pakete mehr angenommen
  • Assured Forwarding:
    • mehrere Traffic-Klassen, jede bekommt min. an Traffic
    • jede Klasse hat eigene Que und kommt nur dran, wenn in "besserer" Que keine Pakete mehr sind

DPS

• Dynamic Packet State
• soll Int-Serv ähnliche Guarantien bieten und so wenig State wie Diff-Serv
• Edge-Router packen State in Paket-Header
• Core-Router routen entsprechend state und ändern ihn entsprechnend neuem Status
• DPS nutzt fair queuing:
  • Datenströme, die mehr Bandbreite als obere Grenze verbrauchen, werden auf obere grenze Eingestampft (Mehr an Paketen wird verworfen)
  • In Paket steht aktuelle Rate des flows
  • Falls dieser größer als ist als Grenzbandbreite b, dann werden Pakete verworfen (mit Wahrscheinlichkeit 1-b/r)
  • In Paketheader der restlichen Pakete wird neue Rate (also b) reingeschrieben und weitergeleitet

Multi-Protocol Label Switching (MPLS)

• Grund: was effizienteres als normales IP-Switching wird gesucht (QoS, schneller als IP lookup, andere Kriterien als shortest path routing)
• Intelligenz wird noch mehr an den Rand gedrängt
• Label werden an Pakete geklebt, nach denen gerouted wird
• Label definieren eine bestimmte forward equivilance class, welche bestimmten Pfad durch die Label switched router darstellt (und potentiell QoS bietet)
• Label haben immer nur lokale Bedeutung -> Pakete werden bei jedem Hop umgelabelt
• An Edgeroutern wird Paket je nach Zielort, QoS oder wasauchimmer einer FEC zugewiesen und ins Labelgeswitchte Netz entlassen
• mehrere Label sind möglich -> LIFO
  • z.B. um im Kern noch mehr Traffic zu einem Kanal zusammenzufassen
• Das/Die Routingprotokoll(e) verteilen Routinginformationen zwischen Label switched routern und sorgen für Erzeugung der Forwardingtabellen in den Routern
• Routenauswahl kann auf zwei Weisen erfolgen: Hop-by-Hop oder Explicit
  • Hop-by-Hop ist ähnlich normalem IP-Switching
    • könnte z.B. auch normale Routingprotokolle nutzen
    • Vorteile: immer noch schnelles Label-Switching, kann einzelne Flows getrennt behandeln
    • Blöd: kein traffic engeneering oder policy routing
  • bei explizitem Routen (Teil-) Pfade vorher festgelegt (durch Ein- Ausgangs- Router)
    • traffic engeneering und policy routing können unterstützt werden
• um die Pfade für die einzelnen FECs im Netzt zu verteilen müssen:
  • jeder Router seine upstream-Router informieren, welches Label er für welche FEC erwartet
  • den nächsten Hop des Labelswitched Pfades kennen lernen und in Erfahrung bringen, wie der Router im nächsten Hop sein Label für diese FEC haben möchte
  • Label verteilen sich von den Downstream Routern gen Upstream - also vom Ziel zum Anfang, entgegen der eigentlichen Datenrichtung

Multicast

• Teil der Klasse D IP-Adressen für Multicast reserviert (224.0.0.0-239.255.255.255)

Protokolle

Welche Möglichkeiten gibt es überhaupt die Pakete zu verteilen?

• Flooding - ganz einfach, überall hin
• Source Based Tree: ein Baum pro Quelle
  • Shortest Path Tree: Baum aus kürzesten Wegen - Dijkstra
  • Reverse Path Forwarding: wenn kommendes Päckchen auf Port mit kürzestem Weg zur Quelle ankam, floode ich an alle andern Ausgänge
    • gibts auch mit Erweiterungen: z.B. pruning oder dass ich gucke, ob der Empfänger mich als kürzesten Pfad zur Quelle ansieht (wenn nicht muss ich ihm nix schicken, da er eh verwirft)
• Shared Tree: Ein Baum für alle Mitglieder der MCAST-Gruppe
  • Steiner Tree: Baum, der alle Gruppenmitglieder mit geringsten Kosten verbindet
    • wird praktisch nicht genutzt, da viel zu aufwendig zu berechnen
  • Core Based Tree: mit Rendevouz Punkt in der Mitte, zu dem sich alle verbinden
    • erzeugt nicht zwangsläufig die kürzesten Wege, single point of failure, dafür aber kein flooding

IGMP (Internet Group Management Protocol)

• dient der Organisation von MCAST Gruppen
• vornehmlich dem Mitteilen eines lokalen MCSAST Routers, dass ich Pakete einer bestimmten mcast Gruppe bekommen will
• Router fragen gelegentlich alle lokalen MCAST Hosts (per 224.0.0.1)
• Darauf antworten Hosts mit Gruppen, in denen sie sind (andere Hosts, die das hören antworten nicht nochmal)

DVMRP (Distance Vektor Multicast Routing Protocol)

• macht flood and prune mit reverse path forwarding, und baut somit einen source based tree
• ermittelt Info über Netztopologie selbst, muss also nicht auf zugrundeliegende Unicast info zurückgreifen
• soft state - vergisst also geprune regelmäßig
• nutzt IGMP für Verständigung der Router untereinander

PIM (Protocol Independent Multicast)

• zwei Modi - Dense Mode und Sparse Mode:

  Densemode

  • beim Densemode wird an alle gemulticasted, bis sie explizit prunen
  • Flood and prune mit reverse path forwarding (Info für RPF kommt von drunter liegendem unicast protocol)

  Sparsemode

  • beim Sparsemode bekommt keiner was, bis er nicht ausdrücklich beitritt
  • baut Baum mit Rendevouz Punkt als Wurzel (an diesem müssen sich sowohl Sender als auch Empfänger anmelden)
  • nutzt hauptsächlich shared trees - können aber für höhere Effizient auch zu source based tree umgeschalten werden

BGMP (Border Gateway Multicast Protocol)

• arbeitet auf domainlevel
• baut auch shared tree auf (mit Rendevouz Punkt)
• läuft auf Routern an den Grenzen von multicast routing domains
• nutzt TCP

MASC(Multicast Address Set Claim)

• Adressen werden hierarchisch verteilt ähnlich IP-Adressen
• je niedriger in der Hierarchie, umso kürzer der Präfix
• Wenn ich 'ne Multicastadresse will, dann muss ich bei meinem Provider einen Leas beantragen, der nur 'ne bestimmte Zeit gültig ist (wie bei DHCP)
• Wenn ich eine ich von meiner übergeordneten Instanz eine bestimmte Multicast adresse anforder (claim), dann fragt er erst seine andern Kinder, ob die schon vergeben ist und wenn ja, dann muss ich mir 'ne neue aussuchen

Internet Security

• klärt erst was Sicherheit überhaupt heißt, und was alles so zu schützen ist bzw. was alles so falsch laufen kann
• dann kommt kurzer Abriss über Verschlüsselung (symetrisch udn asymetrisch)
• lohnt sich aber alles nicht zusammenzufassen, da recht kurz behandelt

IPSec

• Sicherheitsprotokoll, welches irgendwo zwischen/auf Network- und Transport- Layer rumrödelt
• zwischen Gesprächspartnern wird sog. Security Association festgelegt, welche beschreibt, welche Art von Sicherheit man gerne hätte
• zwei Sicherungsprotocolarten: Authentication Header und Encapsulated Security Payload
• zwei Modi: Transportmode (nur Inhalt des IP-Pakets wird verpackt) und Tunnelmode (komplettes IP-Paket wird eingepackt (inkl. IP-Header (muss dann natürlich mit neuem Header versehen werden)))
• IPSec geschützte Pakete lasse sich zudem beliebig tief verschachteln (wie wenn ich einen Tunnel in einem Tunnel baue)

  AUthentication Header AH

  • über alle nichtveränderlichen Daten wird Prüfsumme berechnet und in IPSec-Header geschrieben
  • verhindert unbemerktes Ändern der IP-Pakete

  Encapsulated Security Payload

  • das ganze wird zusätzlich verschlüsselt
  • hilft gegen unbemerktes mitlesen
  • beide Verfahren besitzen Sequenznummern um zu verhindern, dass Kopien der Pakete später erneut verschickt werden

Firewalls

• einfache Paketfilter
• Screened Host Architecture
  • Bastion Host gegenüber des Internets durch Paketfilter gesichert aber nicht gegenüber des Inneren Netzes
  • Paketfilter sorgt dafür, dass sämtlicher (oder zumind. sämtlicher zu einem Dienst gehörender) Verkehr über den Bastionhost gehen muss (indem er den Rest blockt)
• Screened Subnet Architecture
  • Bastion Host(s) sowohl Richtung Internet als auch Richtung Intranet mit Paketfiltern gesichert
  • verhindert Gefahr des Intranets, falls Bastionhost doch mal kompromittiert wird