03 Tcpip

Webbasierte Anwendungen
Internet Protocol Suite (TCP/IP)

Univ.-Prof. Dr.-Ing. habil. Gero Mühl
Architektur von Anwendungssystemen (AVA)

Fakultät für Informatik und Elektrotechnik (IEF)
Universität Rostock
Überblick
> TCP/IP-Referenzmodell
> Schichtenmodelle
> TCP/IP-Modell
> Internetschicht
> Internet Protocol (IP)
> Transportschicht
> Transmission Control Protocol (TCP)
> Datenfluss- und Überlastkontrolle
> Dienstgüte
> Leaky Bucket und Token Bucket
> Integrated Services und Differentiated Services
G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 2

TCP/IP-Referenzmodell

Schichtenmodelle
> In hierarchischen Architekturen gibt es Schichten
mit verschiedenen Funktionen
> Jede Schicht

> realisiert eine bestimmte Funktionalität
> bietet der jeweils nächst höheren Schicht ihre Dienste
mittels einer festgelegte Schnittstelle an
> nutzt Dienste der jeweils nächst niedrigeren Schicht
zur eigenen Funktionserbringung
> abstrahiert von Details der Implementierung
> Ziele
> Geringere Komplexität
> Austauschbarkeit der Implementierungen
der einzelnen Schichten

Protokoll
> Ein Protokoll der Schicht n legt fest, wie Schicht n der Maschine A
mit Schicht n der Maschine B kommuniziert
> Eine Protokollhierarchie (engl. Protocol Stack)
besteht aus mehreren übereinander angeordneten Schichten
> Hierbei baut Schicht n mit n > 1 auf dem Dienst auf, den Schicht
n – 1 erbringt, ohne deren Implementierungsdetails zu kennen
> Beim Senden leitet jede Schicht die Daten an die darunterliegende
Schicht weiter, bis die unterste Schicht erreicht ist
> In jeder Schicht können die Daten transformiert (z.B. aufgeteilt) und
zusätzliche Informationen (z.B. Header, Trailer) hinzugefügt werden
> Der Empfang erfolgt entsprechend umgekehrt

Protokollhierarchien
Schicht 3 Schicht 3
Schicht 3-Protokoll
Schicht 2/3- Schicht 2/3-

Schnittstelle Schnittstelle
Schicht 2 Schicht 2
Schicht 2-Protokoll
Schicht 1/2- Schicht 1/2-
Schnittstelle Schnittstelle
Schicht 1 Schicht 1
Schicht 1-Protokoll
Physikalisches Medium

Protokollhierarchien PhilosophIn/ÜbersetzerIn/
SekretärIn-Architektur
I like Nachricht Philosoph J‘aime

rabbits. les lapins.
Deutsch Information Übersetzerin Deutsch

Ich mag für entfernte Ich mag
Kaninchen. Übersetzerin Kaninchen.
Fax # ----- Information Sekretär Fax # -----

Deutsch für entfernten Deutsch
Ich mag Sekretär Ich mag
Kaninchen. Kaninchen.

Informationsfluss
M M
M: Gesamte Nachricht
Mi: Teilnachricht i
Hi: Header der Schicht i
H3 M H3 M
H2 H3 M1 H2 M2 H2 H3 M1 H2 M2
H1 H2 H3 M1 H1 H2 M2 H1 H2 H3 M1 H1 H2 M2
1. 2. 1. 2.

Leitungsvermittelt vs. Paketvermittelt
> Leitungsvermittelt
> Bevor zwei Rechner Nutzdaten austauschen, wird ein
Weg festgelegt, über den alle Daten vom Sender
zum Empfänger und vice versa übertragen werden
> Oft wird Bandbreite für die Übertragung reserviert
> Analog zur ursprünglichen Realisierung des Telefonnetzes
> Paketvermittelt
> Jedes Paket reist unabhängig von anderen Paketen vom Sender
zum Empfänger und nimmt potentiell einen anderen Weg
> Einfachere Realisierung, aber Pakete können in einer anderen
Reihenfolge ankommen, als sie gesendet wurden

