Routing
Bridges: aneinanderkoppeln mehrerer Netzsegmente
Hub: Weiterleitung von Paketen an alle Endsysysteme (darunter ist dann auch Zielsystem) -> skaliert nicht
Switch: wie ein Hub mit dem Unterschied, dass ein Switch lernt wo ein Endsystem zu erreichen ist -> Switch leitet Paket nur an gewünschtes Zielsystem
Single hop: Weiterleitung über einen Router von Source zu Destination
Multi hop: Weiterleitung über mehrere Router von Source zu Destination
Router: funktioneller Aufbau
Zwei grundlegene Aufgaben:
Control Plane (Kontrollebene): zuständig für die Verwaltung der Routing Table
Data Plane (Datenebene): Weiterleitung der Pakete
Routing: einen Pfad von A nach B durch das Netzwerk finden. Wünschenswerte Eigentschaften sind hierfür: Korrektheit, Einfachheit, Robustheit, Stabilität, Fairness und Optimalität. Dabei kommt es oft zu Konflikten zwischen Fairness und Optimierung.
[abbildung VL2 seite 12]
Um Eigenschaften wie Faireness besser definieren zu können benutzt der Routing Algorithmus sogenannte Metriken um das Routing zu optimieren:
durchschnittliche Paketverzögerung
gesamter Durchsatz
individuelle Verzögerung
In der Praxis versuchen Routing Algorithmen die Anzahl der Sprünge pro Paket zu minimieren. Dies tendiert zu einer Reduzierung der Verögerungen, senkt die benötigte Bandbreite und steigert Durchsatz.
Routing Algorithmus: füllt die Routing Table erstmals und versucht diese danach aktuell zu halten. Dafür benötigt der Algorithmus Informationen (lokal oder von anderen Routern) . Zudem sucht der Algorithmus einen "guten" Pfad ("gut" meint typischerweise "geringste Kosten"). Unterschiedliche Subnetze können dabei unterschiedliche Routing Algorithmen haben. Zwischen den Subnetzen kommt dann ein Intersubnetz-Routing Algorithmus zum Einsatz. Das liegt an verschiedenen Anforderungen an die Netze (zB ist ein Subnetz meist unter einer administrativen Verwaltung und muss nicht skalierbar sein, während ein Netz sich mehr verändert und skalierbar bleiben muss).
Es wird zwischen non-adaptive und adaptive Routing Algorithmen unterschieden:
Non-adaptive: schauen sich nicht an in welchem Zustand das Netz ist z.B. Flooding, Preconfiguration
Adaptive: schaut zunächst wie der Status des Netzes ist, welche Knoten noch Kapazität haben Daten weiterzuleiten z.B. distance vector routing, link state routing
Datenpakete: kommen von verschiedenen Kanälen in den Router. Anhand der Routing Table wird festgestellt wo die Datenpakete weitergeleitet werden müssen (Forwarding)
Software Defined Networking (SDN): mehr Kontrolle in Netzen durch Software. Router entscheidet nicht mehr selbst, sondern sammelt Daten und sendet diese an einen Controller. Dieser subnetzzentrale Controller entscheidet über die Routenberechnung. Forwarding bleibt weiterhin den einzelnen Rourtern überlassen
CONS (Connection Oriented Network layer Service):
Verbindung wird aufgesetzt und beim Aufsetzen den Pfad durch das Netz finden
Verbindung über die Laufzeit aufrecht erhalten
Zudem versieht man die Pakete nicht mehr mit der Zieladresse, sondern bekommt für genau diese Verbindung eine genaue Identifikation (Circuit ID)
CLNS (Connectionless Network layer Service):
Routingtabelle sieht etwas anders aus, da diese nicht nach jedem Paket aktualisiert wird (zu großer overhead). Diese wird periodisch erneuert.
Network Layer Service (Internet) ist connectionless, das heißt ein "Datagram" Service
Flooding:
Elementare Strategie im Non-adaptive Routing. Dabei wird jedes ankommende Paket zu jedem Nachbarn gesendet, die auf dem Weg zum Zielendsystem liegen (Pakete werden also nicht an allen Systemen ankommen). Dadurch entsteht eine vervielfachte Anzahl an Paketen. Es gibt zwei Ansätze die Anzahl an Duplikaten zu reduzieren:
Lösung: ein TTL (Time To Live) im Paket Header, welcher an jedem neu ankommenden Router um 1 gesenkt wird. Wenn TTL = 0 dann wird das Paket verworfen. Dafür muss man aber eine gute Vorstellung davon haben wie lang die Pfade von Source zu Destination sind.
Lösung: jedem Paket wird eine Sequenznummer zugewiesen und Router verwalten eine Sequenztabelle in der alle Sequenznummern eingetragen werden, die schon weitergeleitet wurden. Pakete mit bereits bekannter Sequenznummer werden verworfen.
Flooding macht in schnell ändernden Netzwerken Sinn oder wenn viele/alle Pakete Multicast sind.
Statisches Routing (Preconfiguration):
Elementare Strategie im Non-adaptive Routing. Hierbei werden alle Router mit Pfaden zu allen möglichen Zielen vorkonfiguriert und funktioniert in statischen, sich nicht oft ändernden Netzen gut.
Adaptive Routing Algorithmen:
Zentrales adaptives Routing-Verfahren:
Das Routing Control Center (RCC) hat die Aufgabe die Einträge in Routing Tabellen auf die Situation im Netz anzupassen (z.B. wenn neue Routen dazugekommen sind). RCC liegt irgendwo im Netz. Jeder Router sendet in regelmäßigen Abständen die Routing Tabelle an das RCC. Dadurch hat das RCC die Möglichkeit mit allen Informationen das Netz in einem Graphen darzustellen und die besten Routen zu berechnen (z.B. mit Dijkstra). Die besten Routen werden dann an alle Router gesendet.
Probleme:
Verwundbarkeit: Wenn das RCC ausfällt kann es nicht mehr sinnvoll routen weil es keine Updates mehr bekommt. Dadurch verschlechtert sich das System immer mehr wenn neue Links dazukommen/wegfallen wird dies nicht im RCC aktualisiert -> RCC ist in diesem Fall Non-adaptive
Skalierbarkeit: RCC muss mit vielen Routing Informationen umgehen, besonders bei großen Netzwerken
Bottleneck: alle Updates fließen zum RCC, daraus folgt, dass der Traffic um das RCC hoch ist und es bei vielen Änderungen im Netz zu einem Overload kommen kann
Aging: Router, welche näher am RCC liegen können schneller Updates senden aber auch Änderungen erhalten, als Router, die weiter weg liegen. Es sind also nicht alle Router zu jedem Zeitpunkt auf dem selben Stand
Zentrales adaptives Routing-Verfahren:
Routing Entscheidung werden nur anhand von lokalen Informationen getroffen (z.B. Hot potato, backward learning).
Verteiltes adaptives Routing-Verfahren:
Router tauschen periodisch untereinander Informationen aus und auf Basis dieser Informationen die Routing Tabelle berechnet wird. Hier wird zwischen statisch und dynamisch unterschieden. Ein statisches Verfahren wird in Netzen eingesetzt, die sich langsam ändern. Zudem hat man eine statische Routing Tabelle die auf alle Router geladen wird (weniger fehleranfällig). Dynamische Verfahren werden dementsprechend dann eingesetzt wenn sich Routen ständig ändern. Hier wird dann entweder in periodischen Abständen eine Aktualisierung durchgeführt oder wenn sich die Kosten verändern. Des Weiteren unterscheidet man zwischen dezentralen und globalen Informationshaltung. Bei einem dezentralen Vorgehen kennt jeder Router (Knoten) seinen physisch-verbundenen Nachbarn und die Kosten zu diesem Nachbarn (geschieht durch hin- und hersenden von Paketen). Durch dieses hin- und hersenden von Paketen werden die Router langsam verstehen wie das ganze Netz aufgebaut ist. Dies nennt man "Distance Vector"(RIP [Routing Information Protocol])-Verfahren oder "Path Vector"(BGP [Border Gateway Protocol])-Verfahren. Beim globalen Vorgehen will man erreichen, dass alle Router die komplette Struktur des Netzes und die Verbindungskosten kennen. Um die besten Pfade bestimmen zu können benutzt man die sogenannten "Link state" Algorithmen (Dijkstra Algorithmus, OSPF Protocol [Open Shortest Path First]).
Hot potato:
Regel: Werde das ankommende Paket so schnell wie möglich los, egal wohin du es schickst. Diese Methode ist nicht sehr effektiv, wird heute dennoch in speziellen Netzwerken genutzt um z.B. Nutzer oder die Topologie eine Netzes zu entdecken.
Backward Learning:
Grundidee ist, dass jeder Router an dem ein Paket ankommt sich die Source Adresse und die Anzahl der Sprünge im Paketheader anschaut und diese Daten sammelt. Dadurch lernen die einzelnen Router allmählich wie das Netzwerk aussieht. Durch Vergleichen der Anzahl der Sprünge wird der beste Pfad ermittelt. Um sich für den Fall einer Verschlechterung der Pade anzupassen, werden in regelmäßigen Abständen die gesammelten Daten "vergessen" ("soft-state") und neu eingetragen.
Distance Vector Routing (DVR):
DVR ist iterativ, wird also so lange Pakete mit Nachbarn austauschen bis es keine Unbekannten mehr gibt -> self-terminating.
DVR ist verteilt (dezentralisiert), Router bekommt nur von direkten Nachbarn Informationen.
Jeder Router (Knoten) hat seine eigene Distanztabelle in der die Wege zu den Nachbarn gespeichert werden. Zeilen enthalten alle möglichen Ziele und Spalten alle direkt anliegenden Nachbarn => "good new travel fast". DVR hat ein Problem mit Schleifen umzugehen ("count-to-infinity" Problem).
Lösung 1: Poisoned Reverse (vermeidet Schleifen, sendet aber weiterhin Updates zu Nachbarn). Funktioniert aber nicht in größeren Netzwerken ODER bei bestimmten Strukturen (z.B. Es gibt nur einen Pfad von C nach D, dieser wird gekappt. A versucht also über B nach D zu gelangen und B versucht über A nach D zu gelangen weil C ihnen sagt, dass es selbst nicht mehr nach D kann -> count-to-infinity Problem)
=> "vergiften" eine Route indem wir Kosten als unendlich angeben
Lösung 2: Die Idee hinter Split Horizon ist, dass Routing Informationen nie in die Richtung zurückgesendet werden, aus der sie erhalten wurden -> kann nämlich wieder zu Schleifen führen
=> unterdrückt Updates
Lösung 3: Split Horizon mit Poisoned Reverse
=> wenn Routen gültig sind dann unterdrücken (um Schleifen zu verhindern), wenn wir explizit wissen, dass eine Route ungültig ist und gebrochen ist dann geben wir ein Update aber setzen es auf unendlich
Border Gateway Protocol (BGP):
Es erhält von seinen benachbarten autonomen Systemen Informationen über die Erreichbarkeiten der AS Subnets und verbreitet diese im eigenen internen AS. Zudem bestimmt BGP einen "guten" Pfad zu anderen Subnets auf Basis der Erreichbarkeit und Policies. Der Austausch von Routing Informationen bei einem Paar von Routern (BGP Peers) wird über eine semi-permanente TCP Verbindung, welche man BGP session nennt, ausgeführt (diese stimmen nicht 1:1 mit physikalischen Verbindung überein).
eBGP (external) Session: ist der Austausch zwischen zwei Routern aus unterschiedlichen AS
iBGP (internal) Session: ist der Austausch zwischen zwei Routern im selben AS
Hierbei besteht eine Routing Information aus dem Prefix und Attributen:
AS-PATH (Attribut): enthält die ASs durch die das Prefix schon durchgelaufen ist
NEXT-HOP (Attribut): zeigt den bestimmen internen AS Router zu welchem AS der next-hop geht
Link-State Routing (LSR):
LSR möchte globale Informationen (Netzwerk Topologie, Pfadkosten) auf jedem einzelnen Knoten benutzen via "link state broadcast" -> jeder Router misst die Kosten zu seinen Nachbarn, daraus werden "link state packets" gebildet und mit Flooding an alle anderen Router gesendet (Pakete mit bereits bekannter Sequenznummern oder Pakete mit einem zu alten Datum werden nicht nochmal weitergeleitet).
Hierarchisches Routing
Hätte man eine flache Struktur, würde das Suchen einer IP Adresse in Routing Tabelle zu lange dauern, weil er alle Einträge durchlaufen müsste (schlecht zu skalieren). Zudem ist mit flacher Struktur keine Kontrolle mehrerer Admins möglich.
Internet ist in mehrere autonome Systeme (AS) unterteilt. Diese können kleine, große Unternehmen, aber auch Provider sein.
Außerdem gibt es Internet Exchange Points (IXP) in denen sich mehrere Provider zusammenschließen.
AS haben verschiedene Größen und unterschiedliche Beziehungen zueinander. Jedes AS besitzt eine einzigartige Nummer, die von Registrierungsorganisationen vergeben werden. Jedes AS muss zudem zu jedem Netz eine Route kennen.
AS helfen bei der Skalierbarkeit und Netze so zu trennen, dass Admins ihre Entscheidung im Netz treffen können.
Jeder Router muss über die anderen Router im AS bescheid wissen.
Es gibt also ein Two-level routing: Innerhalb des autonomen Systems gibt es ein Routing (Distance Vector[RIP], Link State[OSPF]) und zwischen den autonomen Systemen (Path Vecotr[BGP])
-> Intra-AS Routing ist dem Betreiber überlassen
-> Inter-AS Routing hat ein festgelegtes Verfahren
Funktionsweise: Router werden in sog. Regionen angehäuft. Router im selben autonomen System nutzen die selben Intra-AS Routing Protokolle. Router aus unterschiedlichen AS können unterschiedliche Intra-AS Routing Protokollen ausführen.
Gateway Router ermöglichen die Anbindung an andere autonome Systeme. Diese benutzen sowohl das Intra-AS Routing Protokoll, um mit den Routern im AS zu kommunizieren, als auch Inter-AS Routing Protokoll, um mit den anderen autonomen Systemen zu kommunizieren.
=> Skalierbarkeit: spart an der Größe der Routing Tabellen und reduziert den Update Verkehr
=> Policy: im Intra-AS will ein Admin die Kontrolle über das autonome System haben, weshalb hier keine Policy Entscheidungen nötig sind. Im Inter-AS wird hingegen kontrolliert wie Pakete zwischen den autonomen Systemen verteilt wird
=> Performance: im Intra-AS steht die Effizienz im Vordergrund. Beim Inter-AS dominieren die Policies
Wie kann ich nun von einem Intra-AS Router an ein anderes autonomes System ein Paket senden? -> Aufgabe des Inter-AS Routing Protokolls: Jedes AS lernt von welchem internen Gateway ein anderes AS erreichbar ist und verbreitet diese Information an alle internen Router. Diese Info speichert jeder Router in seiner Forwarding Tabelle.
Angenommen ein Ziel ist über mehrere AS erreichbar: Dann wird mithilfe des Intra-AS Protokoll der günstigste Pfad ausgewählt, auch wenn unbekannt ist wie lang der Pfad hinter dem nächsten AS ist (eine Art Hot potato Routing). Der günstigste Pfad wird in der lokalen Forwarding Tabelle nachgeschaut.
Overlay Routing
Overlay Routing ist extrem populär geworden. Alle Peer-to-Peer File Sharing Networks sind Overlay Netzwerke. Auch die meisten Cloud / Data Center sind Overlay Netzwerke.
Ein Overlay Netzwerk ist eine virtuelle Netzwerktopologie auf ein reales Netzwerk gelegt. Nachbarn im Overlay sind nicht zwingend die Nachbarn aus dem darunterliegenden Netzwerk. Das Overlay Netzwerk zeigt nur die Verbindungen der Endsysteme an - gesendet werden die Pakete aber über die Knoten im darunterliegenden Netz. Um den günstigsten Pfad berechnen zu können betrachtet man hier zwei Metriken: Wie viele Hops gibt es im Overlay (diese versucht man zu minimieren) und die Anzahl der Hops im darunterliegenden Netzwerk (z.B. kann der Fall eintreten, dass ein Hop im Overlay drei Hops im Underlay bedeutet, es aber auch einen kürzeren Pfad geben würde [im Underlay]. Dies wird "stretch" genannt. Diesen "stretch" gilt es zu minimieren.
Für Peer-to-Peer Overlays gibt es einige Annahmen:
Knoten kooperieren miteinander
Knoten kommen und gehen, diese Fluktuation nennt man auch "routing churn" (wenn es stark fluktuiert, wird es schwer ein Overlay aufrech zu erhalten)
Knoten sind überall im Netz
Knoten können hinzugefügt werden node identifier) und Nachen können ausgewählt werden (neighbor selection)
Im Overlay Netzwerk geht es in erster Linie nur um die Ressource. Diese kann über z.B die Knoten gefunden werden. Dabei wissen wir aber zu keinem Zeitpunkt den Namen oder den Ort an dem die Ressource gespeichert ist.
Verschiedene Strategien der Organisation:
flache Hierarchie: zufällige Nachbarn suchen (kann robust sein, ist heute aber ineffizient aufgrund der Underlay-Pfade)
hierarchisch: Supernodes einführen, die stabil sind und die anderen Knoten kennen
strukturiert: Aufbau wie ein Ring
Internetworking
IP Packet Format
IP protocol version number: IPv4 oder IPv6
IP HeaderLength: 32-bit words
Type of Service: enthält Prioritätsinformationen (selten genutzt)
Total Length: gesamte Länge des Datagramms in bytes (inkl. Header)
Identification: wenn ein IP Paket in mehrere Fragmente segmentiert wird, bekommt jedes Fragment die selbe Identifikation, um sie am Ende wieder zusammensetzen zu können
Flags:
DF: Dont Fragment
MF: More Fragments, wenn ein Paket fragmentiert wurde, haben alle Fragmente bis auf das letzte dieses Bit Set
Fragment Offset: Position des Fragments innerhalb des Originalpakets (spezifiziert in Einheiten von 8 Oktetts)
Time to Live: wird nach jedem Hop um 1 reduziert, wenn es 0 erreicht wird Paket verworfen
Protocol: identifiziert welches Transport Layer Protokoll für das Paket genutzt wird (TCP oder UDP)
Header Checksum: erlaubt den Inhalt des IP Headers zu verifizieren
Source and Destination Addresses: eindeutige Identifizierung von Sender und Empfänger des Pakets
Options: bis zu 40 bytes Länge; wird für erweiterte Funktionen genutzt z.B. source routing, record route)
IP Addresses:
32 bits lang (4 bytes)
jedes byte wird in dezimal MSB geschrieben (129.195.1.80)
0.0.0.0 (niedrigste) zu 255.255.255.255 (höchste)
Address Classes: Class A, B, C, D, E, Loopback, Broadcast
IP Address Classes
Class A: 16 Millionen Hosts erlaubt -> die ersten 8 bit stellen Netzwerk dar
Class B: 65.000 Hosts erlaubt -> die ersten 16 bit stellen Netzwerk dar
Class C: 255 Hosts erlaubt -> die ersten 24 bit stellen Netzwerk dar
Class D: Multicast Adressen, keine Netzwerk/Host Hierarchie
Class E: reserviert
Jede Adresse enthält einen Netzwerk- und einen Host-Teil. Der Netzwerk-Teil gibt an, wie eine Adresse erreicht werden kann, der Host-Teil, gibt die Endpunkte innerhalb des Netzes wider. Dabei kann der Host-Teil in weitere Subnetze unterteilt werden.
Spezielle Adressen in einem Subnetz:
Netzwerk-Adresse: ist die Basis-Adresse die das Netz adressiert. Hier werden alle Host-bits auf 0 gesetzt
Broadcast-Adresse: ist die "letzte" Adresse in einem Subnetz und dient dazu, alle Systeme im Netz gleichzeitig zu adressieren. Die Host-bits für Broadcast werden alle auf 1 gesetzt.
Loopback: startet mit 127.xx.yy.zz und wird nur lokal zum testen benutzt. Pakete die also an diese Adresse gesendet werden bleiben lokal und werden als "incoming packets" behandelt.
Private IP Addresses: (Adressen, die man nicht im Internet weiterrouten wird)
Class A Range: 10.0.0.0 - 10.255.255.255
Class B Range: 172.16.0.0 - 172.31.255.255
Class C Range: 192.168.0.0 - 192.168.255.255
Link local IP Addresses: (Adressen die man sich bei Konfiguration selbst gibt)
Range: 169.254.0.0 - 169.254.255.255
Net Mask: Die Netzmaske setzt sich aus dem Netzwerk- und dem Host-Teil einer IP Adresse zusammen. Dabei ist der Netzwerk-Teil die Zieladresse, die Router in Forwarding Tables benutzen um Pakete an das richtige Ziel weiterzuleiten. Der Netzwerk-Teil wird auch Netzwerk-Prefix genannt.
Class A: 11111111.00000000.00000000.00000000 (255.0.0.0, /8) /8 ist die Subnetz-Maske
Class B: 11111111.11111111.00000000.00000000 (255.255.0.0, /16)
Class C: 11111111.11111111.11111111.00000000 (255.255.255.0, /24)
-> Router werden üblicherweise die Host-bits ignorieren und sich nur die Netzwerk-bits anschauen
Subnet
Ein Subnetz ist ein eigenes Netzwerk, die untereinander kommunizieren können ohne abhängig von einem Router zu sein. Alle Interfaces in einem Subnets haben den gleichen Netzwerk-Teil einer IP Adresse.
Wie erkenne ich ein Subnetz? Wenn ich andere Geräte erreichen kann ohne den Router zu nutzen habe ich ein Subnetz (selber Netzwerk-Teil).
Wie kann ich ein Subnetz erstellen? Die mir vom Provider zugewiesene IP Adresse hat einen Netzwerk-Teil und einen Host-Teil. Ich kann einen Teil des Host-Teils als Subnetz-Teil nehmen. Dafür muss ich eine neue Subnetz-Maske erstellen. Bsp.: angenommen ich bekomme vom Provider die IP Adresse 223.1.0.0/16 zugewiesen. Mein Netzwerk-Teil ist die 223.1. Um ein Subnetz zu erstellen nehme ich die 3. 8 bit. Damit kann ich 254 Subnetze mit jeweils 254 Hots anlegen. Die zugehörige Subnetz-Maske wäre dann 255.255.255.0
ACHTUNG!: Normalerweise hat man 256 mögliche IP-Adressen, davon wird die 0 für die Beschreibung des Netzes und die 255 für den Broadcast genutzt. Deshalb nur 254 verfügbare Adressen für Hosts.
Variable Length Subnet Masks (VLSM): Da die Subnetzunterteilung in /8 /16 /24 nicht sehf effektiv ist, kann man auch variable Längen des Netzwerk-Teils bestimmen. So ist bei einem Class B Netz (normalerweise /24) Netzwerk-Teile von /17 bis /32 möglich.
Dadurch unterscheidet man in zwei Typen:
Classfull addressing: beschreibt die Nutzung von den festgelegten Subnetzmöglichkeiten mit /8 /16 /24 (ein Class B Netz kann theoretisch 65k Hosts haben, wenn ein Unternehmen jedoch nur 2k Hosts benötigt bleibt ein Großteil ungenutzt)
Classless InterDomain Routing (CIDR): der Netzwerk-Teil kann hier frei gewählt werden. Das / beschreibt dabei den Teil des Netzwerks, z.B. 200.23.16.0/23.
Supernetting: Zusammenfassen mehrerer kleinerer Subnetze
"Longest match routing": der spezifischste Eintrag im Router muss als erstes betrachtet werden.
Bsp.:
200.23.16.0/23
200.23.18.0/23
200.23.20.0/23
...
200.23.30.0/23
Wenn ich alle obengenannten IP Adressen zusammenfassen möchte muss ich den Eintrag mit dem kürzesten Netzwerk-Teil nehmen -> 200.23.16.0/20. Dadurch liegen auch alle anderen IP Adressen im Bereich.
Wenn jetzt aber die IP Adresse 200.23.18.0/23 zu einem anderen Provider wechselt, dann muss der neue Provider dies in seiner Routing Tabelle angeben und dabei das "Longest match routing" berücksichtigen.
Wie bekommt Host eine IP Adresse?
Statisch: Admin weißt jedem Geräte eine Adresse zu oder über RARP (reverse address resolution protocol), hier sendet der Host ein RARP Paket mit seiner MAC Adresse und erhält eine hard-coded IP Adresse.
Dynamisch: mit DHCP (Dynamic Host Configuration Protocol). Host sendet einen DHCP request und erhält dann vom Server eine IP Adresse + Subnetzmaske + Default Gateway + DNS-Server etc.
NAT (Network Address Translation): Um zu verhindern, dass jedes einzelne Gerät über das Internet direkt angesprochen wird, besitzt jedes Gerät im Heimnetz eine lokale IP Adresse. Der Router bekommt also als einziger eine IP Adresse die mit dem Internet agieren kann. NAT ist nun im Router dafür zuständig die lokale IP Adresse eines Geräts in die öffentliche Adresse zu übersetzen, damit einzelene lokale Geräte mit dem Internet kommunizieren können. Auch die Port Nummer wird umgeschrieben.
Nachteile: Intranspazenz (Ende-zu-Ende), Sever intern betreiben
IP Adressbereiche die ausschließlich als lokale Adressen genutzt werden sind:
192.168.x.x, 172.16.x.x - 172.31.x.x, 10.0.x.x - 10.255.x.x
PROBLEM: Schichtenmodell wird verletzt: normalerweise ist die Transportschicht eine Ende-zu-Ende Kommunikation. NAT fummelt jedoch durch das Umschreiben von Ports in der Transportschicht herum.
ARP (Address Resolution Protocol): Wenn ein Paket das Zielnetzwerk erreicht hat, wie findest es nun das richtige Gerät? Im lokalen Netzwerk einfach fragen wer genau diese IP Adresse hat. Das Gerät mit der IP Adresse wird dann mit der MAC Adresse antworten. Router kann dann das Paket an die MAC Adresse schicken.
Wenn ein Hacker im lokalen Netz ist kann dieser versuchen schneller als das Gerät mit der eigentlichen IP Adresse zu antworten. Dadurch wird eine falsche MAC in der ARP Table gespeichert -> ARP cache poisoning/ ARP spoofing
Transport Layer
Die beiden meist genutzten Protokolle sind:
TCP (Transmission Control Protocol):
zuverlässige Übertragung der Pakete in der richtigen Reihenfolge
vermeidet Überlastungen
Sender und Empfänger senden nur so schnell wie es beim Empfänger verarbeitet werden kann (Flusskontrolle)
verbindungsorientiert (COTS [Connection Oriented Transfer Service])
UDP (User Datagram Protocol):
unzuverlässige Übertragung, wenn die Reihenfolge nicht stimmt, werden die Pakete auch nicht umgeordnet
Dabei kann keiner der beiden Protokolle Verzögerungs- und Bandbreiten-Garantien geben.
Verbindungsorientierte Dienste (COTS)
Es gibt drei Phasen der Verbindung:
Verbindungsaufbauphase (Connect)
Datentranserphase (Data)
Verbindungstrennphase (Disconnect)
Für jede Phase gibt es spezielle "service primitives". Die service primitives Connect, Data und Disconnect finden sich in verschiedenen Schichte des OSI Modells wider:
Transportschicht: T-Connect (Type: confirmed), T-Data (Type: unconfirmed), T-Disconnect (Type: unconfirmed/confirmed)
Netzwerkschicht: N-Connect, N-Data, N-Disconnect (dies gilt aber nicht für IP!!! denn IP ist verbindunglos?)
T-Connect Primitives:
T-Connect.Request -> Senderseite (Destination Address, Source Address)
T-Connect.Indication -> Empfängerseite (Destination Address, Source Address)
T-Connect.Response -> Bestätigung auf Empfängerseite (Responding Address)
T-Connect.Confirmation -> Bestätigung auf Senderseite (Responding Address)
T-Data Primitives:
T-Data.Req (userdata)
T-Data.Ind (userdata)
T-Disconnect Primitives:
T-Disconnect.Req (userdata)
T-Disconnect.Ind (cause, userdata) (cause könnte sein: angefragt von user, schlechte Qualität des Services, Error aufgetreten, Transport service nicht erreichbat)
Die Adressen die hier benötigt werden sind nicht IP Adressen, sondern die Socket Adresse, also solche die eine Relevanz auf der Transportschicht haben (Destination/Source). Die Responding Address ist die des Nutzers der den Service gestartet hat.
Bsp.
T-Connect.Req -------------> T-Connect.Ind
T-Connect.Cnf <------------- T-Connect.Rsp
T-Data.Req -----------------> T-Data.Ind
T-Data.Req <----------------- T-Data.Ind
T-Disconnect.Req --------------> T-Disconnect.Ind
Der Three-Way Handshake dient als Lösung für den Verlust einer Verbindung:
T-Connect.Req ------CR-----> T-Connect.Ind CR=ConnectionRequest
T-Connect.Cnf <------CC------ T-Connect.Rsp CC=ConnectionConfirm
------------ACK or DT(Data)----->
Szenario: Sender schickt eine Disconnect Anfrage, bis jedoch die Anfrage am Empfänger ankommt werden weitere Daten an Sender gesendet:
---- T-Data.Req
-----
T-Disconnect.Req -------DR-------> T-Disconnect.Ind
<------------DT
<----------------DC---------------- T-Disconnect.Ind
Zwei-Armeen Problem:
In einem Netzwerk in dem Nachrichten verloren gehen können, kann es passieren, dass ich eine Anfrage schicke und nicht sicher sein kann ob die Nachricht angekommen ist. Selbst wenn die Nachricht den Empfänger erreicht hat und dieser eine Bestätigung schickt, kann auch diese verloren gehen und der Empfänger kann sich nicht sicher sein, ob die Bestätigung angekommen ist.
Lösung: Nach senden des T-Disconnect.Req eine gewisse Zeit auf Antwort warten und solange noch eingehende Daten annehmen
Fall 1: DR von Sender erreicht Empfänger, DR von Empfänger erreicht Sender, das ACK von Sender zu Empfänger geht verloren: Dann wird der Empfänger, der seinen DR geschickt hat warten bis der Timer abgelaufen ist und ohne ACK die Verbindung trennen.
Fall 2: DR von Sender erreicht Empfänger, DR von Empfänger zu Sender geht verloren: Der Sender wird warten bis Timer abgelaufen ist, wenn immernoch keine Antwort von Empfänger angekommen ist, wird er ein weiteres mal einen DR senden.
Fall 3: DR von Sender erreicht Empfänger, DR von Empfänger geht verloren. Sender schickt neue DR, geht aber auch verloren: Wenn die N-mal (Einstellungssach passiert weiß der Sender, dass hier größere Probleme im Netz herrschen und wird die Verbindung beenden.
Lösung für Three-Way Handshake, welches Duplikate oder Verzögerungen ausschließt:
Host1 -----------CR(seq=x)-----> Host2
Host1 <--------ACK(seq=y, ACK=x)--- Host2
Host1 -------DATA(seq=x, ACK=y)--> Host2
Protokollfunktionen
Segmentierung ist eine wichtige Funktion um SDUs (Service Data Units [Datenpakete]) aus höheren Schichten, die etwas länger sein können als was in niedrigeren Schichten möglich ist, zu versenden. Zum Beispiel können IP Pakete maximal 64k bits inkl. Header transportieren. Jedoch überschreiten TCP Streams meistens dieses Limit, weshalb SDUs transparent segmentiert und später wieder zusammengeführt werden müssen. Andersrum auch möglich: mehere kleine SDUs zu einem großen PDU zusammenführen und beim Empfänger wieder in die einzelnen SDUs zerteilen.
Multiplexing ist eine Funktion die es erlaubt Daten von mehreren CEPs (Connection End Point, "sockets") zu sammeln und diese in einem PCI zusammenzufassen und gebündelt weiterzuleiten. Beim Empfänger kann mithilfe des Demultiplexers das korrekte CEP wieder entpackt werden.
Wenn nun z.B. ein Paket an einen Webserver gesendet wird hat dieses Paket eine Source Adresse und eine Destination Adresse. TCP muss diese IP Adressen untersuchen, um den vollen Socket herauszubekommen -> dies ist aber eine starke Verletzung des OSI Prinzips! Denn normalerweise sollte der Header in der Netzwerk-Schicht aufgelöst werden, wird aber in der Transport-Schicht für diese Untersuchung gebraucht.
Ports sind lokale "Adressen" im Endsystem die für bestimmte Dienste standartisiert sind. D.h. bestimmte Ports warten auf Pakete von bestimmten Diensten. Der Port wird dabei immer mit der zugehörigen IP Adresse angegeben. Sonst ist keine Weiterleitung an eine bestimmte Schnittstelle nicht möglich. Es kann auch sein, dass ein Prozess mehrere ankommende Verbindungen akzeptiert. Hierfür kann eine Verbindung nur durch <local socket> oder <remote socket> auseinandergehalten werden.
Flusskontrolle
Dient dazu den Empfänger vor einer größeren Rate eingehender Pakete vom Sender zu schützen. Dazu kommt, dass auf der Transportschicht die eingehenden PDUs sich stark in der Größe unterscheiden können. Zudem können Prozesse auf der Transportschicht (service users) eingehende Pakete blockieren, berechnen etc. Außerdem hat ein Endsystem meistens mehrere Verbindung parallel geöffnet, was bedeutet, dass es einen dynamisch aloziierten Puffer geben muss.
Wie kann Empfänger die Senderate des Senders regulieren?
Wenn Empfänger keinen Puffer mehr hat wird er dies implizit oder explizit mitteilen. Der Empfänger kann dem Sender aber auch anzeigen wie viel Puffer jetzt frei ist. Der Sender könnte auch eine Anfrage zum Puffer schicken (Problem: dafür wieder ein separater Kontrollkanal nötig).
Alternating-Bit-Protokoll:
Empfänger informiert Sender über die empfangenen Pakete. Das bedeutet, Sender schickt erst ein neues Paket sobald dieser ein ACK zum vorherigen Paket erhalten hat. Empfänger schickt also ein ACK wenn er Paket bearbeitet hat.
Was macht der Sender wenn kein ACK ankommt?
Paket geht verloren
ACK geht verloren
ACK kommt spät an (viel Verkehr)
ACK kommt spät an (wegen Flusskontrolle)
Der Sender kann nicht zwischen diesen vier Fällen unterscheiden. Man könnte einen Time-Out einbauen aber hier ist nicht klar wie lange der Sender warten soll.
=> wenn lokale Distanz nicht groß ist, ist Alternating-Bit gut, jedoch über sehr lange Strecken nicht effizient
Andere Möglichkeit wäre, solange Pakete zu senden bis der Empfänger "Stop" sagt und erst dann weitere Pakete zu schicken sobald wir ein "Continue" vom Empfänger erhalten. Dies erhöht den Durchsatz zwar etwas, jedoch ist es schwierig abzuschätzen für den Empfänger wann er Stop sagen kann ohne überzulaufen. Zudem ist die Zeit zwischen Continue und Datensenden verschwendete Zeit.
Weitere Alternative ist es dem Sender mitzuteilen wie schnell Empfänger Daten verarbeiten kann (Daten-basiert oder Puffer-basiert). Hat den Vorteil, dass es einen geringen Austausch von Nachrichten gibt und eine reibungslose Übertragung vorliegt. ABER: es gibt keine Informationen über die erfolgreich übermittelten Pakete. Es muss also Wiederholungsmethoden geben um nicht erhaltene Pakete erneut anfragen zu können.
Credit-Based:
Empfänger teilt Sender die exakte Anzahl an zu sendenden Paketen mit. Sender sendet bis er keine Credits mehr hat. Auch hier muss es eine bestimmte Kommunikation für fehlgeschlagene Pakete geben.
absolute Credit: Empfänger gibt sender eine exakte Zahl vor (z.B. "sende mir 5 Pakete"). Es kann dabei zu Ungenauigkeiten kommen. Denn wenn die absolute Credit beim Sender ankommt, hat sich die Zahl der Kapazität beim Empfänger möglicherweise erhöht
Credit window ("sliding window"): Credits werden in Relation zu den bestätigten Paketen vergeben
Unterscheidung zwischen Permits und Acknowledgements:
Permits: Empfänger hat Puffer, sende mir mehr Pakete
Acknowledgements: Empfänger hat ein bestimmtes Paket erhalten
Fehlerkontrolle
Nicht alle Übertragungsfehler werden erkannt. Aber wenn, dann gibt es keine Reaktion des Empfängers. Das Paket wird einfach fallengelassen weil es eine Wahrscheinlichkeit der Fehlinterpretation gibt. Empfänger gibt ein verlorenes Paket als "negative ACK: please resend" an.
Automatic Repeat reQuest (ARQ):
Typ 1: Stop-And-Wait ARQ: wie Alternating-Bit-Protokoll
Typ 2: Go-Back-N: annehmen, dass alle gesendeten Pakete verloren gegangen sind seit dem letzten ACK -> Pakete erneut senden ab letztem ACK
Typ 3: Selective Reject / Selective Repeat: sehr wahrscheinlich, dass nicht alle Pakete verloren gehen, zudem kann Empfänger einige Paktet im Puffer halten. Empfänger sendet ein NAK (negative ACK) vom Paket, welches nicht angekommen ist. Nur dieses wird erneut gesendet
Überlastkontrolle (congestion control)
Wo der der Bottleneck? Wenn der Bottleneck im Netz, also zwischen Sender und Empfänger ist, ist die Überlastkontrolle wichtig um Stau vorzubeugen oder zu beheben.
Eine Überlast tritt auf, wenn mehr Daten von Sendern durch das Netzwerk gesendet wird, als es an Kapazität hat. Die Folge: Pakete gehen verloren. Zuverlässige Transport Protokolle bemerken den Paketverlust und senden diese Pakete erneut -> dadurch noch mehr Traffic, was die Überlast verstärkt.
Fairness: gib allen Teilnehmern den selben Teil an Kapazität im Netz. Bedeutet fair "equal"? (video conference = telnet session?)
Mechanismen:
Open loop: System so eine große Kapazität geben, dass es nicht zu einer Überlast kommen kann
Closed loop: System soll regelmäßiges Feedback geben damit Sender sich an aktuelle Situation anpassen können
explicit feedback: Punkt wo die Überlast herrscht informiert Sender
implicit feedback: Überlast wird vom Verhalten des Netzwerks abgeleitet
Mögliche Aktionen:
die Kapazität erhöhen - ist kurzfristig nicht immer möglich
Reservierung und Zugangskontrolle - wenn Netz an Kapazitätsgrenze, wird kein neuer Traffic bearbeitet, meistens umsetzbar bei circuit-switched Netzwerken
Ladung reduzieren - alle Quellen reduzieren ihre Daten ohne die Sessions zu beenden. Benötigt Feedback vom Netzwerk
Router-zentriert vs. Host-zentriert - wo werden Informationen gesammelt, Entscheidungen getroffen, Aktionen durchgeführt? Im Internet beim Endsystem (außer für "dropping packets")
Window-based vs. rate-based - rate: bestimmte Anzahl an Bytes/s, congestion window: eine Sequenz von Bytes
Router Aktionen: Welches Paket kann er verwerfen?
One candidate: das neueste Paket wird verworfen, da das "älteste" Paket den größeren Wert hat z.B. Go-Back-N Protokoll. Wird auch drop-tail queue genannt.
Oder: ältere Pakete werden verworfen - Intuition: für Multi-Media Traffic sind alte Pakete nicht so wichtig (neu sind viel wichtiger)
Choke Packtes: wenn Router merkt er ist überlastet sendet er choke Pakete, welche den Sendern sagen langsamer zu senden. Wird in einem schon überlasteten Netz nicht viel bringen. Außerdem ist die Frage wie lange es dauert bis der Sender das choke Paket erhält.
Warning Bit: wenn Router merkt, dass er überlastet ist, setzt er warning bits in alle Pakete die er weiterleitet. Empfänger erkennt dies und wird in ACKs ebenfalls warning bits setzen. Dadurch sieht auch der Sender die warning bits und wird die Senderate drosseln
Random Early Detection (RED): früh schon anfangen Pakete zu verwerfen um Feedback zu bieten. Die Wahrscheinlichkeit mehr Pakete zu verwerfen wird erhöht wenn Router mehr und mehr überlastet
UDP (User Datagram Protocol)
UDP ist connectionless, benötigt als kein Handshake zwischen Sender und Empfänger. Heißt aber auch, dass Pakete verloren gehen können.
Worin liegt dann der Unterschied zu IP?
UDP baut eine Ende-zu-Ende Verbindung von Prozess zu Prozess auf, was IP nicht macht. UDP gibt die Dest. IP Address und Dest. Port Number an. Am Empfänger wird die Dest. Port Number überprüft und an das Socket mit der Portnummer weitergeleitet. Es ist auch kein Problem mehrere Datagramme mit unterschiedlichen Source IP Adressen / Source Port Nummern an den selben Socket zu schicken. Andersrum aber auch möglich: ein Sender, viele Empfänger (Multicast).
Wird dort angewandt wo ein Verlust von Paketen tolerierbar ist, z.B. Multimedia, DNS, SNMP.
Alle Transportprotokolle im Userbereich nutzen UDP.
UDP Checksum: existiert, um "errors" zu erkennen. Die Sender addiert den ganzen Inhalt eines Pakets auf, bildet das Komplement und legt den Wert der Checksum im UDP Checksum-Feld ab. Der Empfänger erhält das Paket und addiert den Inhalt der Pakets mit dem Komplement. Ist das Ergebnis überall auf 1, liegt kein Fehler vor. Wenn doch ein Fehler auftritt wird das Paket verworfen.
TCP (Transmission Control Protocol)
Point-to-point: ein Sender, ein Empfänger
Zuverlässig: in-order byte stream, angezeigt durch die Sequence Number. Im ACK steht dann die nächst erwartete Sequence Number
Full duplex data: Bi-directionaler Datenfluss in Verbindung möglich
Pipelining: mehrere Pakete parallel schicken ist möglich, wenn der Puffer beim Empfänger dementsprechend groß genug ist (Größer der Fensters)
Connection-Oriented: Three-Way-Handshake nötig
Flow Control und Congestion Control wichtig!
Auch bei TCP ist es möglich, dass ein Port am Empfänger mit mehreren TCP Socketsinteragieren kann.
Im TCP werden vier Variablen benötigt, um einen TCP Socket zu identifizieren: Source IP Address, Source Port Number, Dest. IP Address, Dest. Port Number. Der empfangende Knoten weiß mit diesen Informationen an welchen Socket er das Paket weiterleiten muss.
TCP Timeout: muss länger sein als die Zeit die es brauchen würde ein Paket hin und zurück zu senden (Round Trip Time). RTT ändert sich aber, jenachdem wie überlastet das Netz ist. Timeout sollte nicht zu kurz gesetzt werden, da es sonst zu unnötigen erneuten Übertragungen kommt. Zu lang ist auch nicht gut weil sonst viel Zeit verloren geht.
TCP Verbindung:
Active Mode: aktiv eine Verbindung anfragen mit dem genauen Transport Service User (welcher durch IP Adresse und Port Nummer identifiziert wird)
Passive Mode: eine Anwendung informiert TCP, dass es bereit ist eingehende Verbindungen zu akzeptieren. Nun kann spezifiziert werden, ob ein bestimmter Port für eingehende Verbindungen zur Verfügung steht oder ob alle eingehenden Anfragen akzeptiert werden. Wenn eine Anfrage kommt wird ein neuer Socket erstellt, welcher als Verbindungsendpunkt dient.
Wenn ein Paket von Sender zu Empfänger verloren geht wird der Empfänger ein ACK mit der Sequenznummer des Pakets, welches fehlt, an den Sender übermitteln (duplicate ACKs). Wenn der Sender 3 ACKs mit der selben Sequenznummer erhalten hat, wird er annehmen, dass das Segment wohl verloren gegangen ist und es erneut senden. Nennt man auch Fast retransmit, da das erneute senden des Segments gesendet werden kann bevor es zum Timeout kommt.
Sowohl Sender als auch Empfängerseite haben einen Puffer. Beim Sender ist dieser nötig falls Pakete verloren gehen und erneut gesendet werden müssen. Erst nach Ablauf des Timers werden diese aus dem Puffer entfernt. Der Empfänger besitzt einen Puffer für Pakete, die er noch nicht abgearbeitet hat.
TCP Flusskontrolle: Advertised Window (Größe des noch zur verfügungstehenden Platzes im Puffer)
Advertised Window = MaxRcvdBuffer - ((NextByteExpected -1) - LastByteRead)
TCP Sender stellt sicher das gilt: LastByteSent - LastByteAcked <= AdvertisedWindow
Self-clocking: Die Ankunft eines ACKs beim Sender bedeutet, dass neue Daten zum Empfänger geschickt werden können. Aber ist das sinnvoll wenn das ACK nur für eine kleine Menge von Daten steht? NEIN -> "silly window syndrome". Man würde auch nicht einen LKW losschicken wenn ein Joghurtbecher im Laden verkauft wurde, sondern warten, bis man den LKW ganz füllen kann => Nagle´s Algorithm: wenn sowohl die verfügbaren Daten also auch das advertised window >= MSS (Maximum Sequence Size [eines Pakets]) sind, sende volles Segment. Falls noch un-acked Daten vorhanden sind, puffer neue Daten bis MSS voll ist.
TCP Überlastkontrolle:
Wenn Pakete verloren gehen, nimmt TCP an, dass eine Überlast vorliegt und wird dann die Überlastkontrolle (window-based) starten: LastByteSent - LastByteAcked <= CongWin [Flusskontrolle wird hier nicht berücksichtigt]
Angenommen TCP bestimmt die korrekte Größe des congestion windows, wann können mehr Daten gesendet werden? Erst wenn wieder Platz im Netz ist. Dafür können die ACKs herangezogen werden. Diese werden nun als Erlaubnis interpretiert eine bestimmte Menge an Daten ins Netz zu senden (ACK-clocking [self-clocking] Verhalten von TCP). Wenn ACKs ankommen wird das congestion window vergrößert (greedy). Um wie viel wird das Fenster vergrößert? Generell: wenn alle Pakete innerhalb der RTT angekommen sind, versuche ein Paket mehr zu senden (additive increase). Dieses Vorgehen benötigt aber lange Zeit bis es einen angemessenen Durchsatz erreicht.
"Slow Start": Startet bei einem Paket und verdoppelt in der Initialisierungsphase das congestion window nach jedem RTT bis zu einem gewissen Punkt. Von da an nur noch ein Paket hinzufügen. [Der Name "Slow Start" ist historisch bedingt - früher gab es noch aggressivere Modelle].
Wenn keine ACKs ankommen und ein Timeout eintritt bedeuted das wohl, dass das Paket verloren gegangen ist und das Netz überladen ist - congestion window wird verkleinert. Congestion window wird um 50% verkleinert, aber nicht kleiner als 1 Paket (multiplikative decrease). Es kann natürlich auch sein, dass ein Paket aufgrund von trasmission errors verworfen wurd und nicht wegen Überlast. TCP wird dies in diesem Fall falsch interpretieren (transmission errors treten aber selten in kabelgebundenen Netzwerken auf).
AIMD (Additive Increase Multiplicative Decrease) ist fair!
Problem: Paket Bursts: Angenommen Sender schickt volles congestion window and Daten, es kommen aber keine ACKs vor Timeout. Congestion window wird halbiert und Paket gesendet. Danach kommt auf einmal das ACK für alle vorherig gesendeten Daten. Dann wir der Sender die Hälfte des congestion window auf einmal senden (single burst).
Lösung: Sender sollte auch hier Slow Start anwenden. Merke dir wie groß die Netzwerkkapazität war (congestion threshold) und wende Slow Start bis zu diesem Punkt an und von da an additive increase.
QUIC (von Google)
Bearbeitet heute ca. 20% des Internettraffics. QUIC ersetzt TLS und Teile von TCP und baut auf UDP auf. Zudem justiert es die Paketrate zum gemessenen RTT -> smooth und effizient. Es unterstützt forward error correction.
Warteschlangentheorie
Die fünf funamental wichtigen Punkte:
Ankunftsprozess: interarrival times (Zwischenankunftszeit): A(t) = P[Zeit zwischen Ankünften <= t]
Serviceprozess: Wie viel Nachfrage generieren Anfragen? Service time B(x) = P[Service time <= x]
Wie viele Plätze in Warteschlange?
Wie viele Server?
Strategie: Wie wird eine Warteschlange bearbeitet? First-come-first-serve, shortest job first, earliest deadline first etc.
Birth-death Process: beschreibt die Zahl der Kunden im System (Birth = Ankunft neuer Kunden [k+1], Death = Kunden wurde "abgefertigt" und verlassen das System[k-1]), Zustandsübergänge können nur zu Nachbarzuständen stattfinden.
Markov Process, Poisson Process
Queues: M/M/1, M/M/m, M/M/1/N
Littles Law: N = λT [λ = average requests?, T = average system time]
Die Utilization in einem Single Server System gibt das Verhältnis zwischen der durchschnittlichen Ankunftsrate und der durchschnittlichen Servicerate an.
Parameter für stochastischen Prozess: Zustandsraum (state space), Zeitparameter, Abhängigkeit zwischen X(t)´s
Bedingungen für Markov Prozesse: müssen homogen sein, Prozesse sind gedächtnislos, Verteilung der Prozesszeiten ist exponentiell verteilt
Kendalls Notation:
A -> Ankunftsprozess
S -> Serviceprozess
m -> Serveranzahl
N -> Anzahl der Plätze im System
Multicast
Ist die Möglichkeit eine Nachricht an viele verschiedene Empfänger zu senden (z.B. Radio, Videokonferenz, Shared Whiteboard, Live-Video etc.). Mit Multicast kann Bandbreite gespart werden, weil es nur an eine Gruppe von Empfängern geschickt wird, die den Inhalt auch sehen wollen, anders als beim Broadcast, welches an alle sendet.
Theoretisch kann ein Sender, welcher zu jedem Empfänger eine Unicast (1-zu-1 Verbindung) aufbaut, ein Multicast sein. Dies wäre aber nur "syntaktischer Zucker" und kann nicht schon als Multicast bezeichnet werden. Dafür müssen noch andere Bedingungen erfüllt werden, z.B. höhere Effizienz und/oder stärkere Sendegarantien (z.B. reliability). Duplikate entstehen direkt beim Sender.
Network Multicast: Der Sender schickt nur ein Paket and den Router, der weiß wie er das Paket an die Empfänger weiterleiten muss. Duplikate entstehen nur da, wo sich die Wege zu den Empfängern trennen.
Application-layer Multicast: Hier sind die Endsysteme mit eingebunden im Multicast-Prozess, d.h. dass der Sender das Datagram an einen Empfänger sendet und dieser die Inhalte an die anderen Empfänger via Unicast weiterleitet. Dies wird in einer Topologie durchgeführt von der man annimmt, dass kein Multicast unterstützt wird. Duplikate entstehen an den Endsystemen.
Multicast Routing
Flooding: intelligent eingesetzt kann es nützlich für Multicast eingesetzt werden
Spanning Trees: Hier soll nur ein aktiver Pfad zwischen zwei Multicast Routern aktiv sein. Zudem sollten sich keine Schleifen bilden um alle Empfänger zu erreichen (jedes Ziel auf genau einem Weg erreichen). Sollten effizient sein und nur den kürztesten Pfad nehmen.
Steiner Tree: es werden nur die Router in betracht gezogen, die direkt mit einem Endsystem verbunden sind. Meistens gibt diese Methode die ideale Lösung an, jedoch wird dieses Vorgehen nicht für Multicast genutzt, da der Rechenaufwand bei größeren Netzwerken zu komplex wird
Shared-tree: die selbe Struktur wird von allen Mitgliedern der Mutlicastgruppe genutzt um Pakete an Empfänger zu senden
Core-Based Tree: ein Router wird als das Zentrum ausgemacht. Die Edge-Router (Router die direkt an einem Endsystem anliegen) adressieren eine Unicast-Nachricht an den Zentrums-Router (die Nachricht wird von dazwischenliegenenden Routern zum Zentrum weitergeleitet. Entweder wird ein schon existierender Pfad zum Zentrum oder das Zentrum getroffen). Diese Variante ist weniger Komplex, jedoch gibt es einen erhöhten Traffic um den Zentrums-Router (bottleneck).
Source-based tree: die Struktur sieht für jeden Sender anders aus (SPT [Shortest Path Trees], RPF [Reverse Path Forwarding])
Shortest Path Tree: baut mithilfe des Dijkstra Algorithmus die ganze Topologie auf. Die Router die für das Multicast nicht gebraucht werden können dann im zweiten Schritt entfernt werden ("pruning")
Reverse Path Forwarding: Sender schickt Paket an die Empfänger. Wenn das zurückkommende Paket den kürzesten Pfad aufweist, wird sich dieser Pfad gemerkt. Wie kann der Sender wissen ob es sich um den kürzesten Pfad handelt? Dafür wird die Routing Tabelle für Unicast herangezogen
Group-shared tree: (MST [Minimal Spanning Trees], CBT [Core Based Trees])
Reliable Multicast
Die Grundidee von simplen Multicast Algorithmen war, dass man für jedes korrekte Senden eines Pakets an das Endsystem ein ACK fordert. Dies führt jedoch zu einer sogenannten "ACK Implosion", bedeutet dass die ACKs von den Endsystemen relativ zeitgleich zurück an den Sender geschickt werden und dadurch eine Überlast entsteht. Lösung: Da Multicast in den meisten Fällen erfolgreich Pakete verschickt, fordere nur NACKs an um in diesem Fall ein Paket erneut zu senden.
Application Layer
Verteiltes System: Client/Server Model
Kommunikation durch "request-response" Paare
Kommunikation ist asymmetrisch (Client sendet Anfrage an Server, Server verarbeitet Anfrage und sendet Antwort)
Server können iterativ oder konkurrierend sein.
Iterative Server: Server bearbeitet nur eine Clienten-Anfrage zu einer Zeit. Wenn Anfragen von unterschiedlichen Clients gleichzeitig beim Server eingehen, werden die anderen Anfragen vom Betriebssystem in eine Warteschlange gepackt
Concurrent Server: Hauptaufgabe ist es mehrere Anfragen von Clients zu akzeptieren. Dabei ist der Hauptprozess zuständig für die Annahme von Anfragen und leitet diese weiter and child processes, welche die Anfragen bearbeiten. Child-Prozesse werden wieder beendet, nachdem sie die Anfrage beantwortet haben
Extended Client/Server Model
Anfragen können an einen weiteren Server delegiert werden
DNS (Domain Name System)
Liegt auf der Anwendungsschicht und ist zuständig um Host-Adressen, Mail-Server, Aliasnamen etc. aufzulösen.
DNS ist hierarchisch aufgebaut. Ganz oben ist die root-zone, darunter sind die Top-Level Domains (.com, .edu, .org, .gov etc) + für jedes Land ein Country Code (.de, .ru, .uk, .jp etc), darunter die sub domains.
Root Name Servers: Diese werden kontaktiert wenn die lokalen Name Server Namen nicht auflösen können. Wenn der Root Name Server den Namen direkt auflösen kann, wird er diesen direkt zurückgeben, ansonsten (und typischerweise) wird der Root Server die Anfrage an den dazugehörigen TLD resolver weiterleiten. Weltweit gibt es 13 Root Name Server (heute sind es nicht mehr 13 Server [~1000 heute] aber immernoch 13 IP-Adresen).
Resource Records: so werden die festen Einträge in DNS genannt. Diese Einträge enthalten den Namen der Webseite, TTL (Time-to-live), Klasse (IN [Internet]), Type (IPv4, IPv6, NS [Name Server], MX [Mail Exchange]), rdlength (Länge des nächsten Feldes), rdata (Inhalt)
Iterative Queries: (Weiterleiten der Anfrage)
Bsp.: ein Host möchte die Seite cis.poly.edu besuchen. Diese Anfrage wird zunächst an den lokalen DNS Server geschickt. Wenn dieser keinen Eintrag hat, sendet der lokale DNS Server die Anfrage an den Root DNS Server. Wenn dieser keinen Eintrag hat, wird Root DNS dem lokalen DNS sagen, dass er einen TLD DNS Server fragen soll, der für .edu zuständig ist. Der lokale DNS Server fragt TLD DNS Server, der für .edu zuständig ist an und erhält die Antwort, dass es sich um die Webseite umass.edu handelt. Der lokale DNS Server fragt umass.edu an und der dafür zuständige Server gibt die IP-Adresse für gaia.cs.umass.edu zurück.
Pro: die Antwort ist auf jedenfall vom richtigen Server
Recursive Queries:
Host fragt lokalen DNS Server nach cis.poly.edu, wenn lokaler DNS Server keinen Eintrag hat, leitet er die Anfrage and root DNS Server weiter. Dieser leitet die Anfrage direkt an TLD DNS Server, - zuständig für .edu - weiter. TLD DNS Server sendet Anfrage weiter an den für die Seite umass.edu zuständigen DNS Server weiter, der dann die Antwort auf selben Wege zurück zum Hoste leitet.
Pro: Anfragen können gecached werden. Falls also ähnliche Anfragen kommen, können die Server direkt darauf antworten.
Con: Cache Poisoning möglich: dadurch werden falsche Einträge in Cache gemacht
HTTP/1.0: nonpersistent, konnte höchstens ein Objekt über TCP Verbindung senden, danach wurde Verbindung geschlossen
Problem: eine Seite kann mehrere Objekte enthalten (z.B. jpeg files), d.h. für jedes Objekt auf der Seite muss ein erneuter request geschickt werden -> RTT erhöht sich
HTTP/1.1: persistent ohne pipelining, konnte mehrere Objekte über einzelne TCP Verbindung zwischen Client und Server senden, d.h. Verbindung bleibt nach Senden offen
HTTP/1.1: persistent mit pipelining, Client konnte mehrere Anfragen parallel senden. Zwar wurden die Anfragen nicht alle auf einmal bearbeitet, war aber schneller als ohne pipelining.
Problem: Anfragen wurden in Reihenfolge bearbeitet. Wenn ein Fehler aufgetreten ist, wurden die nachfolgenden Anfragen nicht mehr bearbeitet
HTTP/2: multiplexing: mehrere Anfragen in einer gebündelt. Es gibt keine Reihenfolge der Bearbeitung von Anfragen mehr, sondern Priorität -> löst pipelining Problem von HTTP/1.1. Daten im Header werden binär komprimiert
Cookies: können genutzt werden um Authorisierung, Warenkorb zu speichern. Durch Cookies lernt die Website aber auch Dinge über mich, z.B. Name, E-Mail, Verhalten.
Peer-to-Peer
Hierarchie ist sehr flach. Es gibt keine Server. Somit agiert jeder Client auch als Server (während Client z.B. etwas von einem anderen Peer runterlädt, agiert der Client als Server und stellt die bereits runtergeladenen Inhalte zum Download bereit).
Anwendungsbereiche: File Sharing, Blockchain, Video Streaming
-> gute Skalierbarkeit
