:: wikimiki.org ::
| Asynchronous Reliable Delivery Protocol |
Asynchronous Reliable Delivery ProtocolDas ARDP-Protokoll (Asynchronous Reliable Delivery Protocol) ist ein Kommunikations-Protokoll, das für den Prospero-Service entwickelt wurde. Es wird allerdings auch für Services wie NetCheque, NetCash oder PPV genutzt. Eine Zeit lang war es in Diskussion, ARDP als Alternative zu TCP einzusetzen. Es arbeitet einen Layer über UDP.
ARDP wurde als Frage-Antwort-Protkoll entwickelt bei dem im Normalfall der Client eine Anfrage mit so wenig Paketen wie möglich stellt und der Server dann eine Antwort schickt. Der Server darf Anfragen in eine Warteschlange stecken und die Antwort verschicken, wenn die Daten verfügbar sind. In der Zwischenzeit kann er weitere Anfragen entgegen nehmen und beantworten. ARDP wurde so konzipiert, dass der Overhead, der durch die Sicherstellung der Datenintegrität entsteht (vergleiche TCP), so klein wie möglich ist. ARDP ist also entwickelt worden, um Daten-Integrität ohne den Verbindungs-Auf- und -Abbau-Overhead von TCP sicherzustellen. Solange keine spezielle Behandlung nötig ist, ist der Header klein gehalten und solange keine Daten verloren gehen, werden keine weiteren Pakete verschickt.
Kategorie:Netzwerkprotokoll
Prospero (Protokoll)Das Prospero-Protokoll stellt auf Basis einer internetweit verteilten Architektur ein vom Benutzer abhängiges Dateisystem zur Verfügung. Clifford Neumann entwickelte es speziell für seine Anforderungen. Das unterliegende Netzwerk-Protokoll ist ARDP, darunter ist UDP. Die Kommunikation zwischen Server und Client läuft bei dem Prospero-Protokoll mittels natürlichsprachlicher Kommandos. Dadurch wurden die seinerzeit problematischen unterschiedlichen Codierungen zwischen den verschiedenen Architekturen und Systemen umgangen. Die Kommunikation ist zeilenbasiert, wobei jede Zeile nochmal unterteilt ist in Tokens. Tokens werden durch zwei Leerzeichen oder zwei Tabs voneinander getrennt, Zeilen müssen durch
Transmission Control Protocol
Das Transmission Control Protocol (TCP) ist eine Vereinbarung (Protokoll) darüber, auf welche Art und Weise Daten zwischen Computern ausgetauscht werden sollen. Alle am Datenaustausch beteiligten Computer kennen diese Vereinbarungen und befolgen sie. Es ist damit ein zuverlässiges, verbindungsorientiertes Transportprotokoll in Computernetzwerken. Es ist Teil der TCP/IP-Protokollfamilie.
Entwickelt wurde TCP von Robert E. Kahn und Vinton G. Cerf. Ihre Forschungsarbeit, die sie im Jahre 1973 begannen, dauerte mehrere Jahre. Die erste Standardisierung von TCP erfolgte deshalb erst im Jahre 1981 als RFC 793.
TCP stellt einen virtuellen Kanal zwischen zwei Endpunkten einer Netzwerkverbindung (Sockets) her. Auf diesem Kanal können in beide Richtungen Daten übertragen werden. TCP setzt in den meisten Fällen auf das IP (Internet-Protokoll) auf. Es ist in Schicht 4 des OSI-Referenzmodells angesiedelt.
Verbindungsaufbau und Abbau
OSI-Referenzmodell
OSI-Referenzmodell
OSI-Referenzmodell
OSI-Referenzmodell
TCP ist im Prinzip eine Punkt-zu-Punkt-Verbindung in Vollduplex. Diese Verbindung kann in zwei Halbduplex-Verbindungen eingeteilt werden, wobei die Daten in Gegenrichtung zusätzliche Steuerungsinformationen enthalten.
Das Management dieser Verbindung sowie die Datenübertragung wird von der TCP-Software übernommen, siehe Abb. 1.
Die TCP-Software ist eine Funktionssammlung, zum Beispiel bei Windows in der Winsock.dll beziehungsweise wsock32.dll oder bei Linux im Kernel (je nach Betriebssystem unterschiedlich). Die Anwendung ist zum Beispiel ein Webbrowser oder ein Webserver (zum Beispiel Apache).
Jeder Endpunkt stellt ein Tupel bestehend aus IP-Adresse und Port
dar. Ports sind 16-Bit-Zahlen und reichen von 0 bis 65535. Ports von 0 bis 1023 sind reserviert (englisch: well known ports [http://www.iana.org/assignments/port-numbers]) und werden von der
IANA vergeben, z. B. ist Port 80 für das HTTP-Protokoll reserviert.
Allerdings ist das Benutzen der vordefinierten Ports trotzdem nicht bindend. So kann jeder Administrator einen FTP-Server (normalerweise Port 21) auch auf einem anderen Port laufen lassen.
Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte definiert. So ist es beispielsweise möglich, dass ein Webserver auf einem Port mehr als eine Verbindung zu einem anderen Rechner geöffnet haben kann.
Ein Webserver, der seinen Dienst anbietet, generiert einen Endpunkt mit dem Port und seiner Adresse (er kann auch beliebige Adressen zulassen). Dies wird als passive open bezeichnet.
Will ein Client eine Verbindung aufbauen, generiert er einen eigenen Endpunkt aus seiner Rechneradresse und einer noch freien Portnummer. Mit Hilfe eines ihm bekannten Ports und der Adresse des Servers kann dann eine Verbindung aufgebaut werden.
Während der Datenübertragungsphase (active open) sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch. Insbesondere kann jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten.
Während des Abbaus kann die Gegenseite noch Daten übertragen, die Verbindung kann also halb-offen sein.
Der Drei-Wege-Handshake
Beim Aufbau einer TCP-Verbindung kommt der so genannte Drei-Wege-Handshake zum Einsatz. Der Rechner, der die Verbindung initiieren will, sendet dem anderen ein SYN-Paket mit einer Sequenznummer x. Es handelt sich also um ein Paket, dessen SYN-Bit im Paketkopf gesetzt ist (siehe TCP-Header). Die initiale Sequenznummer ist beliebig und wird vom jeweiligen Betriebssystem festgelegt.
Die Gegenstelle (siehe Skizze) empfängt das Paket und sendet in einem eigenen syn-Paket im Gegenzug seine initiale Sequenznummer y, zugleich bestätigt sie den Erhalt des ersten SYN-Pakets, indem sie die Sequenznummer inkrementiert und x+1 im ACK-Teil des Headers zurückschickt.
Der Client bestätigt zuletzt den Erhalt des SYN/ACK-Pakets durch das Senden eines eigenen ACK-Pakets mit der Sequenznummer x+1 und dem ACK-Wert y+1. Die Verbindung ist damit aufgebaut.
1. SYN-SENT --> --> SYN-RECEIVED
2. ESTABLISHED <-- <-- SYN-RECEIVED
3. ESTABLISHED --> --> ESTABLISHED
Der geregelte Verbindungsabbau erfolgt ähnlich. Statt des SYN-Bits kommt das FIN-Bit zum Einsatz. Der Erhalt des Pakets wird wiederum mittels ACK bestätigt. Der Empfänger des FIN-Pakets sendet zuletzt seinerseits ein FIN-Paket, das ihm ebenfalls bestätigt wird.
Obwohl eigentlich vier Wege genutzt werden, handelt es sich beim Verbindungsabbau auch um einen Drei-Wege-Handshake, da die ACK- und FIN-Operationen vom Server zum Client als ein Weg gewertet werden. Zudem ist ein verkürztes Verfahren möglich, bei dem FIN und ACK genau wie beim Verbindungsaufbau im selben Paket untergebracht werden.
Aufbau des TCP-Headers
Betriebssystem
Das TCP-Segment besteht immer aus zwei Teilen – dem Header und der Nutzlast (Payload). Die Nutzlast enthält die zu übertragenden Daten, die wiederum Protokollinformationen der Anwendungsschicht wie HTTP oder FTP entsprechen können.
Den schematischen Aufbau des TCP-Headers kann man im Bild rechts sehen.
Die Werte werden in network byte order (big endian) angegeben.
Erläuterung
Source Port:
Gibt die Portnummer auf der Senderseite an.
Destination Port:
Gibt die Portnummer auf der Empfängerseite an.
Sequence Number:
Sequenznummer des ersten Daten-Oktetts (Byte) dieses TCP-Paketes oder die Initialisierungs-Sequenznummer falls das SYN-Flag gesetzt ist.
Nach der Datenübertragung dient sie zur Sortierung der TCP-Segmente, da diese in unterschiedlicher Reihenfolge beim Empfänger ankommen können.
Acknowledgment Number (Quittierungsnummer):
Sie gibt die Sequenznummer an, die der Sender dieses TCP-Segmentes als nächstes erwartet. Nur gültig, falls das ACK-Flag gesetzt ist.
Data Offset:
Länge des TCP-Headers in 32-Bit-Blöcken - ohne die Nutzdaten (Payload). Indiziert die Startadresse der Nutzdaten.
Reserved:
Das Reserved-Feld wird nicht verwendet und muss null sein.
Flags:
URG:
Ist das Urgent-Flag gesetzt, so werden die Daten auf die das Urgent Pointer-Feld zeigt sofort von der Anwendung bearbeitet. Dabei unterbricht die Anwendung alle anderen Aufgaben. Dieses Verfahren ist fern verwandt mit einem Softwareinterrupt. Dieses Flag kann zum Beispiel verwendet werden, um eine Anwendung auf dem Empfänger abzubrechen.
ACK:
Das Acknowledgment-Flag hat in Verbindung mit dem Acknowledgment-Feld folgende Aufgaben. Einmal dient es in Verbindung mit dem ACK- und SYN-Flag zur Bestätigung beim 3 Way-Handshake und zur Bestätigung von TCP-Segmenten beim Datentransfer.
Das Acknowledgment-Feld ist nicht gültig, wenn das Flag nicht gesetzt ist.
PSH:
Das Push-Flag hat die Aufgabe die Daten unter Umgehung des Buffers sofort an die Anwendung weiterzuleiten. Hilfreich ist dies, wenn man zum Beispiel bei einer Telnet-Sitzung einen Befehl an den Empfänger senden will. Würde dieser Befehl ersteinmal im Buffer zwischengespeichert, so würde dieser erst (stark) verzögert abgearbeitet.
RST:
Das Reset-Flag wird verwendet, wenn eine Verbindung abgebrochen werden soll. Dies geschieht zum Beispiel bei technischen Problemen oder zur Abweisung von unerwünschten Verbindungen.
SYN:
Pakete mit gesetztem SYN-Flag initiieren eine Verbindung, d.h. beginnen den 3-Wege-Handshake. Der Server antwortet normalerweise entweder mit SYN+ACK, wenn er bereit ist, die Verbindung anzunehmen, andernfalls mit RST. Dient der Synchronisation von Sequenznummern beim Verbindungsaufbau (daher die Bezeichnung SYN).
FIN:
Dieses Finish-Flag dient zur Freigabe der Verbindung und zeigt an, dass keine Daten mehr vom Sender kommen.
Die FIN- und SYN-Flags haben Sequenznummern, damit diese in der richtigen Reihenfolge abgearbeitet werden.
Window:
Ist die Anzahl der Daten-Oktetts (Bytes), beginnend bei dem durch das Acknowledgmentfeld indizierten Daten-Oktett, die der Sender dieses TCP-Paketes bereit ist zu empfangen.
Checksum:
Die Prüfsumme dient zur Erkennung von Übertragungsfehlern und wird über den Header und die Daten berechnet.
Urgent Pointer:
Ist ein Zeiger auf das Ende einer Sequenz mit dringenden Daten. Den Anfang der Sequenz muss die Anwendung selbst ermitteln.
Der Pointer ist nur gültig, falls das URG-Bit gesetzt ist.
Options:
Das Options-Feld ist unterschiedlich groß und enthält Zusatzinformationen. Die Optionen müssen ein Vielfaches von 32 Bit lang sein. Sind sie das nicht, muss mit Null-Bits aufgefüllt werden (Padding). Dieses Feld gibt die Möglichkeit Verbindungsdaten auszuhandeln, die nicht im TCP-Header enthalten sind. Wie zum Beispiel die Maximalgröße des Nutzdatenfeldes.
Datenübertragung
Prüfsumme
Über ein TCP-Segment können maximal 65495 Byte Nutzdaten bei darunterliegendem IPv4 und 65515 Byte bei IPv6 versandt werden. Dies errechnet sich so:
In das IPv4-Paket passen maximal 65515 Byte Nutzdaten (65535 Byte abzüglich 20 Byte IP-Header). In ein IPv6-Paket passen maximal 65535 Byte Nutzdaten.
Von diesem Wert müssen noch 20 Byte für den TCP-Header abgezogen werden.
In der Praxis ist das Nutzdatenfeld kleiner.
Bei Ethernet darf das Nutzdatenfeld zum Beispiel nur maximal 1500 Byte groß sein, deshalb kann
ein TCP-Segment nur maximal 1460 Byte (Maximum Segment Size MSS) transportieren (1500 Byte - 20 Byte - 20 Byte).
Empfänger und Sender einigen sich vor dem Datenaustausch über das Options-Feld auf die Größe der MSS.
Die Anwendung, die Daten versenden möchte, beispielsweise ein Webserver, legt zum Beispiel einen 10 Kilobyte großen Datenblock im Buffer ab.
Wie kann man mit einem 1460 Byte großen Nutzdatenfeld 10 Kilobyte Daten versenden?
Ganz einfach, man teilt die Daten auf (Segmentierung), fügt einen TCP-Header hinzu und versendet die TCP-Segmente. Im Buffer ist der Datenblock, dieser wird in 5 Segmente aufgeteilt (siehe Abb. 6). Jedes Segment erhält durch die TCP-Software einen TCP-Header. 3 TCP-Segmente wurden aktuell abgeschickt. Diese sind nicht geordnet, da im Internet jedes TCP-Segment einen anderen Weg nehmen und es dadurch zu Verzögerungen kommen kann. Damit die TCP-Software im Empfänger die Segmente wieder ordnen kann, ist jedes Byte "nummeriert" (die Bytes werden sozusagen gezählt). Bei der Zuordnung der Segmente wird die Sequenznummer herangezogen.
Der Empfänger muss TCP-Segmente, die einwandfrei (Checksumme ist in Ordnung) angekommen sind, bestätigen.
Maximum Segment Size
Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 (variiert) und einer Nutzdatenlänge von 1460 Byte an den Empfänger. Der Empfänger bestätigt es mit einem TCP-Header ohne Daten mit ACK=1461 und fordert damit das zweite TCP-Segment ab dem Byte Nummer 1461 beim Sender an. Dieser schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger. Dieser bestätigt es wieder mit einem ACK=2921 und so weiter. Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind. Empfängt er die TCP-Segmente 1,2,3,4,5 so braucht er nur das letzte TCP-Segment zu bestätigen.
Fehlt zum Beispiel das TCP-Segment 3 weil es verloren gegangen ist, so kann er nur die 1 und die 2 bestätigen 4 und 5 jedoch noch nicht. Da der Sender keine Bestätigung für die 3 bekommt läuft sein Timer ab und er verschickt die 3 noch einmal. Kommt die 3 beim Empfänger an, so bestätigt er alle 5 TCP-Segmente.
Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt einen Timer (RTT).
Flusssteuerung
RTT
Da die Anwendung Daten aus dem Buffer liest, ändert sich der Füllstand des Buffers ständig. Deshalb ist es notwendig den Datenfluss entsprechend dem Füllstand zu steuern. Dies geschieht mit dem Sliding Window und dessen Größe.
Den Buffer des Senders erweitern wir, wie in Abb. 8 zu sehen, auf 10 Segmente.
In der Abb. 8a werden gerade die Segmente 1-5 übertragen. Die Übertragung ist vergleichbar mit Abb. 7. Obwohl der Buffer des Empfängers in Abb. 7 am Ende voll ist, fordert er mit ACK=7301 die nächsten Daten ab dem Byte 7301 beim Sender an. Dies hat zur Folge, dass das nächste TCP-Segment vom Empfänger nicht mehr verarbeitet werden kann. Ausnahme sind jedoch TCP-Segmente mit gesetztem URG-Flag.
Mit dem Window-Feld kann er dem Sender mitteilen, dass er keine Daten mehr verschicken soll. Dies geschieht indem er im Window-Feld den Wert Null einträgt (Zero Window). Der Wert Null entspricht dem freien Speicherplatz im Buffer.
Die Anwendung des Empfängers liest nun die Segmente 1-5 aus dem Buffer, womit wieder ein Speicherplatz von 7300 Byte frei ist. Damit kann er die restlichen Segmente 6-10 mit einem TCP-Header, der die Werte SEQ=1, ACK=7301 und Window=7300 enthält, beim Sender anfordern. Der Sender weiß nun, dass er maximal 5 TCP-Segmente an den Empfänger schicken kann und verschiebt das Window um 5 Segmente nach rechts (siehe Abb. 8b).
Die Segmente 6-10 werden nun alle zusammen als Burst verschickt.
Kommen alle TCP-Segmente beim Empfänger an, so quittiert er sie mit SEQ=1 und ACK=14301 und fordert die nächsten Daten an.
Silly Window Syndrome:
Der Empfänger sendet ein Zero Window an den Sender, da sein Buffer voll ist.
Die Anwendung beim Empfänger liest allerdings nur zwei Byte aus dem Buffer. Der Empfänger schickt ein TCP-Header mit Window=2 (Window Update) an den Sender und fordert gleichzeitig die zwei Byte an. Der Sender kommt der Aufforderung nach und schickt die zwei Byte in einem 42 Byte großem Paket (mit IP-Header und TCP-Header) an den Empfänger. Damit ist der Buffer des Empfängers wieder voll und er schickt wieder ein Zero Window an den Sender. Die Anwendung liest jetzt zum Beispiel hundert Byte aus dem Buffer. Der Empfänger schickt wieder ein TCP-Header mit einem kleinem Window-Wert an den Sender. Dieses Spiel setzt sich immer wieder fort und verschwendet Bandbreite, da nur sehr kleine Pakete versandt werden.
Clarks Lösung ist, dass der Empfänger ein Zero Window senden und solange mit dem Window Update warten soll bis die Anwendung mindestens die Maximum Segmentsize (in unserem bisherigen Beispielen 1460 Byte) aus dem Buffer gelesen hat oder der Buffer halbleer ist. Je nachdem was zuerst eintritt (Dave Clark, 1982).
Auch der Sender kann zu kleine Pakete abschicken und dadurch Bandbreite verschwenden. Dieser Umstand wird mit dem Nagle-Algorithmus beseitigt. Deswegen ergänzt er sich mit Clarks Lösung.
Aufbau und Funktion des TCP Pseudo-Headers
Der Pseudo-Header wird zur Checksummenberechnung verwendet und dient daher zur Erhöhung der Zuverlässigkeit. Es ist dadurch auch möglich fehlgeleitete Pakete zu erkennen.
In die Berechnung fließen außerdem noch der TCP-Header und seine Nutzdaten (TCP-Segment) ein.
Bevor die TCP-Software ein TCP-Segment abschickt bildet sie einen Pseudo-Header aus der IP-Adresse des Senders und des Empfängers, sowie der TCP-Segment-Länge. Vor Berechnung der Checksumme wird das Checksummen-Feld im TCP-Header auf Null gesetzt und es wird dem Nutzdatenfeld ein Null-Byte angehängt, wenn die Länge eine ungerade Zahl ist.
Die Berechnung der Checksumme erfolgt durch Addition von 16 Bit-Werten im Einerkomplement. Aus der Summe wird nocheinmal das Einerkomplement gebildet.
Nach der Berechnung wird das 16 Bit-Ergebnis im TCP-Header abgelegt und das TCP-Segment abgeschickt.
Der Empfänger führt diese Berechnung nocheinmal unter Einbezug der Checksumme aus, wodurch das Ergebnis Null sein sollte.
Ist die Checksumme beim Empfang des TCP-Segmentes nicht Null, so wird es ohne Nachricht verworfen.
Dies hat zur Folge, dass der RTT-Timer beim Absender abläuft und das TCP-Segment nochmal abgeschickt wird.
Einerkomplement
Source IP Address:
IP-Adresse des Absenders.
Destination IP Address:
IP-Adresse des Empfängers.
000000:
Füllbits.
Protocol:
Hat immer den Wert Sechs für das TCP-Protokoll (siehe auch IP-Header).
TCP Length:
Länge des TCP-Segments in Bytes.
Datenintegrität und Zuverlässigkeit
Im Gegensatz zum verbindungslosen UDP implementiert TCP einen bidirektionalen, byte-orientierten, zuverlässigen Datenstrom zwischen zwei Endpunkten. Das darunterliegende Protokoll (IP) ist paketorientiert, wobei Datenpakete verlorengehen können, in verkehrter Reihenfolge ankommen dürfen und sogar doppelt empfangen werden können. TCP wurde entwickelt, um mit der Unsicherheit der darunter liegenden Schichten umzugehen. Es prüft daher die Integrität der Daten mittels der Prüfsumme im Paketkopf und stellt die Reihenfolge durch Sequenznummern sicher. Der Sender wiederholt das Senden von Paketen, falls keine Bestätigung innerhalb einer bestimmten Zeitspanne (Timeout) eintrifft. Die Daten der Pakete werden beim Empfänger in einem Puffer in der richtigen Reihenfolge zu einem Datenstrom zusammengefügt und doppelte Pakete verworfen.
Zu beachten ist, dass der Sender mittels TCP lediglich zuverlässig erfahren kann, ob der Empfang von Daten vom Empfänger korrekt quittiert wurde oder nicht.
Der Datentransfer kann selbstverständlich jederzeit nach dem "Aufbau einer Verbindung" gestört, verzögert oder ganz unterbrochen werden. Das Übertragungssystem läuft dann in einen Timeout. Der vorab getätigte "Verbindungsaufbau" stellt also keinerlei Gewähr für eine nachfolgende sichere Übertragung dar.
Bestätigungen
Die jeweilige Länge des Puffers, bis zu der keine Lücke im Datenstrom existiert, wird bestätigt (Windowing). Dadurch ist die Ausnutzung der Netzwerk-Bandbreite auch bei großen Strecken möglich. Bei einer Übersee- oder Satellitenverbindung dauert das Eintreffen des ersten Acknowledges (ACK) aus technischen Gründen bisweilen mehrere 100 ms, in dieser Zeit können unter Umständen mehrere hundert Pakete gesendet werden. Der Sender kann den Empfängerpuffer füllen, bevor die erste Bestätigung eintrifft. Alle Pakete im Puffer können gemeinsam bestätigt werden. Bestätigungen können zusätzlich zu den Daten in den TCP-Header des entgegengesetzten Datenstroms eingefügt werden (Piggybacking), falls der Empfänger ebenfalls Daten für den Sender bereithält.
Weitere Protokolleigenschaften
Über ein Dringlichkeitsbit (Urgent) können Daten als vorrangig gekennzeichnet werden. Dadurch ist beispielsweise die bevorzugte Behandlung von CTRL-C (Abbruch) bei einer Terminalverbindung (TELNET) möglich.
Um Bandbreite zu sparen, wird auf der TCP Ebene meistens der Nagle-Algorithmus eingesetzt.
Problematik der Datenwiederholung
Die Wiederholung von Daten, für die noch keine Bestätigung empfangen wurde, ist nicht unproblematisch. Im Internet, in dem viele Netzwerke mit unterschiedlichen Eigenschaften verbunden werden, ist Datenverlust einzelner Pakete durchaus normal. Wird eine Verbindung stark belastet, werden immer mehr Pakete verworfen, die entsprechend wiederholt werden müssen. Durch die Wiederholung steigt wiederum die Belastung, ohne geeignete Maßnahmen kommt es zu einem Datenstau.
Die Verlustrate wird von einem IP-Netzwerk ständig beobachtet. Abhängig von der Verlustrate wird die Senderrate durch geeignete Algorithmen beeinflusst: Normalerweise wird eine TCP/IP-Verbindung langsam gestartet (Slow Start) und die Senderate schrittweise erhöht, bis es zum Datenverlust kommt. Ein Datenverlust verringert die Senderate, ohne Verlust wird sie wiederum erhöht. Insgesamt nähert sich die Datenrate so zunächst dem jeweiligen zur Verfügung stehenden Maximum und bleibt im Wesentlichen dann dort. Eine Überbelastung wird vermieden.
Literatur
- Craig Hunt: TCP/IP Netzwerk-Administration. O'Reilly, 2003, ISBN 3-89721-179-3
- Richard Stevens: TCP/IP Illustrated. Volume 1: The Protocols. Addison-Wesley, 1994, ISBN 0-2016-3346-9
- Richard Stevens: TCP/IP Illustrated. Volume 2: The Implementation. Addison-Wesley, 1994, ISBN 0-2016-3354-X
- Andrew S. Tanenbaum: Computernetzwerke. 4. Auflage. Pearson Studium, München 2003, ISBN 3-8273-7046-9 (Der relevante Teil ist ab S. 580ff)
- James F. Kurose, Keith W. Ross: Computernetze. Ein Top-Down-Ansatz mit Schwerpunkt Internet. Bafög-Ausgabe, Pearson Studium, München 2004, ISBN 3-8273-7150-3
- Michael Tischer, Bruno Jennrich: Internet Intern. Technik & Programmierung. Data-Becker, Düsseldorf 1997, ISBN 3-8158-1160-0
Weblinks
- RFC 793 - Transmission Control Protocol
- RFC 1122 - Fehlerbehebungen bei TCP
- RFC 1323 - Erweiterungen bei TCP
- RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery - Algorithmen der Flusskontrolle
- [http://citeseer.ist.psu.edu/593307.html Congestion Avoidance and Control] - TCP-Meilenstein 1988
- [http://www.multi-online.com/netzwerk/tcpip.php Netzwerk TCP/IP] - Die TCP/IP-Protokollfamilie
- [http://citeseer.ist.psu.edu/367499.html TCP Vegas] - TCP Meilenstein 1994
Kategorie:Netzwerkprotokoll
ja:Transmission Control Protocol
ko:TCP
User Datagram Protocol
Das User Datagram Protocol (UDP) ist ein minimales, verbindungsloses Netzprotokoll. Es gehört zur Transportschicht der TCP/IP-Protokollfamilie und ist im Gegensatz zu TCP nicht auf Zuverlässigkeit ausgelegt.
UDP erfüllt im Wesentlichen den Zweck, die durch die IP-Schicht hergestellte Endsystemverbindung um eine Anwendungsschnittstelle (Ports) zu erweitern. Diese Erweiterung der Host-zu-Host- auf eine Prozess-zu-Prozess-Übertragung wird als Anwendungsmultiplexen und -demultiplexen bezeichnet. UDP bietet auch eine Integritätsüberprüfung, indem Fehlererkennungsfelder in die Header einbezogen werden.
UDP-Datagramm
Das UDP-Paket wird zur Ãœbertragung in ein IP-Paket gekapselt. Neben dem eigentlichen UDP-Header besitzt das UDP-Datagramm noch einen sog. Pseudo-Header. Dieser Pseudo-Header ist virtuell er wird berechnet und ist nich Teil des Datagramms.
gekapselt
Header
Der UDP-Header besteht aus vier Headerfeldern, von denen zwei optional sind. Die Quell- und Ziel-Port Felder sind 16 Bit groß und identifizieren den sendenden und den empfangenden Prozess. Da UDP verbindungslos ist, ist der Quell-Port optional. Er wird dann auf 0 gesetzt. Den Portfeldern folgt das verbindliche Längenfeld, das die Größe der Daten und des Headers des UDP-Datagramms in Oktetten enthält. Der kleinstmögliche Wert sind 8 Oktette. Das letzte Headerfeld ist eine 16 Bit große Prüfsumme über den Header, den so genannten Pseudo-Header und den Daten. Die Prüfsumme ist auch optional, wird aber in der Praxis fast immer benutzt (falls nicht, wird sie ebenfalls auf 0 gesetzt).
Dem Header folgen anschließend die Nutzdaten.
Pseudo- Header
Prüfsumme
Für die Erzeugung der UDP-Prüfsumme gibt es den Pseudo-Header. Damit werden Teile des IP-Headers in die UDP-Prüfsumme übernommen. Er dient nur zur Erzeugung der Prüfsumme und wird nicht übertragen. Er hat eine Länge von 12 Byte und setzt sich zusammen aus IP-Quelladresse (32 Bit), IP-Ziel-Adresse (ebenfalls 32 Bit), 8 Bit Leerfeld, 8 Bit Protokoll-ID (UDP hat die ID 17) und der Länge des UDP-Datagramms (16 Bit).
Eigenschaften
Verbindungslos bedeutet, dass nicht erst eine Verbindung zum Gegenüber aufgebaut wird (mittels Handshaking wie bei TCP), sondern dass sofort die Daten zu der Gegenstelle geschickt werden. Es wird nicht garantiert, dass ein einmal gesendetes Paket ankommt oder dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden; eine Quittierung ist nicht vorgesehen. Die Kommunikationspartner können also nicht feststellen, ob Pakete verloren gingen oder wie lange sie verzögert wurden (Delay). Auch eine Vervielfältigung von Paketen kann auftreten. Eine Anwendung, die UDP nutzt, muss daher gegenüber verloren gegangenen und umsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmaßnahmen beinhalten.
Da vor Übertragungsbeginn nicht erst eine Verbindung aufgebaut werden muss, können die Hosts schneller mit dem Datenaustausch beginnen. Dies fällt vor allem bei Anwendungen ins Gewicht, bei denen nur kleine Datenmengen ausgetauscht werden müssen. Ein Beispiel hierzu ist das Domain Name System, das auf UDP aufsetzt: hier werden üblicherweise nur zwei Pakete ausgetauscht, ein Paket mit der Anfrage und eines mit der Antwort. Hierzu erst noch per Drei-Wege-Handshake eine Verbindung aufzubauen würde lediglich Overhead erzeugen. Daneben bietet die ungesicherte Übertragung auch den Vorteil von geringen Übertragungsverzögerungsschwankungen: geht bei einer TCP-Verbindung ein Paket verloren, so muss es erneut angefordert werden. Dies braucht Zeit, die Übertragungsdauer kann daher schwanken, was für Multimediaanwendungen schlecht ist. Bei VoIP z.B. würde es zu plötzlichen Aussetzern kommen bzw die Wiedergabepuffer müssten größer angelegt werden. Solche Anwendungen setzen daher auf UDP, verlorengeganene Pakete bringen hier nicht die gesamte Übertragung ins Stocken.
Weblinks
- RFC 768 - User Datagram Protocol
Siehe auch
UDPsec, Vorschlag einer Modifikation von UDP für verbesserte Sicherheit
Kategorie:Netzwerkprotokoll
ja:User Datagram Protocol
Transmission Control Protocol
Das Transmission Control Protocol (TCP) ist eine Vereinbarung (Protokoll) darüber, auf welche Art und Weise Daten zwischen Computern ausgetauscht werden sollen. Alle am Datenaustausch beteiligten Computer kennen diese Vereinbarungen und befolgen sie. Es ist damit ein zuverlässiges, verbindungsorientiertes Transportprotokoll in Computernetzwerken. Es ist Teil der TCP/IP-Protokollfamilie.
Entwickelt wurde TCP von Robert E. Kahn und Vinton G. Cerf. Ihre Forschungsarbeit, die sie im Jahre 1973 begannen, dauerte mehrere Jahre. Die erste Standardisierung von TCP erfolgte deshalb erst im Jahre 1981 als RFC 793.
TCP stellt einen virtuellen Kanal zwischen zwei Endpunkten einer Netzwerkverbindung (Sockets) her. Auf diesem Kanal können in beide Richtungen Daten übertragen werden. TCP setzt in den meisten Fällen auf das IP (Internet-Protokoll) auf. Es ist in Schicht 4 des OSI-Referenzmodells angesiedelt.
Verbindungsaufbau und Abbau
OSI-Referenzmodell
OSI-Referenzmodell
OSI-Referenzmodell
OSI-Referenzmodell
TCP ist im Prinzip eine Punkt-zu-Punkt-Verbindung in Vollduplex. Diese Verbindung kann in zwei Halbduplex-Verbindungen eingeteilt werden, wobei die Daten in Gegenrichtung zusätzliche Steuerungsinformationen enthalten.
Das Management dieser Verbindung sowie die Datenübertragung wird von der TCP-Software übernommen, siehe Abb. 1.
Die TCP-Software ist eine Funktionssammlung, zum Beispiel bei Windows in der Winsock.dll beziehungsweise wsock32.dll oder bei Linux im Kernel (je nach Betriebssystem unterschiedlich). Die Anwendung ist zum Beispiel ein Webbrowser oder ein Webserver (zum Beispiel Apache).
Jeder Endpunkt stellt ein Tupel bestehend aus IP-Adresse und Port
dar. Ports sind 16-Bit-Zahlen und reichen von 0 bis 65535. Ports von 0 bis 1023 sind reserviert (englisch: well known ports [http://www.iana.org/assignments/port-numbers]) und werden von der
IANA vergeben, z. B. ist Port 80 für das HTTP-Protokoll reserviert.
Allerdings ist das Benutzen der vordefinierten Ports trotzdem nicht bindend. So kann jeder Administrator einen FTP-Server (normalerweise Port 21) auch auf einem anderen Port laufen lassen.
Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte definiert. So ist es beispielsweise möglich, dass ein Webserver auf einem Port mehr als eine Verbindung zu einem anderen Rechner geöffnet haben kann.
Ein Webserver, der seinen Dienst anbietet, generiert einen Endpunkt mit dem Port und seiner Adresse (er kann auch beliebige Adressen zulassen). Dies wird als passive open bezeichnet.
Will ein Client eine Verbindung aufbauen, generiert er einen eigenen Endpunkt aus seiner Rechneradresse und einer noch freien Portnummer. Mit Hilfe eines ihm bekannten Ports und der Adresse des Servers kann dann eine Verbindung aufgebaut werden.
Während der Datenübertragungsphase (active open) sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch. Insbesondere kann jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten.
Während des Abbaus kann die Gegenseite noch Daten übertragen, die Verbindung kann also halb-offen sein.
Der Drei-Wege-Handshake
Beim Aufbau einer TCP-Verbindung kommt der so genannte Drei-Wege-Handshake zum Einsatz. Der Rechner, der die Verbindung initiieren will, sendet dem anderen ein SYN-Paket mit einer Sequenznummer x. Es handelt sich also um ein Paket, dessen SYN-Bit im Paketkopf gesetzt ist (siehe TCP-Header). Die initiale Sequenznummer ist beliebig und wird vom jeweiligen Betriebssystem festgelegt.
Die Gegenstelle (siehe Skizze) empfängt das Paket und sendet in einem eigenen syn-Paket im Gegenzug seine initiale Sequenznummer y, zugleich bestätigt sie den Erhalt des ersten SYN-Pakets, indem sie die Sequenznummer inkrementiert und x+1 im ACK-Teil des Headers zurückschickt.
Der Client bestätigt zuletzt den Erhalt des SYN/ACK-Pakets durch das Senden eines eigenen ACK-Pakets mit der Sequenznummer x+1 und dem ACK-Wert y+1. Die Verbindung ist damit aufgebaut.
1. SYN-SENT --> --> SYN-RECEIVED
2. ESTABLISHED <-- <-- SYN-RECEIVED
3. ESTABLISHED --> --> ESTABLISHED
Der geregelte Verbindungsabbau erfolgt ähnlich. Statt des SYN-Bits kommt das FIN-Bit zum Einsatz. Der Erhalt des Pakets wird wiederum mittels ACK bestätigt. Der Empfänger des FIN-Pakets sendet zuletzt seinerseits ein FIN-Paket, das ihm ebenfalls bestätigt wird.
Obwohl eigentlich vier Wege genutzt werden, handelt es sich beim Verbindungsabbau auch um einen Drei-Wege-Handshake, da die ACK- und FIN-Operationen vom Server zum Client als ein Weg gewertet werden. Zudem ist ein verkürztes Verfahren möglich, bei dem FIN und ACK genau wie beim Verbindungsaufbau im selben Paket untergebracht werden.
Aufbau des TCP-Headers
Betriebssystem
Das TCP-Segment besteht immer aus zwei Teilen – dem Header und der Nutzlast (Payload). Die Nutzlast enthält die zu übertragenden Daten, die wiederum Protokollinformationen der Anwendungsschicht wie HTTP oder FTP entsprechen können.
Den schematischen Aufbau des TCP-Headers kann man im Bild rechts sehen.
Die Werte werden in network byte order (big endian) angegeben.
Erläuterung
Source Port:
Gibt die Portnummer auf der Senderseite an.
Destination Port:
Gibt die Portnummer auf der Empfängerseite an.
Sequence Number:
Sequenznummer des ersten Daten-Oktetts (Byte) dieses TCP-Paketes oder die Initialisierungs-Sequenznummer falls das SYN-Flag gesetzt ist.
Nach der Datenübertragung dient sie zur Sortierung der TCP-Segmente, da diese in unterschiedlicher Reihenfolge beim Empfänger ankommen können.
Acknowledgment Number (Quittierungsnummer):
Sie gibt die Sequenznummer an, die der Sender dieses TCP-Segmentes als nächstes erwartet. Nur gültig, falls das ACK-Flag gesetzt ist.
Data Offset:
Länge des TCP-Headers in 32-Bit-Blöcken - ohne die Nutzdaten (Payload). Indiziert die Startadresse der Nutzdaten.
Reserved:
Das Reserved-Feld wird nicht verwendet und muss null sein.
Flags:
URG:
Ist das Urgent-Flag gesetzt, so werden die Daten auf die das Urgent Pointer-Feld zeigt sofort von der Anwendung bearbeitet. Dabei unterbricht die Anwendung alle anderen Aufgaben. Dieses Verfahren ist fern verwandt mit einem Softwareinterrupt. Dieses Flag kann zum Beispiel verwendet werden, um eine Anwendung auf dem Empfänger abzubrechen.
ACK:
Das Acknowledgment-Flag hat in Verbindung mit dem Acknowledgment-Feld folgende Aufgaben. Einmal dient es in Verbindung mit dem ACK- und SYN-Flag zur Bestätigung beim 3 Way-Handshake und zur Bestätigung von TCP-Segmenten beim Datentransfer.
Das Acknowledgment-Feld ist nicht gültig, wenn das Flag nicht gesetzt ist.
PSH:
Das Push-Flag hat die Aufgabe die Daten unter Umgehung des Buffers sofort an die Anwendung weiterzuleiten. Hilfreich ist dies, wenn man zum Beispiel bei einer Telnet-Sitzung einen Befehl an den Empfänger senden will. Würde dieser Befehl ersteinmal im Buffer zwischengespeichert, so würde dieser erst (stark) verzögert abgearbeitet.
RST:
Das Reset-Flag wird verwendet, wenn eine Verbindung abgebrochen werden soll. Dies geschieht zum Beispiel bei technischen Problemen oder zur Abweisung von unerwünschten Verbindungen.
SYN:
Pakete mit gesetztem SYN-Flag initiieren eine Verbindung, d.h. beginnen den 3-Wege-Handshake. Der Server antwortet normalerweise entweder mit SYN+ACK, wenn er bereit ist, die Verbindung anzunehmen, andernfalls mit RST. Dient der Synchronisation von Sequenznummern beim Verbindungsaufbau (daher die Bezeichnung SYN).
FIN:
Dieses Finish-Flag dient zur Freigabe der Verbindung und zeigt an, dass keine Daten mehr vom Sender kommen.
Die FIN- und SYN-Flags haben Sequenznummern, damit diese in der richtigen Reihenfolge abgearbeitet werden.
Window:
Ist die Anzahl der Daten-Oktetts (Bytes), beginnend bei dem durch das Acknowledgmentfeld indizierten Daten-Oktett, die der Sender dieses TCP-Paketes bereit ist zu empfangen.
Checksum:
Die Prüfsumme dient zur Erkennung von Übertragungsfehlern und wird über den Header und die Daten berechnet.
Urgent Pointer:
Ist ein Zeiger auf das Ende einer Sequenz mit dringenden Daten. Den Anfang der Sequenz muss die Anwendung selbst ermitteln.
Der Pointer ist nur gültig, falls das URG-Bit gesetzt ist.
Options:
Das Options-Feld ist unterschiedlich groß und enthält Zusatzinformationen. Die Optionen müssen ein Vielfaches von 32 Bit lang sein. Sind sie das nicht, muss mit Null-Bits aufgefüllt werden (Padding). Dieses Feld gibt die Möglichkeit Verbindungsdaten auszuhandeln, die nicht im TCP-Header enthalten sind. Wie zum Beispiel die Maximalgröße des Nutzdatenfeldes.
Datenübertragung
Prüfsumme
Über ein TCP-Segment können maximal 65495 Byte Nutzdaten bei darunterliegendem IPv4 und 65515 Byte bei IPv6 versandt werden. Dies errechnet sich so:
In das IPv4-Paket passen maximal 65515 Byte Nutzdaten (65535 Byte abzüglich 20 Byte IP-Header). In ein IPv6-Paket passen maximal 65535 Byte Nutzdaten.
Von diesem Wert müssen noch 20 Byte für den TCP-Header abgezogen werden.
In der Praxis ist das Nutzdatenfeld kleiner.
Bei Ethernet darf das Nutzdatenfeld zum Beispiel nur maximal 1500 Byte groß sein, deshalb kann
ein TCP-Segment nur maximal 1460 Byte (Maximum Segment Size MSS) transportieren (1500 Byte - 20 Byte - 20 Byte).
Empfänger und Sender einigen sich vor dem Datenaustausch über das Options-Feld auf die Größe der MSS.
Die Anwendung, die Daten versenden möchte, beispielsweise ein Webserver, legt zum Beispiel einen 10 Kilobyte großen Datenblock im Buffer ab.
Wie kann man mit einem 1460 Byte großen Nutzdatenfeld 10 Kilobyte Daten versenden?
Ganz einfach, man teilt die Daten auf (Segmentierung), fügt einen TCP-Header hinzu und versendet die TCP-Segmente. Im Buffer ist der Datenblock, dieser wird in 5 Segmente aufgeteilt (siehe Abb. 6). Jedes Segment erhält durch die TCP-Software einen TCP-Header. 3 TCP-Segmente wurden aktuell abgeschickt. Diese sind nicht geordnet, da im Internet jedes TCP-Segment einen anderen Weg nehmen und es dadurch zu Verzögerungen kommen kann. Damit die TCP-Software im Empfänger die Segmente wieder ordnen kann, ist jedes Byte "nummeriert" (die Bytes werden sozusagen gezählt). Bei der Zuordnung der Segmente wird die Sequenznummer herangezogen.
Der Empfänger muss TCP-Segmente, die einwandfrei (Checksumme ist in Ordnung) angekommen sind, bestätigen.
Maximum Segment Size
Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 (variiert) und einer Nutzdatenlänge von 1460 Byte an den Empfänger. Der Empfänger bestätigt es mit einem TCP-Header ohne Daten mit ACK=1461 und fordert damit das zweite TCP-Segment ab dem Byte Nummer 1461 beim Sender an. Dieser schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger. Dieser bestätigt es wieder mit einem ACK=2921 und so weiter. Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind. Empfängt er die TCP-Segmente 1,2,3,4,5 so braucht er nur das letzte TCP-Segment zu bestätigen.
Fehlt zum Beispiel das TCP-Segment 3 weil es verloren gegangen ist, so kann er nur die 1 und die 2 bestätigen 4 und 5 jedoch noch nicht. Da der Sender keine Bestätigung für die 3 bekommt läuft sein Timer ab und er verschickt die 3 noch einmal. Kommt die 3 beim Empfänger an, so bestätigt er alle 5 TCP-Segmente.
Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt einen Timer (RTT).
Flusssteuerung
RTT
Da die Anwendung Daten aus dem Buffer liest, ändert sich der Füllstand des Buffers ständig. Deshalb ist es notwendig den Datenfluss entsprechend dem Füllstand zu steuern. Dies geschieht mit dem Sliding Window und dessen Größe.
Den Buffer des Senders erweitern wir, wie in Abb. 8 zu sehen, auf 10 Segmente.
In der Abb. 8a werden gerade die Segmente 1-5 übertragen. Die Übertragung ist vergleichbar mit Abb. 7. Obwohl der Buffer des Empfängers in Abb. 7 am Ende voll ist, fordert er mit ACK=7301 die nächsten Daten ab dem Byte 7301 beim Sender an. Dies hat zur Folge, dass das nächste TCP-Segment vom Empfänger nicht mehr verarbeitet werden kann. Ausnahme sind jedoch TCP-Segmente mit gesetztem URG-Flag.
Mit dem Window-Feld kann er dem Sender mitteilen, dass er keine Daten mehr verschicken soll. Dies geschieht indem er im Window-Feld den Wert Null einträgt (Zero Window). Der Wert Null entspricht dem freien Speicherplatz im Buffer.
Die Anwendung des Empfängers liest nun die Segmente 1-5 aus dem Buffer, womit wieder ein Speicherplatz von 7300 Byte frei ist. Damit kann er die restlichen Segmente 6-10 mit einem TCP-Header, der die Werte SEQ=1, ACK=7301 und Window=7300 enthält, beim Sender anfordern. Der Sender weiß nun, dass er maximal 5 TCP-Segmente an den Empfänger schicken kann und verschiebt das Window um 5 Segmente nach rechts (siehe Abb. 8b).
Die Segmente 6-10 werden nun alle zusammen als Burst verschickt.
Kommen alle TCP-Segmente beim Empfänger an, so quittiert er sie mit SEQ=1 und ACK=14301 und fordert die nächsten Daten an.
Silly Window Syndrome:
Der Empfänger sendet ein Zero Window an den Sender, da sein Buffer voll ist.
Die Anwendung beim Empfänger liest allerdings nur zwei Byte aus dem Buffer. Der Empfänger schickt ein TCP-Header mit Window=2 (Window Update) an den Sender und fordert gleichzeitig die zwei Byte an. Der Sender kommt der Aufforderung nach und schickt die zwei Byte in einem 42 Byte großem Paket (mit IP-Header und TCP-Header) an den Empfänger. Damit ist der Buffer des Empfängers wieder voll und er schickt wieder ein Zero Window an den Sender. Die Anwendung liest jetzt zum Beispiel hundert Byte aus dem Buffer. Der Empfänger schickt wieder ein TCP-Header mit einem kleinem Window-Wert an den Sender. Dieses Spiel setzt sich immer wieder fort und verschwendet Bandbreite, da nur sehr kleine Pakete versandt werden.
Clarks Lösung ist, dass der Empfänger ein Zero Window senden und solange mit dem Window Update warten soll bis die Anwendung mindestens die Maximum Segmentsize (in unserem bisherigen Beispielen 1460 Byte) aus dem Buffer gelesen hat oder der Buffer halbleer ist. Je nachdem was zuerst eintritt (Dave Clark, 1982).
Auch der Sender kann zu kleine Pakete abschicken und dadurch Bandbreite verschwenden. Dieser Umstand wird mit dem Nagle-Algorithmus beseitigt. Deswegen ergänzt er sich mit Clarks Lösung.
Aufbau und Funktion des TCP Pseudo-Headers
Der Pseudo-Header wird zur Checksummenberechnung verwendet und dient daher zur Erhöhung der Zuverlässigkeit. Es ist dadurch auch möglich fehlgeleitete Pakete zu erkennen.
In die Berechnung fließen außerdem noch der TCP-Header und seine Nutzdaten (TCP-Segment) ein.
Bevor die TCP-Software ein TCP-Segment abschickt bildet sie einen Pseudo-Header aus der IP-Adresse des Senders und des Empfängers, sowie der TCP-Segment-Länge. Vor Berechnung der Checksumme wird das Checksummen-Feld im TCP-Header auf Null gesetzt und es wird dem Nutzdatenfeld ein Null-Byte angehängt, wenn die Länge eine ungerade Zahl ist.
Die Berechnung der Checksumme erfolgt durch Addition von 16 Bit-Werten im Einerkomplement. Aus der Summe wird nocheinmal das Einerkomplement gebildet.
Nach der Berechnung wird das 16 Bit-Ergebnis im TCP-Header abgelegt und das TCP-Segment abgeschickt.
Der Empfänger führt diese Berechnung nocheinmal unter Einbezug der Checksumme aus, wodurch das Ergebnis Null sein sollte.
Ist die Checksumme beim Empfang des TCP-Segmentes nicht Null, so wird es ohne Nachricht verworfen.
Dies hat zur Folge, dass der RTT-Timer beim Absender abläuft und das TCP-Segment nochmal abgeschickt wird.
Einerkomplement
Source IP Address:
IP-Adresse des Absenders.
Destination IP Address:
IP-Adresse des Empfängers.
000000:
Füllbits.
Protocol:
Hat immer den Wert Sechs für das TCP-Protokoll (siehe auch IP-Header).
TCP Length:
Länge des TCP-Segments in Bytes.
Datenintegrität und Zuverlässigkeit
Im Gegensatz zum verbindungslosen UDP implementiert TCP einen bidirektionalen, byte-orientierten, zuverlässigen Datenstrom zwischen zwei Endpunkten. Das darunterliegende Protokoll (IP) ist paketorientiert, wobei Datenpakete verlorengehen können, in verkehrter Reihenfolge ankommen dürfen und sogar doppelt empfangen werden können. TCP wurde entwickelt, um mit der Unsicherheit der darunter liegenden Schichten umzugehen. Es prüft daher die Integrität der Daten mittels der Prüfsumme im Paketkopf und stellt die Reihenfolge durch Sequenznummern sicher. Der Sender wiederholt das Senden von Paketen, falls keine Bestätigung innerhalb einer bestimmten Zeitspanne (Timeout) eintrifft. Die Daten der Pakete werden beim Empfänger in einem Puffer in der richtigen Reihenfolge zu einem Datenstrom zusammengefügt und doppelte Pakete verworfen.
Zu beachten ist, dass der Sender mittels TCP lediglich zuverlässig erfahren kann, ob der Empfang von Daten vom Empfänger korrekt quittiert wurde oder nicht.
Der Datentransfer kann selbstverständlich jederzeit nach dem "Aufbau einer Verbindung" gestört, verzögert oder ganz unterbrochen werden. Das Übertragungssystem läuft dann in einen Timeout. Der vorab getätigte "Verbindungsaufbau" stellt also keinerlei Gewähr für eine nachfolgende sichere Übertragung dar.
Bestätigungen
Die jeweilige Länge des Puffers, bis zu der keine Lücke im Datenstrom existiert, wird bestätigt (Windowing). Dadurch ist die Ausnutzung der Netzwerk-Bandbreite auch bei großen Strecken möglich. Bei einer Übersee- oder Satellitenverbindung dauert das Eintreffen des ersten Acknowledges (ACK) aus technischen Gründen bisweilen mehrere 100 ms, in dieser Zeit können unter Umständen mehrere hundert Pakete gesendet werden. Der Sender kann den Empfängerpuffer füllen, bevor die erste Bestätigung eintrifft. Alle Pakete im Puffer können gemeinsam bestätigt werden. Bestätigungen können zusätzlich zu den Daten in den TCP-Header des entgegengesetzten Datenstroms eingefügt werden (Piggybacking), falls der Empfänger ebenfalls Daten für den Sender bereithält.
Weitere Protokolleigenschaften
Über ein Dringlichkeitsbit (Urgent) können Daten als vorrangig gekennzeichnet werden. Dadurch ist beispielsweise die bevorzugte Behandlung von CTRL-C (Abbruch) bei einer Terminalverbindung (TELNET) möglich.
Um Bandbreite zu sparen, wird auf der TCP Ebene meistens der Nagle-Algorithmus eingesetzt.
Problematik der Datenwiederholung
Die Wiederholung von Daten, für die noch keine Bestätigung empfangen wurde, ist nicht unproblematisch. Im Internet, in dem viele Netzwerke mit unterschiedlichen Eigenschaften verbunden werden, ist Datenverlust einzelner Pakete durchaus normal. Wird eine Verbindung stark belastet, werden immer mehr Pakete verworfen, die entsprechend wiederholt werden müssen. Durch die Wiederholung steigt wiederum die Belastung, ohne geeignete Maßnahmen kommt es zu einem Datenstau.
Die Verlustrate wird von einem IP-Netzwerk ständig beobachtet. Abhängig von der Verlustrate wird die Senderrate durch geeignete Algorithmen beeinflusst: Normalerweise wird eine TCP/IP-Verbindung langsam gestartet (Slow Start) und die Senderate schrittweise erhöht, bis es zum Datenverlust kommt. Ein Datenverlust verringert die Senderate, ohne Verlust wird sie wiederum erhöht. Insgesamt nähert sich die Datenrate so zunächst dem jeweiligen zur Verfügung stehenden Maximum und bleibt im Wesentlichen dann dort. Eine Überbelastung wird vermieden.
Literatur
- Craig Hunt: TCP/IP Netzwerk-Administration. O'Reilly, 2003, ISBN 3-89721-179-3
- Richard Stevens: TCP/IP Illustrated. Volume 1: The Protocols. Addison-Wesley, 1994, ISBN 0-2016-3346-9
- Richard Stevens: TCP/IP Illustrated. Volume 2: The Implementation. Addison-Wesley, 1994, ISBN 0-2016-3354-X
- Andrew S. Tanenbaum: Computernetzwerke. 4. Auflage. Pearson Studium, München 2003, ISBN 3-8273-7046-9 (Der relevante Teil ist ab S. 580ff)
- James F. Kurose, Keith W. Ross: Computernetze. Ein Top-Down-Ansatz mit Schwerpunkt Internet. Bafög-Ausgabe, Pearson Studium, München 2004, ISBN 3-8273-7150-3
- Michael Tischer, Bruno Jennrich: Internet Intern. Technik & Programmierung. Data-Becker, Düsseldorf 1997, ISBN 3-8158-1160-0
Weblinks
- RFC 793 - Transmission Control Protocol
- RFC 1122 - Fehlerbehebungen bei TCP
- RFC 1323 - Erweiterungen bei TCP
- RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery - Algorithmen der Flusskontrolle
- [http://citeseer.ist.psu.edu/593307.html Congestion Avoidance and Control] - TCP-Meilenstein 1988
- [http://www.multi-online.com/netzwerk/tcpip.php Netzwerk TCP/IP] - Die TCP/IP-Protokollfamilie
- [http://citeseer.ist.psu.edu/367499.html TCP Vegas] - TCP Meilenstein 1994
Kategorie:Netzwerkprotokoll
ja:Transmission Control Protocol
ko:TCP
Kategorie:NetzwerkprotokollComputer und andere digitale Geräte verwenden zur Kommunikation Netzwerkprotokolle, um Daten über Telegramme auszutauschen. Ein Datentelegramm enthält dazu verschiedene Felder für Nachrichten und Steuerinformationen. Kommunikationsdienste erfüllen dazu Aufgaben wie zum Beispiel Auf- und Abbau der Kommunikationsübertragung.
Protokoll
Kategorie:Automatisierungstechnik
ja:Category:通信プãƒãƒˆã‚³ãƒ«
Falklands Islands Company LtdFalkland Islands Holdings Plc (FIH) is a company which plays a key role in the economy of the Falkland Islands. It is a British registered company, with its head office in the town of Bishop's Stortford in England, and an operational office in Stanley, the capital of the Falklands. It is a public company which is traded on the Alternative Investment Market (AIM) in London.
History
The company's key subsidiary, the Falkland Islands Company (FIC), was incorporated in 1851 and received its Royal Charter on 10 January 1852. Established with an authorised capital of £100,000 its purpose was to engage in agricultural and general trading activities. It established shops and a shipping line, and by 1945 it owned 1.2 million acres (4,900 km²) in the Falklands and a flock of 300,000 sheep. It first listed on the London Stock Exchange in 1962. In 1972 it was acquired by The Dundee Perth and London Shipping Company, and two further changes of ownership occurred before it became independent again as Falkland Islands Holdings in 1997. Meanwhile the agricultural holdings had been sold to the Falkland Islands Government in 1991. In 2004 FIH diversified by acquiring stakes in Falkland Gold and Minerals Limited (FGML) and Falkland Oil and Gas Limited (FOGL), which were both established to exploit potential mineral developments in the Falklands, and full ownership of the Portsmouth Harbour Ferry Company (PHFC) which operates the passenger ferry across the mouth of Portsmouth Harbour in England.
Current activities
Falkland Islands Company Limited (100% owned by FIH)
FIC's operations are small by the standards of a large country, but in the Falkland Islands, which have a population of around 3,000, they are crucial.
- Retail & Distribution: several outlets in Stanley and Mount Pleasant including a supermarket (featuring supplies from Waitrose), a gift shop, a home entertainment shop, a homecare centre, an office supplier, a building supplies company and a clothes shop. There is also a restaurant.
- Upland Goose Hotel: an 18 bedroom hotel which dates from the mid 19th century and was originally called the Eagle Inn.
- Darwin Shipping: the main shipping link between the Falkland Islands and the United Kingdom. FIC can also arrange coastal shipping and shipping to Chile, which is the nearest country to the Falklands excluding Argentina.
- Port services: cargo handling, warehousing, refuelling and maintenance.
- Automotive agency: a Land Rover dealership, a Caterpillar agency, and boat maintenance.
- Property: FIC owns residential property for let, as well as commercial units and development land.
- Insurance: a general insurance agency and a Lloyd's agency.
Falkland Gold and Minerals Limited (14.4% owned by FIH)
This company was established in 2004 and raised £10 million to prospect for gold and other minerals in the Falklands. It has the only mineral exploration licence on the islands, with rights to prospect almost all of the landmass.
Falkland Oil and Gas Limited (18.3% owned by FIH)
For many years there has been speculation that the waters around the islands may contain large reserves of oil and gas. Falkland Oil and Gas is carrying out seismic surveys across thousands of square miles of seabed, mainly to the south and east of the islands, and as of 2005 it hopes to start drilling in 2007. Falkland Oil and Gas is itself an AIM listed company.
Portsmouth Harbour Ferry Company plc (100% owned by FIH)
This company operates a ferry service between Portsmouth and Gosport, two large towns on the south coast of England which lie on adjacent peninsulas.
For the year ended 31 March 2005 Falkland Islands Holdings Plc's turnover was £12.754 million. Profits were £874,000 before tax and £592,000 after tax.
See also
- Economy of the Falkland Islands
External links
- [http://www.fihplc.com/index.php?section=0 Falkland Islands Holdings]
- [http://www.the-falkland-islands-co.com/?section=0 Falkland Islands Company]
- [http://www.fgml.com/default.aspx Falkland Gold and Minerals Limited]
- [http://www.fogl.com/ Falkland Oil and Gas]
- [http://www.gosportferry.co.uk/ Gosport Ferry Limited] - the ferry service operated by the Portsmouth Harbour Ferry Company
Category:Falkland Islands
Category:Service companies of the United Kingdom
online casinos Odzyskiwanie danych cheap holidays lanzarote narty we francji jednorêki bandyta
|
|
|
| :: RELATED NEWS :: |
Huronjärvi
]
Huronjärvi on yksi viidestä Pohjois-Amerikan Suuresta järvestä ja se erottaa Michiganin Ontariosta. Georgian Bay, järven itäisin osa, kuuluu kokonaan Kanadalle.
Huronjärven erottaa Michiganjärvestä kapea Mackinacsalm
|
Ukrainalaiset
Ukrainalaiset (vanh. nimitys vähävenäläiset) ovat itäslaavilainen kansa, johon luetaan 42-45 miljoonaa henkilöä. Ukrainalaiset puhuvat kielenään sekä ukrainaa että sille hyvin läheistä sukua olevaa venäjän kieltä. Uskonnoltaan pääosa ukrainalaisista on ortodokseja.
Ukrainalaisten jakautuminen valtioittain
-
Rodos on suurin Dodekanesian saarista Egeanmeren kaakkoisosassa Välimeressä. Kreikalle kuuluvan saaren pinta-ala on 1412 neliökilometriä, ja asukasluku 89 000 (2002). Saaren pÃ
|
Riitti
Riitti on uskonnollinen toimitus eli seremonia. Riitti voidaan suorittaa säännöllisesti tiettynä aikana (kalendaaririitti), yksilön elämässä tapahtuviin muutoksiin liittyvänä (siirtymäriitti) tai onnettomuuden kohdatessa (kriisiriitti).
Rituaali taas on säännönmukainen, tiettyä kaavaa noudattava toimitus, riitin vakiintunut toimitustapa. Esimerkkinä hautaus- tai kasterituaali.
Katso myös
- aikuistumisriitti
tietoa eri osaamistason omaaville ihmisille. Se voi olla laaja-alaista, kuten tietosanakirjat, tai jonkun tieteen tai tutkimuksen alan erikoistietoa.
Tietokirjoiksi kutsutaan kirjoja, joissa esitetyt asiat perustuvat tutkittuun tietoon, ovat siis totta. Tutkittua tietoa on monenlaista: ufoista ja uskonnoista tietotekniikkaan ja avaruustutkimukseen.
Eräs tietokirjojen luokitustapa on se, jota kirjastot käyttävät:
- 0 Yleisteokset. Kirja-ala. Kirjastoto
|
Kai Hansen
]
Kai Hansen (syntynyt 1963) on tunnettu ja arvostettu eurooppalainen muusikko. Hän oli vuonna 1984 yksi suositun power metal-yhtye Helloweenin perustajista. Hansen toimi Helloweenissä aluksi laulajana ja kitaristina, mutta hänellä oli vaikeuksia laulaa ja soittaa kitaraa samaan aikaan. Niinpä yhtyee
|
Michael Weikath
]
Michael Weikath (syntynyt 1962) on eurooppalainen muusikko. Hän oli vuonna 1984 yksi power metal-yhtye Helloweenin perustajista. Weikath on soittanut Helloweenissä kitaraa koko yhtyeen historian ajan. Hän aloitti kitaran soittamisen 12-vuotiaana.
Hän on myös tehnyt useita kappaleja, tunnetuim
|
Riittiä
Riitti on uskonnollinen toimitus eli seremonia. Riitti voidaan suorittaa säännöllisesti tiettynä aikana (kalendaaririitti), yksilön elämässä tapahtuviin muutoksiin liittyvänä (siirtymäriitti) tai onnettomuuden kohdatessa (kriisiriitti).
Rituaali taas on säännönmukainen, tiettyä kaavaa noudattava toimitus, riitin vakiintunut toimitustapa. Esimerkkinä hautaus- tai kasterituaali.
Katso myös
- aikuistumisriitti
| |