Verbindungslos vs. Verbindungsorientiert
> Verbindungslos
> Direkter Austausch von Nutzdaten ohne
vorherige Abstimmung
> Unidirektionale Kommunikation möglich
> Verbindungsorientiert
> Vor dem Austausch von Nutzdaten Verbindungsaubau
zwischen den Kommunikationspartnern
> Setzt bidirektionale Kommunikation voraus
> Voraussetzung für zuverlässige Ende-zu-Ende-Kommunikation
und Ende-zu-Ende-Flusssteuerung
> Zwei häufige Variationen zuverlässiger Ende-zu-Ende-
Kommunikation: Nachrichtenfolgen und Byteströme

Kombinationsmöglichkeiten
Leitungsvermittelt Paketvermittelt
Verbindungslos Rohrpost UDP/IP
Verbindungsorientiert Analoges Telefon TCP/IP

> Verarbeitung
> Stellt Anwendungsprotokolle bereit (z.B. HTTP, FTP oder SMTP)
> Transport
> Kommunikation zwischen Anwendungen
> TCP: verbindungsorientierte, zuverlässige, Verarbeitung
Kommunikation auf Basis von Byteströmen
> UDP: unzuverlässige, verbindungslose Transport
Kommunikation auf Basis von Datenpaketen
Internet
> Internet
> Ende-zu-Ende Senden und Empfangen
Host-an-Netz
einzelner Pakete zwischen Rechnern
> Host-an-Netz
> Senden, Weiterleiten und Empfangen von Paketen
zwischen direkt verbundenen Rechnern

Verarbeitung Verarbeitung
Transport Transport
Internet Internet Internet
Host-an-Netz Host-an-Netz Host-an-Netz
Gateway (Router)

HTTP, SMTP, DNS, IMAP

Verarbeitung
Protokolle TCP, UDP
Transport
IP
Internet
Netze LAN, ATM, FDDI, WLAN
Host-an-Netz
Quelle: Wikipedia
> Internet-Schicht/Internet-Protokoll (IP)

> Verbirgt verschiedenste Netzwerke und Netzwerktechnologien
> Bildet die Basis unterschiedlichster Dienste und Anwendungen
 Stundenglas-Architektur

TCP/IP – Kommunikationsbeispiel
Internet-Protokoll (IP)
> IP-Adresse identifiziert Rechner
IP-Adresse Transport-Protokoll (TCP, UDP)
192.168.0.3
> Port-Nummer identifiziert
Applikation Port
Dienst/Anwendung
Mail-Client 50123
Browser 52987
IP-Adresse
192.168.0.1
IP-Adresse
192.168.0.2
Port Dienst
Applikation Port 25 Mail
Browser 49654 80 WWW
Netz
Client Server

Fragen?

Internetschicht

Internet Protocol (IPv4)
> IP als kleinster gemeinsamer Nenner ermöglicht Austausch
von Datenpaketen zwischen beliebigen Rechnern
 unterste Schicht mit Ende-zu-Ende Bedeutung
> Einheitliches, internetweit gültiges Adressierungsschema
> Jeder Rechner (strenggenommen jede Netzwerkkarte)
erhält eindeutige Kennung  IP-Adresse
> Verbindungslose Weiterleitung von Datenpaketen

vom Quellrechner zum Zielrechner
> Best Effort-Kommunikation
> Pakete können verändert oder dupliziert werden,
verloren gehen, etc.

IP-Paket
Version IHL TOS Total Length

D MF
Identification F Fragment Offset
TTL Protocol Header Checksum
Header
Source Address
Destination Address
Options
Content
Data
32 Bit

Fragmentierung bei IP
> Jedes Paket trägt die Information (d.h. Quell- und Zieladresse),
um von der Quelle zum Ziel zu gelangen
> Pakete, die für das physikalische Netzwerk zu groß sind,
werden in kleinere Fragmente aufgeteilt
> Die Fragmente werden unterwegs nicht mehr zusammengesetzt,
sondern jedes Fragment reist als eigenständiges IP-Datagramm
Ethernet Punkt-zu-Punkt FDDI

1 ETH 1400 2 PPP 512 3 FDDI 512 4
PPP 512 FDDI 512
PPP 376 FDDI 376
x 0 0 x 1 0 x 1 512 x 0 1024
1400 512 512 376
More Framents-Flag Offset

