TCP und UDP
Holger Junker
Inhaltsverzeichnis
1. Grundlegendes zur Datenkommunikation
1.1 Kommunikation zwischen Rechnern
1.2 Adressierung
1.3 Ports
2. TCP
2.1 Grundlegende Eigenschaften
2.2 Stream-Datenpakete
2.3 Virtuelle Verbindung
2.4 Full-duplex-Datentransfer
2.5 Gepufferte Datenübertragung
2.6 Multiplexing
3. Verlässlichkeit
3.1 Acknowledgement
3.2 Timer, Neusendung
3.3 Das gleitende Fenster zur Flußsteuerung
4. TCP-Verbindung
4.1 Verbindungsaufbau
4.2 Verbindungsabbau
5. TCP Header
6. UDP
6.1 Grundlegende Eigenschaften
6.2 Datagramme
6.3 Verbindungslosigkeit
6.4 Verläslichkeit
7. UDP Header
8. Zusammenfassung
Literatur
Grundlage von Netzwerken ist die Kommunikation zwischen Rechnern, also
der Austausch von Daten. Um die Vorgänge bei der Datenkommunikation zu
verdeutlichen betrachtet man das sogenannte Schichtenmodell, wie es in
der unteren Grafik dargestellt ist. Dabei unterscheidet man zwischen
der Applikationsschicht, den beiden Protokollschichten TCP/UDP und IP
und der physikalischen Schicht (z.B. Ethernet, Point-To-Point-Line).
Da große Unterschiede in der Umsetzung der Schichten bestehen können
wird durch die Protokolle lediglich beschrieben, auf welche Art und
Weise der Datenaustausch von Statten geht. Netzwerkprotokolle sind
daher keine eigenständigen Programme, sondern vielmehr Bibliotheken
von Diensten, die von anderen Schichten in Anspruch genommen werden
können. Das Prinzip der Einteilung in Schichten ist sehr sinnvoll, da
sonst jede Applikation alle benötigten Dienste selbst implementieren
müsste. Die wichtigsten und bekanntesten Dienste der im folgenden
betrachteten TCP/UDP-Schicht sind FTP, Telnet, Mail oder Network File
Systems.
Abb. 1: Schichtenmodell der Rechnerkommunikation
Die Adressierung von Rechnern innerhalb des Internet erfolgt mittels
der sogenannten IP-Adresse. Diese besteht aus einer 32bit Zahl, die
getrennt in 4x8bit (sogenannten Oktets) als dreistellige,
vorzeichenlose Dezimalzahlen dargestellt wird. Durch diese Adresse
wird jeder Rechner innerhalb des Internet eindeutig identifiziert.
Bei heutigen Betriebssystemen handelt es sich meist um
Multitasking-Betriebssysteme. Es laufen also auf einem Rechner mehrere
Prozesse gleichzeitig, die auch gleichzeitig und separat angesprochen
werden sollen. Daher findet Datenkommunikation aber nicht zwischen
Rechnern, sondern genauer zwischen einzelnen Prozessen statt. Es ist
daher notwendig, nicht nur Rechner im Internet eindeutig zu
identifizieren sondern auch die einzelnen Prozesse auf diesen
Rechnern. Dieses erfolgt durch die sogenannte Portnummer. Dabei
handelt es sich um eine 16bit Zahl dargestellt als Integerzahl. Bei
den Portnummern unterscheidet man zwischen zwei Arten. Die global
festgelegten oder konventionellen Portnummern reichen von
0-49150. Jeder dieser Zahlen ist genau eine Higher-Level-Applikation
zugeordnet. Die dynamisch vergebenen Portnummern von 49151-65535
werden wie der Name sagt während der Laufzeit vergeben. Dies bietet
Vorteile wie z.B. Erweiterbarkeit. Durch die IP und den Port, die
gemeinsam den sogenannten Socket bilden, wird jeder Prozess auf einem
Rechner der dem Internet angeschlossen ist eindeutig
identifiziert. Eine schematische Darstellung der Ports mit einigen
Beispielen ist in der folgenden Grafik dargestellt.
Abb. 2: Spektrum der Port-Nummern und wichtige Ports
TCP bedeutet Transmission Control Protocol. Es wurde 1981 spezifiziert
in STD-7/RFC-793. Neuerungen, Erweiterungen und Bugfixes sind
festgehalten in den RFCs 1323 und 1122. Ziel bei der Spezifikation
dieses Transportprotokolls war es, auf Basis des unzuverlässigen
Internet-Protocol (IP) eine verlässliche Datenkommunikation zu
gewährleisten.
Die Datenübertragung erfolgt in einem sogenannten Stream. Dieser
besteht aus Sequenzen von 8bit, also einem Byte, auch Oktet
genannt. Die Größe des übertragenen Streams ist nicht garantiert. Es
besteht sowohl die Möglichkeit der Bündelung von Daten als auch die
der Aufteilung. Beliebige Paketgrößen sind bei der Übertragung nicht
möglich. So gibt es beispielsweise eine obere Schranke für die
Paketgröße, genannt Maximum Transmission Unit (MTU). Das theoretische
Maximum dieser MTU liegt bei 64 kByte. Ein üblicher Wert ist
allerdings 1,5 kByte. Auf Applikationsebene erscheint der TCP-Stream
wie eine flat-line. Es ist also auf dieser Ebene nicht möglich zu
rekonstruieren, wie die Daten übertragen wurden, also ob z.B. eine
Aufteilung stattgefunden hat.
Die Verbindung zwischen zwei Prozessen wird als virtuell bezeichnet,
weil sie wie eine feste, unmittelbare physikalische Verbindung
erscheint. In Wirklichkeit besteht aber gar keine direkte Verbindung
zwischen den beiden Prozessen. Zu Begin des Datenaustauschs ist es
notwendig, die Verbindung aufzubauen. Dazu müssen beide Rechner der
Verbindung zustimmen. Dies wird später noch ausführlich beschrieben
werden.
Beim TCP-Datentransfer findet das Senden und Empfangen der Daten in
der Form statt, als ob zwei separate Verbindungen verwendet würden. In
Wirklichkeit erfolgt dies aber über eine Verbindung. TCP verwendet
ausserdem das Huckepack-Prinzip. Wird ein Datenpaket in eine Richtung
verschickt so enthält es auch Informationen zur Überwachung des
Datenverkehrs in die umgekehrte Richtung.
Die Daten werden vom TCP nicht direkt übermittelt, sondern durchlaufen
einen Puffer. Daraus erfolgt eine sinnvolle Größeneinteilung der
Pakete und somit ein effizienter Datentransfer. Ob nun eine
Fragmentierung oder ein Zusammenfassen der Daten erfolgt hängt von
vielen Dingen ab, wie z. B. vom Datenverkehr (traffic), von
Router-Algorithmen oder zufälligen Fehlern. Besteht die Notwendigkeit
Daten unmittelbar zu übertragen wie z. B. bei Durchführung eines
remote login oder ssh erfolgt dies mittels des sogenannten
Push-Befehls. Alle Daten die gepusht werden, werden unmittelbar
übertragen und haben höhere Priorität als gewöhnliche Daten. Erst wenn
alle Daten die mit dem Push-flag versehen sind übertragen wurden, wird
der reguläre Datentransfer fortgesetzt.
TCP ist multiplexingfähig. Es besteht also die Möglichkeit, dass
mehrere Hosts gleichzeitig jeweils eine Verbindung zu ein und dem
selben Server an ein und dem selben Port betreiben. Hierbei dient der
Socket des jeweiligen Rechners und der Header der Pakete zur
eindeutigen Zuordnung auf Serverseite.
Eine der Hauptaufgaben des TCP ist es, auf einer unzuverlässigen Basis
(nämlich dem Internet) eine zuverlässige Kommunikation zwischen zwei
Endprozessen zu gewährleisten.
Diese Zuverlässigkeit wird gewährleistet durch das sogenannte
Acknowledgement (ACK). Hierzu wird die Sequence-Number (SEQ)
verwendet. Für beide Richtungen der Datenkommunikation wird beim
Verbindungsaufbau eine Anfangs-SEQ-Nummer vergeben. Mit dieser Nummer
werden nun byteweise die übertragenen Daten durchnummeriert. Die
SEQ-Nummer bestimmt also eindeutig die Position des jeweiligen Byte im
Stream. Die ACK-Nummer wird nun verwendet, um für erhaltene
Datenpakete eine Empfangsbestätigung an den Absender
zurückzusenden. Dabei bezieht sich das gesendete ACK immer auf das
nächste Byte, was erwartet wird. Das Byte mit der SEQ-Nummer i wird
also mit der ACK-Nummer i+1 bestätigt. Es werden stets nur solche Byte
bestätigt, bis zu denen alle Byte erhalten wurden. Geht der Vorgänger
eines Byte verloren kann das nachfolgende Byte nicht bestätigt werden,
bis der Vorgänger empfangen wurde. Weiter ist hier von Vorteil, dass
es keine Auswirkungen hat, wenn einzelne ACK-Sendungen verloren
gehen. Schließlich wird das verlorenen ACK durch einen bestätigten
Nachfolger mitbestätigt. Das ACK gewährleistet also eine fehlerfreie
und vollständige Datentransmission unter Beibehaltung der korrekten
Reihenfolge der Daten im Stream. Es besteht die Möglichkeit der
Autokorrektur bzw. einer Benachrichtigung des anderen Prozesses, falls
keine Korrektur möglich ist.
Abb. 3: Das gleitende Fenster und Acknowledgement
Zur Überwachung des Datenverkehrs werden im TCP verschiedene Timer
eingesetzt. Der retransmission-timer legt fest, nach welcher
Zeitspanne die Neusendung eines Datenpakets stattfindet, für das keine
Empfangsbestätigung eingegangen ist. Der quiet-timer dient dazu, den
Empfang von Paketen zu gewährleisten, die nach dem eigentlichen
Verbindungsende empfangen werden. Hierdurch wird also den
"Nachzüglern" die Möglichkeit gegeben, doch noch vom Zielprozess
empfangen zu werden. Diese beiden Timer werden berechnet nach dem
TimeToLive-Wert, welcher bestimmt, wieviel Zeit einem Datenpaket
gegeben wird, um sein Ziel zu erreichen und bestätigt zu werden. Ein
weiterer Timer ist der sogenannte persistence-timer. Dieser sorgt
dafür, dass während einer Fenstergröße von 0 die Aufforderung zum
Weitersenden nicht verloren geht. So wird nach Ablauf des
persistence-timers eine 1 Byte Sendung zur Kontrolle der Verbindung
gesendet. Der keep-alive-timer gewährleistet, dass eine Verbindung
nicht unterbrochen wird wenn kurze Zeit keine Daten übermittelt
werden. Schließlich existiert noch der idle-timer, nach dessen Ablauf
die Verbindung als unterbrochen gilt, falls keine Antwort der
Gegenseite während dieser Zeit eingegangen ist.
Das Acknowledgement gewährleistet mit den verschiedenen Timern eine
zuverlässige Datenübertragung. Jedoch wäre es sehr ineffizient, ein
einzelnes Paket zu senden und dann jedes Mal auf eine Bestätigung zu
warten, bis das nächste gesendet wird. Daher verwendet man im TCP das
sogenannte gleitende Fenster welches festlegt, wie viele Daten auf
einmal übertragen werden. Bei jedem übertragenen Paket erfolgt ein
sogenanntes window-advertisement. Hierdurch erfolgt eine ständige,
automatische Anpassung an die Fähgkeiten des Netzwerks und auch
verschieden starke Rechner können miteinander kommunizieren. Das
Datenvolumen, das sich noch im Puffer des Empfängers befindet wird vom
window abgezogen, um den Empfänger nicht zu überlasten. Das Fenster
wird um so viele Byte weiter nach rechts bewegt, wie sie bestätigt
wurden. Das Byte ganz links im Fenster ist also das älteste Byte für
das noch keine Bestätigung vorliegt.
Abb. 4: Das gleitende Fenster
Der Datentransfer im TCP ist verbindungsorientiert. Bevor der
eigentliche Datenverkehr stattfinden kann wird also eine Verbindung
hergestellt, wobei beide Seiten der Verbindung zustimmen müssen. Dabei
wird unter anderem die Größe der Datenpakete ausgehandelt. Dies
geschieht durch den Drei-Wege-Handschlag. Damit eine Verbindung
hergestellt werden kann, muss beim Server ein Prozeß am Zielport
"lauschen". Auf dem Client läuft eine Applikation, die dessen
TCP-Schicht mitteilt, dass sie eine Verbindung aufbauen soll. Die
TCP-Schicht sendet nun ein Datenpaket an den Server in dem sie ihm
eine Anfangs-SEQ-Nummer mitteilt (SEQ=i). Auf Serverseite teilt dessen
TCP-Schicht dies der Applikation mit die diesen Prozeß überwacht. Ist
diese mit der Verbindung einverstanden sendet sie eine Bestätigung
(ACK) der erhaltenen SEQ-Nummer und vergibt seinerseits ebenfalls eine
Start-SEQ-Nummer (SEQ=j, ACK=i+1). Diese werden zurück an den Client
gesendet. Der Client wiederum bestätigt die erhaltene SEQ-Nummer mit
einer Sendung an den Server (ACK=j+1) und teilt der
Applikationsschicht mit, dass die Verbindung aufgebaut ist. Der Client
führt einen sogenannten active-open-Vorgang aus; das Äquivalent auf
Serverseite nennt man passive-open. Die beiden Sequenznummern i und j
werden dabei zufällig ausgewählt und liegen zwischen 0 und 2^32.
Hier wird das beim TCP verwendete Huckepack-Prinzip deutlich. Bei
Senden von Daten in die eine Richtung werden Informationen zur
Kontrolle des Datentransfers in die andere Richtung mitgesendet.
Abb. 5: Verbindungsaufbau im TCP
Ist der Datentransfer abgeschlossen wird die Verbindung beendet um
Ressourcen zu sparen. Der reguläre Verbindungsabbau ist dem
Drei-Wege-Handschlag des Verbindungsaufbaus sehr ähnlich und ist in
der untenstehenden Abbildung dargestellt. Der Rechner, der die
Verbindung beenden möchte, sendet ein Datenpaket mit dem Finalize-Flag
(FIN) unter Angabe der SEQ-Nummer. Der andere Rechner bestätigt diese
SEQ-Nummer und sendet seinerseits die SEQ-Nummer zusammen mit dem
gesetzten FIN-Flag. Der Rechner, der anfangs die Verbindung beenden
wollte, sendet nun noch eine Bestätigung der erhaltenen
SEQ-Nummer. Sendet eine Seite ein FIN-Flag und erhält keine
Bestätigung innerhalb des doppelten der maximalen Lebenszeit eines
Pakets, wird die Verbindung ebenfalls als beendet betrachtet. Auf der
anderen Seite wird die Verbindung dann dadurch beendet, dass der
idle-timer abläuft.
Des weiteren besteht die Möglichkeit, eine bestehende Verbindung
unmittelbar zu beenden ohne den Drei-Wege-Handschlag. Dies geschieht
durch Sendung eines Datenpakets mit einem gesetzten Reset-Flag
(RST). Wird eine Verbindung auf diese Weise beendet findet kein
weiterer Darantransfer statt.
Eine Verbindung wird auch beendet, wenn nach einer bestimmten Zeit
keine Daten mehr gesendet wurden um Ressourcen zu sparen.
Abb. 6: Verbindungsabbau im TCP
Ein Datenpaket nennt man auch Segment. Jedes Segment besteht aus einem
Kopf (Header) und dem Datenpaket, das es von der darüberliegenden
Schicht erhält. Dieses Datenpaket aus der darüberliegenden Schicht
enthält seinerseits den eigentlichen zu übertragenden Datenteil und
Header der darüberliegenden Schichten. Datensegment und Header bilden
jeweils die sogenannte Protocol Data Unit (PDU). Die Größe einer
solchen PDU ist beschränkt auf 65535 Byte und darf ausserdem die
Maximum Transmission Unit des Netzes nicht überschreiten. Der TCP
Header, der eine Größe von 20 Byte hat ist in Abbildung 7
dargestellt. Im Feld Quell- und Zielport werden jeweils die 16bit
Zahlen eingatragen, die die Ports der beiden Rechner
identifizieren. Die Sequenz-Nummer dient wie bereits behandelt zur
Bestimmung der Position der gesendeten Daten im Stream. Außerdem wird
aus ihr die ACK-Nummer bestimmt. Diese Acknowledgement-Nummer ist
Inhalt des nächsten Feldes. Sie dient zur Bestätigung der erhaltenen
Bytes. Die Headerlänge beschreibt wieviele Vielfache von 32bit-Wörtern
die Länge des Headers beträgt. Das nächste Feld mit einer Länge von
6bit ist reserviert für zukünftige Erweiterungen. Als nächstes folgen
die Code-Bits (auch Flags genannt), die die Art der übertragenen Daten
kennzeichnen: URG=Urgent: Dringende Daten die unmittelbar übermittelt
werden, ACK=Acknowledgement: Bestätigung eines empfangenen
Datenpakets, PSH=Push: Der Puffer wird geleert und die Daten werden
unmittelbar übertragen, RST=Reset: Sofortiges Beenden der Verbindung,
SYN=Synchronize: Zuteilen einer Sequenz-Nummer beim Verbindungsaufbau,
FIN=Finalize: Zeigt die reguläre Beendigung einer Verbindung an.
Nun folgt das Fenster, welches beschreibt, wieviele Daten auf einmal
übertragen werden können. Die Prüfsumme dient zur Kontrolle der
Korrektheit der Datenübermittlung. Die Berechnung der Prüfsumme ist
gleich der beim UDP und wird dort noch beschrieben werden. Der
urgent-pointer bewirkt den Sprung auf ein bestimmtes Oktet im
Bytestream. Schließlich folgt dann der Block mit den eigentlich zu
übertragenden Daten. Eine Neuerung zum ursprünglichen TCP ist die der
window-scale-size. Bei sehr hohen Bandbreiten kann das 16bit-Fenster
unter Umständen zu klein sein. Daher besteht die Möglichkeit das
Fenster um bis zu 16bit nach links zu shiften. So wird eine maximale
Fenstergröße von 2^32Byte möglich.
Abb. 7: Der TCP-Header
Wie auch beim UDP wird beim TCP ein zweiter Header verwendet, nämlich
der sogenannte Pseudo-Header. Dieser erfüllt verschiedene
Funktionen. In ihm werden einige Verbindungsinformationen
gespeichert. Da der Pseudoheader auch in die Prüfsumme einbezogen
wird, erfolgt hierdurch auch eine zusätzliche Kontrolle der
Datenkommunikation. Ausserdem wird der Header an die IP-Schicht
übergeben und von dieser komplettiert bzw. werden von der IP-Schicht
Informationen übernommen. Dies ist zwar ein Bruch mit dem
Schichtenkonzept, wo alle Schichten eigenständig arbeiten, aufgrund
der Effizienz wird dies aber hingenommen. Der Pseudoheader enthält die
Quell- und Ziel-IP, das verwendete Protokoll und die Segmentlänge.
Abb. 8: Der Pseudo-Header
UDP bedeutet User Datagram Protocol und beschreibt ein
minimalistisches Transportprotokoll, das lediglich grundlegende
Funktionen zum Datentransport bereitstellt. Es wurde 1980 spezifiziert
im RFC 768.
Genau wie das IP werden die zu transportierenden Daten in Paketform
verschickt, die hier Datagramme genannt werden.
UDP arbeitet aufgrund des angestrebten Minimalismus nicht mit einer
ständigen, beidseitigen Verbindung. So entfallen beispielsweise sowohl
der Verbindungsauf und -abbau als auch die Bestätigung der empfangenen
Pakete.
Beim User Datagram Protocol ist zur Kontrolle des Datenverkehrs
lediglich eine Prüfsumme vorgesehen, die dazu noch optional ist. Alle
anderen Mechanismen zur Fehlerbehebung, wie sie bei TCP existieren,
gibt es hier nicht. Daher ist der Verlust, die Duplizierung und Fehler
in der Reihenfolge der zu sendenden Daten möglich. All diese möglichen
Fehler müssen dann auf Applikationsebene behandelt werden.
Die Prüfsumme wird wie beim TCP gebildet, in dem die Summe der
1'er-Komplemente aller 16bit-Wörter des Datenbereichs inklusive des
Pseudoheaders berechnet wird. Von dieser Summe wird dann das
1'er-Komplement als Prüfsumme eingesetzt. Da der Pseudoheader in die
Berechnung einbezogen wird ist sichergestellt, dass die korrekte
Zieladresse angesprochen wird. Um auf Empfängerseite die Korrektheit
des gesendeten Datagramms zu überprüfen addiert man die Summer aller
16bit-Wörter auf die empfangene Prüfsumme. Ist das Resultat von 0
verschieden ist bei der Datentransmission ein Fehler aufgetreten.
Wie das gesamte UDP ist auch dessen Header minimalistisch angelegt. Er
besteht lediglich aus vier Felder der jeweiligen Länge von 2
Byte. Diese sind Quellport, Zielport, Datagramm-Größe (Maximum=65535
wie bei TCP) und Prüfsumme (optional).
Abb. 9: Der UDP-Header
TCP und UDP sind die beiden gebräuchlichsten Transportprotokolle. Sie
senden die zu übertragenden Daten beide in Pakete und bauen beide auf
dem Internet Protokoll (IP) auf, welches für den eigentlichen
Transport der Pakete sorgt. In den Aspekten Sicherheit und Leistung
unterscheiden sich beide nur gering. Für belastete Server ist UDP oft
besser geeignet weil weniger Ressourcen verbraucht werden.
- [TA]:
A. S. Tanenbaum:
Computer Networks.
- [BB]:
M. Bossert, M. Breitbach:
Digitale Netze.
- [CO1]:
Douglas E. Comer:
Internetworking with TCP/IP vol 1:
principles, protocols and architecture.
- [CO1]:
Douglas E.Comer:
Computer Networks and Internet.
- [PA]:
Tim Parker:
Teach Yourself TCP/IP in 14 days 2nd
edition.
- [JA]:
Professor Raj Jain, Professor of CIS:
Transport
Protocols.
Ohio State University.
- [CS]:
Cisco Systems Inc.:
Internet Protocols.
www.ieng.com.
- [IC]:
TCP/IP:
Department of Computing, Imperial College.
London/UK, www.doc.ic.ac.uk.
- [CN]:
connected - an internet enclycopedia:
http://compnetworking.about.com.
- [C1]:
RFC 768: UDP:
ftp://ftp.isi.edu/in-notes/.
- [C2]:
RFC 793: TCP:
ftp://ftp.isi.edu/in-notes/.
|
Letzte Änderung: 2001-02-07 13:22:56
|
![[Universität Karlsruhe]](/images/ico_uni.png)
![[Institut für Technische Informatik]](/images/ico_home.png)
![[E-Mail an Autor]](/images/ico_mail.png)