Komplexität verwalten \& beherrschen & Funktionen vl redundant \\
Änderung der Implementierung transparent & selbe Information für verschiedene Layer nötig \\
Ideales Netzwerk & Layer n benötigt eventuell Einblick in Layern n+x \\
\end{tabular}
\section{Architekturvoraussetzungen}
für das Internet
\begin{description}
\item[Generalität] Unterstütze alle möglichen Sets von Applikationen
\item[Heterogenität] Verbinde alle Arten von Netzwerktechnologien
\item[Robustheit] Wichtiger als Effizienz
\item[Erweiterbarkeit] Wichtiger als Effizienz
\item[Skalierbarkeit] Spätere Entdeckung
\end{description}
\section{Medium Access Control (MAC)}
\subsection{Annahmen für die dynamische Kanalzuweisung}
\begin{itemize}
\item Stationsmodell
\begin{itemize}
\item N unabhängige Stationen
\item Mögliches Lastmodell: Wahrscheinlichkeit des Generierens eines Pakets im Intervall t ist x*T, mit x konstant
\end{itemize}
\item Einkanalannahme: Nur ein Kanal für alle Stationen und für alle Nachrichten
\item Kollisionsannahme: Nur je ein Frame zeitgleich fehlerfrei übertragbar
\item Zeitmodell
\begin{itemize}
\item Kontinuierlich: Übertragungen können jederzeit stattfinden
\item Geslottet: Zeit ist in Slots eingeteilt, Übertragung kann nur an Slotgrenzen beginnen
\end{itemize}
\item Carrier Sensing (CSMA)
\begin{itemize}
\item Stationen können (oder auch nicht) erkennen, ob der Kanal frei oder in Benutzung ist
\item Falls Kanal als belegt angesehen, so wird nichts übertragen
\end{itemize}
\end{itemize}
\subsection{Carrier Sensing}
\begin{description}
\item[] Höre bevor du redest, und sende nichts, wenn das Medium gerade belegt ist
\item[1-Persistent CSMA] Falls belegt, so warte bis frei und sende dann -> Probleme entstehen, wenn mehrere nach der jetzigen Nachricht senden wollen
\item[Non-Persistent CSMA] Wenn Kanal frei so übertrage, wenn Kanal belegt, so warte eine zufällige Zeit vor dem nächsten Freiheitstest
\item[P-Persistent CSMA] Kombiniert bisherige Ideen + geslottete Zeit, Warte ständig auf freiwerden des Kanals übertrage aber nicht sofort
\end{description}
\subsection{Collision Detetion - CSMA/CD}
Abhängig vom physischen Layer können Kollisionen erkannt werden, so warte eine zufällige Zeit k
\subsection{Bit-Map-Protokoll}
Stationen melden Sendewunsch während eines Reservierungsslots an
\begin{itemize}
\item Verhalten bei geringer Last: Wenn kaum ein Paket versendet werden soll, so wiederholt das Medium die Contentionslots -> Wartezeit
\item Verhalten bei großer Last: Hoher und stabiler Durchsatz mit vernachlässigbarem Overhead
\item Bit-Map ist ein Carrier Sense Protokoll
\end{itemize}
\subsection{Limited Contention Protokoll}
\begin{itemize}
\item Idee 1:
\begin{itemize}
\item Anpassen der Stationsanzahl per Contentionslot
\item Contentionslots sind gut für den Durchsatz, bei geringer Last können wir es uns aber nicht leisten, auf die Antworten zu warten -> Stationen müssen sich dynamisch einen Slot teilen
\end{itemize}
\item Idee 2: Adaptives Baumprotokoll := Verwende verschiedene Auflösungslevel für die Wettbewerbsslots
\end{itemize}
\subsection{Ethernetversionen}
\begin{description}
\item[Switched Ethernet] mehrere Stationen über ein Kabel
\item[Fast Ethernet] wie Switched nur mit 10ns Bitzeit
\item[Gigabit Ethernet] jedes Kabel hat genau zwei Maschinen angehängt
\begin{itemize}
\item mit Switch
\begin{itemize}
\item Keine geteilten Kollisionsdomönen, benötigen kein CSMA-CD
\item Beim Empfang eines Frames lernt der Switch den Ort des Senders kennen (Rückwärtslernen)
\end{itemize}
\subsection{Weiterleiten}
\begin{itemize}
\item Falls Ziel bekannt so prüfe, ob es in das selbe Segment gehört aus dem es kommt -> verwerfen,
\item sonst leite es passend weiter
\item andernfalls flute das Netzwerk damit
\end{itemize}
\subsection{Rückwärtslernen in Bridges - Bootstrapping}
\begin{itemize}
\item Flute, falls nicht bekannt wohin gesendet werden muss, oder
\item verwerfe, wenn bekannt, dass es nicht nötig ist, oder
\item leite spezifisch weiter, wenn das Ziel bekannt ist
\end{itemize}
\subsection{Gateways}
Wenn selbst Router nicht ausreichend, dann sind Higher-Layer-Verbindungen notwendig; Arbeit auf dem Transportlevel und oberhalb, zum Beispiel für Transcodierung
\subsection{Verbindung einzelner LANs}
\begin{itemize}
\item Physisches Layer - Repeater und Hub
\item Data-Link-Layer - Bridges und Switches
\item Netzwerklayer - Routing
\item Higher-Layer - Gateways
\end{itemize}
\section{Netzwerklayer}
\subsection{Durchsuchen der Routingtabelle}
\begin{itemize}
\item Suche nach übereinstimmender Hostadresse (Flag H gesetzt)
\item Suche dann nach passender Netzwerkadresse
\item Drittens, Suche nach einem Defaulteintrag
\end{itemize}
\subsection{Switching Fabric}
\begin{itemize}
\item Switching mittels Speicher
\begin{itemize}
\item Herkömmliche Rechner mit Switching unter direkter CPU-Kontrolle
\item Kopieren der Pakete in den Systemspeicher
\item Geschwindigekeit limitiert durch die Speicherbandbreite
\end{itemize}
\item Switching mittels BUS
\begin{itemize}
\item Übertragung von Datagrammen intern über einen Bus
\item Switchinggeschwindikeit limitiert durch die Busbandbreite
\item typ. 1Gbps Bus, ausreichend für Heim und Businessrouter
\item Headerchecksum: Erlaubt Verifizierung der Inhalte im IP Header
\item Quell und Zieladressen: identifizieren der Quelle und des Ziels
\item Optionen: bis 40 Byte, zur Erweiterung verwendet
\end{itemize}
\subsection{Klassen von IP-Adressen}
\begin{itemize}
\item Class A: rießige Organisationen, bis 16 Mil. Hosts
\item Class B: große Organisationen, bis 65 Tausend Hosts
\item Class C: kleine Organisationen, bis 255 Hosts
\item Class D: Multicast, keine Netzwerk/Host Hierarchie
\item Class E: reserviert
\item Loopback: 127.xxx.xxx.xxx ist zum Testen reserviert, hierauf versendete Pakete werden als eingehende behandelt
\item Broadcast: alles 1en
\end{itemize}
\subsection{IP-Adressierung}
\begin{itemize}
\item IPv4 Adresse: 32 Bit Identifier für Hosts oder Routinginterfaces
\item Interface: Verbindung zwischen Host und dem physischen Link. IP Adressen werden an das jeweilige Interface vergeben
\end{itemize}
\subsection{CIDR: Classless Inter Domain Routing}
\begin{itemize}
\item Überwinden der Klassengrenzen durch Supernetting
\item ISPs können nun Class C Blocks zu einem großen Block zusammenfassen
\item "Longest match routing" auf maskierten Adressen
\item Beispiel: Alle in Europa vergebenen Adressen teilen sich einen gemeinsamen Prefix -> Nur ein Eintrag für alle Verbindungen nach Europa in den meisten amerikanischen Routern
\end{itemize}
\subsection{NAT - Network Address Translation}
\begin{itemize}
\item Lokale Netzwerke haben nur eine der Außenwelt bekannte IP-Adresse, somit hat nicht jedes Gerät eine vom ISP bereitgestellte Adresse
\begin{itemize}
\item Möglichkeit intern Adressen zu vergeben ohne die Außenwelt informieren zu müssen
\item Wechsel des ISPs möglich, ohne intern Adressen zu verändern
\item Geräte im Netzwerk nicht von außen ansprechbar (Sicherheitsfaktor)
\end{itemize}
\item 16 Bit Portnummernfeld -> 60 000 simultane Verbindung mit nur einer einzigen LAN-Side Adresse
\end{itemize}
\subsection{ICMP: Internet Control Message Protocol}
\begin{itemize}
\item Verwendet von Hosts und Routern um auf Netzwerkebene Informationen auszutauschen
\item In Netzwerkebenen oberhalb von IP werden ICMP Nachrichten als IP Datagramme versendet
\item ICMP Nachrichten: Typ, Code + erste 8 Bytes des den Fehler auslösenden IP-Datagramms
\end{itemize}
\subsection{IPv6}
\begin{itemize}
\item Header mit 40 Byte Größe (also 20 Byte mehr als bei IPv4 mit 32 Bit Adressen)
\item Fragmentierung ist nicht mehr erlaubt
\item Headerformat hilft bei schneller Verarbeitung und Weiterleitung
\item Checksummen -> komplett entfernt
\item Optionen -> Erlaubt, aber außerhalb des Headers
\item Priority: Signalisiert die Priotität der Datagramme im Fluss
\item Flow Label: Identifiziert Datagramme im selben Fluss
\item Next Header: Identifiziert das Layer der höheren Schicht für Daten
\end{itemize}
\subsection{Routing Algorithmen}
\begin{itemize}
\item Ein Router führt einen Routingalgorithmus aus, um zu entscheiden, an welchem Ausgang ein eingehendes Paket weiter übertragen werden sollte.
\begin{itemize}
\item Verbindungsorientiert: nur beim Verbindungsaufbau
\item Verbindungslos: entweder für jedes Paket oder periodisch ausgeführt
\end{itemize}
\item Oftmals unter Verwendung von Metriken -> Zuweisung eines Kostenfaktors an jeden Link, bspw. Anzahl an Hops, Kosten eines Links,…
\item Zwei grundlegende Typen existieren:
\item\begin{itemize}
\item Nichtadaptive Routingalgorithmen: Nehmen keine Rücksicht auf aktuellen Netzwerkzustand (z.B. Fluten)
\item Adaptive Routingalgorithmen: Berücksichtigen aktuellen Netzwerkzustand (z.B. Distanzvekotrrouting, Link State Routing)
\end{itemize}
\end{itemize}
\begin{description}
\item[Fluten] jedes eingehende Paket wird auf jede ausgehende Linie geschickt, außer auf die Herkunftslinie
\item[Zufallsrouting] Jedes ankommende Paket wird auf einen zufälligen Ausgang geschickt, außer auf den Quellausgang -> es bahnt sich seinen Weg sozusagen durch den Router
\item[Adaptive Routingalgorithmen]\
\begin{description}
\item[Zentralisiertes adaptives Routing] Anpassen an die vorherrschende Verkehrslast; Ein Routingkontrollcenter muss ins Netzwerk eingebaut sein, welches periodisch den Linkstatus der Router erhält und kürzeste Routen berechnet und diese an die Router sendet
\item[Isoliertes adaptives Routing] benötigt keinen Informationsaustausch zwischen Routern; Routingentscheidungen werden nur anhand der Informationen des lokalen Routers getroffen, wie bei Hotpotato oder Rückwärtslernen
\item[Verteiltes adaptives Routing] Router tauschen periodisch Infos aus und aktualisieren Weiterleitungstabellen; Finde einen guten Pfad durch das Netzwerk, welcher einen von der Quelle zum Ziel führt; Graphabstraktion für Routingalgorithmen mit Linkkosten und Pfadkosten
\end{description}
\end{description}
\subsection{Distanzvektorrouting Algorithmen}
\begin{description}
\item[Iterativ] Läuft bis keine Knoten mehr Informationen austauschen. Selbstterminierend -> kein Stoppsignal
\item[Asynchron] Knoten müssen Informationen nicht getaktet austauschen
\item[Verteilt] Jeder Knoten kommuniziert nur mit seinem direkten Nachbarn
\item[Distanztabellendatenstruktur] Jeder Knoten hat seine eigene Spalte für jedes mögliche Ziel und Zeile für jeden direkt angeschlossenen Nachbarknoten
\end{description}
\subsubsection{Vergleich zwischen Link-State und Distanzvektoralgorithmen}
\begin{itemize}
\item Nachrichtenkomplexität:
\begin{itemize}
\item LS: mit N Knoten und E Links werden $O(n-e)$ Nachrichten versandt
\item DV: Austausch nur zwischen Nachbarn
\end{itemize}
\item Konvergenzgeschwindigkeit
\begin{itemize}
\item LS: $O(n^2)$ Algorithmus benötigt $O(N-E)$ Nachrichten (teils mit Oszillation)
\item DV: Konvergenzzeit variiert (Routingschleifen, Count to Infinity Problem, Oszillation)
\end{itemize}
\item Robustheit: (im Falle eines Routerausfalls)
\begin{itemize}
\item LS: Ein Knoten kann falsche Linkkosten ausgeben; Jeder Knoten berechnet nur seine eigene Tabelle
\item DV: DV Knoten kann falsche Gewichte ausgeben; Jede Tabelle wird nun noch von anderen Routern verwendet -> Fehler breiten sich über das ganze Netzwerk aus
\end{itemize}
\end{itemize}
\subsection{Routing im Internet - Autonome Systeme}
Das globale Internet besteht aus miteinander verbundenen AS
\begin{description}
\item[Stub AS] kleine Unternehmen (ein Link zum Internet)
\item[Multihomed AS] große Unternehmen (mehrere Links, ohne Transitverkehr)
\item[Transit AS] Netzbetreiber
\end{description}
Zwei Level Routing:
\begin{description}
\item[Intra-AS] Administrator verantwortlich für die Auswahl (RIP, OSPF, IGRP)
\item[Inter-AS] Einheitlicher Standard (BGP)
\end{description}
\subsection{Intra-AS und Inter-AS Routing}
\begin{itemize}
\item Policy:
\begin{itemize}
\item Inter AS: Admin möchte Kontrolle über sein Netz haben
\item Intra AS: ein einziger Admin, also keine Policyentscheidungen nötig
\end{itemize}
\item Skalierbarkeit: Hierarchisches Routing spart Tabellenplatz und sorgt für weniger Updateverkehr
\item Performance:
\begin{itemize}
\item Inter-AS: Policy wichtiger als Performance
\item Intra-AS: Performance als oberstes Gut
\end{itemize}
\end{itemize}
\section{Transport Layer}
\subsection{Multiplexing und Demultiplexing}
Hosts verwenden IP-Adressen und Portnummern um Segmente an korrekte Sockets zuzustellen
\begin{description}
\item[Multiplexing auf Sendeseite] Sammeln von Daten an mehreren Sockets, verpacken der Daten mit Header zum Demultiplexing
\item[Demultiplexing auf Empfangsseite] Zustellen empfangener Segmente an den korrekten Socket
\end{description}
\begin{description}
\item[Verbindungslos (UDP)] Erstelle Sockets mit Portnummern; Sockets werden übber Zweiertupel aus Ziel IP und Ziel Port identifiziert
\item[Verbindungsorientiert (TCP)] TCP Sockets werden durch ein Vierertupel aus Quell-IP, Quellport, ZielIP und Zielport identifiziert
\end{description}
\subsection{verbindungsorientierte Kontrolle}
Connect $\rightarrow$ Data $\rightarrow$ Disconnect
\begin{itemize}
\item T-Connect.Request(Zieladr., Quelladr)
\item T-Connect.Indication(Zieladr., Quelladr.)
\item T-Connect.Response(Antwortadresse)
\item T-Connect.Confirmation(Antwortadresse)
\end{itemize}
CR (Connection Request) oder CC (Connection Confirm) TPDU
\subsection{Drei Wege Handshake}
\begin{itemize}
\item Verbindung wird Aufgabaut, sobald beide Verbindungsaufbau TPDUs bestätigt wurden
\item Benötigt zusätzliches ACK (Acknowledgement) oder DT (Data)
\item Packe hierzu eine Sequenznummer in die CR, ACK, CC, DATA TPDUs
\item Muss durch die Gegenseite kopiert werden, und erlaubt den Verbindungsaufbau nur dann, wenn die korrekte Nummer bereit gestellt wird. Verwende Sequenznummern deshalb möglichst nicht schnell hintereinander erneut.
\end{itemize}
\subsection{Verbindunsabbau}
\begin{description}
\item[implizit] Abbau der Netzwerklayerverbindung
\item[explizit] Verbindungsfreigabe mit Disconnect-TPDUs
\end{description}
Kann den Verlust von nicht bestätigten Daten nach sich ziehen, TCP verhindert dies, indem alle gesendeten PDUs vor Beenden der Verbindung bestätigt werden müssen
\section{Flusskontrolle}
\subsection{Pufferallokation}
\begin{itemize}
\item Flusskontrolle abhängig von der Puffermöglichkeit
\item Um ausstehdene Pakete zu unterstützen müssen diese entweder sofort und in korrekter Reihenfolge beim Empfänger ankommen, oder es muss genügend Puffer vorhanden sein
\item Empfänger verlangsamt den Sender oder Anforderung von Pufferspeicher durch den Sender
\item Mitteilung des Empfängers an den Sender, dass nur noch so viel Puffer verfügbar ist (bei Sliding Window einfach das Sendefenster anpassen)
\end{itemize}
\subsection{Continue und Stop}
Einfachste Lösung: Sende Stopnachrichten wenn der Empfänger nicht schritthalten kann und Continue, sobald wieder Ressourcen vorhanden sind. \
Beispiel: XON/XOFF: funktioniert aber nur bei Fullduplexverbindungen.
\subsection{Implizite Flusskontrolle}
Idee: Halte ACKs oder NACKs zurück, um den Sender zu verlangsamen, somit werden Fehlerkontrollmechanismen nun zur Flusskontrolle missbraucht werden.\
Nachteil: Senderseitig keine Unterscheidung mehr möglich, ob Pakete verloren gingen, oder er verlangsamt werden soll, was in unnötigen Wiederholungsübertragungen resultiert.
\subsection{Kreditbasierte Flusskontrolle}
Der Empfänger gewährt dem Sender expliziten Kredit, sodass dieser meherere Pakete senden kann. Ist der Kredit aufgebraucht, so muss der Sender warten, bis er wieder neuen zugeteilt bekommt. Hierbei benötigen wir Fehlerkontrolle um auf verlorene Kreditnachrichten resultieren zu können
\subsection{Permits und Acknowledgements}
\begin{itemize}
\item Permits = Empfänger hat Pufferspeicher, sende also weiter
\item Acknowledgements = Empfänger hat Anzahl X an Paketen empfangen
\item Kombinierbar mit dynamisch wachsendem Pufferplatz beim Emfänger (Beispiel TCP)
\end{itemize}
\section{Staukontrolle}
Jedes Netzwerk kann nur eine gewisse Anzahl an Traffic pro Zeit transportieren, wenn nun mehr Traffic von den Quellen ausgeht, als das Netzwerk als nominelle Kapazität hat, so kommt es zu Staukollapsen und verlorenen Paketen. Immer $\lambda$-in = $\lambda$-out (goodput)\
Staukontrolle ist essentiell, um Schneeballeffekte zu vermeiden: Sobald ein Netzwerk einmal überladen ist, wird es Pakete verlieren. Nach Erkennung von Paketverlusten durch ein zuverlässiges Transportprotokoll, werden Pakete erneut übertragen, was die Last abermals erhöht
\begin{itemize}
\item Die Senderate jeder Quelle muss an die aktuelle Kapazität des Netzwerks angepasst werden
\item Staukontrolle ist ein globales Problem, da dies abhängig von allen Routern, Weiterleitungsdisziplinen, Lastinjektionenund so weiter ist.
\item Flusskontrolle wiederum ist ein lokales Problem: Die Quelle darf das Ziel nicht überlasten, also sind nur Ziel und Quelle involviert
\end{itemize}
\subsection{Design/Aktions Optionen}
\begin{description}
\item[Open Loop] Designe das System von Beginn an so, dass es korrekt funktioniert und man keine Korrekturen zur Laufzeit vornehmen muss
\item[Closed Loop] Verwende Feedback, um zu erlauben, dass sich der Sender an die Situation anpasst
\item[Explizited Feedback] Die Stelle, an welcher der Stau auftritt informiert den Sender
\item[Implizites Feedback] der Sender extrahiert aus dem Netzwerkverhalten Informationen darüber, wie er sich verhalten sollte
\end{description}
\begin{itemize}
\item Erhöhen der Kapzität -> teuer, kurzfristig nicht umsetzbar
\item Reservierungen und Zugriffskontrolle - erlaube also keinen zusätzlichen Verkehr wenn das Netzwerk stark ausgelastet ist -> nur für schaltkreisbasierende Netzwerke verfügbar
\item Reduzierung der Last in kleiner Granularität -> Bringe einzelne Quellen dazu ihre Last zu reduzieren, sodass nichts terminiert werden muss (benötigt Feedback vom Netz: closed loop)
\item Verwerfen von Paketen -> Pufferplatz ist voll und alte Pakete werden verworfen. Für Medieninhalte sind neue wichtiger als alte Pakete
\end{itemize}
\subsection{Choke Pakete}
Sobald ein Stau der Router einen Stau erkannt hat -> Sende Chokepakete. Chokepakete sagen dem Ziel, dass es seine Senderate verringern soll
\subsection{Warnungsbits}
Sobald ein Router feststellt, dass er von Stau betroffen ist, setzt er ein Warnbit in allen Paketen die er verschickt -> Da das Ziel das Warnungsbit in sein ACK Paket aufnimmt, erfährt die Quelle vom Stau und kann ihre Sendeleistung minimieren.
\subsection{Random Early Detection}
nutze verworfene Pakete als implizites Feedback, bereits bevor die Warteschlange voll ist, wirf also vorzeitig Pakete weg um Feedback zu geben.
Mit steigender Staubelastung am Router kann die Entwurfswahrscheinlichkeit erhöht werden
\section{TCP}
\subsection{Drei Wege Handshake}
\begin{itemize}
\item Client sendet ein TCP SYN (SYN = 1, ACK = 0) an den Server -> spezifiziert initiale, nie benutzte Sequenznummer
\item Server erhält das SYN Paket und antwortet mit einem SYNACK (SYN = 1, ACK = 1) -> Server alloziert Puffer und spezifikation der initialen Sequenznummer des Servers
\item Der Client erhält das SYNACK und antwortet hierauf mit einem ACK (SYN = 0, ACK = 1), hier können nun erstmals Daten enthalten sein
\end{itemize}
Terminieren einer Verbindung
\begin{itemize}
\item Client sendet ein TCP FIN
\item Server empfängt das FIN, antwortet mit einem ACK und sendet ebenfalls ein FIN
\item Client erhält ein FIN Segment, antwortet darauf mit ACK und geht in timed Wait Zustand, antwortet auf alle FINs mit ACKs
\item Server erhält ein ACK, die Verbindung ist geschlossen
\end{itemize}
\subsection{Sende- und Empfangspuffer}
\begin{itemize}
\item Sender: Puffer um Fehlerkontrolle bereit zu stellen
\item Empfänger: Zwischenspeichern von noch nicht abgerufenen, oder nicht reihenfolgegetreu angekommenen Paketen
\end{itemize}
\subsection{Flusskontrolle: Angebotenes Fenster}
Der Empfänger kann seine Empfangpufferkapazitäten verkünden
\subsection{Nagles Algorithmus - Selbsttaktung und Fenster}
\begin{itemize}
\item TCP Selbsttaktung: Ankunft eines ACKs ist ein Zeichen dafür, dass neue Daten auf das Netzwerk geschickt werden können
\item falls sowohl angebotene Daten und das angebotene Fenster >= MSS -> Sende ein volles Segment
\item falls unbestätigte Daten auf dem Weg sind, so puffere neue Daten bis das MSS voll ist,
\item andernfalls schicke die Daten sofort
\end{itemize}
\subsection{Staukontrolle}
\begin{itemize}
\item Implizites Feedback durch verworfene Pakete. Annahme: Stau als Hauptgrund für verworfene Pakete
\item Fensterbasierte Staukontrolle: TCP führt Buch über die Anzahl an Bytes die es noch in das Netzwerk injezieren darf, diese Fenstergröße kann wachsen oder schrumpfen
\end{itemize}
\subsection{AIMD - Sägezahnmuster der Last}
\begin{itemize}
\item TCP verwendet AIMD, also additive increase, multiplicative decrease Taktik
\item Es wird also kontinuierich auf zusätzliche Bandbreite geprüft und durch die Erhöhung der Bandbreitengrenze wird das Netzwerk regelmäßig die multiplikative Verringerung ausführen -> Sägezahnmuster
\end{itemize}
\section{Application Layer}
\subsection{HTTP Statuscodes}
\begin{itemize}
\item 200 OK - Anfrage okay, das angefragte Objekt folgt
\item 301 Moved Permanently - das angefragte Objekt wurde verschoben, der neue Pfad folgt
\item 400 Bad Request - Anfrage wurde nicht verstanden
\item 404 Not Found - angefordertes Objekt konnte auf dem Server nicht gefunden werden
\item 505 HTTP Version not supported
\end{itemize}
\subsection{Cookies}
\begin{itemize}
\item Cookieheaderzeile in der Antwort
\item Cookieheaderzeile in der Anfrage
\item Die Cookiedatei wird auf dem Rechner des Hosts gespeichert und vom Browser verwaltet
\item Speichern der Cookieinformationen in einer Backenddatenbank der Webseite
\end{itemize}
\subsection{Webcaches (Proxyserver)}
Bedienen der Clientanfrage ohne den urpsrünglichen Webserver dabei zu involvieren
\begin{itemize}
\item Der Nutzer stellt den Browser so ein, dass dieser über einen Cache auf das Netz zugreift
\item Alle Anfragen des Browsers gehen zuerst an den Cache, hat er das angefragte Material, so wird er dieses an den Client schicken, oder andernfalls beim Webserver besorgen und dem Client dann weiterleiten
\item Der Cache agiert sowohl als Client als auch als Server
\item Reduzieren von Antwortzeiten für Clientanfragen
\item Reduzieren von Verkehr auf dem Zugangslink des ISPs
\item Ein Internet voller Caches erlaubt es armen Anbietern effektiv Inhalte zu übertragen
\end{itemize}
\subsection{Webserver}
\subsubsection{Grundlegende Webserveraufgaben}
\begin{itemize}
\item Zum Empfang von Anfragen bereitmachen
\item Annehmen von Verbindungen und Anfragen
\item Lesen und Verarbeiten von Anfragen
\item Antworten auf Anfragen
\item Bereitmachen und Annehmen von Anfragen
\end{itemize}
\begin{enumerate}
\item Prozessmodell
\begin{itemize}
\item Einem Prozess werden alle benötigten Schritte zugewiesen, welche benötigt werden, um eine Anfrage zu bearbeiten
\item Wenn die Bearbeitung abgeschlossen ist, so ist der Prozess wieder in der Lage neue Verbindungen zu akzeptieren
\item Typischerweise werden mehrere Prozesse benötigt
\item Ein Prozess blockiert, beispielsweise read(), dann entscheidet das OS, welcher Prozess als nächstes ausgeführt werden darf
\item Die Parallelität wird durch die Anzahl an Prozessen limitiert
\item Vorteile: Synchronisation dem Prozessmodell inhärent; Absicherung zwischen Prozessen
\item Nachteile: Langsam; Schwere Ausführbarkeit von Operationen, welche auf globalen Informationen beruhen
\end{itemize}
\item Threadmodell
\begin{itemize}
\item Verwende Threads anstelle von Prozessen
\item Vorteile: Schneller als Prozesse; Teilen standardmäßig aktiv
\item Nachteile: Benötigt OS Unterstützung; Kann per Prozess Limitierungen überlasten; Beschränkte Kontrolle über Schedulingentscheidungen
\end{itemize}
\item In-Kernel Modell
\begin{itemize}
\item möglich: ganzer Server im Kernel
\item Meist: nur statische Dateien werden vom Kernel bedient, andere Anfragen gehen an den regulären User-Space-Server
\item Dedizierter Kernelthread für HTTP Anfragen
\item Vorteile: Vermeidet das Kopieren von und in den Userspace; Sehr schnell, solange es eng in den Kernel integriert ist
\item Nachteile: Bugs können das OS, also die ganze Maschine crashen; Schwer zu debuggen und zu Erweitern; Inhärent OS-spezifisch
\end{itemize}
\item Eventbasiertes Modell
\begin{itemize}
\item Verwenden eines einzelnen Webserverprozesses um mehrere Anfragen zu behandeln
\item Vorteile: Sehr schnell, kein Kontextwechsel; Inhärentes Teilen ohne Locks; Komplette Kontrolle über die Schedulingentscheidungen; Kein komplexer OS-Support benötigt
\item Nachteile: Per-Prozess Begrenzungen; Nicht jedes OS mit voll asynchroner E/A, so können beim Lesen immernoch Blockierungen entstehen; Flash verwendet immerhin Hilfsprozesse um dies zu verhindern
\end{itemize}
\end{enumerate}
\subsection{Mailzugriffsprotokolle}
\begin{description}
\item[SMTP] Zustellen/Speichern auf dem Empfangsserver
\item[POP] Post Office Protocol: Autorisierung und Download; POP3 ist zustandlos über mehrere Sitzungen
\item[IMAP] Internet Mail Access Protocol: Mehr Features aber komplexer; Behält alle Nachrichten am Server
\item[HTTP] Yahoo Mail, Hotmail, etc.
\end{description}
\subsection{DNS - Domain Name System}
verteilte Datenbank implementiert in der Hierarchie von vielen verschiedenen Nameservern
Anwendungsschichtprotokoll für Hosts, Router und Nameserver zum Kommunizieren zur Namensauflösung
\section{Sicherheit}
\subsection{Sicherheitsziele}
\begin{description}
\item[Vertraulichkeit] Verschickte oder gespeicherte Daten sollen nur einem bestimmten Nutzerkreis zugänglich sein; Vertraulichkeit von Instanzen wird auch als Anonymität bezeichnet
\item[Datenintegrität] Es sollte möglich sein, jede Veränderung von Daten zu erkennen, dies benötigt unter anderem, die Möglichkeit den Ersteller von Daten identifizieren zu können
\item[Verantwortlichkeit] Es sollte möglich sein, eine Instanz zu identifizieren, welche für irgendein Kommunikationsereignis zuständig ist
\item[Verfügbarkeit] Dienste sollten verfügbar sein und auch funktionieren
\item[Kontrollierter Zugriff] Nur autorisierte Instanzen solle in der Lage sein auf bestimmte Dienste oder Daten zuzugreifen
\end{description}
\subsection{Bedrohnungen technisch definiert}
\begin{description}
\item[Maskerade (Spoofing)] Eine Instanz behauptet jemand Anderes zu sein
\item[Abhören (Sniffing)] Jemand versucht Daten zu lesen, welche er nicht lesen darf und soll
\item[Autorisierungsverletzungen] Eine Instanz verwendet Ressourcen die sie nicht verwenden darf
\item[Verlust oder Veränderung von übertragener Information] Veränderung oder Zerstörung von Daten
\item[Fälschung von Daten] Eine Instanz erzeugt Daten im Namen einer Anderen
\item[Abstreiten von Kommunikationsereignissen] Eine Instanz streitet seine Beteiligung an einem Kommunikationsereignis ab
\item[Sabotage] Jede Art von Aktion welche darauf abzielt, die Verfügbarkeit oder korrekte Funktion von Diensten zu reduzieren
\end{description}
\subsection{Sicherheitsanalyse von gelayerten Protokollarchitekturen}
Dimension 1: Auf welchem Interface findet der Angriff statt?\
Dimension 2: Auf welchem Layer findet der Angriff statt?
\subsection{Sicherheitsmechanismen}
\begin{description}
\item[Physische Sicherheit] Abschließen der Betriebsräume, Zutrittskontrolle; Schutz vor Überwachung der Umgebung
\item[Personelle Sicherheit] Sensitivität bei Mitarbeitern erzeugen; Überprüfung der Angestellten; Sicherheitstraining
\item[Administrative Sicherheit] Kontrollieren neuer Software; Prozeduren um Sicherheitsverstöße zu erkennen; Ansehen und Reagieren auf Audittrails
\item[Ausstrahlungssicherheit] Steuerung von Frequenzen und anderer elektromagnetischer Ausstrahlungen
\item[Mediensicherheit] Kontrollieren der Erstellung, Reproduktion und Zerstörung von Informationen; Scannen von Medien auf Schadsoftware
\item[Lifecyclekontrollen] Vertrauenswürdiges Systemdesign der Implementierung, Evaluation und Unterstüzung; Dokumentierung; Einhalten von Programmierstandards
\item[Computersicherheit] Schutz der Informationen, während diese auf Rechnern gespeichert oder verarbeitet werden; Schutz der Rechner selbst
\item[Kommunikationssicherheit] Schutz der Informationen beim Transport von einem zum anderen System; Schutz der Kommunikationsinfrastruktur an sich
\end{description}
\subsection{Sicherheitsdienste}
\begin{description}
\item[Authentisierung] Grundlegender Sicherheitsdienst, welcher sicherstellt, dass eine Instanz tatsächlich die Identität hat, welche sie vorgibt zu haben
\item[Integrität] Kleiner Bruder der Authentisierung, da er sicherstellt, dass Daten, welche von einer gewissen Einheit erstellt worden sind, nicht ohne Erkennung verändert werden können
\item[Vertraulichkeit] Stellt sicher, dass die geschützen Daten geheim bleiben
\item[Zugriffskontrolle] Kontrolliert, dass jede Identität nur auf die Informationen und Dienste zugreift, zu welchen sie auch zugriffsberechtigt ist
\item[Nicht Ablehnung] Schütz davor, dass andere Einheiten nach einer Kommunikation behaupten können, nie daran teilgenommen zu haben
\end{description}
\subsection{Wichtige Eigenschaften von Verschlüsselungsalgorithmen}
Fehlerausbreitung: Charakterisiert die Effekte von Bitfehlern während der Übertragung von Ciphertext zum rekonstruierten Klartext\
Synchronisation: Charakterisiert die Effekte von verlorenen Ciphertexten auf den rekonstruierten Klartext
\subsection{Sicherheitsziele von IPSec}
\begin{description}
\item[Datenherkunftsauthentisierung/Datenintegrität] maskierte Quell- oder Zieladresse zu versenden, Pakete während der Übertragung zu verändern, gespeichertes Paket zu späterem Zeitpunkt zu versenden soll unmöglich sein (dass der Empfänger dies nicht merkt)
\item[Vertrauenswürdigkeit] Es soll nicht möglich sein, den Inhalt der IP Datagramme auszuspähen; Es soll weiterhin eine begrenzte Traffic Flow Confidentiality geben
\item[Sicherheitsrichtlinie] Sender, Empfänger und zwischenliegende Knoten sollen erkennen können, ob ein Paket ihrer Sicherheitsrichtlinie entspricht und dieses gegebenenfalls verwerfen
\end{description}
\subsection{Pakete}
\subsubsection{DHCP}
DHCP Discover an Broadcast (255.255.255.255), Server sendet DHCP Offer zurück mit Payload, DHCP Request (gleich wie Discover)\\
DHCP: Discover/Offer/Request/ACK\\
UDP/TCP: SrcPort \& DstPort\\
IP: SrcIP \& DstIP\\
MAC: SrcAddr \& DestAddr\\
Payload: (optional)
\subsubsection{ARP}
ARP-Request/Response:\
ARP: ARP-Request Payload: XXXX\\
MAC: SrcAddr XXXX DestAddr XXX
\subsubsection{DNS}
(A-Records bilden URL auf IP ab)\\
DNS: DNS Query "A random.org"/ DNS Response "A random.org 123.45.67.890"\\
UDP/TCP: SrcPort \& DstPort\\
IP: SrcIP \& DstIP\\
MAC: SrcAddr \& DestAddr
\section{Ports}
\begin{tabular}{l| l}
UDP DHCP & 67/68 \\
FTP & 21 \\
SSH & 22 \\
Telnet & 23 \\
SMTP & 25 \\
DNS & 53 \\
IMAP & 143 \\
IMAP TLS/SSL & 993 \\
Non-privileg & >1023 \\
\end{tabular}
\newpage
\section{Begriffe}
\begin{description}
\item[Simplex] nur ein Nutzer kann immer senden
\item[Half Duplex] beide Nutzer senden abwechselnd (Time Division Duplex)
\item[Full Duplex] beide Nutzer senden gleichzeitig (Frequency/Time Division Duplex)
\item[Circuit Switching] einfach; einmal aufgesetzt verbleiben die Ressourcen beim Nutzer; Circuit muss hergestellt werden, bevor kommuniziert werden kann
\item[Packet Switching] Aufteilen von Daten in kleinere Pakete die nach und nach gesendet werden; Problem: Informationen zu Sender/Empfänger und Start/Endzeitpunkt eines Pakets müssen mit übermittelt werden; Wird deshalb 'Store and Forward' Netzwerk genannt
\item[Broadcast Medium] Nur ein Sender zu jeder Zeit; Zugriffskontrolle (MUX o. Absprache)
\item[Baudrate] beschreibt die Anzahl der Symbole welche innerhalb einer Zeiteinheit übertragen werden; Symbolrate * Informationsgehalt je Symbol
\item[Protokoll] Protokolle sind Regelsätze, welche beschreiben wie zwei oder mehr entfernte Teile (peers oder protocol entities) eines Layers kooperieren, um den Dienst des gegebenen Layers zu implementieren. Ein Protokoll ist die Implementierung eines Services
\item[Signale] sind die physische Repräsentation von Daten in der Form einer charakteristischen Variation in Zeit oder Ausbreitung…
\item[Delay d] = distance / speed v
\item[Strict Layering] Jedes Layer verwendet nur den Service des darunter liegenden Layers
\item[Hammingdistanz] Anzahl an Stellen an denen sich zwei Frames x und y in binärer Darstellung unterscheiden lösbar mittels (x XOR y).
\item[Fehlerkontrolle vorwärts] Sender sendet redundante Infos so, dass der Empfänger selbst ausbessern kann
\item[Fehlerkontrolle rückwärts] Sender sendet redundante Infos so, dass der Empfänger fehlerhafte Pakete wahrscheinlich erkennt und Pakete in dem Fall nochmal verschickt werden können
\item[Burst Traffic]
\item[Broadcastkanal] Völllig dezentralisiert und so einfach wie möglich mit Rate b/s
\item[Statisches Multiplexing] einzelne Ressource statisch gemultiplext durch feste Sendezeiten und mehrere Frequenzbänder
\item[Polling] Masterknoten läd Slaveknoten zum Übertragen in Reihenfolge ein
\item[Tokenweitergabe] Kontrolltoken wird von einem zum anderen Knoten übertragen
\item[Hub] Eingehende Bits werden an alle Ausgänge mit selber Rate und ohne Puffern verteilt; Kein CSMA-CD am Hub; Alle verbundenen Kabel formen eine Kollisionsdomäne
\item[Switch] nicht nur eine einfache elektrische Verbindung für sternförmige Topologie; Switches enthalten Puffer, welche direkt ankommende Pakete zwischenspeichern, bevor sie diese weiterleiten
\item[Repeater] Physical Layer Gerät, verbindet zwei Kabel und verstärkt die ankommenden Signale und leitet dieses weiter; Versteht den Inhalt der Pakete nicht und interessiert sich nicht dafür
\item[Bridge] Jedes mit einer Bridge verbundene Netzwerk ist eine eigene Kollisionsdomäne und auch verschiedene LAN-Typen können miteinander verbunden werden
\item[Effizienz] Definiert als die Rate der Zeit, in welcher der Sender neue Informationen sendet (für den fehlerfreien Kanal)
\item[Bustoplogie] Alle Geräte sind an einem Kabel angebunden und sind in einer Kollisionsdomäne
\item[Sterntopologie] einfachere automatische Verwaltung und Wartung bei fehlerhaften Adaptern
\item[Spannbaum] Gegeben sei ein Graph G=(V,E), ein Spannbaum T = (V,E-T) ist ein Subgrap von V, wobei E-T ein Teil von E ist, welcher ein Spannbaum, der verbunden und azyklisch ist.
\item[Weiterleiten] Bewege Pakete vom Routereingang auf den entsprechenden Ausgang
\item[Routing] Berechnen der Route, die die Pakete von Quelle bis zum Ziel gegangen sind
\item[DHCP] Dynamic Host Configuration Protocol. beziehe die Adresse dynamisch von einem Server
\item[ARP] Adress Resolution Protocol Broadcast auf das LAN, mit der Frage, welcher Node IP X.X.X.X hat -> Antwort des Nodes mit der MAC-Adresse -> Zustellung möglich
\item[Hot Potato Routing] Wenn ein Paket ankommt, so leite es auf schnellste Art und Weise an den Ausgang mit der kleinsten Ausgangswarteschlange, ganz egal wohin dieser Ausgang dann führt
\item[Rückwärtslernen (Routing)] Paketheader enthalten wichtige Infos, wie Quelle, Ziel, Hopzähler -> Netzwerkknoten lernen etwas über die Netzwerktopologie während sie Pakete behandeln
\item[RIP] Routing Information Protocol. Distanzvektoralgorithmus mit Hops als Metrik. Falls nach 180s kein Advertisement empfangen wurde, so deklariere den Nachbarn als tot
\item[BGP] Border Gateway Protocol. Routerpaare tauschen Routinginformationen über semipermanente TCP Verbindungen aus
\item[OSPF] Open Shortes Paths First. annocieren nun keine Wege sondern Linkzustände mit je einem Eintrag pro Nachbarknoten
\item[Poisoned Reverse] Wenn Z durch Y routet um zu X zu gelangen: Z sagt Y, dass seine eigene Distanz zu X unendlich ist (somit routet Y nicht über X nach Z)
\item[Link State Routing] Berechnung des kleinsten Kostenpfades von einem Knoten S zu allen andern Knoten V erzielt durch den Link-State-Broadcast
\item[Gateway Router] Spezielle Router innerhalb des AS, führen das Intra-AS Routingprotokoll mit allen anderen Routern im AS aus. Zusätzlich verantwortlich für das Routing an exteren Ziele -> Inter-AS Routingprotokolle mit anderen Gatewayroutern
\item[Unicast] Ein Sender, ein Empfänger
\item[Multicast] Ein Sender, eine Gruppe von Empfänger
\item[Broadcast] Ein Sender, alle Teilnehmer eines Netzes
\item[UDP] Unzuverlässige, ungeordente Zustellung, Einfache Erweiterung des best Effort IP Ansatzes
\item[RTT] Round Trip Time: Benötigte Zeit um ein kleines Paket so zu senden, dass es vom Client zum Server und zurück geschickt wird.
\item[CSMA] Carrier Sense Multiple Access
\item[CSMA/CD] + Collision Detection
\item[CSMA/CA] + Collision Avoidance
\item[HTTP] Hyper Text Transfer Protocol; Das Anwendungsnachrichtenprotokoll des Webs
\item[Nichtpersistentes HTTP] höchstens ein Objekt wird über die TCP Verbindung verschickt
\item[Persistentes HTTP ] Mehrere Objekte können über eine TCP Verbindung zwischen Client und Server ausgetauscht werden
\item[Server] ständig eingeschaltet und mit permanenter IP-Adresse; Serverfarmen zur Skalierung
\item[Client] Kommunizieren zeitweise mit Server; Können dynamische IP-Adressen haben; Kommunizieren nie direkt miteinander
\item[Peer to Peer] Ohne ständig eingeschalteten Server. Beliebige Endsysteme kommunizieren direkt miteinander, sind dabei zeitweise verbunden und haben wechselnde IP Adressen.
\item[POST Methode] Webseiten beinhalten oft Formulareingaben, die Eingabe wird dann im Entity Body an den Server geschickt
\item[URL Methode] Verwendet die GET Methode; Die Eingaben werden im URL Feld der Requestline hochgeladen
\item[FTP] File-Transfer-Protokoll: Dateitransferprotokoll, Übertrage Daten von und zum Server
\item[Mail Useragent] Erlaubt das Schreiben, Lesen und Bearbeiten von Nachrichten; Ein- und ausgehende Nachrichten werden auf einem Server gespeichert
\item[Mailserver] Die Mailbox beinhaltet eingehende Nachrichten, die Nachrichtenschlange die ausgehenden Nachrichten
\item[SMTP] Mailübertragungsprotokoll: Verwendet TCP um Nachrichten zuverlässig vom Client zum Server zu übertragen, verwendet Port 25; Direkte Übertragung vom Sender zum Empfänger
\item[IMAP] Internet Message Access Control
\item[MIME] Multimedia Mail Extensions: Zusätzliche Zeilen im Nachrichtenheader deklarieren den MIME Inhaltstyp
\item[TLP Server] Top Level Domain Server: Verantwortlich für .com, .org, .net, .edu und die Landesdomains
\item[Authorative DNS Server] DNS Server einer Organisation, stellen den authorativen Hostnamen für das IP Mapping der Organisationsserver
\item[Lokal DNS Server] Jeder ISP hat einen eigenen; Wenn ein Host eine DNS Anfrage stellt, so wird die Frage zuerst zum lokalen DNS Server gesendet (fungiert also als ein Proxy)
\item[Ressource Records (RR)] in DNS Datenbank; Format: (name, value, type, ttl)
\item[P2P Filesharing] Ein Peer ist sowohl ein Webclient als auch ein transienter Webserver; Alle Peers sind Server -> Hoch Skalierbar; Dateiübertragung ist dezentralisiert, die Lokalisierung findet allerdings zentral statt.
\item[Socket] Ein lokal auf dem Host laufendes, von einer Anwendung erstelltes, OS-kontrolliertes Interface, durch welches ein Anwendungsprozess sowohl Nachrichten vom und zu anderen Anwendungsprozessen Senden, als auch Empfangen kann.
\item[Bedrohnung] Eine Bedrohung in einem Kommunikationsnetzwerk ist jedes mögliche Ereignis oder eine Sequenz von Aktionen, welche zu einer Verletzung einer oder mehrerer Sicherheitsziele führen
\item[Kryptologie] Wissenschaft, die sich mit Kommunikation in sicherer und geheimer Art befasst
\item[Kryptographie] (graphein = schreiben): Die Lehre der Prinzipien und Techniken, durch welche Informationen in Ciphertext verpackt und später durch legitimierte Nutzer, wieder durch einen geheimen Schlüssel entschlüsselt werden können
\item[Kryptoanalyse] (analyein = etwas lösen): Die Wissenschaft und Kunst Informationen von Ciphern wiederherzustellen und dies ohne das Wissen über den Schlüssel zu schaffen
\item[Cipher] Methode eine Nachricht so zu transformieren, dass die Bedeutung nicht mehr erkannt werden kann
\item[Verschlüsseln von Daten] Transformiert Plaintext in Ciphertext um die Inhalte zu verschleiern
\item[Signieren von Daten] Berechnet einen Checkwert oder eine digitale Signatur zu einem gegebenen Plaintext oder Ciphertext, sodass dieser durch alle oder einige Instanzen mit Zugriff verifiziert werden kann
\item[Symmetrische Kryptographie] verwendet einen Schlüssel für Ver- und Entschlüsselung oder Signieren und Überprüfen
\item[Assymmetrische Kryptographie] verwendet zwei Schlüssel für Ver- und Entschlüsselung
\item[IPSec Authentication Header (AH)] Im Tunnelmodus stellt der Payload nochmals ein ganzes IP Paket dar; Wichtig: AH funktioniert nur in NAT freien Umgebungen
\item[IPSec Encapsulating Security Protocol (ESP)] Dem ESP Header folgt direkt ein IP Header oder ein AH-Header; Das next-header Feld vom vorhergehenden Header indiziert 50 für ESP
\item[Firewall] Eine oder eine Menge an Komponenten, welche den Zugriff zwischen einem geschützten Netzwerk und dem Internet oder zwischen einer Menge an Netzwerken beschränkt
\item[Paketfiltern/Screening] Die Aktion, welche ein Gerät ausführt, um selektiv den Fluss an Daten in und aus einem Netzwerk zu kontrollieren. Paketfiltern ist eine wichtige Technik um Zugriffskontrolle auf dem Subnetzwerklevel für paketorientierte Netzwerke zu implementieren
\item[Bastion Host] Ein Computer, welcher besonders gesichert werden muss, da er anfälliger für Angriffe ist, als andere Computer im Subnetz
\item[Dual Homed Host] Ein Computer mit > 2 Netzwerkinterfaces
\item[Proxy] ein Programm, welches sich im Auftrag interner Clients mit externen Servern beschäftigt. Proxies leiten genehmigte Clientanfragen an die Server, und die Antworten auch wieder an den Client weiter
\item[Network Address Translation (NAT)] eine Prozedur, durch welche ein Router die Daten in Paketen ändert um die Netzwerkadressen zu modifizieren; Dies erlaubt es die interne Netzwerkstruktur zu verschleiern
\item[Perimeternetzwerk] Ein Subnetz, welches zwischen einem externen und einem internen Netzwerk hinzugefügt wird, um eine weitere Sicherheitseben bereitzustellen; Ein Synonym hierfür ist DMZ (De Militarized Zone)
\item[QPSK] Quadrature Phase Shift Keying; Phasenverschiebung für Multiplexing
\item[Medium Access Control (MAC)] Verteilter Algorithmus, der bestimmt, wie Knoten auf ein geteiltes Medium zugreifen
Round Trip Time $EstimatedRTT =(1-a)* EstimatedRTT + a * SampleRTT$
~ TCP Durchsatz $0,75*\frac{W}{RTT}$
\end{multicols}
\newpage
\section{ISO/OSI - sehr nützliches Modell, keine existierenden Protokolle}
Jedes Layer nimmt Daten vom darüberliegenden Layer, fügt eine Headereinheit hinzu und erstellt eine neue Dateneinheit und schickt diese an das Layer darunter
\begin{tabular}{l | l | l}
PH & Physisches Layer &
Bietet eine bittransparente Schnittstelle zum physischen Medium\\
&&Spezifiziert mechanische, elektrische, funktionale und prozedurale Mittel um die physische Verbindung zwischen zwei offenen Systemen zu unterstützen.\\
&&In-sequence Zustellung der Bits ist sichergestellt\\
&&Fehlererkennung ist manchmal inkludiert\\
&& Zeitliche Synchronisation (Non-Return to Zero Level oder Manchstercodierung)\\
&& Breitband- vs Basisbandübertragung (Amplituden-/Phasen-/Frequenzmodulation ) Bsp: QPSK, 16-QAM \\
&& Digital vs Analog \\
\hline
L & Link Layer &
Unterstützt Übertragung von service data units (SDU) größer als "word" unter Systemen, welche über einen einzigen physischen Pfad verbunden sind.\\
&&Essentielle Funktion ist block synchronization\\
&&Im Fall von Halb-duplex oder multipoint links muss der Zugriff auf das Medium kontrolliert werden und Peersysteme müssen addressiert werden.\\
&& Framing durch Charakterzählen, Flagbitmuster/Bitstuffing oder Codeverletzung \\