IP-Subnetze
> Ermöglichen eine für die Außenwelt transparente Aufteilung
eines größeren Netzes in mehrere kleinere
> Interpretation eines Teils der Rechneradresse als Subnetz-Adresse
> Erkennung, ob Zieladresse in eigenem Subnetz liegt,
durch logische UND-Verknüpfung mit der Subnetzmaske
> Ist das Ergebnis gleich der eigenen Subnetznummer, dann direktes
Senden; sonst indirektes Senden über Router
> Beispiel
27 = 128 Subnetze
16 7 9
Netz Subnetz Rechner
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0
Subnetzmaske = 255.255.254.0
Alternative Notation: /23 29 - 2 = 510 Rechner

IP-Routing
> Wie gelangen IP-Pakete durch evtl. mehrere Netze zum Ziel?
> Routing-Tabellen
> Ordnen IP-Adressen die nächste zu wählende Teilstrecke zu
> Direktes Routing (im selben Netz)
> Indirektes Routing (über einen Router)
> Tabelle enthält IP-Adressen, keine physischen Adressen

> Routing-Entscheidungen unabhängig von physischen Adressen
> Verbirgt Details der Netze vor IP, klare Separation
> Isoliert Routing-Information in Routing-Tabellen
> IP-Routing ändert die Adressen von Quelle und Ziel nicht
> Paket wird „hopweise“ weitergereicht, bis es sein Ziel erreicht

IP-Routing-Protokolle
> Aktualisieren die Routing-Tabellen

> Intradomain- vs. Interdomain-Routing
> Beispiele für Intradomain-Routing-Protokolle

> Routing Information Protocol (RIP) [RFC 1058]
> Router tauschen periodisch Distanzvektoren aus
> Vektor beinhaltet, Entfernung zu anderen Netzen in „Hops“
> Open Shortest Path First (OSPF) [RFC 1247]
> Jeder Router kennt Netzwerk und berechnet kürzesten Pfad
> Beispiel für Interdomain Routing-Protokolle

> Border Gateway Protocol (BGP) [RFC 1654]

Fragen?

Transportschicht

Transmission Control Protocol (TCP)
> RFCs 793, 1122, 1323
> Bereitstellung eines zuverlässigen bidirektionalen Bytestroms

zwischen 2 Endpunkten in unzuverlässigem Netzverbund
> Endpunkt: IP-Adresse + TCP-Portnummer
(z.B. 139.30.1.211:80)
> Verbindungsorientierter Transportdienst

> Teilt Anwendungsdaten in Blöcke (Segments) à max. 64 KBytes
(meistens ca. 1500 Bytes), die als IP-Paket versandt werden
> Sliding Window Protocol
für Fehlerbehandlung und Flusskontrolle

Zuverlässiger Bytestrom
> Die Anwendungsdaten (Bytestrom) werden fehlerfrei

empfangen, ohne Datenverluste oder -duplikate, in der
Reihenfolge, in der sie gesendet wurden
> Dies wird durch das Versenden der Pakete mit

Checksummen und Sequenznummern erreicht
> Checksummen: Erkennen fehlerhafter Segmente
> Sequenznummern: Erkennen fehlerhafter / doppelter Segmente
sowie Anordnung der Segmente in der richtigen Reihenfolge
> Anwendung selbst sieht keine Paketgrenzen

> ein send kann zu mehreren receives führen und umgekehrt!
> z.B. send(170 Bytes) + send(230)  receive(400)

Aufbau eines TCP-Pakets
0 8 16 24 32
Source Port Destination Port
Sequence Number
20 Byte
Acknowledgement Number
Header HLen Flags Window Size
Checksum Urgent Pointer
Options
Body Data

Aufbau eines TCP-Pakets
> Source- und Destination Port

> Identifizieren die lokalen Endpunkte der Verbindung
> Sequence- and Acknowledgement Number

> Bytenummerierung und Empfangsbestätigung
> Window Size (Fenstergröße)

> Größe des Empfangsfensters beim Sliding Window Protocol
> Checksum (Prüfsumme)

> Gebildet über TCP-Header + Daten + IP-Pseudo-Header

TCP-Segmente
> Kommunikationspartner geben ihre

maximale Segmentgröße (MSS) bekannt
> Größere Segmente sind effizienter
> MSS ≤ MTU des Netz – IP-Header – TCP-Header

(20 Byte) (20 Byte)
> Z.B. Ethernet MTU = 1500 Byte  MSS = 1460 Byte
> Z.B. Berkeley UNIX Implementierung  MSS = 1024 Byte
> Voreinstellung MSS = 536 Byte  IP-Pakete mit 576 Byte

