LE 5 Transportschicht Flashcards
Port:
→ Durch die Transportschicht können Anwendungen auf Endgeräten unterschieden werden, wozu eine zusätzliche Art der Adressierung notwendig ist
→ Pakete müsse unterschieden werden zu welcher Anwendung sie gehören
→ Mithilfe von Portnummern
Was versteht man unter einem „Well-known Port“? Was sind typische Beispiele? Gelten diese Festlegungen für Client- und/oder Server-Seite?
→ Die Portnummern 1 bis 1023 werden zentral von der IANA vergeben und können auf den meisten Systemen nur von Systemprozessen oder privilegierten Benutzern verwendet werden
→ für die Serverseite benutzt
Welche Protokolle werden auf der Transportschicht verwendet?
User Datagram Protocol (UDP, RFC 768 , August 1980) und
Transmission Control Protocol (TCP, RFC 793 , September 1981
Dabei implementiert TCP alle geforderten Eigenschaften der Transportschicht und ist
ziemlich komplex. UDP dagegen ein einfaches Protokoll und ebenso unzuverlässig wie
IP.
Was sind die wesentlichen Eigenschaften von UDP
→ UDP:
- User Datagram Protocol
- einfaches Protokoll
- auf der Datagrammvermittlung basiert, Dateneinheiten von UDP werden Datagramme genannt
- kennt keine Fluss- oder Staukontrolle
- unfair
- beachtet auch nicht, welche MTU-Größenbegrenzung auf der Sicherheitsschicht gilt, ggf. Fragmentierung notwendig (ineffizient)
- nicht verbindungsorientiert, ein Server kann mit mehr Clients gleichzeitig über UDP in Kontakt stehen als mit TCP
- simplex
Was sind die wesentlichen Eigenschaften von TCP?
→ TCP:
- Transmission-Controll-Protocol
- dient der zuverlässigen Datenübertragung zwischen zwei Endgeräten
- es wird sichergestellt, dass keine Daten verloren gehen und alle Bitfehler korrigiert werden u. Daten in der richtigen Reihenfolge an die Anwendung geliefert werden
- Dateneinheiten werden bei TCP als Segmente bezeichnet
- implementiert eine Flusskontrolle, damit der Empfänger nicht zu viele Daten zugesendet bekommt, die er nicht mehr aufnehmen kann
- ein Algorithmus zur Staukontrolle wird verwendet, der Geräte im Netz wie Router und Switches vor Überlastung schützen soll
- verbindungsorientiertes Protokoll
- am Anfang einer TCP-Verbindung Verbindungsaufbauphase (Three-Way-Handshake)
- am Ende eine Verbindungsabbauphase (Four-Way-Close)
Wie funktioniert der Aufbau und Abbau von TCP-Verbindungen?
→ Aufbau „Three-Way Handshake“:
1. SYN: Der Client sendet ein SYN-Segment (SYN-Bit im Header gesetzt) mit einer Initial Sequence Number (Client ISN).
2. SYN-ACK: Der Server antwortet mit einem SYN-Segment mit einer Server ISN. Das Segment der ersten Seite wird positiv bestätigt, so dass auch das ACK-Bit gesetzt ist. Die Nummer im Bestätigungsfeld ist die Client ISN + 1.
3. ACK: Der Client bestätigt das Segment des Servers, so dass wiederum das ACK-Bit gesetzt ist. Die Bestätigungsnummer ist Server ISN + 1. Im letzten Segment ist das SYN-Bit nicht mehr gesetzt.
- Verbindung ist aufgebaut
- duplex Kommunikation möglich
→ Abbau „Four-Way-Close“:
- Da TCP duplex arbeitet, können beide Übertragungskanäle unabhängig voneinander abgebaut werden
1. Eine Seite sendet FIN und zeigt, dass diese Seite keine Daten mehr senden wikk
2. Andere Seite bestätigt den Empfang mit einem ACK-Segment und kann weiterhin Daten senden
3. Wenn alle Daten übertragen, wird ebenfalls ein FIN gesendeten
4. Wird mit ACK bestätigt
- Verbindung ist abgebaut
Wie wird die Wartezeit vor der Übertragungswiederholung von TCP-Segmenten bestimmt?
→ Beim Verbindungsabbau geht die Seite, die das letzte ACK gesendet hat, in den TIME-WAIT-Zustand, bevor die Verbindung vollständig abgebaut werden kann.
→ Wenn das letzte ACK verloren geht, wird das letzte FIN-Segment wiederholt.
→ die Seite, die das letzte ACK gesendet hat, wartet solange, wie ein wiederholtes FIN-Segment ankommen kann
→ solange, wie ein Segment im Netz unterwegs sein kann
→ maximale Segment Laufzeit (Maximum Segment Lifetime, MSL)
→ das letzte ACK-Segment wie auch ein wiederholtes FIN-Segment haben eine max. Laufzeit von MSL, daher wird die Wartezeit auf 2xMSL gesetzt
Was versteht man unter „Duplicate Acknowledgements“?
→ ein Segment kommt an, dessen Sequenznummer aber nicht dem erwarteten Wert entspricht, sondern zu hoch ist
→ die vorherige Bestätigung wird sofort wiederholt (Fast Retransmit)
→ Diese Bestätigung bezieht auf den Punkt, bis zu dem alle Segmente richtig angekommen waren
Wie funktioniert „Fast Retransmit“?
→ Es wird mehrfach in den Bestätigungen auf eine Sequenznummer verwiesen, die als nächstes erwartet wird
→ Wenn 3 doppelte ACKs (also 4 gleiche ACKs) nacheinander empfangen werden, wird vom Verlust des Segmentes ausgegangen
→ das verlorene Segment wird noch einmal gesendet, ohne auf den Retransmission Timeout (Wartezeit auf Bestätigung für ein erneutes Senden) zu warten
→ Mit diesem Algorithmus können Fehler in der Übertragung also schneller ausgeglichen werden.
Wie ist die Flusskontrolle TCP implementiert?
→ Flusskontrolle:
- Fenstertechnik (Sliding Window)
- im typischen Fall werden einige TCP-Segmente kurz nacheinander losgeschickt, die dann im günstigen Fall nur mit einem Acknowledgement bestätigt werden
- Empfänger hat einen Empfangspuffer, in dem er aus dem Netz erhaltene Daten zwischenspeichert, die von einer Anwendung abgeholt werden (Receive Buffer)
- freier Platz im Buffer wird Receive Window genannt
- Puffer komplett gefüllt (Receive Window = 0) → Empfänger kommt mit Verarbeitung nicht hinterher, Sender muss warten
- Problem, wenn wenig freier Speicher direkt wieder voll gemacht wird „Silly Window Syndrom” (SWS), viele kleine Pakete werden gesendet
Wie ist die Staukontrolle TCP implementiert?
→ Staukontrolle:
- Maximum Segment Size (MSS) wird bei Verbindungsaufbau ausgehandelt, festgelegt, wie viele Daten mit einem TCP-Segment übertragen werden sollen
→ Man wählt die MSS als MTU minus der Größen von IP Header und TCP Header um Framentierung zu vermeiden (TCP- Segmente werden in IP-Paketen übertragen)
- Additive Increase bedeutet, dass ein Endsystem die Datenrate linear erhöht
→ Solange es keine Verluste gibt (alle Bestätigungen ankommen), wird die Datenrate immer wieder um einmal die MSS erhöht.
- Multiplicative Decrease reagiert auf ein Ausbleiben von Bestätigungen
→ deutlichen Verminderung (Halbierung) der Datenrate zur Entlastung der Zwischensysteme
→ anschl. wieder linear erhöhen
- AIMD führt nicht zu einer konstanten Datenrate, eher ständiges Ausprobieren
- Anzahl der Bytes, die aktuell mit direkt aufeinander folgenden Segmenten übertragen werden darf heißt Staukontrollfenster (Congestion Window)
→ Receive Window und Congestion Window begrenzen die Datenrate des Senders
- lineares Erhöhen kann lange dauernden
→ Slow Start: die Datenrate zu Beginn einer Verbindung exponentiell zu erhöhen, bis ein vorh
Warum ist es bei TCP-basierten Übertragungen besonders schwierig, bei Netzen mit großer Ausdehnung und potentiell großen Bitraten diese Bitraten tatsächlich zu erreichen?
→ Bei einer großen Verzögerung ist es problematisch, dass man erst nach der RTT erfährt, ob die Daten richtig ankamen, und erst danach eine Entscheidung über eine Erhöhung oder Senkung der Datenrate treffen kann
→ nicht schnell möglich sich an ändernde Bedingungen im Netz anzupassen
→ längere Zeiten vergehen ohne optimale Nutzung der Leitung (z.B. durch Paketverlust und Senken der Datenrate)
→ auf der Sender- und der Empfängerseite werden große Puffer benötigt, da sich bei solchen Netzen viele Daten auf der Leitung befinden
→ geringe Größen von Empfangspuffern bremsen die Datenrate aus, da der Sender nicht mehr Daten losschicken darf, als freier Platz im Puffer ist
Wie sind die Wechselwirkungen, wenn TCP- und UDP-Datenströme parallel im Netz vorkommen?
→ UDP kennt keine Staukontrolle, Bitraten werden bei UDP Strömen eingestellt und mit denen werden Daten ins Netz übertragen, ohne beachten von möglichen Datenverlusten
→ UDP kann TCP dadurch vollständig verdrängen, da TCP sich den Gegebenheiten anpasst
→ Fairness
→ Fairness bedeutet, dass TCP-Verbindungen etwa gleiche Datenraten erhalten
Was versteht man unter Sockets?
→ Anwendungsprogramme greifen über die Socket API (Application Programming Interface) auf die Protokolle der Transportschicht (TCP und UDP) zu
→ Betriebssystem gibt dem Socket Ressourcen zur Verfügung (z.B. die Sende- und Empfangsbuffer)
→ Ein Socket beschreibt einen Verbindungsendpunkt im Anwenderprogramm
→ Es gibt im Internet drei verschiedene Typen von Sockets:
1. Verbindungslose Sockets (Datagramm Sockets). Hier wird UDP benutzt.
2. Verbindungsorientierte Sockets (Stream Sockets). Hier wird TCP benutzt.
3. Rohe Sockets, die kein Transportschichtprotokoll benutzen, sondern direkt Protokolle der Vermittlungsschicht, wie IP oder ICMP
Welche Eigenschaften hat das Protocol QUIC?
→ basiert auf UDP
→ integriert neben den Funktionen eines Transportschichtprotokolls auch die Aufgaben von SSL/TLS, um als Basis von HTTP verwendet zu werden
→ Sicherheit wie bei der TLS-Version 1.3 (Transport Layer Security) sichergestellt, möglichst viele Bereiche verschlüsselt übertragen
→ Verbindung wird mit dem ClientHello und dem ServerHello aufgebaut (Verknüpfung der Handshakes von TCP und TLS 1.3 und so können nach der RTT bereits Nutzdaten verschlüsselt übertragen werden
→ Verbindungen können ohne Verzögerung fortgesetzt werden (0-RTT Connection Resumption)
→ Staukontrollverfahren flexibel festgelegt durch Pluggable Congestion Control
→ QUIC-Pakete werden fortlaufend durchnummeriert, auch wenn Pakete neu übertragen werden müssen
→ Vorteilhaft für Berechnung des Retransmission Timeouts (RTO)
→ Bessere Rückmeldungsmöglichkeiten bei Paketverlusten
→ Verfahren zur Vorwärtsfehlerkorrektur kann genutzt werden
→ Paketverluste zu kompensieren und Neuübertragungen zu vermeiden