Sliding Window Protocol
gesendet und
Fenstergröße Sender bestätigt
gesendet aber
nicht bestätigt
kann gesendet
werden
kann noch nicht
send_base send_next gesendet werden
ausgeliefert an
Anwendung
Fenstergröße Empfänger
empfangen und
bestätigt
empfangen
erwartet
Kann noch nicht
rec_base empfangen werden

TCP-Retransmission Timer
> Problem: Wahl des Timeouts für

Wiederholungen bei fehlender Bestätigung?
Timeout
> Timeout zu kurz  unnötige Wiederholung
> Timeout zu lang  unnötige Verzögerung
von Wiederholungen
> Idee: Orientierung an der Round Trip Time
> Round Trip Time („Rundreisezeit“)

> Zeit für eine Nachricht vom Sender zum Empfänger und zurück
> Ändert sich u.U. dauernd und schnell
> Dynamische Algorithmen zur Anpassung des

Time-out-Intervalls (Jacobsen, 1988)

Jacobsen Algorithmus
> Round Trip Time (RTT) sowie Schwankungen der RTT

zur Wahl des Timeouts heranziehen
> Schätzung der Round Trip Time (RTT)
RTT = α1 · RTT + (1 – α1) · M
> Berechnung der durchschnittlichen Abweichung (D)

D = α2 · D + (1 – α2) · |RTT – M|
> Wahl des Timeouts

Timeout = RTT + 4·D
M: RTT des letzten bestätigten Segments

α1, α2: Glättungsfaktoren (typisch α1 = α2 = 7/8)

TCP-Überlastkontrolle
> Durch Überlast entsteht Paketverlust

> Zwei wesentliche Ursachen
1. Überlasteter Empfängerprozess (liest Daten zu langsam)
2. Überlastete Strecken bzw. Router
Sender
Überlauf nach
Netzüberlastung
Empfänger
TCP-Überlastkontrolle
> TCP führt Überlastkontrolle aus (engl.: Flow Control)
> Ziel: Überlast möglichst durch dynamische Anpassung der

Senderate vermeiden
> Verwendung eines Empfängerfensters beim Empfänger sowie
eines Überlastungsfenster beim Sender
> Aktuelle Größe des Sendefensters ergibt dann sich aus dem
Minimum der beiden Fenster
> Funktioniert auch dann, wenn viele TCP-Verbindungen

zwischen verschiedenen Rechnern aktiv sind, die sich
physikalische Verbindungen teilen

Empfängerfenster
> Entspricht der Anzahl an Bytes, die der Empfänger bereit ist,
maximal als nächstes zu akzeptieren
> Angabe der Größe des Empfängerfensters bei Bestätigungen
> 16 Bit Größe  max. 64KB
> Skalierungsfaktor im Header (für größere Fenster) möglich

Überlastungsfenster
> Slow-Start zur Adaption des Überlastungsfensters [Jacobsen, 1988]
> Ausgehend von Initialwert exponentielle Vergrößerung des
Überlastungsfensters bis zu Schwellwert, ab dort lineare Steigerung
> Bei Überlast Zurücksetzen des Schwellwerts auf das halbe aktuelle
Überlastungsfenster und des Überlastungsfensters auf den Initialwert
> Unterstützung durch alle TCP-Implementierungen
Schwelle
Größe des Über-

lastungsfenster
initial 1 KB ( = MSS)

TCP–Effizienz: Senderseite
> Tinygrams
> Eine Anwendung sendet ständig kleinste Datenmengen
(z.B. 1 Byte)  enormes Verkehrsaufkommen
> 1 Byte Daten + 20 Byte TCP Header + 20 Byte IP Header
= 41 Byte Übertragungslast für 1 Byte Nutzlast
> Zusätzlicher Aufwand durch z.B. darunter liegendes Ethernet
(14 Bytes Header + 4 Bytes Checksumme)
> Lösung: Nagle-Algorithmus

> Leistungsverbesserung durch Sammeln von Sendedaten
> Sollte bei interaktiven Anwendungen (z.B. SSH, X Windows)
allerdings deaktiviert werden

TCP–Effizienz: Empfängerseite
> Silly Window Syndrome

> Nur kleine Segmente werden geschickt, obwohl der Sendepuffer
genügend Daten für ein größeres Segment enthält
> Ursache
> Anwendung beim Empfänger liest Daten, z.B. byteweise
> Speicher im vollen Puffer wird byteweise frei
> Empfänger bietet zu kleines Empfängerfenster (hier 1 Byte) an,
anstatt zu warten, bis ein größeres Fenster möglich wäre
> Lösung: Clark-Algorithmus

> Empfänger aktualisiert das Fenster nur, wenn Erhöhung um
definierte Mindestmenge möglich ist

User Datagram Protocol (UDP)
> Verbindungsloser Transportdienst [RFC 768]

> Ermöglicht das Senden einzelner Pakete an einen Endpunkt
(IP-Adresse + UDP-Portnummer)
> Empfänger empfängt einzelne UDP-Pakete
> UDP-Pakete können verloren gehen und in beliebiger
Reihenfolge beim Empfänger eingehen
> Bietet größtmögliche Freiheit und Flexibilität bei weniger
Overhead als bei TCP
> Die Anwendung kümmert sich selbst, falls notwendig, um
Fehlerbehandlung und Flusssteuerung
> Unterstützt auch Multicast-Kommunikation
auf Basis von IP-Multicast

Aufbau eines UDP Pakets
0 8 16 24 32
UDP-Quellport UDP-Zielport
Header
Länge Prüfsumme
Daten Body
Quell- und Zielport wie bei TCP

Länge Länge des Datagramms in Bytes
(inkl. 8 Byte Header)
Prüfsumme Fehlerüberprüfung für Header, Daten und
wichtige IP-Informationen

Well-Known TCP/UDP-Ports
> Well-Known Ports (Portnummern < 1024) reserviert für

bestimmte Dienste
[http://www.iana.org/assignments/port-numbers]
> Achtung: TCP- und UDP-Portnummern sind
unabhängig voneinander!
FTP SSH Telnet SMTP HTTP DNS NFS SNMP
22 23 25 80 53 111
20 161
21 162
TCP UDP
IP

Literatur
1. V. Jacobson. Congestion Avoidance and Control. In Symposium
Proceedings on Communications Architectures and Protocols,
pages 314–329, Stanford, CA, USA, 1988. ACM.
2. W. R. Stevens. TCP/IP Illustrated, Volume 1: The Protocols.

Addison-Wesley, 1991.
3. G. R. Wright and W. R. Stevens. TCP/IP Illustrated, Volume 2: The

Implementation. Addison-Wesley, 1995.
4. J. Nagle. Congestion Control in IP/TCP Internetworks. RFC 896,

January 1974.
5. D. D. Clark. Window and Acknowledgement Strategy in TCP. RFC 813,
July 1982.

Fragen?

Dienstgüte

Neue Anwendungen und Anforderungen
> Neuere Anwendungen des Internets
> Audio
> Video
> Internet Telephony Dienst Bitrate
> Tele Learning
> Online Gaming Audio MP3 100-200 Kbit/s
MPEG Video 2 Mbit/s
> Game Streaming Standard Video 140 Mbit/s
> ... HDTV (1080i50/MPEG-2) 27 Mbit/s
> Neue Anforderungen

> Echtzeit
> Synchronisation
> Multicast („Fernsehen“ per Internet)
> Niedriger Ping
> ...

Dienstgüte
> Dienstgüte (engl.: Quality of Service (QoS))

> wird vom Empfänger bzw. Kunden festgestellt
> erfordert Ende-zu-Ende-Sicht
> betrifft alle Schichten
> Diensteigenschaften aus Benutzersicht

> Wiedergabequalität, Antwortzeit, Zuverlässigkeit,
Verschlüsselung, ...
> Anforderungen eines Dienstes an das Netzwerk

> Fehlerrate, Verzögerung, Schwankungsbreite (Jitter), Bandbreite
> Synchronisation (z.B. Lippen-Synchronisation bei
Videokonferenz)

Anforderungen an die QoS-Parameter
Anforderung Anforderung Anforderung Anforderung

Anwendung
an Fehlerrate an Verzögerung an Schwankung an Bandbreite
E-Mail Hoch Niedrig Niedrig Niedrig
Dateitransfer Hoch Niedrig Niedrig Mittel
Web–Zugriff Hoch Mittel Niedrig Mittel
Remote Login Hoch Mittel Niedrig Niedrig
Audio on demand Niedrig Niedrig Hoch Mittel
Video on demand Niedrig Niedrig Hoch Hoch
IP-Telefonie Niedrig Hoch Hoch Niedrig
Video-Konferenz Niedrig Hoch Hoch Hoch

Allgemeine QoS-Techniken
> Überdimensionierung
Senden
> Pufferung beim Empfänger
Ankunft
> Gleicht Schwankungen aus
> Üblich sind ca. 10 sec Pufferung
Wiedergabe
> Eingangssteuerung
(engl. Admission Control) Übertra- Pufferung
t
> Türsteher entscheidet, gungszeit
ob Datenstrom akzeptiert wird
> Verkehrsformung (engl. Traffic Shaping)

> Glätten des Datenstroms nach vorheriger Vereinbarung
> Reservierung von Ressourcen

Verkehrsformung (Traffic Shaping)
> Überlastsituationen werden vorrangig durch

Verkehrsspitzen verursacht
> Diese entstehen z.B., wenn Rechner mit
stark ungleichmäßiger Rate senden
> Ziel
> Beeinflussung der Rechner, so dass sie gleichmäßiger senden
und damit weniger Überlastsituationen auftreten
> Vorgehen
> Beim Sender werden Algorithmen ausgeführt, die den
Verkehr formen  Verkehrsformung

Leaky Bucket
> Maximale Senderate
wird begrenzt
> Zu sendende Pakete
kommen in den Eimer
> Pakete verlassen Eimer
mit konstanter Rate
und werden gesendet
> Eimer hat
beschränkte Kapazität
> Bei vollem Eimer
werden Pakete verworfen
> Implementierung des © Tanenbaum, Computer Networks
Eimers als Warteschlange

Token Bucket
> Durchschnittliche
Senderate wird begrenzt
> Token werden mit
konstanter Rate
in Eimer gelegt
> Bis zu n Token können
gesammelt werden
> Jede Nachricht nimmt
beim Senden ein Token
> Bursts mit bis zu n
Nachrichten gehen durch
> Es werden keine
Nachrichten verworfen,
sondern der Sender
© Tanenbaum, Computer Networks
wird blockiert

Verkehrsformung
> Ohne Verkehrsformung (a)
> 2 MB/sec Leaky Bucket (b)
> 2 MB/sec Token Bucket

> mit Kapazität von 250 KB (c)
> mit Kapazität von 500 KB (d)
> mit Kapazität von 750 KB (e)
> 2 MB/sec Token Bucket mit

500 KB Kapazität
und nachfolgend
10 MB/sec Leaky Bucket (f) © Tanenbaum, Computer Networks

QoS-Erweiterungen für das Internet
Integrated Services (IntServ)

> Annahme: Knappe Ressourcen
> Feingranulare Reservierung von Ressourcen per Flow
auf dem Pfad zwischen Sender und Empfänger  Garantien
> Umsetzung durch Resource reSerVation Protocol (RSVP)
> Nicht skalierbar und daher nur für Intranets geeignet
1. Path
Empfänger
2. Resv
Sender

QoS-Erweiterungen für das Internet
Differentiated Services (DiffServ)

> Annahme: Genügend Ressourcen
> Grobgranulare Verteilung der Ressourcen mittels
Verkehrsklassen  Flow-Aggregation
> Bevorzugt Pakete aufgrund ihrer Klassifikation
> Minimierung des Verwaltungsaufwands
> Keine Garantien
> Keine dynamische Anpassung
> Skalierbarkeit gegeben

Kombination von IntServ und DiffServ
Subnetz A Backbone Subnetz B
IntServ DiffServ IntServ
> Endsysteme > Weitverkehr

> Reservieren > Klassen zuteilen
> Garantien > Einfache und
schnelle Bearbeitung

Fragen?

Exemplarische Fragen zur Lernkontrolle
1. Was ist ein Protokoll?
2. Was ist eine Protokollhierarchie (engl.: protocol stack)?
3. Aus welchen zwei Hauptbestandteilen besteht ein Paket?
4. Welche Struktur hat ein Paket der Schicht n?
5. Erklären Sie den Unterschied zwischen verbindungsorientierter und
verbindungsloser Kommunikation!
6. Erläutern Sie den Unterschied zwischen leitungsvermittelter und
paketvermittelter Kommunikation!
7. Erläutern/skizzieren Sie das TCP/IP-Referenzmodell!
8. Nennen Sie Beispiele für Protokolle der einzelnen Schichten!
9. Welchen Dienst erbringt eine Schicht der nächst höheren Schicht?
10. Auf welcher Schicht arbeiten die Router bei TCP/IP?
11. Welches ist die unterste Schicht mit Ende-zu-Ende Bedeutung?
IP
1. Welche Funktionalität bietet IP?
2. Wie ist eine IPv4-Addresse aufgebaut?
3. Was sind Klasse A/B/C-Netze?
4. Was sind Subnetze und warum werden sie verwendet?
5. Erläutern Sie das Konzept der Netzmasken!
6. Wovon hängt die maximal mögliche Rechneranzahl in einem
Subnetz ab?
7. Wie viele Rechner unterstützt ein Subnetz mit der Maske
255.255.255.128?

TCP und UDP

1. Welchen Dienst bietet TCP bzw. UDP?
2. Unterstützt TCP Multicast-Kommunikation?
3. Was ist ein Port?
4. Erläutern Sie das Sliding Window Protocol!
5. Wozu dient der Algorithmus von Nagle?
6. Wie wird bei TCP vermieden, dass ein schneller Sender den
Empfänger überlastet? Zu welchen Problemen kann dieser
Mechanismus führen?
7. Warum sind zu kurze und zu lange Timeouts beim TCP
Retransmission Timer problematisch? Erläutern Sie den
diesbezüglichen Vorschlag von Jacobson!

Dienstgüte
1. Was versteht man unter Dienstgüte?
2. Nennen Sie Beispiele für Netzwerkeigenschaften, die die
Dienstgüte beeinflussen können!
3. Welche Garantien gibt das Internet?
4. Warum hat der Empfänger einen Puffer z.B. beim Abspielen
eines Films?
5. Was versteht man unter Verkehrsformung?
6. Erläutern sie die Funktion eines Leaky Buckets bzw.
eines Token Buckets?
7. Vergleichen Sie IntServ mit DiffServ! Auf welchen Annahmen
beruhen beiden Ansätze?

Vielen Dank für Ihre
Aufmerksamkeit!
Univ.-Prof. Dr.-Ing. Gero Mühl
gero.muehl@uni-rostock.de
https://www.ava.uni-rostock.de

03 Tcpip

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

03 Tcpip

Hochgeladen von

Copyright:

Verfügbare Formate

Webbasierte Anwendungen

Internet Protocol Suite (TCP/IP)

Architektur von Anwendungssystemen (AVA)

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 2

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 3

> Jede Schicht

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 4

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 5

Schicht 2/3- Schicht 2/3-

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 6

I like Nachricht Philosoph J‘aime

Deutsch Information Übersetzerin Deutsch

Fax # ----- Information Sekretär Fax # -----

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 7

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 8

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 9

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 10

Verbindungslos Rohrpost UDP/IP

Verbindungsorientiert Analoges Telefon TCP/IP

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 11

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 12

Internet Internet Internet

Host-an-Netz Host-an-Netz Host-an-Netz

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 13

HTTP, SMTP, DNS, IMAP

> Internet-Schicht/Internet-Protokoll (IP)

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 14

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 15

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 16

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 17

> Verbindungslose Weiterleitung von Datenpaketen

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 18

Version IHL TOS Total Length

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 19

Ethernet Punkt-zu-Punkt FDDI

1400 512 512 376

More Framents-Flag Offset

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 21

> Tabelle enthält IP-Adressen, keine physischen Adressen

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 22

> Aktualisieren die Routing-Tabellen

> Beispiele für Intradomain-Routing-Protokolle

> Beispiel für Interdomain Routing-Protokolle

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 23

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 24

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 25

> RFCs 793, 1122, 1323

> Bereitstellung eines zuverlässigen bidirektionalen Bytestroms

> Verbindungsorientierter Transportdienst

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 26

> Die Anwendungsdaten (Bytestrom) werden fehlerfrei

> Dies wird durch das Versenden der Pakete mit

> Anwendung selbst sieht keine Paketgrenzen

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 27

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 28

> Source- und Destination Port

> Sequence- and Acknowledgement Number

> Window Size (Fenstergröße)

> Checksum (Prüfsumme)

G. Mühl Webbasierte Anwendungen / Internet Protocol Suite 29

> Kommunikationspartner geben ihre

> MSS ≤ MTU des Netz – IP-Header – TCP-Header

> Z.B. Ethernet MTU = 1500 Byte  MSS = 1460 Byte